Shadow mode: how to test fraud rules on live traffic without declining anyone
Shadow mode lets an issuer run a new fraud rule on real payments and see what it would have stopped, without affecting a single cardholder. How to use it well.
Every fraud rule has two costs: the fraud it misses and the good customers it stops. The second cost is the one teams underestimate, because a declined genuine payment rarely shows up as a line item. It shows up as a cardholder who quietly moves their spending to another card.
Shadow mode is how you find out a rule's real cost before you pay it.
What shadow mode is
A rule in shadow mode runs on every live authorisation exactly as it would in production. It records what it would have done: approve, decline or ask the cardholder. Then it lets the payment through untouched.
After a few weeks you have real numbers from your own traffic: how many payments the rule would have stopped, how many of those turned out to be fraud, and how many were good customers.
How to run a good shadow test
- Define success first: the fraud rate you want to catch and the false-positive rate you can accept.
- Run long enough to cover a full billing cycle, so disputes and confirmed fraud have time to arrive.
- Compare against confirmed outcomes, not just alerts. A rule that flags many payments isn't good unless those payments were actually fraud.
- Look at who it stops: new customers, travellers, certain merchants. Concentrated false positives are a design problem, not a tuning one.
- Switch on gradually: one card programme or segment first, then the rest.
Why every 0Fraud layer starts in shadow
Keyed-entry blocking, location matching, online approval and the scam check all ship in shadow mode by default. An issuer sees exactly what each would have done on their own traffic before deciding to enforce it, card programme by card programme.