Fraud-signal sharing
A domain protocol for comparing patterns and exchanging fraud signals without sharing the underlying data.
The fraud-signal sharing protocol lets independent parties compare patterns and exchange fraud signals without sharing the underlying data behind them. Each party derives an irreversible, deterministic fingerprint from an underlying attribute and submits only the fingerprint, never the attribute. Two parties holding the same underlying fact produce the same fingerprint, so a common signal can be established without either party learning what the other holds.
This overview orients and links; the normative rules live in the versioned specification.
The outcome it delivers
A bank, a payment service, and a delivery firm can each hold a fragment of the same fraud pattern, none of them permitted to share the personal data behind it. This protocol lets them establish a common signal and route it to one authorised recipient without any of them disclosing a record. Records never leave a party's environment; only irreversible fingerprints are compared, and only a threshold-gated match reaches a single mandated receiver.
Shared dependencies
This domain protocol adds no base-layer mechanism of its own. It builds on the shared layer and reuses, as clickable descents:
- The base protocol for data sharing: the record shape, per-field encryption, anchoring, verification, and identity.
- Exchange patterns: it configures the request-response and cross-sector patterns.
- Runtime concepts it relies on directly: the envelope, keys and derivation, identity and delegation, addressing and discovery, and anchoring and the audit log.
Specification
The normative rules live in the versioned specification:
Use case
- Cross-sector fraud signals: the public-private explainer, with a copy-and-paste diagram.
Working group
This domain protocol is developed in an open working group. Sector coordinators, participating parties, and domain experts join to review the taxonomy, agree the domain parameters (the overlap threshold, the ciphersuite, and the key-custody model), and admit parties into an exchange.
Working-group members: pending consent. No participating party is named here yet. Member names and logos are published only with each party's written consent, and their absence is deliberate, not an omission. This section describes how participation works; it makes no claim that any named party is using the protocol in production. To take part, see Governance and working group.