Guglielmo Anfossianfossi.systemsCoffee chat

Four Firebreaks Between a Mixer and an Exchange

Constraints, episode 16

Four Firebreaks Between a Mixer and an Exchange

A deposit reaches an exchange from a private wallet. Screening asks the only question it can ask at that moment: where did this come from? It looks back one hop and finds another exchange, a regulated venue that funded the wallet minutes earlier. The deposit is credited.

Look further back and the answer changes. Before that exchange, a service operating inside it. Before that, another private wallet. Before that, a bridge out of an obscure chain, and a bridge into it. At the start, a mixer.

A firebreak is a strip of cleared ground a fire cannot cross. In laundering, it is a point attribution cannot cross: whatever goes in, what comes out carries the name of the place, not its past. The pattern I keep meeting puts several of them in a row, with unhosted wallets between them. None of them is there by chance. Each one is chosen for what it does to the risk score of an exchange that, at the end of the path, will check the source of the funds.

What a source-of-funds check reads

This is about the inbound side. When value arrives at an exchange, the first question compliance asks is where it came from.

Exchanges do not investigate every deposit. First they score it. A screening tool looks back from the deposit address and builds a risk score from the exposure it can attribute: which known services the funds came from, directly or through intermediate wallets, and in what share. Above certain thresholds, the deposit is held for review. Below them, it is credited. At an exchange’s volume, a manual investigation behind every deposit is not possible, so screening has to work as a filter.

The filter has a structural limit, and it is not the one people assume. The best tools are very capable. They follow indirect exposure back through long chains of unhosted wallets, decode swaps, DeFi protocols and the major bridges, and group addresses into the entities that control them. But a recognised service still acts as a boundary. Looking back from a deposit, a tool can see that the funds came out of a service. It cannot reliably see what went into that service on behalf of the same customer. Provenance does not disappear at the boundary. On-chain attribution stops there.

People who launder at scale know this limit as well as the vendors who build the tools. The path below is designed backwards from the receiving exchange’s check. At every step, the question is the same: when the last tool looks back, what will it find, and will it accept it?

The unhosted wallets in between

A transfer between two exchanges falls under the Travel Rule: the providers exchange originator and beneficiary data. A mule can sit on both ends of that transfer and the data will be accurate. The unhosted wallets between services do a different job. Each one adds a hop with no counterparty provider, where the only information comes from whoever controls the wallet, and pushes every service one step further from the next.

The starting point: the mixer

The path starts with the loudest signal a source-of-funds check can find. Mixer exposure is one of the heaviest weights in any risk model. A deposit that traces back to a mixer, directly or within a few hops, is the deposit most exchanges will stop.

So the mixer’s output is never deposited. Everything that follows exists to put enough boundaries between the mixer and the exchange that, looking back, the tool never reaches it.

The first firebreak: the bridge in

Value leaving the mixer goes into a bridge to an exotic chain: one with little liquidity, few users, and thin coverage from analytics vendors. The choice of chain matters more than the choice of bridge. A popular chain is well indexed. An obscure one may be partly indexed, indexed late, or not covered at all.

On the exotic chain, the funds start again as the output of a bridge. Any tool that can see this chain, if it can see it at all, finds a bridge where the mixer used to be.

The second firebreak: the bridge out

The funds do not stay on the exotic chain. They leave through a second bridge, back to a major chain where exchanges take deposits, and land at a fresh unhosted address.

This is where the design pays off. A tool looking back from that address finds the bridge out. To go further, it has to follow the bridge’s records into the exotic chain, trace the funds there, and cross the bridge in back to the mixer. If the exotic chain is poorly covered, the trail stops at the bridge out. The tool scores what it can see: shared infrastructure that honest users touch every day.

Bridge in and bridge out are not redundancy. They wrap the mixer inside a chain that screening cannot read well. In economic terms, the value has gone nowhere. What changed is everything the score can read.

The third firebreak: the nested service

From that unhosted address, the funds go to a service that lives inside a larger exchange.

