Chapter 26 — Risk, Compliance & Monitoring

The Email No Merchant Wants

It arrives on a Tuesday morning, from a no-reply address at your payment provider:

"Following a review of your account, we have determined that we can no longer support your business. Your account will be closed in 30 days. Funds may be held in reserve for up to 180 days. This decision is final and we are unable to share further details."

No warning. No appeal. No explanation. Your payments still worked yesterday; your customers are still buying; your chargeback rate looks fine. And yet somewhere inside your PSP, a system — or a person reading that system's output — decided you were no longer worth the risk.

To understand that email, you need to understand the machinery this chapter describes: the two great policing systems that watch every transaction you process, and the quietly enormous difference between them. Because here's the thing almost nobody outside the industry realizes: fraud and money laundering are handled by different systems, answering to different masters, playing entirely different games. Confuse the two and you'll misread every risk conversation you ever have with a bank or PSP.

Two Games, Two Referees

Start with the sharpest version of the distinction.

Fraud prevention protects money — yours, the issuer's, the cardholder's. Fraud is someone taking funds that aren't theirs: a stolen card, an account takeover, a customer who lies about not receiving the goods (the friendly fraud we met in Chapter 13). Fighting it is a business decision governed by economics: every fraud dollar blocked is revenue saved, and every legitimate customer wrongly declined is revenue lost. Companies fight fraud because it costs them.

AML — anti–money laundering — protects the financial system itself. Money laundering is making criminally-earned funds look legitimate: drug proceeds becoming "consulting income," sanctions-evading transfers dressed as e-commerce. The victim isn't any single merchant; it's the integrity of the system that lets everyone trust that money is what it claims to be. Fighting it is not a business decision. It's the law — in the US under the Bank Secrecy Act, in Singapore under MAS notices, in the EU under successive AML directives — and the penalty for failing isn't lost revenue, it's fines and criminal exposure for the institution.

Here's the asymmetry that explains so much industry behavior: a bank can choose to tolerate some fraud (and they all do — more on false positives below). A bank cannot choose to tolerate money laundering. Fraud losses are a P&L line; AML failures are an existential legal event. When a compliance officer overrules a profitable business decision, this asymmetry is why.

Table 1: Fraud vs. AML. Same transaction stream, different games. Fraud is a cost to manage; AML is a law to obey.

The Fraud Game: Milliseconds and Trade-offs

Recall from Chapter 4 that an authorization completes in about two seconds. Somewhere inside that window — usually a slice measured in tens of milliseconds — the transaction is scored for fraud, often twice: once by the merchant's PSP, once by the issuer. What happens in that slice?

Velocity Rules: The Oldest Trick That Still Works

The simplest fraud signals are about rate. A card that made three purchases this month suddenly makes nine in an hour. One device tries six different card numbers in ten minutes. A shipping address receives orders paid by fourteen distinct cards.

These are velocity rules: thresholds on how often something — a card, a device, an email, an address, an IP — can appear in a time window. They're crude, explainable, and devastatingly effective against the most common attack patterns: a fraudster testing a batch of stolen card numbers behaves nothing like a human doing their shopping, and velocity rules see it instantly.

Why it works is worth stating plainly: fraud has different economics from commerce. A legitimate customer buys when they need something. A fraudster with 500 stolen cards is running a pipeline — test the card with a small charge, confirm it's alive, extract value fast before the cardholder notices. Pipelines have throughput. Throughput is velocity. Velocity is visible.

Risk Scoring: Beyond the Rules

Rules catch patterns you've named. Modern fraud engines layer on machine-learned risk scores that weigh hundreds of signals at once: Does the device fingerprint match past sessions? Does the email address predate the order or was it created an hour ago? Is the shipping address a freight forwarder? Does the time-of-day fit the cardholder's history? Is the basket typical — or is it the maximally-resellable combination of gift cards and electronics?

Each answer nudges a score; the score crosses one of three thresholds. Approve (most transactions, invisibly), decline, or the middle path we met in Chapter 11: challenge — route through 3DS and make the customer's bank authenticate them, which also shifts fraud liability to the issuer.

Technical note — The three-outcome design is why 3DS exists commercially, not just technically. A binary approve/decline forces you to price uncertainty as loss. A challenge lets you convert uncertainty into a cheap authentication step — friction for the suspicious few instead of declines for everyone in the gray zone.

The False-Positive Trap

Now the counterintuitive part, and the single most important operational fact in merchant-side fraud: the biggest fraud cost for most legitimate businesses isn't fraud. It's the fraud engine.

