> ## Content Index
> Fetch the complete content index at: https://blog.amlbot.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# AML for Crypto Payment Gateways: How to Screen Merchants, Payments, and Payouts
- URL: https://blog.amlbot.com/crypto-payment-gateway-aml/
- Published: 2026-09-30T09:05:15.000Z
- Updated: 2026-09-30T09:05:15.000Z
- Author: AMLBot Team
- Tags: AMLBot Academy

Most crypto payment gateways settle in stablecoins. So does most crypto crime.

In a targeted report published on 3 March 2026, the Financial Action Task Force noted that stablecoins had grown to more than 250 in circulation by mid-2025 with a combined market capitalisation above USD 300 billion — and cited blockchain-analytics research indicating that stablecoins accounted for roughly 84% of illicit virtual asset transaction volume in 2025, frequently moving through unhosted wallets.

> (Source: FATF, "Targeted Report on Stablecoins and Unhosted Wallets — Peer-to-Peer Transactions," 3 March 2026 — [https://www.fatf-gafi.org/en/publications/Virtualassets/targeted-report-stablecoins-unhosted-wallets.html](https://www.fatf-gafi.org/en/publications/Virtualassets/targeted-report-stablecoins-unhosted-wallets.html?ref=blog.amlbot.com))

That overlap is the practical problem here. A gateway does not choose its payers. A merchant publishes a checkout link, and whoever pays, pays — from a wallet the gateway has never seen, in the asset that dominates both legitimate commerce and illicit settlement. The merchant may be entirely legitimate. The payment may not be.

One scope distinction changes almost every answer below. A shop accepting crypto for its own goods handles its own money. A payment gateway accepts, routes, converts, settles or pays out crypto on behalf of third-party merchants, standing between payers and businesses it did not incorporate and does not control. The two models carry different obligations, and [AML controls depend on how the crypto payment product actually handles merchant funds](https://blog.amlbot.com/crypto-startup-aml-checklist/). Everything below assumes the intermediary model.

Whether a given gateway is a regulated payment institution, a VASP or an MSB depends on its activity and geography — a licensing question for elsewhere. The question here is narrower: once the payment flow exists, where exactly do the AML checks sit inside it?

## Map the Crypto Payment Flow Before Applying AML Controls

Start by drawing the flow, because controls are easier to place when you can see the movement they attach to:

> **Payer → Incoming Wallet → Payment Gateway → Merchant Balance / Settlement → Merchant Payout Wallet**

Each box holds a different object with a different risk question. The merchant is a business relationship. The payer is a counterparty the gateway usually has no relationship with at all. The incoming transaction is a movement of value with its own on-chain history. The payout destination is a separate address that may have nothing to do with any of them. Four distinct AML objects — and a control examining one says little about the others. That gives 5 checkpoints:

- Merchant Activation, before the gateway processes anything on this business's behalf;
- Incoming Payment, when funds arrive at an address tied to the merchant;
- Settlement, when those funds are credited to the merchant's balance;
- Payout, when funds leave for a destination the merchant nominates;
- Ongoing Monitoring, because none of the above stays static.

The most common failure in crypto payment compliance is a present one placed at the wrong checkpoint, verifying the merchant thoroughly, then treating every payment that merchant receives as verified by association. Correct placement starts with being able to [map AML controls to the actual crypto business model](https://blog.amlbot.com/crypto-startup-aml-checklist/) rather than applying one generic checklist across the product.

## Screen the Merchant Before Payments Start

Merchant onboarding answers one question and one question only: *who is this business, and are we willing to provide payment services to it?*

### Verify the Business and Its Controllers

The verification set is familiar: the legal entity and its registration details, directors and senior management, ultimate beneficial owners, sanctions and where applicable PEP exposure across those parties, what the business actually sells, and the jurisdictions it operates in and sells into.

Depth scales with risk. A small domestic retailer and a high-volume gaming platform incorporated somewhere with weak corporate transparency are not the same onboarding case, even filling in the same form. The mechanics of [merchant KYB and beneficial ownership checks](https://blog.amlbot.com/crypto-kyb-business-verification-vasps/) are a subject in their own right, and for most gateways the practical route through document collection and registry work is [automated merchant KYB](https://amlbot.com/kyc?ref=blog.amlbot.com).

What matters here is the limit of what KYB produces. It tells you who you are doing business with, and nothing about the risk carried by any payment that merchant later receives, because merchants do not choose their payers any more than gateways do. **A merchant that passes KYB can still receive a high-risk crypto payment.** Merchant identity and transaction risk answer different questions.

Note also what KYB does not reach. Verifying a merchant is not verifying that merchant's end customers, and a gateway is generally not positioned to run full KYC on everyone paying a merchant's invoice.

### Build an Expected Merchant Activity Profile

This is the step most often skipped, and skipping it quietly disables monitoring later.

Alongside identity verification, onboarding is the moment to capture what normal looks like for this merchant: what it sells, expected payment volume, typical transaction size, which assets and networks it will accept, the geography of its customer base, payout frequency, and preferred settlement method.

None of that is a compliance requirement in itself. Its value is comparative. Six weeks later, when a merchant that described itself as a small European software vendor starts receiving large, frequent transfers from wallets clustered in an unrelated region, the gateway has something concrete to compare against. Without a baseline, that pattern is just activity. With one, it is a discrepancy worth reviewing.

Treat the profile as a working document, not an onboarding artefact. Merchants grow, pivot and enter new markets. The point is not holding them to month one — it is noticing when reality and the record diverge, then updating the record deliberately when there is a good explanation. Avoid hard-coding fixed thresholds while doing it: what counts as a large payment for one merchant is a routine Tuesday for another.

## Screen Incoming Crypto Payments Before Settlement

An incoming payment is a separate compliance event from the merchant relationship that produced it.

### Screen the Transaction and Sending Wallet

When funds arrive, the questions are about the funds: where did this value come from, what has the sending wallet been doing, and does anything in its history create exposure the gateway must act on?

Screening typically covers the source wallet and its history, direct exposure to known illicit services, indirect exposure through intermediate hops, sanctions-linked exposure, contact with categories such as mixers, darknet markets or stolen-funds clusters, and the amount and context of the transaction itself.

> The core principle: **blockchain confirmation confirms the payment, but not its AML risk.** Confirmation means the network accepted the transaction and the value is final. It says nothing about where that value came from. Treating confirmation as clearance is an easy category error when the product's success signal and the compliance signal arrive in the same webhook.

A screening result also has limited value in isolation. A risk score attached to a floating transaction hash is a fact with nowhere to go; the same result attached to a specific merchant, payment reference and activity profile is something a reviewer can act on. So [crypto transaction monitoring and wallet risk screening](https://amlbot.com/transaction-monitoring?ref=blog.amlbot.com) needs to write its output back into the payment record, not into a separate log nobody reads at decision time.

One caution: a high-risk flag warrants attention, not a conclusion. Exposure can be indirect and attribution imperfect. Screening produces a decision about what to do next, not a verdict.

### Handle Third-Party and Unexpected Payers

Crypto payments often arrive from somewhere other than the party the merchant expected: an unrelated corporate wallet, an intermediary or exchange withdrawal address, an aggregated payment covering several invoices, repeated payments from a cluster of connected wallets, or a payer with no explicable relationship to the merchant's stated customer base.

None is automatically a problem. Businesses pay through subsidiaries, customers withdraw from exchanges, providers aggregate. What each creates is a gap between expected and observed payment context, and that gap needs either an explanation or an escalation.

The workable approach: link the payment to the merchant relationship it belongs to, capture whatever payer context exists, screen the transaction and wallet as normal, and escalate where the economic relationship cannot reasonably be explained. This is one scenario among several inside a gateway, though it has enough depth to warrant separate treatment — the full method for how to [review a crypto payment coming from a third party](https://blog.amlbot.com/third-party-crypto-payments-aml/) covers what to ask and when an answer is sufficient.

### When Source of Funds Becomes Relevant

Source of funds is not a check that runs on every transaction. A gateway demanding documentary evidence for routine merchant payments will wreck its conversion rate and produce files nobody reads.

It becomes relevant on specific triggers: the on-chain source is unclear or obscured, the pattern is unusual for that merchant, screening surfaces high-risk signals, or the payment is unusually large, unexpected, or simply inconsistent with what the gateway knows about the business.

When it applies, the exercise is comparative rather than administrative — not collecting a document, but checking whether what the merchant or payer says about the money matches what the blockchain shows. That is the discipline of learning to [match source-of-funds information with on-chain evidence](https://blog.amlbot.com/source-of-funds-in-crypto-aml-how-to-match-customer-information-with-on-chain-evidence/), where an explanation contradicting the transaction graph is more informative than no explanation at all.

## Screen Settlement and Merchant Payouts Separately

Here is the gap that catches otherwise well-built gateways: enormous effort screening money on the way in, and then money leaves through a process nobody treats as a compliance event.

### Verify the Payout Destination

A payout is its own event with its own question: where are these merchant funds actually going?

A clean incoming payment does not automatically make the payout destination low risk. Separate transactions, separate counterparties, separate exposure profiles. Value arriving from an ordinary customer wallet can leave toward an address with a history the gateway would never have accepted inbound.

Destination screening matters most at specific moments: a merchant adds a new payout wallet, an existing destination changes, funds go onward to another service rather than a wallet the merchant appears to control, or the settlement route itself changes — different network, different asset, different intermediary. Each is a point where the gateway makes a fresh decision about where value goes, and each deserves a check rather than an inherited approval.

### Re-Screen Recurring Payout Wallets When Risk Changes

A wallet screened in January is not certified for the year. **A previously approved payout wallet should not be treated as permanently safe.**

Risk changes for reasons outside the gateway's control: new sanctions exposure, newly identified clusters the wallet interacts with, connections invisible at first screening that surface as more of the graph becomes known. Blockchain intelligence improves retroactively, so a wallet's risk profile can change without the wallet doing anything new.

For recurring payouts (which is most payouts, since merchants settle to the same addresses repeatedly) this argues for [continuous transaction monitoring and automatic re-checks](https://blog.amlbot.com/amlbot-continuous-transaction-monitoring/) rather than a one-time approval stored as a permanent flag.

> Sanctions cut across the whole flow rather than sitting at one checkpoint. Exposure can arise on the merchant side, on an incoming payment or on a payout destination, and a sanctions match differs in kind from a risk score — a legal requirement, not a risk-based judgement. Applying [sanctions screening across wallets, transactions, and counterparties](https://blog.amlbot.com/sanctions-screening-for-crypto-businesses/) as a distinct control keeps that visible.

## Connect Merchant, Payment, and Payout Risk in One Compliance Workflow

Each control above is necessary and none is sufficient alone. The failure mode for mature gateways is rarely a missing check — it is three working checks that cannot see each other. The chain that needs to hold together:

> **Merchant ID → Payment ID → Incoming Transaction → Risk Result → Review Decision → Settlement → Payout Wallet → Outgoing Transaction**

> Isolated screening results miss the questions that matter. One transaction with a moderate risk signal may be unremarkable. The same signal on the fifteenth payment to the same merchant, from wallets sharing a common funding source, is a different observation entirely, and only a system connecting payments to merchants can see it. **Merchant-level patterns can matter more than any individual transaction.**

This is also where a risk score has to become an action. A score recorded and never acted on is a liability, not a control: it documents that the gateway knew something and did nothing. The realistic outcomes are short — allow, hold pending review, request information from the merchant, escalate to a reviewer, or reject where policy or applicable obligations require it. Which one applies depends on the signal, the merchant context and documented policy, which is where a business needs to [apply risk-based AML controls to different transaction signals](https://blog.amlbot.com/risk-based-approach-crypto-aml/) rather than run one fixed rule for everyone. Technically this is a data problem before it is a compliance problem. The merchant or account identifier, payment reference, transaction hash, network and asset, relevant addresses and screening result all need to travel together. How to [connect AML API results to payment and payout decisions](https://blog.amlbot.com/crypto-aml-api-requirements/) decides whether a reviewer opening a case sees the whole picture or reconstructs it from three systems.

A simple test: pick any payout made last month and ask which merchant, which payments funded it, what screening said, and who decided what. If that takes an afternoon, the workflow is not connected.

## A Practical AML Flow for a Crypto Payment Gateway

Pulling it together, the operational shape:

**Merchant Onboarding**

- Checked: company, UBOs, business activity.
- Question: who are we providing payment services to?
- Outcome: approve, enhanced due diligence, or reject.

**Incoming Payment**

- Checked: the transaction and the source wallet.
- Question: where are these funds coming from?
- Outcome: accept, review, or hold.

**Settlement**

- Checked: the payment against merchant context.
- Question: can these funds enter the merchant settlement balance?
- Outcome: settle or review.

**Payout Setup**

- Checked: the destination wallet.
- Question: where will merchant funds be sent?
- Outcome: approve or review.

**Payout**

- Checked: the outgoing transaction.
- Question: is the destination still acceptable?
- Outcome: send, hold, or escalate.

**Ongoing Monitoring**

- Checked: merchant and payment patterns over time.
- Question: has risk changed?
- Outcome: continue, review, or restrict.

Six stages can look like six separate processes. They should not run as six separate systems. **Merchant KYB, incoming payment screening and payout screening are distinct controls, but they should not operate as isolated compliance silos.** The requirement is that the gateway can connect a merchant to its payments, those payments to their screening results, and those results to the reviews, settlements and payouts that followed. That traceability separates a gateway that can explain its decisions from one that can only show it bought the right tools.

## Three Questions, One Traceable Workflow

Strip away the detail and a crypto payment gateway runs three AML questions at three points in the same flow. Merchant KYB answers who the gateway is doing business with. Incoming transaction screening answers where individual payments come from. Payout screening answers where merchant funds are ultimately sent. Each is a legitimate control with a natural place in the flow, and none answers either of the other two.

The work that actually reduces risk is connective. **A crypto payment gateway needs to link these three layers into one traceable AML workflow rather than treating KYB, wallet screening, and transaction monitoring as isolated checks.** Screening thoroughly at all three points while being unable to reconstruct the relationship between them carries the cost of a compliance programme without much of the benefit.

For teams building this into a live product, the two integration points carrying most weight are merchant verification at onboarding through [automated KYC and KYB verification](https://amlbot.com/kyc?ref=blog.amlbot.com), and screening against incoming payments and payout destinations through [continuous crypto transaction monitoring](https://amlbot.com/transaction-monitoring?ref=blog.amlbot.com), with both writing results into the same payment record.

## FAQ  

### Do Crypto Payment Gateways Need AML Screening?

A gateway handling crypto on behalf of merchants may need controls across merchant onboarding, incoming payments, settlement and payouts, depending on its activity and applicable regulatory framework. Merchant KYB alone does not assess the risk of individual transactions, and transaction screening alone does not verify the business receiving the funds.

### What Should a Crypto Payment Gateway Screen?

Three objects at minimum: the merchant, through business verification and beneficial ownership checks; the incoming transaction and its source wallet; and the payout destination and outgoing transaction. Ongoing patterns across a merchant's payments often reveal more than any single transaction.

### Is Merchant KYB Enough for a Crypto Payment Processor?

No, not as a complete transaction-risk control. KYB explains who the merchant is and who owns and controls it. It does not determine the AML risk of every wallet or payment interacting with the gateway. A verified merchant can still receive funds from a high-risk source.

### Should Incoming Crypto Payments Be Screened Before Merchant Settlement?

Where the product flow allows it and the business's AML framework requires transaction screening, reviewing incoming risk before settlement lets the provider act before high-risk funds mix into normal merchant balances or are paid onward. Timing follows the business model rather than a universal rule.

### Should Crypto Payout Wallets Be Screened?

In operational terms, yes, screening a merchant payout address helps assess destination risk before funds leave the gateway. For recurring payouts, ongoing monitoring and re-checks are relevant because wallet risk can change over time through new sanctions exposure, new attribution, or newly visible connections.

### What Is the Difference Between Merchant Screening and Transaction Screening?

Merchant screening asks who the business is. Transaction screening asks where specific funds come from or go to. They run at different points, use different data and answer different questions. One does not substitute for the other, and a gateway needs both connected to the same record.

### How Should a Payment Gateway Handle Third-Party Crypto Payments?

Link the payment to the merchant relationship it belongs to, capture whatever payer context exists, screen the transaction and wallet as normal, and escalate where the source or economic relationship cannot reasonably be explained. An unexpected payer is a reason to look closer, not an automatic rejection.

### Does a Crypto Payment Gateway Need Continuous Transaction Monitoring?

It becomes particularly relevant where the gateway handles recurring merchant payments and payouts, and where wallet risk or transaction patterns can change after an initial check. Monitoring scope should follow the business model, risk assessment and applicable obligations rather than a fixed standard.

### What Data Should a Crypto Payment Gateway Keep for AML Reviews?

At minimum: merchant or account identifier, payment reference, transaction hash, network and asset, sender and destination addresses where available, screening result, alerts raised, the review decision, who made it, and the resulting action. The value is in the linkage, those fields should reconstruct one case.