A nested service is a broker, OTC desk or small exchange with no on-chain presence of its own. It works through accounts it holds at a larger host exchange. Its customers deposit to addresses that, on chain, belong to the host. When the host screens incoming funds, the customer it sees is one: the nested service. It does not see the many customers behind it, because their onboarding, if any happened, took place somewhere the host cannot inspect. Nested services tend to sit at the edge of regulation: many hold no licence where they operate and apply no Travel Rule of their own. In my view, this is one of the biggest problems in the system. The host answers for the nested service. The nested service answers for its customers. When the nested service does not do its part, no one answers for the people actually moving the money.

This is a firebreak in its own right, and a different kind from the bridges. The bridges break the chain trail. The nested service breaks the customer trail. Whatever information the host records about the flow, it describes the host’s customer: the nested service, not the person whose money it is.

When the funds leave, they leave from the host’s wallets to another unhosted address. From now on, anyone looking back from the next deposit finds the host, a regulated venue, and stops.

It is not a fringe mechanism. Chainalysis found that much of the illicit value reaching exchanges goes to a small group of deposit addresses, many of them nested services, and FinCEN’s order against Bitzlato targeted exactly this kind of venue.

The fourth firebreak: the mule account

The funds leave that unhosted address and arrive at a second exchange, into an account that passed KYC. The passport is real, the selfie matches, the address checks out.

The account belongs to a money mule. Sometimes it is a student paid a few hundred euros to open it and hand over the credentials. Sometimes it is someone who answered a “remote payments assistant” job offer. Sometimes it is a stolen or bought identity. Account renting has become a market of its own, and Europol’s yearly European Money Mule Action keeps finding the same profile: real people, verified accounts, money that was never theirs.

The mule is the firebreak on the identity side. KYC answers whether this person is who they say they are. It does not answer whether the funds belong to them.

Clean between two exchanges

Now follow the check backwards, the way the second exchange runs it. The deposit came from a self-hosted wallet controlled by a verified customer. One hop behind that wallet is the host exchange: regulated, low risk. Behind the host is a nested service, which the tool cannot see past. Behind the nested service is another unhosted wallet, then a bridge out, which the tool may see as infrastructure. Behind the bridge out is an exotic chain the tool barely reads. The mixer is at the far end, beyond every boundary.

No check was skipped. The risk score read the exposure it could attribute. KYC verified the identity in front of it. Each source was chosen to be something its check already trusts. The laundering does not happen inside any one control. It happens in the boundaries between them. Between two exchanges the funds look clean because each exchange is, in effect, vouching for the other, and the account at the end is vouching for a person who is not in the story.

Time helps the launderer twice. The first delay comes before any check runs: a score can only weigh what has already been labelled. Between an incident, its attribution by investigators, and the label reaching a vendor’s clients, there is a window. Funds that complete the path inside that window are scored against a picture that does not yet contain them. When the label arrives, a re-screen may raise an alert on a deposit whose funds left days ago.

The second delay is the one compliance teams know well. By the time anyone asks the host exchange about the withdrawal, the funds are long gone, and the mule has already cashed out.

What gets across

Flags do not travel forward with the funds, and a source-of-funds check cannot pull them back across a boundary. A label on a mixer output does not follow the value through a bridge into an exotic chain. It does not survive a pooled wallet. It does not see through a nested service to the customer behind it, or through a verified identity to the person who rented it out.

Reconstruction works because each firebreak keeps records. The bridges’ records, where they exist, link what came in to what went out through amounts, timing and destination. The exotic chain is still a public ledger, even if no vendor indexes it well: it can be read directly. The host exchange knows which sub-account of the nested service received the funds and which withdrawal sent them on, and can ask the nested service to identify its customer. The second exchange holds the mule’s KYC, device data, logins and withdrawal destinations, and these often point to the same operator behind dozens of “different” customers. None of these records sits in a screening tool. All of them survive the laundering.

The work is joining what each control saw on its own. None of them was wrong. None of them was asked about the whole source, and the path was designed so that none of them would be.

The funds were never clean. They only looked clean between two exchanges.

Also published on LinkedIn.