The Four Rules That Bind Crypto Compliance

Crypto compliance is not a single rulebook. For a regulated crypto business it resolves to four distinct obligations that each carry their own legal source and their own evidence requirement: identify your customers, monitor their transactions, screen against sanctions lists, and report what the law requires you to report. Miss any one of the four and the other three do not save you.

Three of these four obligations predate crypto entirely. They come from anti money laundering law written for banks. What crypto changes is the evidence. The proof that you met each obligation now lives on a public ledger, which is both easier to inspect and harder to standardize than a bank's internal records.

Key takeaways

• Crypto compliance for a regulated business rests on four obligations: customer identification (KYC), transaction monitoring, sanctions screening, and regulatory reporting.
• These obligations derive from established authorities, chiefly FinCEN guidance in the US, OFAC sanctions rules, and the FATF standards adopted globally.
• The onchain evidence that satisfies each obligation is different: a wallet address is not a customer identity, and a clean address today can be tainted tomorrow.
• Sanctions screening is strict liability. Under OFAC there is no requirement that you intended to transact with a blocked party.
• The hardest technical problem is not finding suspicious activity, it is resolving the same transfer to the same fields across dozens of chains so a monitoring rule fires consistently.

Why the four obligations are converging now

Two things are happening at once. Stablecoin settlement activity has grown large enough to be macro-relevant, and regulators are writing crypto-specific rules rather than stretching old ones. Issuers now compete partly on compliance posture. When Circle's USDC gained share against Tether's USDT, part of the story was regulatory transparency and the ability to freeze illicit funds, a dynamic we covered in USDC overtakes USDT.

On the legislative side, US efforts like the proposed CLARITY Act would assign clearer jurisdiction over digital assets. As we argued in why CLARITY Act compliance is a data infrastructure problem, the practical burden of any new framework lands on the data teams who have to produce the evidence, not just the legal teams who read the statute.

Obligation one: know who your customer is

Customer identification, usually called Know Your Customer or KYC, requires a covered business to verify who it is dealing with before providing service. In the US this flows from Bank Secrecy Act obligations that FinCEN applies to money services businesses, a category that includes many crypto exchanges and administrators per FinCEN's 2013 guidance.

The onchain wrinkle is that a blockchain address is pseudonymous. It proves that a key signed a transaction. It does not prove who holds the key. KYC bridges that gap at the point of onboarding by tying a verified real-world identity to the addresses a customer deposits from and withdraws to. Everything downstream, monitoring and screening, depends on that link being sound.

Why you should care

Before: a withdrawal to an unknown address is just a hash. After: that address is attached to a verified customer, so if it later appears in an investigation you can respond in hours instead of reconstructing identity from scratch.

Obligation two: monitor transactions for the abnormal

Transaction monitoring is the ongoing obligation to watch customer activity for patterns that suggest money laundering, structuring, or fraud, and to file a Suspicious Activity Report when the threshold is met. FinCEN's SAR framework applies to money services businesses, and the FATF virtual asset guidance extends the risk-based approach to virtual asset service providers worldwide.

Monitoring onchain differs from monitoring a bank ledger. The full transaction graph is public, so you can trace funds several hops back to a mixer, a sanctioned entity, or a known exploit. But you can also be flooded with false positives, because a public address touches counterparties its owner never chose. A good program tunes its rules to the risk it actually faces rather than alerting on every hop.

Obligation three: screen against sanctions, with no room for intent

Sanctions screening checks every counterparty against lists maintained by authorities, chiefly OFAC's Specially Designated Nationals list, which now includes specific crypto wallet addresses. The critical fact, stated plainly in OFAC's virtual currency FAQs, is that these prohibitions are strict liability. A US person can violate sanctions without knowing the counterparty was blocked.

That changes the engineering requirement. Screening cannot be a nightly batch job. A blocked address can be added mid-day, and value can move onchain in seconds. Screening has to run against current list state at the moment value moves, and it has to catch not just the listed address but funds that flowed through it.

Obligation four: report what the law requires

Regulatory reporting is the obligation to file specific documents with authorities: Suspicious Activity Reports, Currency Transaction Reports above threshold, and jurisdiction-specific returns. The FATF Travel Rule adds a further requirement that VASPs transmit originator and beneficiary information alongside qualifying transfers, described in the FATF guidance. Reporting is where the other three obligations get audited, because a regulator reviewing a filing will ask for the underlying evidence.

Mapping each obligation to the onchain evidence it needs