Every decline of a legitimate customer — a false positive — costs the full basket, not a fraud-loss fraction of it. And unlike a chargeback, it's invisible: no report line says "good customer, wrongly refused." The customer just sees "payment declined," feels vaguely accused of a crime, and buys from your competitor. Industry studies (the Javelin and Merchant Risk Council literature is consistent on the direction) have repeatedly found that false-decline losses exceed direct fraud losses for card-not-present merchants — often by multiples.

So tuning a fraud system is not "block more fraud." It's an explicit trade: precision against recall, fraud loss against conversion loss, measured in dollars on both sides. The best fraud teams look less like police and more like actuaries — they know exactly how much fraud they are choosing to accept, because the alternative costs more. Zero fraud is trivially achievable: decline everything. The game is optimal fraud, not minimal fraud.

The AML Game: Know Your Customer, Watch Your Customer

Fraud checks ask, "is this transaction what it claims to be?" AML asks a deeper question: "is this money — and this customer — what they claim to be?" That question gets asked at three moments: when a customer arrives, on every transaction, and continuously across the relationship.

Onboarding Is Underwriting: KYC and KYB

Know Your Customer (KYC) is the identity check when an account is opened — verifying that the person exists, is who they claim, and isn't on a prohibited list. Its business-facing sibling, Know Your Business (KYB), does the same for companies, and goes further: who actually owns this entity? Regulators require identifying ultimate beneficial owners — the humans behind the holding companies — precisely because shell-company nesting is the laundering move.

Here's the reframe that makes PSP behavior make sense: when a PSP onboards a merchant, it isn't "signing up a user." It's underwriting a risk — extending something very much like credit. The PSP is fronting its own standing with banks, card networks, and regulators, and vouching that your transaction stream is legitimate. That's why onboarding asks intrusive questions about your business model, why "just let me process payments" isn't a thing, and why certain categories (gambling, adult content, crypto, CBD, travel with long delivery windows) face extra scrutiny or flat refusal: their risk — fraud, chargebacks, and regulatory — exceeds many PSPs' appetite.

Sanctions Screening: The List You Cannot Ignore

Separate from laundering detection is sanctions screening: checking every party against lists of prohibited people, companies, and countries — OFAC's SDN list in the US, plus UN, EU, and local equivalents like MAS's lists in Singapore. This isn't risk-scored or probabilistic. Sanctioned is sanctioned; the payment must not move, at any dollar amount.

The operational reality, though, is messy in a very human way: names. Screening is fuzzy matching against transliterated names from dozens of languages, and the lists contain thousands of entries with aliases. The result is a flood of false positives — ordinary customers who happen to share a name with someone on a list, held in a review queue while a compliance analyst checks dates of birth and addresses. If you've ever had a wire transfer inexplicably delayed by "additional checks," there's a good chance you brushed against a screening queue. Annoying, universal, and non-negotiable — the fines for missing a true match are institution-shaking, so everyone tolerates the noise.

Transaction Monitoring and the Report You Never See

Past onboarding and screening, the ongoing layer is transaction monitoring: software watching patterns across the whole relationship. The classic tells have names. Structuring: breaking amounts into chunks just under reporting thresholds. Round-number transfers that pass straight through an account. Activity wildly inconsistent with the stated business — the "bookstore" settling most of its volume at 3am from one foreign IP range.

When monitoring flags something that an analyst can't explain away, the institution files a Suspicious Activity Report (SAR in the US; Suspicious Transaction Report / STR in Singapore and elsewhere) with the national financial intelligence unit — FinCEN in the US, STRO in Singapore.

And here is the strangest rule in the whole system, the one that explains that Tuesday-morning email: tipping off is a crime. The institution that files a SAR is legally prohibited from telling the subject. Not "discouraged" — prohibited, with criminal penalties. An institution that suspects you can investigate you, report you, and exit the relationship, and at no point is it allowed to say why. "This decision is final and we are unable to share further details" is sometimes evasive customer service. Sometimes it's the law talking.

Who Actually Carries Which Burden?

A transaction touches a merchant, a PSP, and banks — so who owes what? The pattern: fraud is everyone's problem in proportion to their losses; AML obligations concentrate on whoever is licensed.

Merchants carry fraud economics (chargebacks land on them, per Chapter 13) but generally no AML license obligations — unless the business itself is regulated (money services, gaming, high-value dealers). Your AML exposure is indirect: you must stay legible and legitimate to your PSP.

