Every Road Leads There: Spotting an Insider in Four Days of Refunds
The challenge
Kestrel Retail refunds around forty orders a day across three channels, and the finance team only looks at the total. This month the total climbed eleven percent with no matching rise in returns, so they exported four days of refund events and asked for a second pair of eyes. Every row here is an approved refund by a real operator against a real order, with a plausible note attached. Nothing is missing and nothing is malformed. Money is leaving through a door that looks exactly like every other door. Follow it and give the card it is landing on.
What you'll learn
- Compare two fields that should normally agree and investigate only the exceptions
- Identify convergence on a single destination as a fraud signal
- Separate a legitimate repeated pattern from a fraudulent one using the customer field
- Recognise amounts deliberately placed under an approval threshold
- Explain why a per-transaction review misses a pattern that spans transactions
Skills tested
Prerequisites
- What a card refund is
- Reading a tabular event log
How it works
Fraud that survives review rarely looks wrong one row at a time. Each of these refunds is against a real order, for goods that were really bought, approved by an operator who is allowed to approve it, with a note that describes a situation which genuinely occurs. Reviewed individually, every one of them passes. The signal only exists across rows.
The technique that finds it is to pick two fields that should agree and look only at where they do not. A refund returns to the card that paid, so paid_last4 and refund_last4 match on ordinary rows. Filtering down to the mismatches turns twenty-eight rows into twelve, and at that size the convergence on one destination is visible without any tooling at all.
The amounts are the other half of the story. Every fraudulent refund sits between 178 and 256, just below the 260 at which a supervisor has to countersign, and none of them is a round number. Thresholds shape behaviour: publish one and you have told an insider precisely how large each withdrawal may be, and a run of amounts that hug a limit without crossing it is itself evidence.
Common mistakes
- Answering 8827. Two refunds do go to it from a card that did not pay, but both belong to the same customer and the note says the card expired. One customer with one replacement card is exactly what an honest exception looks like.
- Answering 0455 or 1178. Both repeat across several rows, but as the card that paid and was refunded, for a customer who simply shops often.
- Searching 7712 and reading the first hit. It appears once as a legitimate
paid_last4on an in-store refund, which proves nothing on its own. - Naming the operator and stopping. The question asks where the money went. The operator matters, but the destination card is what freezes the money and identifies the account behind it.
- Scanning the amounts for something round. Nothing here looks like a withdrawal. That is deliberate.
How to defend against it
Make the destination a controlled field rather than an operator's choice.
- Refund to the original payment instrument by default, with no override in the interface. Where a genuine exception exists, route it through a separate process with a second approver and a documented reason code.
- Alert on any destination that receives refunds for more than one customer in a rolling window. One query, and it would have fired on day one.
- Stop publishing the approval threshold to the people it constrains, and add a second control that is not value-based, such as a daily count of exception refunds per operator.
- Reconcile refund destinations against customer payment records nightly. A destination that appears on no customer record is either a data problem or a theft, and both need answering.