A defensible AML program for a crypto exchange rests on four layers: a risk-based assessment, address and transaction screening, alert review, and audit-ready records. Identity checks cannot see wallet-level risk. A single address can move funds across chains or through a mixer within minutes. Those four layers must work together before the first deposit clears and after every withdrawal. This guide builds each layer in order. For the broader workflow, see Phalcon Compliance. This page is part of the AML Compliance Hub.
Why Crypto Exchanges Need a Dedicated Onchain AML Program
A traditional AML program is built around identity. It knows who the customer is, where the money came from, and which bank account it moves between. An exchange that settles on chain does not have those anchors. A wallet address is generated in seconds, carries no verified identity, and can be discarded after a single transaction. Funds also move faster than any manual review loop. Chain-hopping, mixer routing, and bridge crossings can move tainted value across networks before a compliance officer finishes the morning queue.
The regulatory floor has moved to match that reality. The FATF risk-based approach for VASPs applies Recommendation 15 to virtual asset service providers of every size. An exchange is expected to calibrate its controls to its assessed money-laundering and terrorist-financing risk rather than to a one-size-fits-all standard. FinCEN imposes AML program obligations on money services businesses including crypto exchanges operating in the United States, so a written program, ongoing training, independent review, and suspicious activity reporting are baseline duties. The question for a compliance officer is no longer whether to build an onchain AML program. It is how to build one that holds up against both authorities. The full discipline-level framework is mapped on the crypto AML compliance platform hub.
The cost of not building one is concrete. Exchanges that skip a risk-based program face enforcement actions, license suspensions, and the loss of correspondent and banking relationships that a regulated business cannot operate without. The cost is not abstract regulatory risk. It is the cost of being unable to evidence the controls a regulator will ask about during an examination, and it is avoidable with a structured program. The FinCEN Bank Secrecy Act program requirements are the baseline a US examiner measures that program against, so the controls an exchange builds have to map directly to those obligations.
Step 1: Risk-Based Assessment for an Exchange
A risk-based assessment is the foundation of the program and the first thing a regulator will ask to see. The FATF risk-based approach expects an exchange to name its specific money-laundering and terrorist-financing exposures and calibrate controls to them. The program does not have to be perfect. It has to be defensible, meaning the compliance officer can explain why each control exists and which assessed risk it addresses.
For an exchange, those exposures look different from those of a bank or a payments company. The assessment should produce a structured list that an examiner can read. The list below covers the risk surfaces an exchange compliance team typically has to defend.
| Exchange-specific risk surface | What it exposes |
|---|---|
| Deposit and withdrawal screening | Counterparty addresses that carry sanctions, laundering, or scam exposure entering or leaving the platform |
| Mixer and sanctions exposure | Funds routed through mixers, tumblers, or sanctioned addresses that taint the receiving wallet |
| High-frequency micro-transactions | Structuring or smurfing patterns split across many small transfers to evade thresholds |
| Cross-chain bridge flows | Funds moving through bridges to obscure origin, requiring cross-chain tracing to follow |
| Non-custodial wallet interactions | Withdrawals to unhosted wallets where no counterparty identity is collected |
| Sanctioned jurisdiction exposure | Users or addresses tied to FATF high-risk or grey-list jurisdictions |
Each row in the table is a defensible input. An exchange that names these exposures in its assessment can map each one to a specific control in the next layer. That is exactly what an examiner wants to see. An exchange that skips the assessment will struggle to justify any individual screening decision later, because it never documented the risk that decision was meant to address.
Step 2: Deploy Screening, Monitoring, and Continuous Re-Analysis
The onchain tool layer that ties the program together is the KYA, KYT, and Monitor triad inside Phalcon Compliance, and Monitor is the piece that keeps a continuously screened wallet list without consuming Screening quota. The three modules split the workload by trigger type: KYA scores addresses, KYT monitors transactions, and Monitor re-analyzes the wallet population over time. An address that was clean yesterday but turns risky tomorrow gets caught without a manual rescan.
Phalcon Compliance KYA scores every counterparty address against a database of more than 600 million labeled addresses, returning a risk tier and the traceable Risk Indicators behind it. Phalcon Compliance KYT monitors transactions in real time as they land. It surfaces alerts for behavioral risk patterns and risk interactions, so the exchange can intercept or escalate before settlement compounds the exposure. Phalcon Compliance Monitor runs a dynamic plan that continuously re-analyzes already-screened addresses for risk changes and raises change alerts, and it does not consume Screening quota. The platform's scoring is built on more than 200 signal types organized into 17 Risk Indicator categories. Each is independently traceable, so every alert carries the underlying indicator and the address interaction that triggered it. The 17 Risk Indicator categories include Sanctioned, Terrorist Financing, Human Trafficking, Drug Trafficking, Attack, Scam, Ransomware, and Child Abuse Material. The rest are Laundering, Mixing, Dark Market, Darkweb Business, Blocked, Gambling, No KYC Exchange, FATF High Risk Jurisdiction, and FATF Grey List Jurisdiction.
The division of labor between the three modules maps directly to the risk surfaces identified in Step 1. KYA runs at deposit and withdrawal, where a counterparty address has to be scored before the funds are accepted. KYT runs at the transaction layer, where behavioral patterns such as rapid pass-through or high-frequency micro-transactions only become visible as movement. Monitor runs across the already-onboarded wallet population, where an address that was clean at onboarding can later touch a sanctioned entity or a mixer and become a risk the exchange still owns. The table below makes the split explicit so the compliance officer can defend which module covers which obligation.
| Module | Trigger | Frequency | Role in the program |
|---|---|---|---|
| KYA screening | Address-level | Per deposit, withdrawal, or batch | Score counterparty risk before the funds are accepted or released |
| KYT monitoring | Transaction-level | Real time | Alert on behavioral risk patterns and risk interactions as transactions land |
| Monitor re-analysis | Wallet population | Dynamic plan | Re-analyze screened addresses for risk changes without consuming Screening quota |
What the triad delivers is continuous coverage. A one-time onboarding screen catches the risks that exist at onboarding, but on-chain risk is not static. A wallet that interacts with a mixer next week is a different exposure than the same wallet at onboarding. The program has to catch that drift to be defensible. Monitor exists to cover that gap. Because it does not consume Screening quota, the exchange does not have to choose between budget and coverage when it decides how large a wallet population to keep under continuous watch.

