P2P Crypto Platform AML Risks: How to Control User-to-User Trades

In December 2025, the U.S. Department of Justice and FinCEN announced parallel enforcement actions against Paxful, once described as "the world's largest P2P marketplace."Between February 2015 and April 2023, the platform processed more than 50 million trades worth several billion dollars — and along the way facilitated over $500 million in suspicious activity, including transactions tied to Iran, North Korea, Venezuela, and Backpage.com.

The dollar figure of the penalty itself was modest ($3.5 million civil, $4 million criminal). The deeper message was structural. According to FinCEN's consent order, even after Paxful introduced a written AML program in 2019, it "remained deficient" because the policies did not "sufficiently account for the risks associated with its business lines" — namely, peer-to-peer trading, hosted wallets, prepaid access, and cross-border payments.

In practical terms, the case sent one clear signal to every compliance team in the industry: P2P crypto platform AML risks cannot be managed with the same playbook used for a traditional, order-book exchange. A P2P marketplace facilitates user-to-user trades, holds crypto in escrow, and depends on off-chain payment legs that the platform cannot fully see. Risk therefore appears in many places at once — onboarding, merchant behavior, wallet exposure, escrow release, disputes, and withdrawals.

Here, the goal is to connect identity, merchants, wallets, trades, disputes, and review decisions into one defensible workflow.

Why AML Risk Is Different on P2P Crypto Platforms

On a centralized exchange, the platform sits in the middle of every trade. It runs the order book, custodies user funds, matches buyers and sellers automatically, and can apply AML controls at clean checkpoints — deposit, trade, withdrawal.

A P2P crypto marketplace works very differently. Two users find each other through the platform and trade directly, often across borders, using payment methods the platform doesn't operate. The marketplace typically holds the crypto in escrow during the trade, but the fiat leg — a bank transfer, a mobile money app, a gift card, sometimes physical cash — happens outside the platform's view.

This changes where the compliance risk actually lives. It is no longer concentrated in a single transaction. It is spread across the entire trade flow: Who is the buyer, and who is the seller in this specific trade? How often does each side trade, and with how many different counterparties? Which payment methods are being used, and do they match the user's declared profile? Was escrow released normally, or after a dispute? Where does the crypto go after the trade ends? Does the user's behavior change as the account ages?

There is also a regulatory layer that P2P platforms cannot ignore. In the United States, FinCEN clarified back in 2019 — through Guidance FIN-2019-G001, "Application of FinCEN's Regulations to Certain Business Models Involving Convertible Virtual Currencies" — that P2P exchangers and platforms that act as money transmitters fall within the Bank Secrecy Act perimeter. (That position has not softened.) In the Paxful matter, FinCEN explicitly emphasized that AML programs must be "commensurate with the specific risks posed by a platform's products, services, customer base, and transaction flows, including peer-to-peer and cross-border virtual currency transactions."

This means a P2P platform cannot defend a generic, off-the-shelf AML Program. Regulators expect controls that respond to the way P2P trades actually happen. The same expectation appears in FATF's 2024 and 2025 Targeted Updates on virtual assets, which highlight unhosted wallets, P2P transactions, and merchant-type activity as areas of growing concern.

According to 2026 Crypto Crime Report, illicit crypto flows reached roughly $158 billion in 2025 — a 145% jump over 2024. Chainalysis's 2026 annual report put the figure at around $154 billion. Whichever methodology you accept, the trajectory is the same: more illicit value moves through more endpoints, and P2P-style endpoints are increasingly part of that picture.

The takeaway is not that P2P is inherently bad, or that P2P means "less compliance." It means that controls have to look different.

Where AML Risk Appears in a P2P Trade Flow

A useful mental model is to stop thinking about "the transaction" and start thinking about "the trade flow." A single P2P trade typically passes through several stages: user identification, deposit, listing or order placement, counterparty match, escrow lock, off-chain payment, escrow release, and finally a withdrawal somewhere later. Risk can appear at any of those stages, and the same user can look low-risk at one stage and high-risk at another.

User and Merchant Risk

Not every P2P user creates the same level of platform risk. A first-time buyer who completes one small trade per month is very different from a "merchant" — a user who trades repeatedly, handles large volumes, and effectively builds a small business on top of the marketplace. In practical terms, merchants are where most concentrated risk sits, because:

