Fraud Detection

In one line: this is the first adversarial subsystem in the course, and adversarial systems obey different rules — they do not converge, they cannot be fully automated, and getting them wrong in the safe direction is also expensive.

Why fraud is a different class of problem

Although fraud represents a small fraction of gross bookings, it can result in disproportionate revenue loss. If not detected and mitigated early, fraudulent behavior can scale rapidly and increase systemic risk.

Detecting fraud is challenging because methods evolve, as with zero-day security exploits. Our system requires intelligence to detect anomalies and human-led audits to ensure accountability for automated decisions.

Three properties that make this unlike availability or latency

It does not converge. Engineer availability once and it stays engineered. Fraud defences decay continuously, because an adversary is studying them. The zero-day analogy is apt: the defence and the attack co-evolve, so a fraud system that is not being actively updated is getting worse.

It scales adversarially. A working exploit gets shared. Fraud does not grow linearly with usage — it grows with how long the hole stays open, which is why the design stresses detecting it early.

It is asymmetric in cost. A small fraction of bookings, a disproportionate loss — because a fraudulent trip does not merely fail to earn, it pays out. Every fraudulent payout is a direct transfer from the platform to an attacker.

That third point connects to Lesson 1. The thing being gamed is the thing being paid out. Compare that building block, where fraud distorted a ranking — bad, indirect, and slow. Here it produces money, immediately.

Any requirement with an adversary behind it needs ongoing investment rather than a one-time design. Saying that in an interview signals you have thought about operations, not just architecture.

What counts as fraud

Every one of these attacks an input the system trusts

Sort them by what they exploit, and a pattern appears:

Every attack targets something the client asserts and the server accepts.

That reframes fraud detection usefully: it is not a bolt-on component, it is the consequence of a design that trusts the edge. Lesson 5 flagged this concretely — confirmPickup takes a client timestamp that determines the fare — and the fix there was to have the server stamp time and treat the client's claim as evidence.

The best fraud detection is a design that does not need it. Every input you can derive server-side rather than accept from a client is an attack removed. Server-stamped times, ETAs the system computed itself, cross-checks between the driver's and rider's independent position streams — each closes a category.

Collusion is the exception and the hardest, because it defeats cross-checking: if driver and rider are the same person, their two streams agree perfectly. That is why detection has to look at patterns across trips — the same pair repeatedly, unusual timing, accounts created together — rather than at any single trip.

RADAR

Uber introduced RADAR, a human-assisted AI solution. RADAR analyzes activity time series to generate blocking rules, proactively stopping unseen fraud in real time. The model incorporates human knowledge for continuous improvement.

RADAR identifies potential fraud attempts and generates prevention rules. A fraud analyst then reviews these rules to approve or reject them. This feedback is sent to the protection system to enforce decisions and back to the detection model to improve future accuracy.

The model generates rules rather than verdicts, and that is the key design decision

Read carefully what RADAR outputs: not "this trip is fraudulent" but a blocking rule that an analyst approves before it takes effect.

That indirection buys four things a direct classifier cannot:

Rules are inspectable. An analyst can read "block accounts created within an hour that share a payment method and complete trips under 90 seconds" and judge it. A model score of 0.87 offers nothing to judge.

Rules apply to future cases. Approve one and it catches the whole pattern going forward — an intervention that scales past the examples that produced it.

Approval is accountable. Someone decided. When a legitimate driver is blocked, there is a decision to appeal and a person who made it. The design names this: "human-led audits to ensure accountability for automated decisions."

The feedback improves the model. Rejected rules teach the detector what looks suspicious but is not.

The honest cost is stated too: "the proposed model incorporates human review, which limits horizontal scalability, but this oversight improves decision quality and reduces false positives."

Deliberately accepting a scalability ceiling to gain accountability is a legitimate trade, and naming it is what makes it a decision rather than an oversight. It is the same conclusion that building block reached about content moderation — automate detection, keep humans on consequential judgements.

False positives are the expensive error, and the design under-weights them

Fraud systems are usually discussed in terms of catching fraud. The other error is worse here.

Block a fraudulent driver: you save a fare's worth of loss. Block a legitimate driver: you take away someone's income, they cannot work, and they may leave the platform permanently.

The costs are wildly asymmetric, and in the direction opposite to intuition. A ride-hailing platform's supply side is its scarcest asset.

There is a second-order problem too: fraud signals correlate with legitimate unusual behaviour. A driver working an unfamiliar city takes inefficient routes. A driver in a poor-signal area produces GPS traces that look manipulated. A new driver has no history to check.

So the system will disproportionately flag new and atypical drivers — which is precisely the population you most want to retain.

That is the strongest argument for the human in the loop, stronger than the accountability one. When false positives cost more than false negatives, automated blocking is the wrong default — the model should raise the case and a human should decide.

Two timescales

The system examines data across two time dimensions:

• Trip time: real-time monitoring of trip completion. For example, checking if driver and rider locations match, or analyzing traffic data to distinguish between intentional slowing and actual congestion.
• Payment settlement time: analysis of payment processing data, which may take days or weeks to settle.

Real-time detection prevents; settlement-time detection recovers

The two dimensions are not two implementations of the same thing — they intervene at different points with different powers.

The distinction matters because collusion is only visible at the second timescale. A single trip between colluding parties looks perfectly normal — the locations match, the route is sensible, the payment clears. Only across many trips does the pattern emerge: the same pair, repeatedly, at odd hours.

The examples for trip time are the good part. "Checking if driver and rider locations match" uses two independent position streams to verify each other — the strongest available defence against GPS spoofing, because an attacker must compromise both devices consistently.

And "distinguishing intentional slowing from actual congestion" uses fleet-wide traffic data as a control: if fifty other drivers on that road are also slow, it is traffic; if only this one is, it is not. Use the population as the control group — a genuinely good idea and one that only works at scale.

The split is a latency budget question. A rule that runs in a millisecond can gate a ride; a model that correlates behaviour across weeks cannot, so it runs behind and feeds decisions on the next transaction rather than this one.

Next: checking the design against its requirements.