REPRODUCIBLE EVIDENCE · JULY 18, 2026

The fraud result, the conversion cost, and the miss—all in one receipt.

We submitted the identical deterministic cohort of 27 synthetic retail-app and tap-to-pay attempts over HTTP to /v1/sentinel/evaluate. Six were labeled fraud and 21 legitimate. Both policies traversed domain routing, legacy payment safety, fast council, domain enforcement, and dry-run certification.

+50.00 ppFraud recall
+$940Fraud value prevented
+4.76 ppLegitimate friction
−16.67 ppFlag precision

Shared-runtime A/B

MetricBaseline v1Titan v2Delta
Fraud recall33.33%83.33%+50.00 pp
Simulated fraud value prevented$2,150$3,090+$940
Legitimate friction0.00%4.76%+4.76 pp
Flag precision100.00%83.33%−16.67 pp

What Titan added

Account-recovery timing, dormant-account takeover sequences, application-device age and trust, wallet-token age, provisioning assurance, gift-card concentration, cross-store velocity, decline probing, daily velocity, and new-account high-value controls—all behind an operator-owned policy that request payloads cannot downgrade.

Failure evidence

Success: three additional labeled fraud attempts were stopped after the shared runtime's existing safety layer strengthened the baseline.

False negative: one mature stolen wallet token with otherwise normal telemetry was approved.

Legitimate friction: one valid purchase shortly after account recovery was escalated to phishing-resistant step-up.

Mature-token takeover: designed next, not claimed now

A mature stolen token can keep ordinary device, velocity, merchant, and spending telemetry looking normal. The correct response is a targeted chain-of-custody layer—not blanket friction.

Provenance: record issuance assurance, recovery path, device enrollment, identity tier, and any SIM-swap or low-assurance link history.

Ownership continuity: compare the present controller with historical device, IP, ASN, carrier, geo, and app fingerprints; enforce token→account→canonical-device binding.

Adaptive policy: route only anomalous mature tokens to independent proof of control for high-risk purchases, and learn from privacy-reviewed issuer decisions and delayed chargebacks.

Status: this layer is designed but not represented in the A/B result above. Production enforcement requires wallet-provider/issuer inputs and a focused hard-positive/hard-negative calibration cohort.

Inspect and reproduce

PYTHONPATH=src:. python3 scripts/simulate_retail_payment_fraud_ab.py

Evidence boundary: this is deterministic synthetic runtime evidence, not processor, issuer, wallet-provider, chargeback, or production loss validation. Thresholds require privacy-reviewed production calibration before enforcement.