• They interact with many counterparties, so any wallet exposure or fraud pattern multiplies quickly.
• They tend to use the same payment methods over and over, which makes them attractive to bad actors looking for predictable cash-out points.
• Their dispute history accumulates faster than that of an occasional user, so review signals are easier to read.
• If their volume grows past what their original KYC tier supports, they may be operating as an unlicensed money transmitter without the platform realizing.

The signals worth watching at the user and merchant layer are familiar in name but specific to P2P in interpretation: Trade Frequency. Volume. Number of Unique Counterparties. Account Age vs. Activity. Dispute History. Geography. Payment Behavior.

A merchant-level review is rarely about a single trade. It's about whether the pattern over weeks or months still looks consistent with how the user originally described themselves.

Wallet and Transaction Risk

The wallet layer is the part of P2P risk that looks most like classic crypto AML — but with an important twist. On a P2P platform, the addresses involved in a trade are not always controlled by the platform. Deposits arrive from somewhere. Withdrawals go somewhere else. Both ends matter. Wallet screening on a P2P marketplace has to cover:

• Deposit Addresses. Where did the crypto come from before it entered the platform?
• Withdrawal Addresses.Where is the user sending crypto after settlement?
• Linked Addresses. Wallets that consistently appear in a user's trade history, even if not owned by them.
• Direct Exposure When a wallet has interacted directly with a risky service (mixer, sanctioned entity, scam cluster).
• Indirect Exposure. When risk reaches the wallet through one or more intermediary hops.

Common risk categories include scams, darknet markets, sanctioned entities, mixers and CoinJoin services, ransomware-linked clusters, and wallets associated with fraud rings. None of these by themselves is a verdict. A wallet receiving funds two hops away from a known scam address is not the same as a wallet that is a scam address.

This is why the right framing for compliance teams is: a risk score is a signal for review, not an automatic accusation. Risk scoring tools assign probabilities. People assign decisions. Treating a score as a binary "guilty/innocent" output is one of the fastest ways to generate either false positives that burn user trust or false negatives that miss real laundering activity.

There is also a temporal problem. A wallet that looks clean at onboarding can become exposed three weeks later, after the user starts interacting with a different counterparty. Single-point-in-time checks miss this entirely — a topic we'll come back to in the monitoring section.

Off-Chain Payment and Dispute Risk

The off-chain leg is the part of a P2P trade where platforms have the least visibility — and, not coincidentally, where attackers focus most of their effort. A P2P trade almost always consists of two legs:

• A crypto leg, fully visible on-chain and to the platform's escrow system.
• A fiat or alternative payment leg, which happens between users on a bank, e-wallet, or in some cases face-to-face.

The platform can see screenshots of payment proofs, transfer references, and dispute statements — but it cannot independently verify what happened in a third-party bank in another country. That asymmetry is the single biggest reason P2P compliance is harder than centralized exchange compliance. In practical terms, this means the off-chain layer has to be evaluated through proxies:

• Payment Proof — was a coherent receipt or screenshot provided, and does it match the trade?
• Dispute Outcomes — how often does a given user lose disputes, win them on technicalities, or end up in repeat arbitration?
• Repeated Cancellations — particularly cancellations that occur late in the trade, just before escrow release.
• Chargeback Patterns — patterns where buyers reverse a bank payment after receiving crypto.
• Mismatch between Profile and Payment Method — for example, a "student in Country A" who consistently sends payments from corporate accounts in Country B.

A useful behavioral rule of thumb: disputes are not customer-service tickets, they are compliance signals. Repeat disputes with different counterparties almost always indicate something worth a closer look, even if each individual dispute resolves normally.

Risk-Based Onboarding for Buyers, Sellers, and Merchants

A common mistake on P2P platforms is treating onboarding as a single event with a single output — verified or not verified. That works on a small exchange. It does not work on a marketplace where the same user might trade $100 today and $50,000 next month, or where a "buyer" account quietly turns into a high-volume seller after three weeks. The model that fits the P2P trade flow is tiered, risk-based onboarding. Different user types pass through different levels of verification, and users can move between tiers as their behavior evolves. A common structure looks like this:

• Basic User — verified identity, limited trade volume, standard wallet screening.
• Higher-Volume Trader — additional identity verification, declared source of funds, broader screening.
• Merchant or Professional Seller — business-grade verification (KYB where relevant), declared business model, regular re-review.
• High-Risk User — enhanced due diligence (EDD), manual senior review, ongoing monitoring at a higher cadence.

