How to automate AML address screening in a crypto service

To automate AML address screening, you build it into four points of the product: incoming transfers before they are credited, the recipient address before a payout, the service’s own wallets, and re-screening of past transactions. The screening result is not just shown to an operator. It changes the order status by itself, according to predefined rules.

This article was prepared by the Nomium team. In its projects, building a crypto exchange includes an AML layer from the very start rather than adding it after launch. The article is based on FATF and OFAC guidance, as well as the requirements of the platforms that crypto businesses work with.

An important caveat: automated screening reduces risks but does not eliminate them entirely. Blockchain analytics databases are incomplete, so some cases will always require manual review.

Why manual screening stops working

At many exchangers and OTC services, screening looks like this: an operator pastes the client’s address into an AML service, looks at the score and decides what to do. While order volume is low, that is enough.

As the flow grows, manual screening shows three weak spots:

• No consistent rules. Two operators may assess the same medium-risk report differently.
• No audit trail. Six months later, it is hard to prove what exactly was checked and why the transaction was approved.
• No re-screening. An address that was clean at the time of the transaction may later get a dangerous label, and no one will notice.

Meanwhile, the cost of a mistake is rising. Tether, the issuer of USDT, reserves the right to freeze tokens and block the addresses that hold them. The BestChange exchanger monitoring service requires payouts to clients to comply with FATF and OFAC requirements: if a transaction sent to a client receives an AML flag, the exchanger must compensate the client for the losses.

Four AML screening points in the product

Screening is useful only if it can stop something. That is why it is placed right before an irreversible action: crediting funds to a client’s balance or sending them to an external address.

1. Incoming transfer – before crediting

When a transfer arrives at the service’s wallet, it is screened together with the sender’s address – before it is credited to the balance or exchanged. While screening is in progress, the order waits.

The order of steps matters: first the required number of network confirmations, then screening, and only then crediting. If the funds are credited earlier, the client can withdraw or exchange them, and the transaction can no longer be stopped.

2. Recipient address – before payout

The payout address is screened twice: when the client enters it and right before sending. The first check makes it possible to reject immediately without creating an order. The second is needed because time may pass between creating the order and the payout.

According to OFAC guidance for the crypto industry, risk also comes from addresses that are not on sanctions lists but have previously interacted with listed addresses. Matching against the list will not find such links, but blockchain analytics will.

3. The service’s own wallets

This step is often forgotten. If funds from a dangerous source have reached the service’s hot wallet even once, all subsequent payouts from it may receive a risky score in analytics reports.

That is why funds from questionable sources are not mixed with the common pool until a decision is made on them, and payouts to clients are made from low-risk addresses. For example, BestChange rules require payouts to be made from one-time addresses or from addresses that AML analytics does not classify as high-risk.

4. Re-screening the history

Labels in analytics databases appear with a delay: an address linked to theft or fraud is sometimes flagged only after the funds have left it. FATF explicitly names data timeliness as one of the limitations of blockchain analytics.

That is why client addresses should be re-screened regularly. FATF recommends checking client and counterparty addresses against lists of undesirable addresses as part of ongoing monitoring, not only at the first transaction.

Screen the address or the transaction?

These are different questions. Address screening shows where funds have generally come from into the wallet. Transaction screening shows where a specific transfer came from.

For incoming transfers, transaction screening is usually more important: a client may use the same address for years, and then a suspicious transfer suddenly arrives on it. For payouts, the recipient address is screened – there is no transaction yet.

A few technical nuances that are often gotten wrong:

• One transaction can contain several payments. In Bitcoin, a single transaction often sends funds to several recipients. For AML purposes, these are separate transfers, so the request must specify the exact address.
• One token – different networks. USDT is issued on Tron (TRC-20), Ethereum (ERC-20), BNB Smart Chain (BEP-20) and other networks, and an address has its own history in each one. Screening must be done on the network where the transfer took place.
• The same address format does not mean the same network. Ethereum and BNB Smart Chain addresses both start with 0x and look identical. If the product stores an address without its network, sooner or later it will screen the wrong history.

How to turn a risk score into a decision

AML services usually return an overall risk score and a breakdown by source of funds. For example, GetBlock uses this scale: 0–30 – low risk, 31–69 – medium, 70–100 – high. Sources are divided into trusted (licensed exchanges, payment services, miners), suspicious (crypto ATMs, unlicensed exchanges) and dangerous (sanctions, darknet markets, mixers, stolen funds, fraud).

Making a decision based on the overall score alone is risky. A small share of funds from a crypto ATM and a direct transfer from a mixer can produce similar numbers but mean completely different things. Among risk indicators, FATF names both direct and indirect links to darknet markets, mixers, questionable gambling sites and stolen funds, with direct links usually carrying more weight.

That is why rules are better built on two parameters: the overall score and the source categories. Below is an example of such a matrix. The thresholds and actions are illustrative: they are set by the compliance policy of a specific service, taking its jurisdiction into account.

What matters is not the specific numbers but the fact that the rules are fixed and the system applies them the same way to every order. An operator steps in only when a rule requires it.

What to build around the AML API

Connecting the screening API is the easiest part of the job. Most of the effort goes into making sure the screening result reliably controls the order.

Order statuses

An order has statuses: “awaiting screening,” “screening passed,” “under manual review,” “rejected.” Crediting or payout is possible only after the “screening passed” status. This rule is better enforced at the backend level rather than the interface: then it cannot be bypassed with a button in the admin panel.

