Driver Promotions with Fraud Detection

Overview

A driver incentive system for a mobility platform: targeted promotions with eligibility rules across vehicle types, regions, and promotional conditions — built with fraud detection as a core design constraint rather than a later patch.

The Problem

Promotions hand out money, which makes them an attack surface. Any gap in eligibility checks becomes a farming opportunity — fake or manipulated activity shaped to qualify for payouts. The system needed to reward genuine driver behavior while making exploitation uneconomical.

A second, subtler problem: promotions are region-scoped. If two promotional geofences overlapped, a single ride could qualify for conflicting promotions — an ambiguity with direct financial cost.

Requirements

• Configurable eligibility: vehicle types, regions, time windows, and promotional conditions
• Layered validation so that no single check is a single point of failure
• Geofence integrity: promotional regions must not overlap
• Auditable decisions: every granted or denied payout traceable to the checks that produced it

Architecture

Eligibility evaluation runs as a pipeline of independent checks — each promotion decision passes through multiple validation layers covering ride authenticity, driver eligibility, and promotional conditions. The layered design means defeating any single check is insufficient.

Geofence integrity is enforced at the data layer with spatial geometry in SQL: overlap detection runs when promotions are created or modified, making conflicting regional promotions structurally impossible rather than procedurally discouraged.

Trade-offs

• Layered checks add latency and complexity to payout decisions — accepted, because false positives (paying fraudsters) are far more expensive than milliseconds
• Enforcing geofence rules in SQL couples integrity to the database, but guarantees it holds regardless of which code path writes promotions
• Strict validation risks denying edge-case legitimate drivers; dispute-handling workflows in the admin panel absorb this rather than loosening the checks

Challenges

Balancing security against usability required judgment calls with the founder directly: every additional check reduces fraud and adds friction. Clarifying requirements up front — which conditions were negotiable and which were not — shaped the design more than any technical constraint.

Supporting customer support workflows mattered as much as the core logic: dispute review needed comments, reports, and data views in the internal panel so promo disputes could be approved or rejected efficiently and consistently.

Lessons Learned

Fraud detection is a design constraint, not a feature. Systems that move money should assume adversarial users from the first line of the spec.

Pushing invariants into the database — like non-overlapping geofences via spatial SQL — is more durable than enforcing them in application code, because data-layer guarantees survive every future code path.