Step 3: Alert Triage SOP and Auditable Records
Screening and monitoring generate alerts. A program is judged by what happens to them. An alert queue with no triage SOP is a liability, because each open alert is an undocumented decision and each undocumented decision is an audit finding waiting to happen. The triage layer is what turns alerts into dispositions an examiner can read.
A defensible triage SOP has four stages. An alert is first classified by the risk levels attached to it, based on the Risk Indicators and exposure figures. It is then routed through automated triage rules that use the attached evidence to recommend a disposition. That is what an explainable score makes possible and a black-box score does not. It is next reviewed by a human analyst for any alert above a threshold or any alert the rules cannot confidently close. Finally, alerts that survive review are escalated into a suspicious activity report or suspicious transaction report for the relevant regulator.
| Triage stage | Input | Output |
|---|---|---|
| Severity classification | Risk Indicators, exposure value and percentage | High, medium, or low tier |
| Auto-triage | Traceable evidence attached to the alert | Recommended disposition with a documented basis |
| Human review | Alerts above threshold or un-resolvable by rules | Confirmed disposition, escalation, or close |
| Regulatory reporting | Confirmed high-risk dispositions | SAR or STR filing package |
Auditable records are the output that ties the whole program together. Every disposition should carry its judgment basis and the data it was made on, so an examiner reading the record months later can follow the same path the analyst took. The Risk Indicator that fired, the address interaction that triggered it, and the exposure value and percentage all live on the same record. So do the triage rule or human reviewer that acted and the final disposition. Records retention follows the obligations of the jurisdiction the exchange is licensed in. The compliance officer is responsible for confirming the applicable retention period rather than relying on a default. How to tune triage to reduce false positives is covered in depth on the dedicated reduce false positives in crypto AML monitoring page. This layer covers the structure that makes triage defensible, not the tuning itself.
Assess Phalcon Compliance for Exchange Compliance
Building an onchain AML program for a crypto exchange is a sequenced job. Risk-based assessment first. Then a screening and monitoring deployment that maps each assessed risk to a control. Then a triage SOP that turns alerts into dispositions. Finally, auditable records that hold up under examination. The platform gives a compliance team the KYA, KYT, and Monitor triad to stand that program up against a database of more than 600 million labeled addresses. That database carries more than 200 signal types organized into 17 Risk Indicator categories. Assess the platform for exchange compliance and map the exchange's assessed risks to a defensible control set before the next examination cycle.