Each obligation maps to a specific type of onchain evidence, the primary authority behind it, and the failure mode when the evidence is missing or wrong.

The field-level problem underneath all four

Every row of that table depends on the same primitive: a transfer that resolves cleanly to a consistent set of fields. Asset, issuer, sender, recipient, amount, USD value, and transaction type. On a single chain that is tractable. Across the many chains a real business touches, it is the hard part.

A USDC transfer on Ethereum, a USDC transfer on Solana, and a bridged USDC transfer on an L2 are the same economic event, but they arrive as different raw structures, different token contract standards, different decimals, and different event logs. A sanctions rule or a monitoring alert that fires reliably on Ethereum can silently miss the same activity on another chain if the fields do not line up. That gap is where compliance programs break, not in the policy but in the plumbing.

Resolving that requires normalizing raw records from every chain into the same schema so the same transfer means the same thing everywhere. This is the data infrastructure layer Allium works on, ingesting raw data from many blockchains and standardizing it into consistent asset, sender, recipient, amount and USD-value fields. For teams building on top, the difference between checklist compliance and real risk understanding often comes down to this data foundation, a theme we develop in the missing data foundation in crypto compliance stacks.

Compliance versus intelligence

Meeting the four obligations is the floor. It tells a regulator you followed the process. It does not tell you whether a given counterparty is actually risky, because a checklist confirms a box was ticked, not that the underlying risk was understood. The distinction between satisfying a rule and understanding exposure is worth reading in full in compliance vs intelligence in crypto, and it shapes how mature teams choose their blockchain intelligence platforms.

Risks and open questions

Several tensions remain genuinely unsettled. Privacy tools and self-custody mean not every counterparty can be attributed, and regulators have not fully resolved how far a business must trace before it has done enough. Cross-chain bridges complicate fund tracing because value can leave the traceable graph and re-emerge with a broken lineage. Definitions differ across jurisdictions, so a transfer that clears one regulator's rules may fail another's. And the SDN list changes without warning, which means a program that was compliant this morning can be exposed by an afternoon designation. None of these have clean answers yet, and any vendor claiming otherwise is overselling.

What good looks like in practice

A working program does four things at once. It links every address it serves to a verified identity. It monitors the full transfer graph with rules tuned to its real risk. It screens against current sanctions state at the moment value moves, not overnight. And it can reconstruct any transaction into a reportable record on demand. All four rest on the same standardized data, because a regulator reviewing one obligation will inevitably pull the evidence behind the others.

Frequently asked questions

What is crypto compliance in simple terms?

Crypto compliance is the set of obligations a regulated crypto business must meet to operate legally. In practice it comes down to four things: verifying who your customers are (KYC), monitoring their transactions for suspicious patterns, screening counterparties against sanctions lists, and filing the reports regulators require. Most of these derive from anti money laundering law that applies to banks, adapted to public blockchains.

Is sanctions screening really strict liability?

Yes. OFAC's guidance makes clear that sanctions prohibitions apply on a strict liability basis, meaning a US person can be liable for transacting with a blocked party even without knowing the party was sanctioned. Because OFAC now lists specific crypto wallet addresses on its SDN list, screening has to run against the current list at the time value moves rather than as an overnight batch.

Does KYC work if blockchain addresses are pseudonymous?

KYC works by tying a verified real-world identity to the addresses a customer uses at the point of onboarding. The blockchain itself only proves a key signed a transaction, not who holds the key. KYC bridges that gap so that later monitoring and reporting can attribute activity to a real person.

What is the FATF Travel Rule and does it apply to crypto?

The FATF Travel Rule requires virtual asset service providers to transmit originator and beneficiary information alongside qualifying transfers, similar to the rule long applied to bank wires. FATF's virtual asset guidance extends this to crypto businesses, and many jurisdictions have adopted it into local law, though implementation details vary.

Why is compliance harder across multiple blockchains?

The same economic event, such as a stablecoin transfer, arrives as different raw data on different chains: different token standards, decimals, and event logs. A monitoring or sanctions rule that fires reliably on one chain can silently miss the equivalent activity on another if the fields do not line up. The core technical challenge is normalizing raw records from every chain into one consistent schema so the same transfer means the same thing everywhere.

Is meeting the four obligations enough to manage risk?

Meeting them satisfies the legal floor, but it confirms a process was followed rather than that a given counterparty is genuinely low risk. Checklist compliance and risk intelligence are related but distinct. Mature programs treat the four obligations as the baseline and layer risk analysis on top to understand actual exposure.