Fraud, security, and compliance
From 1.8: the ledger sees every cent. From 2.10: the feature store computes behavioral features. From 2.6: every new synchronous hop needs a timeout, a budget, and a fallback — fraud scoring is a new hop on the payment path, so it inherits all three.
At first glance, it seems reasonable to use one fraud timeout policy everywhere because the same scorer serves every decision. The choice optimizes the common case by weakening the boundary that matters. Failure policy follows reversibility and blast radius: recoverable activity may continue with audit evidence, while irreversible payout waits for a decision.
A marketplace moving money attracts adversaries: stolen cards, GPS-spoofing drivers farming incentives, collusion rings (fake riders "riding" with colluding drivers), promo abuse, account takeover. Defense is layered. Inline scoring at the decision moments — signup, ride request, capture, payout — combines fast rules (velocity checks, device fingerprints, impossible-geometry checks against the trip trail from 1.7) with a model reading feature-store features, under a hard 150 ms budget. The availability-critical design choice is the failure policy per decision: if scoring is down, ride requests fail open (fraud loss is bounded and recoverable; blocking all rides is a self-inflicted T0 outage) while payouts fail closed (money leaving the platform is irreversible — a payout can wait an hour). Asynchronous behind that: graph analysis over the silver layer catches collusion rings that no single-event score can see, feeding case tools for a human trust team.
sequenceDiagram
autonumber
participant T as Trip service
participant PAY as Payments
participant FR as Fraud scoring (150 ms budget)
participant FS as Feature store
participant PSP as PSP
participant Q as Review queue
T->>PAY: capture fare {trip id}
PAY->>FR: score {rider, driver, trip trail, device}
FR->>FS: online features — velocities, history
FR-->>PAY: score 0.93 — HOLD
PAY->>Q: hold capture, open case (driver payout unaffected? policy: platform absorbs during review)
Note over PAY,Q: human review or model re-score clears or confirms
Q-->>PAY: cleared
PAY->>PSP: capture (idempotency key unchanged — 1.8)
Note over PAY,FR: if FR times out at 150 ms → capture proceeds, score async, clawback if needed. Fail open on captures, fail closed on payouts.
The security spine, briefly but non-optionally: mTLS between all services with workload identities (the mesh from 2.2 provides it); secrets from a vault, short-lived, never in images or env files; least-privilege IAM per service; audit trails on every human production access (the support-console discipline of 1.10, generalized). Compliance: PCI scope is kept microscopic — card numbers touch only the PSP's hosted fields and our payments service sees tokens, so the auditable surface is one service, not fifty; privacy regimes (GDPR-class) demand PII tagging (done at ingestion, 2.10), retention limits, and deletion workflows that reach backups and the lakehouse — deletion is a pipeline, not a SQL statement.
Fraud models train on fraud you caught — survivorship bias in production. Hold out a small random sample from enforcement (score-but-don't-block) to measure ground truth, or the model's precision numbers become a comfortable fiction while novel fraud walks past.