Share · Exchange, groups & MSSP
One sensor meets the attacker. Once corroborated, every tenant gets the block.
Instances contribute what their sensors saw and receive what everyone else’s did, signed, gated by allowlists and counted for poisoning. Vetted sharing groups let the banks of one country, and their central bank as a reader, share mule accounts and scam numbers at TLP:AMBER. Your payment system can ask whether a payee is known before the money moves.
Collective immunity
How the exchange stays honest.
ECDSA-signed
Signed contributions
Every contribution is signed by the instance; the receiving side verifies before it reads.
give-to-get
Feed keys earned by contributing
An instance’s feed key is maintained by what it gives. Silent consumers lose access on the next maintenance pass.
sector
Sector scoping
The hive operator assigns each instance its sector (a contributor cannot claim one), and sector collections carry what is relevant to that sector, not everything to everyone.
allowlist gate
Nothing you allowlisted comes in
Received observations are checked against the tenant allowlist before they touch the graph.
rejected · allowlist collisions
Poisoning counters
Per contributor, the platform counts rejected and allowlist-colliding observations. A contributor that keeps hitting allowlists is visible, and can be cut.
Redistributable
Only what may be shared
The community feed carries only redistributable data: a feed you licensed for internal use never leaks through the hive. Group data never enters it.
Sector sharing groups
A vetted community, with the paperwork done.
A sharing group is a named set of participants on a hive: the banks of one country, a banking group’s subsidiaries, a national CERT’s constituency. The hive operator admits members after verifying them out of band and recording their acceptance of the group’s terms. Any deployment can play the hive: the vendor can host it, or a central bank can run its own.
| distribution | who receives | TLP ceiling | promoted on |
|---|---|---|---|
| group | Current members of the named groups | TLP:AMBER | One accountable contribution from a vetted member |
| community | Every enabled participant | TLP:GREEN | Consensus of two instances, or one highly graded |
| public | Redistributable exports | TLP:CLEAR | As community, and redistributable only |
Inside a vetted group the contributor is accountable by name under signed terms, so one bank’s report of a mule account is enough; waiting for a second victim defeats the purpose.
member · steward · reader
Roles
Members contribute and receive; a steward can retract any observation in the group; a reader (a central bank, a CERT) consumes and never contributes.
tlp · distribution · reasons · expiry
Per-observable labels
Each observation carries its TLP, distribution, closed reason codes (mule, scam payee, smishing, fake app…) and an expiry. A label naming a group you are not in is dropped, never sent.
attributed · anonymised
Contribution identity
Each group decides whether deliveries name the contributing institution or only the group.
MISP sharing groups
MISP push and pull
A member’s existing MISP pushes to and pulls from the group over the MISP REST API, mapped to a MISP sharing group. No second tool to run.
TAXII 2.1 inbox
Contribute in STIX
A member whose product speaks TAXII posts a STIX 2.1 bundle into the group’s collection and reads it back from there.
revoke · expire
Retraction and expiry
A retraction reaches every member, who expire the indicator rather than delete it; membership is checked at every delivery, so a removed member stops receiving at the next pull or push.
DORA Art. 45
The membership notice, generated
Group terms are hashed and accepted per member. The notice a member gives its competent authority on joining an information-sharing arrangement is rendered in English and Montenegrin, drafted for counsel, not instead of counsel.
containment
Group data stays in the group
A group delivery is stamped AMBER and not redistributable on arrival. It reaches your own blocklists and fraud engine, never the community or public feeds, and is never re-shared.
Payee-risk lookup
Is this payee known? Asked before the transfer settles.
Your payment system asks by IBAN or phone number, one at a time or up to 100 in a batch, and gets back whether it is known, the reasons, a confidence and a severity, never which bank contributed it. The key it uses carries an isolated fraud:lookup scope that can do nothing else, and an admin key does not include it. Every known answer is recorded as a sighting, which is how the group learns a mule account is still active. The lookup answers whether a payee is known; your fraud engine decides what to do.
GET /api/fraud/payee/ME25505000012345678951
{
"known": true,
"reasons": ["mule"],
"confidence": 80,
"severity": "high",
"firstSeen": "2026-10-12",
"lastSeen": "2026-11-06",
"sourceCount": 2,
"groups": ["me-banks"]
}The first-party feed, graded
A scorecard you can hold us to.
A daily job grades the platform’s own first-party feed (corroboration, uniqueness, allowlist collisions) from its own data, with nobody editing the result. Give-to-get keys, sector scoping and poisoning counters keep the exchange honest.
The values shown are a sample. They will be replaced by the real figures when the public scorecard goes live.
How the scorecard works- Corroboration62%
share of mature exchange observables reported independently by at least two instances
- Uniqueness37%
share of the feed with no evidence from any third-party feed the deployment ingests
- Allowlist collisions0.4%
share of the feed that matches the allowlist (lower is better)
The first-party feed
Your sensors’ intelligence as a product with a receipt.
feed selector
Selectable on every export path
Blocklists, STIX, MISP and TAXII all take a feed selector; the first-party feed is what your own sensors evidenced plus what the exchange promoted, never third-party feed content or sharing-group deliveries.
TAXII collection
Its own collection
A dedicated TAXII 2.1 collection plus sector and group collections, behind the collection access policy and feed tiers.
daily snapshot
A scorecard, computed daily
Corroboration, uniqueness and allowlist collisions computed every day with history: the numbers you can publish to the people who consume the feed.
tiers
Tiers with a meter
Feed tiers on API keys, with usage metered per key.
MSSP console
Every client from one console, and a report for each.
Client tenants, cross-tenant roll-ups through the API only, protected asset groups per client, and scheduled branded reports (with Advanced AI Intelligence, attribution, targeting-by-country and exclusive intelligence) rendered to PDF and delivered by e-mail or webhook. Multi-tenant and provider licensing is by arrangement, through the partner programme.
| tenant | enforced | sightings | exclusive | report |
|---|---|---|---|---|
| client-01 | 412 | 63 | 11 | sent |
| client-02 | 388 | 41 | 7 | sent |
| client-03 | 295 | 22 | 4 | sent |
| client-04 | 511 | 90 | 19 | sent |
| client-05 | 173 | 12 | 2 | sent |
| client-06 | 244 | 35 | 6 | sent |
Bring the sector to one table.
We will stand up a hive with two member tenants and a reader, share a mule account between them at TLP:AMBER and answer a payee lookup, in one session.