The tier a user sits in should depend on what they actually do, not only what they declared on day one. The Paxful case is again instructive here: FinCEN found that even after the platform introduced KYC, it only applied above a $1,500 activity threshold — and there were no controls to stop users from simply structuring their trades to stay below it. A tier model that can be trivially gamed is, in regulators' eyes, not a tier model.

Basic Users vs High-Volume Merchants

The most important practical distinction is between casual users and merchants. They look the same on day one. They look very different after a month of trading. A merchant should sit in a separate risk profile because the type of risk they bring to the platform is different in kind, not just in size:

• Many Counterparties — more chances to interact with high-risk wallets and users.
• Repeated Payment Methods — bank accounts and e-wallets get re-used, which is convenient for both legitimate sellers and for laundering operations.
• Wallet Exposure Spreads — over time, a merchant's wallet history will include many flows the platform cannot easily attribute.
• They may meet the legal definition of a money transmitter in their own jurisdiction, even if the platform doesn't.

What a merchant review should look at: Declared Activity at Onboarding; Actual Volume; Linked Accounts; Payment Methods; Dispute Rate; Wallet Exposure to Known Risk Categories. A merchant profile is not static. It should be re-reviewed on a schedule — quarterly, semi-annually, or after specific trigger events — and the user's tier should be allowed to move up or down based on what the data shows.

When Enhanced Due Diligence Is Needed

EDD is the layer above standard KYC. It applies when the basic profile is no longer sufficient to explain what the user is doing.

Common triggers for EDD on a P2P platform include: high-risk geography (declared or detected); volume that significantly exceeds the declared tier; unusual velocity (many trades in a short window, especially right after registration); mismatch between user profile and observed trading activity; repeated disputes; wallet exposure to risky clusters that goes beyond a single low-risk hop; patterns suggesting linked accounts under shared control.

EDD does not need to mean blocking the user. It usually means more documentation, source-of-funds questions, possibly a video verification or business documents, and a senior reviewer's signature on the file. The point is to make a defensible decision, not to punish growth.

Transaction Monitoring for P2P Deposits, Escrow, and Withdrawals

Onboarding catches what a user looks like on day one. It does not catch what the user does on day 90. That is the job of transaction monitoring, and on a P2P platform it has to cover more than just on-chain transfers. The zones a P2P monitoring system should cover include:

• Deposits Before a Trade — where the incoming crypto came from.
• Escrow or Locked Funds — how long crypto sits, how often escrow is canceled, who is involved.
• Release of Crypto — was it released after a clean payment, or after a disputed one?
• Withdrawal Addresses — where crypto goes after the trade settles.
• Repeated Counterparties — whether the same pairs of users keep trading with each other.
• Merchant-Level Patterns — aggregated behavior across all of a merchant's trades.

Monitoring on a P2P platform is less about individual alerts and more about patterns over time. A single high-risk transaction may or may not matter. Ten medium-risk transactions from the same merchant over two weeks almost certainly do.

Why One-Time Wallet Screening Is Not Enough

The intuition behind one-time wallet screening is simple: check the wallet when the user signs up or makes a deposit, and if it's clean, you're done. That intuition is wrong for P2P. Three reasons why:

• Wallets Evolve. An address that has no risky exposure today can receive funds from a mixer tomorrow. Risk is a Moving Target.
• Users Change Behavior. A user who initially trades small amounts with low-risk counterparties can pivot quickly toward riskier counterparties, payment methods, or geographies.
• Counterparty Graphs Expand. Every new trade adds new wallets, new users, and new linked addresses to the user's "neighborhood." The risk profile is shaped by that neighborhood, not just by the single address checked at signup.

Alert Review and Escalation

Monitoring without review is just noise. The hard part is not generating alerts — it's processing them in a way that actually produces compliance decisions.

A working P2P review pipeline usually has these stages:

• Prioritize — sort alerts by severity, age, and user tier.
• Review — look at the user's full context: profile, wallet history, trade history, disputes, linked accounts.
• Decide — approve, pause, escalate, or restrict the user/trade.
• Document — record the reasoning behind the decision and the evidence considered.
• Reassess — update the user's risk level based on what was learned.

The document step is what separates a defensible compliance program from a fragile one. The reasoning behind every non-trivial decision needs to be written down, attributed to a reviewer, and timestamped. If a regulator asks two years from now why a particular trade was allowed to settle, "the system said it was fine" is not an answer.

