AML for businesses accepting crypto payments

Accepting crypto makes you interesting to your bank

The moment a company starts taking crypto, two counterparties begin watching it: the exchange or processor that converts the coins, and the bank that receives the fiat. Neither cares how novel the product is. Both ask a single question — can this business explain where each payment came from? A firm that cannot answer loses its off-ramp, and losing the off-ramp is usually more damaging than any individual bad payment.

The good news is that the bar is procedural, not technical. A small company with a written policy, consistent screening and organised records passes reviews that a much larger, sloppier operation fails.

Write the policy before the first payment

A usable crypto AML policy fits on three pages and answers concrete questions rather than quoting legislation.

• Which assets and networks you accept, and which you refuse outright.
• The risk score thresholds for automatic acceptance, manual review and rejection.
• What identity data you collect above given payment sizes.
• Who inside the company decides on a flagged payment, and who can override them.
• How long records are retained — five years is the common default.
• How and when a refund to the originating address is issued instead of accepting funds.

Screening thresholds that survive contact with reality

Blanket rules break businesses. A workable model is tiered: screen every incoming payment automatically, auto-accept below a moderate score, route the middle band to a human with a short questionnaire for the customer, and refund anything above your hard ceiling before it is converted. The middle band is where the money is — treating it as automatic rejection loses legitimate customers, treating it as automatic acceptance is what triggers the bank conversation.

Calibrate by category as well as by number. Exposure to gambling or a high-risk exchange is common and often benign; any direct exposure to sanctions, ransomware or child-abuse material clusters is a hard stop regardless of the aggregate score.

Records are the product of the process

Store the screening report for every payment alongside the invoice, the customer identifier and the decision that was made, including the reasoning for manual overrides. An auditor is not verifying that you never touched a risky coin — that is impossible. They are verifying that you applied your own stated policy consistently and could justify the exceptions.

Automate the storage. A screening step that depends on someone remembering to run it manually will be skipped precisely on the busiest day, which is also the day the unusual payment arrives.

Common failure modes

• Screening only large payments while a stream of small ones from the same cluster accumulates.
• Reusing one static receiving address for every client, which merges all customers into one unexplainable history.
• Converting to fiat instantly and assuming conversion erases the origin. It does not; the processor keeps the trail.
• Refunding a flagged payment to a different address than it came from, which reads as layering.
• No named owner for compliance decisions, so flagged payments sit unresolved until a customer escalates.

The proportionate approach

Most companies do not need an enterprise compliance department. They need consistent screening on the incoming side, a short written policy, clean per-customer addressing and a retrievable archive. That package answers the questions a bank, a processor and an auditor ask, and it costs a rounding error against the revenue it protects.