PSPs and acquirers are licensed financial institutions. They owe regulators full AML programs — KYB on every merchant, screening, monitoring, SAR filing — and they answer to card networks for the fraud and chargeback performance of their portfolio. They are the choke point where both games meet, which is exactly why they can seem paranoid.

Banks carry the heaviest statutory burden — the full Bank Secrecy Act / MAS / EU apparatus, at the scale of every account they hold, including the PSPs themselves. When a bank threatens to "de-risk" a PSP, the PSP tightens its merchant book overnight. Pressure flows downhill.

Diagram: Two Policing Tracks on One Transaction. Fraud checks run inline and answer in milliseconds. AML runs alongside and can take days — and its outcomes (SARs, exits) are ones the customer never sees coming.

Why PSPs Off-board Merchants Suddenly

Now we can fully decode the Tuesday email. A PSP terminates a merchant for reasons that cluster into four groups, and understanding them is your best protection.

Chargeback and fraud performance. The card networks run formal monitoring programs — cross a threshold (the commonly cited line is around 1% of transactions, with network-specific details) and the acquirer enters a remediation program with escalating fines. Long before that, the PSP acts. As Chapter 13 explained, your chargeback ratio is effectively your credit score with your PSP.

Risk-appetite shifts. You didn't change; the PSP did. A new banking partner, a regulator's knock, a board decision to exit a category — and every merchant in that category gets the email the same quarter. This is the most common "but we did nothing wrong!" scenario, and it's true: you didn't. The ground moved.

Compliance red flags. Monitoring surfaced something — a beneficial-ownership mismatch, transaction patterns that don't fit your stated model, a sanctions brush. Because of tipping-off rules, this category is indistinguishable from the others from the outside. You will never be told which one you were in.

Misrepresentation. The merchant who said they sell software but processes gambling volume; the "consultancy" running transaction laundering for an unonboardable business (the industry term is transaction laundering, and PSPs hunt it actively). These exits are deserved, but they also explain the intrusiveness everyone else endures — the questions exist because people lie.

One more institution completes the picture: MATCH (Member Alert to Control High-risk Merchants), a Mastercard-operated list where acquirers record merchants they've terminated for cause — excessive chargebacks, fraud, laundering, PCI failures. Every acquirer checks MATCH during onboarding. Land on it and you'll find that no mainstream PSP will take you for five years. It is the closest thing merchants have to a shared blacklist, it has no meaningful appeal process beyond correcting factual errors through the listing acquirer, and merchants usually discover it only after the second or third mysterious rejection.

The defensive playbook falls out directly: keep chargebacks far below thresholds (Chapter 15's dunning and Chapter 13's dispute practices are your tools), describe your business honestly and update your PSP when your model changes, answer information requests fast and completely, and — if your category is even slightly exotic — maintain a second processing relationship before you need it. Redundancy in processors, like the vault portability of Chapter 25, is insurance you buy before the fire.

What Comes Next

Step back and look at the machinery of Part VI as a whole. PCI-DSS guards the data. Vaults make the data safe to not hold. Fraud engines and AML programs police the flow — and every one of these systems exists because card payments are reversible, identity-bound, and intermediated. Chargebacks need someone to arbitrate. KYC needs someone to check. SARs need someone to file. The entire control structure lives inside institutions.

Which sets up the most interesting question in modern payments: what happens when someone builds a payment rail with no intermediaries to do any of this — where transactions are irreversible by design, accounts are pseudonymous key pairs, and there is no institution to file a report? Is that liberation from the compliance stack, or the loss of everything it protects?

That's Part VII. In Chapter 27, we look at what crypto actually solves — and what it quietly gives up.

Sources

• FinCEN — Bank Secrecy Act requirements, SAR filing rules and confidentiality (tipping-off) provisions
• OFAC — Specially Designated Nationals (SDN) list and sanctions compliance guidance
• Monetary Authority of Singapore — PSN01/PSN02 AML/CFT notices for payment service providers; STRO reporting requirements
• EU Anti–Money Laundering Directives (AMLD framework)
• Mastercard — MATCH system documentation and Excessive Chargeback Program rules; Visa — Acquirer Monitoring Program materials
• FATF — Recommendations on customer due diligence and beneficial ownership
• Merchant Risk Council and Javelin Strategy research on false-decline costs for card-not-present merchants
• Stripe and Adyen documentation on restricted business categories and merchant monitoring