Retail payment fraud strategy: baseline vs. Titan v2.

Titan v2 adds receipted controls for recent password or recovery-contact changes, dormant-account takeover sequences, new application devices, new or weakly provisioned wallet tokens, gift-card concentration, cross-store velocity, decline probing, daily velocity, and new-account high-value purchases. Missing channel-required risk evidence is held rather than silently treated as trusted.

Success: Titan v2 stopped three additional labeled fraud patterns and increased prevented synthetic fraud value from $2,150 to $3,090.

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

False positive/friction: one legitimate purchase shortly after account recovery received a phishing-resistant step-up challenge.

A mature stolen wallet token can preserve normal device, velocity, merchant, and spending telemetry. That makes it a chain-of-custody problem, not a reason to indiscriminately tighten the existing thresholds.

Planned signals: token issuance and recovery provenance; ownership-continuity drift across device, IP, ASN, carrier, and app telemetry; explicit token→account→canonical-device binding; and issuer/chargeback feedback for delayed labels.

Planned policy: only mature tokens with provenance or continuity anomalies enter a stricter tier, with independent proof of control for high-risk purchases rather than blanket blocking.

Status: designed, not included in the A/B above. It requires wallet-provider/issuer data and a focused privacy-reviewed cohort before enforcement.

Ledger boundary: SQL Server Ledger and similar products provide meaningful tamper evidence within a centrally controlled database. Titan adds portable signed receipts that can be verified outside the originating store, but independent multi-party key custody and external anchoring still require operational validation.

Decision boundary: the current fraud path is constrained, auditable policy over structured transaction, device, wallet, velocity, evidence-freshness, and runtime-health inputs. It is not presented as a high-parameter historical fraud model.

Efficacy boundary: cryptographic integrity proves that a decision record was signed and not altered; it does not prove that the fraud decision was correct. Production claims require representative labeled outcomes and a predeclared evaluation design.

Run PYTHONPATH=src:. python3 scripts/simulate_retail_payment_fraud_ab.py from the repository. Every attempt is submitted over HTTP to the shared Sentinel domain router in fast, dry-run mode.

Simulation source · A/B audit receipt