Shadow Mode vs Enforcing for AML Pilots

AML pilots fail in two directions. You enforce on week one, fuzzy matches halt onboarding, and the business asks you to turn the control off. Or you stay in “we are watching it” forever, a confirmed hit never holds a payout, and the first real designation is a post-mortem.

Shadow mode and enforcing mode are the names I use so those two failures stay distinct. Shadow means you run the screenings and AML events, you store the outcomes, and the customer does not feel a new hold. Enforcing means a named outcome changes a named product state: activation stays pending, a withdrawal stays unpaid, a counterparty stays blocked until compliance records a decision.

You need both postures. You should not skip the first.

What shadow is for

Shadow is a measurement week, not a softer product. Call the same AML screening API you will use later. Persist the screening id and, for activity checks, the externalEventId. Route nothing to the customer. Then look at the pile.

Count AUTO_CLEAR, REVIEW, and CONFIRMED on onboarding screens. Count ALERTED on AML events if you are already sending those. Do it daily, not in a month-end slide. Compare the REVIEW count to the number of hours your investigators actually have. If Tuesday’s list update would have created more cases than the team can finish by Thursday, you are not ready to hold money. You are ready to tune matching fields, add date of birth, or narrow which flows you will enforce first.

I also read a sample of REVIEW cases in shadow. Possible matches are supposed to exist. The question is whether a person can clear them with the identity you sent. If every case is “same first name, no DOB,” the fix is the KYC export, not a lower sensitivity that you will regret.

Do not use shadow as a place to hide a confirmed hit. If shadow produces CONFIRMED, treat it as an operational incident even if the product did not block. Someone should open a case and decide what to do with the live account. Shadow means the *automatic* hold is off. It does not mean confirmed listings are trivia.

What enforcing has to name

Enforcing without a product contract is how you get five different pending states and a support script that says “technical issue.” Write the mapping down.

For onboarding, REVIEW and CONFIRMED hold activation. AUTO_CLEAR does not. For payouts, ALERTED is a review signal, not an automatic hold — pause fulfillment only if your policy says so. For counterparties, a confirmed hit stops the payment and leaves the sender account usable unless your policy says otherwise.

Give support one plain-language status per held flow. “Pending compliance review” plus the screening id or externalEventId is enough. “Risk score high” is not a status. AML outcomes here are not ALLOW / BLOCK. Do not reuse the fraud vocabulary on the same banner or you will train the room to treat a possible watchlist match like a velocity rule.

Store screening ids and externalEventId values in the case system before you flip the flag. If enforcing starts and the case cannot find the id, you will unblock people by Slack. That is not a control.

How I cut the flag over

I enforce one flow at a time. Onboarding holds first, because the customer is not mid-payout and the unwind is cheaper. Payouts second, after the queue has proven it can finish overnight hits. New counterparties third. I do not enforce login locks from an AML screen unless compliance asked for that in writing. Screening is not device intelligence.

False positives get a review before I expand coverage. If the first enforced week is all transliteration noise, I stay on that flow until the case quality improves. Expanding enforcing to “the whole book” is how shadow’s lessons get thrown away.

The API flow does not change when you flip the flag. The AML integration guide is the same calls. What changes is whether your product reads REVIEW as a hold. Keep a rollback: a feature flag that returns you to shadow without undeploying the integration. You will use it the first time a list update lands on a holiday.

If you want a longer view of the book after go-live, ongoing monitoring when lists change is the next control. Pilots decide how loudly the product reacts. Ongoing monitoring decides whether you still look after signup. Do both, in that order.