Fraud, security, and compliance
- Add inline fraud scoring at the money moments with a strict latency budget and a fail-open/fail-closed policy per decision.
- Establish the security spine — mTLS, secrets, least privilege — and the compliance posture (PCI scope, privacy).
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.
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.