Skip to content

PATTERN Cited by 1 source

Cross-payment-method fraud network

Pattern

Operate fraud detection across a heterogeneous portfolio of payment methods (cards, bank debits, BNPL, wallets, crypto, real-time payments, cash vouchers) such that fraud signals detected on any one method become evidence on every other method the network covers. The actor is identified by method-orthogonal keys (IP, device fingerprint, browser fingerprint, email) that travel across method silos.

Mechanism

  1. Method-orthogonal signal extraction — IP, device, browser, email signals are captured from every payment-method's transaction representation and normalised to a unified schema.
  2. Unified fraud signal store — signals from card, BNPL, wallet, etc. live in a shared corpus, queryable by any of the orthogonal keys.
  3. Cross-method query at scoring time — when scoring a BNPL transaction, the system queries against all flags accumulated from card / wallet / bank-debit fraud as well as BNPL-specific signals.
  4. Coverage of the new methods themselves — to score a payment method, the network must observe transactions on it. Pre-2026-05 Stripe Radar covered only cards; the 2026-05-27 expansion brought coverage to all supported payment volume globally.

Canonical wiki instance

systems/stripe-radar at 2026-05-27 (sources/2026-05-27-stripe-expanding-stripe-radar-to-protect-more-of-your-business):

"When Radar detects a fraudulent pattern on a transaction, that information becomes available to protect transactions across all payment methods… that same IP address and device fingerprint are now flagged across bank debits, wallets, and BNPL transactions network-wide."

Outcome: 71% suspected-fraud reduction over five months for businesses combining BNPL + wallets + cards (systems/affirm, systems/cash-app, systems/klarna, systems/paypal named).

Trade-off vs alternatives

  • vs single-method fraud detection — siloed by processor; fraud actors trivially shift methods to evade detection. Cross-method propagation closes that gap.
  • vs separate per-method fraud teams — duplicated infrastructure and signal silos; cross-method propagation requires unified signal store and joint scoring.
  • vs federated detection across vendors — cross-vendor signal sharing has privacy / data-licensing barriers; the cross-method pattern works best when one network operator covers many methods (Stripe).

Required substrate

  • Cross-method transaction processing — observe transactions on all relevant methods.
  • Unified signal store — single corpus indexed on method-orthogonal keys.
  • Identity-resolution layer — fingerprints, IPs, emails are noisy keys; some merging logic (graph-based or probabilistic) is implied.
  • Scoring at write time on every method — every method's transactions must hit the unified scoring path.

Sibling patterns

  • patterns/multiprocessor-signal-as-api — extends the network-effect logic to non-processed transactions: even transactions Stripe doesn't process can be scored against the unified corpus.

Caveats

  • Signal-fusion mechanism in the canonical instance is not disclosed. Boolean any-match? Probabilistic identity resolution? Graph-based?
  • Per-method signal-quality variation. A flagged IP is highly relevant to online card fraud, less relevant to in-person cash-voucher transactions.
  • Cross-method false-positive contagion — a false flag on cards now affects the actor's BNPL / wallet experience, not just card.

Seen in

Last updated · 542 distilled / 1,571 read