Abuse-ring detection for card-not-present fraud, priced in rupees rather than ranked by AUC.
A merchant does not lose money to fraudsters one at a time. They lose it to rings — one operator running many cards through a handful of shared addresses, devices and email domains. Scored individually each transaction is unremarkable; scored as a group the operator is obvious.
Card fraud is not a rounding error and it is not shrinking. What makes it worse than the sticker price is that a reversed payment costs a merchant several times the disputed amount: the goods are gone, the money is clawed back, a penalty is levied, and staff time is spent contesting it.
What follows is the measured case: §1 lays out the pipeline and where its leakage boundary sits; §2 reports held-out detection performance against an ablation with the ring layer removed; §3 turns the score into an operating point priced in rupees; §4 breaks each honesty guarantee in turn to show what it cost; §5 shows the review queue an analyst would work. §6 describes the dispute side, which is parameterised rather than measured, and says so. (§ is the section sign — §3 reads “section 3”.)
This page reports held-out performance for a ring-aware detector on the IEEE-CIS card-not-present
dataset, whose ground truth is reported chargebacks. Every figure is generated from the artefacts in
reports/ by scripts/build_site.py, so this page cannot drift from the
experiment that produced it.
Two execution planes, not one pipeline. Training runs on a schedule over history; scoring runs
per transaction the moment it arrives. They share state and, critically, share the same feature
code — features/causal.py is the identical module in both, which is why performance
measured offline means anything online.
every node links to the file that implements it
loading diagram…
Evaluated on transactions from a period strictly later than all training data, with a 7-day embargo at the boundary. The ablation column retrains the identical pipeline with every ring and entity feature removed.
Table 1 Detection performance with and without the ring layer. precision@100 is the one measure where the ring model does slightly worse; both are saturated at the top of the ranking.
Precision and recall trade against each other, so the threshold is not a modelling choice — it is an economic one. Both mistakes are priced: a missed fraud costs the goods, the amount and a penalty fee; a blocked legitimate customer costs that order's margin, scaled for the share who never return.
Drag the threshold. Flagging everything catches all the fraud and is catastrophic.
Claiming a leakage boundary is worth nothing unless the gap is measured. Each guarantee was broken in turn, changing nothing else. The variants below are not results — they are the size of the overstatement avoided.
Getting this wrong, first time
The first version of this ablation replaced the causal features rather than leaking the same ones. That also dropped the lag-gated fraud-history feature, so the “leaky” variant scored 10.5% worse — proving nothing except that it had lost an important feature. A leakage test must vary causality and nothing else.
A ranked list of transaction identifiers is not a product; the reviewer still has to reconstruct what happened. Each ring below carries a generated case file stating what links the accounts, what the model reacted to, a graded and reversible action, and — mandatory — the most plausible innocent explanation.
Table 2 Highest-scoring multi-card rings in the held-out period. Select a row for its case file.
Detection is never perfect. When a chargeback does arrive, a merchant can contest it — and published figures put the gross win rate at 44.6% but net recovery at 10.7%. That gap is the whole argument for triage: contesting everything is what produces it.
There is no public dataset of dispute outcomes, so rather than train a win model on invented labels, the detector is inverted. Conditioned on a chargeback having been filed:
Table 3 How the fraud score is read once a dispute exists.
| Fraud score | Reading | Action |
|---|---|---|
| High | The card really was stolen; the cardholder is a victim telling the truth | Accept — unwinnable, and fighting a real victim is wrong |
| Low | The transaction looked legitimate on every signal yet is disputed — the friendly-fraud signature | Contest |
So a model validated on real labels does the work, and the ethical constraint falls out of the
same signal. Where the decision is to contest, an agent drafts the Razorpay evidence payload; every
document id is checked against the merchant's actual inventory in code, because a
hallucinated id is not a formatting bug but a fabricated evidence claim sent to a bank. The payload
is hard-wired to draft.
This section carries no measured results, and should not be read as if it did. The triage economics are parameterised from the published figures above; the evidence documents used in testing are illustrative, since IEEE-CIS contains no merchant document store.
Every number on this page is regenerated by the commands below. The page reads
docs/data.json, which build_site.py writes from reports/.
uv venv --python 3.11 && uv pip install -e . ringfence data download ringfence data prepare --tag main ringfence train --tag main ringfence train --tag noring --data-tag main --no-ring-features ringfence ablate --force python scripts/build_site.py --with-casefiles