# Exchange, sharing groups & MSSP > Threat intelligence sharing between instances and sector groups: signed contributions, poisoning counters, TLP:AMBER groups, MISP, TAXII, MSSP console. Source: https://wahukeza.com/platform/exchange 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"\] } Illustrative response. Rate-limited per key; a daily count per key is audited. 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](https://wahukeza.com/scorecard) first-party feed · qualitysample values · not live - 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. [For MSSPs & MDR providers](https://wahukeza.com/solutions/mssp) mssp · roll-up · 6 tenantslast 30 days | 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 | Illustrative roll-up. ## 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. [Book a demo](https://wahukeza.com/contact?intent=demo) [Ask for a quote](https://wahukeza.com/contact?intent=quote)