It is also worth being honest about the limits of automation: automated systems prioritize and surface, but they don't make final decisions on complex cases. The Paxful enforcement again illustrates the point — FinCEN's findings emphasized not the absence of tools, but the absence of effective human review and timely SAR filing.

P2P Red Flags Compliance Teams Should Review

A "red flag" is not a verdict. It is a reason to look more carefully. Some red flags resolve into a clean explanation; others mark the start of a real issue. The skill in P2P compliance is being able to tell the difference without freezing every user who looks slightly unusual. Common patterns worth flagging for review on a P2P marketplace:

• High trade volume shortly after registration, especially before basic KYC tiers have been validated.
• Repeated disputes involving different counterparties — not one, not two, but a pattern.
• Frequent cancellations that occur right before settlement, particularly after a counterparty's payment proof is shared.
• Many small trades followed by a single large withdrawal to an external address.
• Payment methods that don't match the user's declared profile, occupation, or country.
• Merchants receiving funds from many unrelated counterparties in a short time window.
• Direct or close-hop exposure to high-risk wallet clusters — sanctioned entities, darknet markets, scam clusters, mixers.
• Multiple accounts that behave similarly, share device or IP fingerprints, or trade with overlapping counterparties.
• Rapid movement of funds out of the platform immediately after a trade closes, often to a fresh withdrawal address.
• Sudden changes in geography that don't fit the user's prior behavior, particularly toward higher-risk jurisdictions.

In practical terms, no single red flag in this list, by itself, means a user is laundering money. The value is in the combination: when several signals appear in the same user file at the same time, the platform has a reason to pause, review, and either clear or escalate.

Records, Evidence, and Internal Review Decisions

P2P compliance has to be defensible. That distinction matters enormously when an audit happens, when a regulator requests information, or when law enforcement asks why a specific account was allowed to operate. A defensible compliance program does two things at once: It makes good decisions. It can prove, after the fact, exactly how those decisions were made. For every meaningful review, a P2P platform should be able to reconstruct the file:

• User ID and merchant ID.
• KYC/KYB status at the time of the decision.
• Trade ID(s) under review.
• Relevant wallet addresses (both platform-side and external).
• Transaction hashes.
• Risk score at the time of review, and the version of the scoring model used.
• Payment method category and any supporting documents.
• Dispute history.
• Reviewer notes — what they considered, what they ruled out.
• Final decision (approve, pause, restrict, escalate, report).
• Timestamps for each step.

This evidence trail is what protects the platform when things go wrong. It is also what makes ongoing improvement possible — a compliance team can only learn from past decisions if those decisions were written down clearly enough to be revisited.

How to Build a Scalable AML Workflow for a P2P Marketplace

Putting all of the above together, the workflow for a P2P marketplace looks less like a checklist and more like a connected pipeline. Each stage feeds the next, and reviews loop back to update earlier decisions. A compact eight-step structure that works well in practice:

• 1. Define the platform's role in the P2P trade flow — what does the platform actually do, custody, match, escrow? This shapes everything else, including regulatory classification.
• 2. Segment users by risk — buyer, seller, merchant, high-volume trader, high-risk user. Treat these as separate populations with separate expectations.
• 3. Apply tiered KYC/KYB — different verification depth for different tiers, with clean rules for moving users between tiers.
• 4. Screen wallets and monitor transactions — both at onboarding and continuously thereafter.
• 5. Track deposits, escrow, releases, and withdrawals — treat the trade flow, not the transaction, as the monitored unit.
• 6. Build alert queues and escalation rules — prioritization, review, and clear authority levels for who can approve, pause, or escalate.
• 7. Keep evidence for every meaningful decision — defensible files, timestamped, attributable to specific reviewers.
• 8. Reassess merchants and higher-risk users over time — risk profiles are not one-time events; they evolve as behavior evolves.

The value of this workflow comes from the connections between steps, not from any one of them in isolation. A great wallet screening tool with no human review is incomplete. A strong review queue with no evidence trail is fragile. Strict onboarding without ongoing monitoring is an illusion of safety.

This is the core idea behind effective AML controls for P2P crypto platforms in 2026: connect user behavior, wallet exposure, trade activity, and review history into one coherent process — and make sure each part of that process can be explained and defended.

FAQ