Transaction monitoring for crypto and stablecoin flows

Crypto transaction monitoring works when the public ledger stops being a wall of hashes and starts resolving to your customers, their counterparties, and the specific reporting duties each transfer creates. The chain tells you what moved and where. It does not tell you who, why, or which obligation just fired. Building and reconciling that mapping is the whole job.

The mistake teams make on their first crypto build is treating on-chain data like a cleaner version of card rails. It is not. On-chain data is public and pseudonymous, structured for consensus rather than compliance. Everything you need is visible, and almost none of it is labelled. A monitoring system has to add three layers the chain leaves out: who controls an address, how that address behaves over time, and what your regulator expects you to do about it.

Start with attribution, and treat it as evidence

The ledger records a transfer between two addresses. Your obligation attaches to people and entities. Closing that gap is entity resolution against blockchain data, and it is where most of the analytical value sits.

You will lean on commercial chain-analytics feeds for the bulk of it, because labelling exchanges, mixers, bridges, gambling services, and sanctioned addresses at scale is a data-collection problem those vendors have already spent years on. What you own is the join: connecting a vendor’s cluster attribution to the deposit and withdrawal addresses you assigned your own customers. Get that join wrong and every downstream alert points at the wrong account.

A few things we insist on when wiring attribution in:

• Store the attribution you acted on, not just the current one. Vendor labels change as clusters get re-analysed. If an alert fired because an address was flagged as a sanctioned entity on the day of the transfer, your audit trail has to show that label as it stood then, with its provenance and confidence. Point-in-time correctness is what separates a defensible SAR from a guess.
• Keep lineage from raw transaction to enriched alert. When an examiner asks why you filed, you want to trace the alert back through the decoded transfer, the address attribution, the customer record, and the rule that triggered, without reconstructing anything by hand.
• Treat confidence as a field, not a footnote. Cluster attribution is probabilistic. A monitoring rule that treats a 60%-confidence mixer label the same as a 99%-confidence exchange label will drown you in noise.

Read the chain correctly before you reason about it

Stablecoin AML lives or dies on decoding. A USDC or USDT transfer moves no native value; it is a call to a token contract that emits a Transfer event. If your ingestion pipeline reads native value and ignores logs, you will miss the majority of stablecoin activity, or double-count it against the gas transaction. We have seen both.

Blockchain forensics also means understanding the shapes that hide intent:

• Peel chains, where value moves through a long sequence of addresses each shedding a small amount, designed to defeat naive hop-counting.
• Bridge and cross-chain movement, where a flow leaves one ledger and reappears on another. Monitoring that stops at the chain boundary loses the thread exactly where laundering wants it lost.
• Contract interactions with mixers, DEX routers, and privacy tools, which look like ordinary transfers unless you decode the destination.

Stablecoins add issuer mechanics you should ingest as signals. Circle and Tether can both freeze and blacklist addresses. When a counterparty your customer transacts with gets blacklisted by the issuer, that is a monitoring event in its own right, and it often lands before any vendor updates its labels. Redemptions to fiat are another discrete event: an off-ramp that has to reconcile against the customer’s bank record, because a redemption your books do not show is a reconciliation break worth investigating.

Behaviour matters as much as endpoints. Point-in-time features over an address history, dwell time between receipt and onward transfer, funding sources, exposure to high-risk services, tell you more than any single transaction. Build those in a feature store with the same discipline you would use for card fraud: no lookahead, no leakage of information that was not knowable at transaction time, and a documented eval set so you can measure whether a new rule actually catches typologies rather than just firing more.

Wire obligations in as first-class logic

The Travel Rule is where chain analytics meets regulation directly. When your customer sends crypto to another crypto-asset service provider, you owe the beneficiary provider originator and beneficiary information, and you expect the same coming back. The EU Transfer of Funds Regulation (Regulation (EU) 2023/1113) removed the de minimis threshold that card rails rely on: for provider-to-provider transfers the obligation applies at any amount, while transfers to or from a self-hosted wallet above EUR 1,000 trigger their own ownership-verification duty. Whether a counterparty is a hosted exchange or a self-hosted wallet decides which obligation fires, so that classification belongs in the core data model, not in an enrichment step bolted on later.

The practical failure mode is a monitoring system that generates alerts nobody can action because the obligation was not modelled. An alert that says “high-risk exposure” is a task. An alert that says “transfer to self-hosted wallet above threshold, Travel Rule counterparty data required, customer risk rating medium” is a decision an analyst can close. Encode the obligation, not just the risk score.

Two things keep the whole system honest over time. First, a false-positive budget agreed with the compliance team before you tune anything, so straight-through processing has a target rather than a vibe, and so nobody quietly loosens rules to clear a backlog. Second, drift monitoring on both the chain and your own book. New tokens, new bridges, new mixing techniques, and shifting customer behaviour all move the ground under a model that looked well-calibrated at launch. Re-check attribution coverage and alert precision every quarter-end at minimum, and keep the eval set current, because a crypto typology that mattered a year ago may be background noise now while three new ones went unlabelled.

None of this is exotic once you stop expecting the chain to hand you answers. It hands you a complete public record with nothing labelled. The engineering is in the labelling, the reconciliation back to your customers, and the obligations you wire in so that every alert a human sees is already tied to a decision they are equipped to make.