Fraud signals

A fraudster opens an account at a bank, pays through a payment service, and takes delivery through a logistics firm. Each company sees one ordinary-looking fragment. Put together, the fragments show a coordinated fraud, but putting them together has normally meant one thing: somebody hands over customer data.

This exchange lets the pattern surface without the data moving. Each organisation turns a fact into a scrambled code that cannot be reversed. The codes are compared, never the facts. Only when several organisations independently show the same code does an alert exist at all, and that alert goes to exactly one authorised receiver.

The exchange in five steps

1. Each organisation keeps its records at home. Nothing is uploaded to a shared database.
2. A fact, say an account number or a delivery address, becomes a scrambled code. The same fact gives the same code, and a code reveals nothing about the fact behind it. The scrambling key is held by a separate role, so no single organisation can run guesses against it on its own.
3. Codes are compared, facts are not. A sector coordinator does the comparing: it sees codes from all sides, never the records behind them, and holding codes is not like holding a copy of everyone's data, because a code reveals nothing about the fact it came from.
4. An alert exists only above a threshold. One match means nothing; several organisations showing the same code, under agreed rules, triggers a single alert to one authorised receiver, and no organisation is told whether its own code was part of the match.
5. A public log records that the exchange happened. Anyone can verify that a match signal was sent and when, never what was compared.

An alert is a reason to investigate, not proof of fraud: a shared code can also come from a coincidence. The specification behind this is a draft under technical review, and any sector exploring the exchange does so as a pilot; nothing here describes a live service.

The problem, from the domain

Fraud rarely stays inside one sector. To see the pattern together, the parties would have to compare records, and comparing records normally means handing customer data to each other or to a central body.

The common answer today

The common answer is a central shared fraud list or clearing-house. Every party hands its records to one trusted holder, which stores them and answers questions against them. This works, and it carries two costs. It concentrates every party's records in a single store that becomes a concentrated target and a single point of breach. And it forces each party to disclose its records to the holder, whether or not a match ever exists. This is a structural contrast between two ways of answering the same need, not a claim against any specific deployment.

How adoption starts

A sector does not need to begin with record-level comparison. Early participants typically start with the signals that are simplest to agree on: descriptions of modus operandi (typified fraud patterns, in a vocabulary the working group agrees) and the interventions that proved effective against them. Those qualitative signals move through the same three roles, under the same moderation, on the same base protocol. As participation and agreements mature, the same working group can switch on real-time fingerprint comparison for record-level signals. Nothing is rebuilt in that transition: the roles, the audit trail, and the protocol stay the same, and the exchange grows from shared descriptions to shared detection.

How it works technically

Parties compare irreversible fingerprints of facts they never share, so a shared fraud pattern can be recognised without anyone disclosing the underlying records. A single match signal moves only once enough parties independently show the same fingerprint, and it goes to just one mandated receiver, so no single party ever holds everyone's data.

This fraud-signals taxonomy is a domain taxonomy on the base protocol. Under it, records never leave a party's own environment.

A party derives an irreversible fingerprint from a fact using an oblivious pseudorandom function, the open standard RFC 9497. The key that computes fingerprints is held by a role separate from the participating parties, so no party can enumerate candidate facts offline. The same fact always yields the same fingerprint, and a fingerprint reveals nothing about the fact it came from. Parties compare fingerprints rather than data. Only when a comparison crosses an agreed threshold does a match signal move, and it moves only to one mandated receiver. No single party ever sees everyone's data. A match is a signal to investigate, not proof of fraud: a shared fingerprint can reflect a coincidence or a benign shared attribute.

Moderation runs in three layers. Participating parties exchange fingerprints (layer 1). Sector coordinators act as moderators and admit parties to working groups (layer 2). One mandated receiver takes the gated signal (layer 3). All roles are functional, and example parties are generic: a bank, a payment service, a delivery firm.

The public audit layer records that an exchange happened, never what was exchanged. It gives evidence the process ran without becoming a store of the facts themselves.

Exchange patterns

Two patterns carry the traffic. The request-response pattern returns a bounded match or no-match answer to a single question. The cross-sector pattern adds sector-coordinator mediation and working-group admission, so parties in different sectors can take part under agreed rules.

Relationship to clean rooms

A data clean room, or secure multi-party compute, answers a bounded batch research question inside a controlled environment. This taxonomy does something different and complementary. It establishes a common signal in a continuing stream of activity and anchors that the exchange happened. The two are not rivals. A clean room suits a one-off analytical question; this suits an ongoing signal that several parties need to recognise as it forms.

Where to go deeper

• The normative rules: the fraud-signals spec.
• The exchange patterns: request-response and cross-sector.
• Common questions: the FAQ.