Test run · July 2026 · not a client deliverable

CADi’s first end-to-end run against a public synthetic benchmark — 6,362,620 PaySim rows on SCM 3.0.0. It demonstrates the mechanism: a decision made at the authorization moment, with a named reason, and the fraud label never in scope. It is not a client deliverable and not a fraud-accuracy claim. It reports recall without the operating point that decides whether the screen could actually be run — the flag alerts on 23.9% of all transactions, roughly 190 alerts for every fraud found — states no baseline comparison, and recorded no provenance stamp while it ran. That re-instrumented run has since landed (SCM 3.2.0, 1 August 2026). It reproduced this run’s confusion matrix exactly - the same 8,012 catches and 201 misses - and added the transaction amount this run never recorded. On that measure recall is 87.5% by value against the 97.6% by count quoted below, because the 201 missed frauds average 5.7× larger than the 8,012 caught. Every recall figure in this document is by count unless it says otherwise.

CADi™ Proof · Internal test run

Decision-time fraud screening, at population scale

A CADi benchmark test run on 6,362,620 transactions · PaySim (Kaggle paysim1) — synthetic mobile-money fraud benchmark

CADi screened 6,362,620 transactions one at a time, deciding at the moment of authorization — before any outcome was known. Without ever being shown which transactions were fraudulent, its BALANCE_EMPTYING_RISK flag surfaced 97.6% of the 8,213 genuine fraud cases for review - 87.5% of that fraud weighted by the amount at stake.

97.6%

of real fraud flagged, by count

87.5%

of real fraud flagged, by value

23.8%

flag-fire on clean traffic

6,362,620

transactions screened

Why this CADi report is better than a conventional analysis

A standard fraud analysis is retrospective: it fits a model on historical rows including the fraud label and reports a score after the outcome is known. This report documents something a conventional analysis structurally cannot produce.

Dimension	Conventional fraud analysis / dashboard	This CADi run
When the call is made	After the fact, on outcomes that already happened	At the authorization moment, before the outcome exists
Needs the fraud label?	Yes — trains on it	No — the label was never in scope; the pattern was caught structurally
What it outputs	A probability / score	A live routing action + a named reason (`BALANCE_EMPTYING_RISK`) an operator can act on
Auditability	Model weights; reason often opaque	Every decision carries its detector flags and an attached intervention (100% of decisions here)
Coverage on this run	—	Recalled 97.6% of 8,213 genuine fraud cases across 6,362,620 transactions, label-free - 87.5% of that fraud by value

The distinction in one line: a dashboard can tell you next month that accounts drained to zero turned out to be fraud; CADi raises a named flag this second, on a transaction whose outcome does not yet exist — without ever having been shown a fraud label.

Where the risk concentrated

The flag fired overwhelmingly on the transaction types that actually carry the fraud, mirroring the real drain-to-zero pattern:

Transaction type	Count	Flag-fire rate
CASH_OUT	2,237,500	42.9%
PAYMENT	2,151,495	15.2%
CASH_IN	1,399,284	0.0%
TRANSFER	532,909	42.9%
DEBIT	41,432	13.6%

What this is — and is not

Synthetic benchmark. PaySim is a synthetic dataset that reproduces the statistical structure of real mobile-money transactions. These results demonstrate the engine's mechanism, not a production fraud-detection accuracy figure.
The engine never saw the label. The fraud label travels out-of-band and is applied only after each decision, to score it. CADi decided at the authorization moment on the information visible then — no outcome leakage.
Recall by count flatters the screen. Weighted by amount rather than transaction count, recall is 87.5%, not 97.6%. The 201 frauds it missed average 5.7× larger than the 8,012 it caught, with a median sitting exactly on PaySim’s 10,000,000 per-transfer cap: the predicate fires on an account drained to zero, so a capped fraud against a larger balance leaves a residue behind and escapes. That is structural rather than statistical - the screen systematically misses the largest frauds. Measured on the re-instrumented run described above; amounts are notional simulator units, not money.
A first-line screen, not a verdict. The BALANCE_EMPTYING_RISK flag is recall-oriented: it is designed to surface risk for review, and flags a share of legitimate balance-emptying activity too - precision is 0.53% at the true base rate.
Routing is pinned to AUGMENT for this payment workload by design; the demonstrable signal here is the explainable risk flag, not route variation.
Computed, not hand-entered — but not reproducible. Every figure was computed from results.json over all 6,362,620 transactions at render time. That run recorded neither its engine commit nor its input hash, so these figures can be read and cited but cannot be re-derived. Its artefacts have since been sealed into runs/paysim-3.0.0/ and are under version control, which makes the numbers hash-checkable — a different property from reproducibility.