Behavior during outages

An external service may not respond or may respond with a delay. For payments, the safest rule is “no screening – no payout.” The request is queued and retried, and the order stays in the “awaiting screening” status.

Retries must not create duplicates or extra paid checks. Some services, such as GetBlock, let you retrieve a report on an already screened address or transaction again for free.

Decision log

For each check, the following is saved: the report itself, the risk score, the version of the rules used to make the decision, and the name of the employee who confirmed a manual decision. A few months later, this is the only way to explain to a bank, partner or regulator why a transaction was processed or rejected.

The retention period depends on the jurisdiction and partner requirements. For example, since March 2025 OFAC has required transaction records to be kept for 10 years (previously 5 years), and BestChange rules require at least 5 years for each exchange operation.

Cache and data freshness

Address screening results can be cached to avoid paying for repeat requests on the same client. But the cache must have a limited lifetime, and it is better to request a fresh check before a payout: labels in the databases change.

Manual review queue

Disputed orders go into a separate queue where an analyst sees the report, the client’s history and the rule that was triggered. Their decision and comment go into the log. Without such a queue, disputed cases end up in messengers, and the decision trail is lost.

Access protection

The API key is kept in a secrets vault, not in the code. If the service supports an IP allowlist, it is worth allowing requests only from the product’s servers.

Requirements that apply in any country

Regulation of crypto services varies greatly from country to country, and in some places it does not exist yet. But there is a minimum set of measures based on FATF standards and counterparty requirements, which makes sense in any jurisdiction.

Baseline under FATF standards

FATF standards underpin national AML rules in most countries. For a crypto service, they lead to several practical requirements:

• assess client risk and adjust the depth of checks accordingly;
• check client and counterparty addresses against lists of undesirable addresses as part of ongoing monitoring;
• track risk indicators not only in addresses but also in client behavior.

FATF’s behavioral indicators include, for example, splitting transfers into small amounts, a large first deposit that does not match a new client’s profile, and withdrawing funds right after a deposit with no trading activity. Address screening will not detect such scenarios, so separate rules are needed for them.

Travel Rule data

FATF Recommendation 16, or the Travel Rule, requires information about the sender and recipient to be transmitted along with the transfer: their names, wallet addresses and the sender’s identifying information. This data is transmitted before the transfer or at the same time. FATF allows a threshold of USD/EUR 1,000, below which the requirements are lighter, but many countries do not apply it.

Even if this requirement is not yet in force in the country where the service operates, it is worth providing fields for this data in the data model right away. Adding them to a live service is harder than building them in during development.

What requirements look like where they already apply

EU Regulation 2023/1113 on transfers of funds requires a crypto provider, for transfers over €1,000 to a self-hosted address, to verify that the address belongs to the client or is under their control. In the US, OFAC has been adding crypto wallet addresses to the SDN list since 2018 and recommends screening not only wallet addresses but also users’ IP addresses to prevent access from sanctioned jurisdictions.

These examples show where regulation is heading, but they are mandatory only in their own jurisdictions.

Counterparty requirements

Even where the law does not require AML checks, partners do. Exchanges may freeze funds from risky sources, stablecoin issuers may freeze tokens on an address, and exchanger monitoring services set AML conditions for participation. That is why a service without an AML layer risks not so much fines as the loss of funds and client acquisition channels.

Settings instead of code

A practical tip: thresholds, lists, required fields and rules for each country should be stored in settings that a compliance specialist can change, not in the code. Then changing the rules or entering a new country only requires changing the configuration, not the payment processing logic.

Limitations of automated screening

Blockchain analytics has accuracy limits, and they need to be taken into account in the design:

• Incomplete data. FATF explicitly names the limitations of analytics: coverage, timeliness, accuracy and reliability of data.
• Different scores from different providers. Each has its own databases and rules, so the same address may receive different scores. When switching providers, the thresholds will have to be revised.
• The wallet owner cannot be identified precisely. FATF writes in its guidance that it is not aware of a technically proven way to fully and accurately identify the provider that manages the recipient’s wallet.
• False positives. A client with a good history may get a medium risk score because of old transactions. For this case, a procedure is needed: a request for explanations, re-screening, an analyst’s decision.
• Address screening does not replace client verification. It answers the question of where the funds came from, but not who the client is. A complete AML layer combines transaction screening, KYC and behavior monitoring.

Pre-launch checklist

1. Incoming transfers are screened before crediting, after the required number of confirmations.
2. The recipient address is screened when entered and again before payout.
3. Disputed deposits are not mixed with the payout wallet.
4. Addresses are stored together with their network, and screening is done on the network of the transfer.
5. Decisions are based on the score and source categories, and the rules are fixed in advance.
6. Crediting and payout are impossible without the “screening passed” status, and this is enforced by the backend.
7. If the screening service is unavailable, payouts stop and requests are retried without duplicates.
8. Every decision is saved together with the report and the rules version.
9. There is a manual review queue for disputed cases.
10. Addresses of regular clients are re-screened regularly.
11. The data model has fields for the Travel Rule.
12. Thresholds and rules for each country are changed in settings, not in code.

Such an AML layer does not make a service invulnerable, but it changes the main thing: decisions on risky funds are made by the same rules, on time and with a clear trail. For a crypto business, this means fewer frozen funds, fewer disputes with partners and less dependence on the attentiveness of a particular operator.