Fraud, trust, and engineering teams at ridesharing companies have to fight fraud in a way that is structurally different from any other business. You need a unique, two-sided control architecture to prevent threats from two distinct areas: the rider side and the driver side. Yet the fraud controls in place today may be missing a critical layer...
———
Introduction: Two-sided marketplace, two-sided fraud
Most companies manage fraud from one direction: the customer.
Ridesharing platforms have to manage it from two: the driver and the rider.
Each presents distinct challenges, distinct economic incentives for bad actors to exploit, and distinct failure points and impacts to the business when controls don't work.
What makes these challenges especially acute is that the two sides are interdependent.Â
A fraudulent driver can put riders at risk, harm the platform's reputation, and impact regulatory standing. A fraudulent rider can reduce driver earnings, distort growth metrics, and bleed revenue from the business.Â
Neither side can be addressed in isolation. Both can undermine the company's ability to gain a foothold and grow in the markets where they want to.
In this report, we'll uncover the twin sides of fraud that ridesharing platforms are fighting today, the structural gaps in many current identity architectures, and why device intelligence is the missing layer for teams who want to build a stronger fraud stack at scale.
Trust behind the wheel: The three most common types of driver-side fraud
The fraud vectors that cause the most operational damage on the driver side break down into three overlapping categories.
-
Account sharing and tenant drivers
In emerging markets with high demand and high growth—like across Eastern Europe, Sub-Saharan Africa, and parts of the Middle East—a verified driver account is itself an asset with monetary value. An individual who has passed onboarding, built up a rating, and achieved preferred status may sell or rent that account to another driver who either could not pass verification or has already been deactivated. This creates "tenant drivers": individuals operating anonymously behind borrowed credentials. From the platform's perspective, the account looks legitimate. The behavior looks legitimate. The problem is that the actual person behind the wheel is completely untracked. Their real identity is unknown, their history is invisible, and if something goes wrong, the account holder can claim no knowledge.
-
Profile rental
More damaging still is the use of rented profiles by previously deactivated drivers. Say a driver is removed from the platform for poor ratings, safety violations, or fraudulent activity. This account-level ban is the only control in place. That deactivated driver can then pay another verified account holder to use their profile, re-enter the platform, and continue operating under that assumed profile. The ban for the individual is meaningless because it was applied to an account, not a device.
-
Fake cancellations
Riders may submit false service complaints, or cancel trips in ways designed to extract credits or refunds, in order to exploit platform dispute mechanisms. Drivers are the ones who the bear the economic and rating consequences, through no fault of their own. In markets where resolutions lean toward the rider by default, this can contribute to a negative driver experience: loss of earnings, frustration, and churn.
The re-entry gap: What identity verification checks don't see
Driver-side fraud in ridesharing is not just a problem of verifying identity. It's a problem of persistence over time.
Most ridesharing platforms have invested in a strong set of document and identity verification tools, like selfie checks, liveness detection, and document verification.
The problem with these methods is that they operate at a single point in time.
Identity verification answers one question: Is this the real person behind this account, right now, at onboarding?
It does not answer the questions that matter after that moment:
- Is the same person operating the account today as the one who passed verification six months ago?
- Has this device been used by a previously banned driver?
- Is the device presenting this new account linked to a pattern of deactivated accounts?
The re-entry cost for a banned driver in a high-fraud market is trivially low. A new SIM card costs less than a dollar in most emerging markets. A fresh email address takes thirty seconds. An app reinstall wipes the local footprint.
Identity verification was designed to confirm who someone is. It was not designed to tell if someone is acting like someone else.
Rider-side fraud: The referral and multi-account problem
If driver-side fraud is about persistent identity evasion, rider-side fraud is about account proliferation. The economic model that powers ridesharing growth—first-trip credits, referral bonuses, promotional discounts for new users—creates a structural incentive for multi-accounting that email verification alone cannot address.
How referral fraud works in ridesharing
Ridesharing referral programs are designed to turn existing riders into growth channels: refer a friend, both parties get credit. The mechanics are straightforward. The fraud is equally straightforward.
A single fraudster, or a coordinated group, may create dozens of "new" rider accounts using freshly registered email addresses, new phone numbers, and, if necessary, cheap prepaid SIMs.
Each account receives first-trip credits. Each account can generate a referral payout back to the original account. The fraudster extracts platform credits, real trip value, and referral bonuses. The platform records a spike in "new user" signups and growth metrics that look healthy until the unit economics are examined.
This is referral farming at scale. It's the ridesharing equivalent of account cycling, and it's operationally damaging in ways that go beyond the direct cost of credits paid out.
Why standard controls fail here
The standard fraud control playbook with email verification, phone number validation, and credit card checks doesn't work against device-level multi-accounting for a simple reason: A determined fraudster doesn't reuse those signals.
What they almost always reuse, because it's expensive or difficult to change, is the device.
The same phone running six different email addresses with six different SIM cards will still have the same hardware fingerprint, the same app install history, and the same behavioral patterns across sessions.
Device intelligence that persists over time can identify this linkage and stop referral farming at the root. Email verification cannot.
The false-positive problem
Aggressive controls against multi-accounting create a problem that's the mirror image of the fraud problem: Legitimate new users in the same high-fraud markets get caught in broad-brush rule-based filters.
A genuine first-time rider in Nairobi or Lagos, signing up on a shared device or from an IP associated with previous fraud attempts, gets blocked. The platform loses a real customer while the fraudster continues operating.
Precision matters. The goal is not to make account creation harder for everyone. It's about identifying a specific set of device-level signals that can distinguish a genuine new user from an account cycling operation.
This level of precision is something that static, IP-based, or email-based checks cannot provide. Device intelligence can.
The compliance side: Doing your due diligence with device intelligence
The financial cost of driver fraud is clear (and significant). It can be seen in lost fares, operational overhead, and inflated customer service load.
But the compliance dimension is where exposure to driver fraud can compound and become existential. Especially for any platform operating across dozens of regulatory jurisdictions.
In markets with weaker regulatory oversight, ridesharing platforms have become vectors for informal economic activity that regulators classify as money laundering.
When an operator can use a rented profile to run thousands of dollars in fares through a verified account without that account holder's knowledge, the platform has inadvertently facilitated a financial crime.
The account holder is nominally responsible. The platform is operationally responsible.
In what could be an early signal of a broader regulatory trend across many countries and regions, Tunisia recently investigated ridesharing activity to see if unverified operators were using ridesharing platforms to move funds outside formal banking systems.
As ridesharing matures, regulators in developing markets are beginning to treat platforms as financial infrastructure, not just transportation services.
The compliance argument for persistent device-level visibility is not that it eliminates fraud. It's that it constitutes demonstrable due diligence.
The key takeaway: A platform that can show it links identities to device-level data—and that it actively detects when a device associated with a banned user attempts re-onboarding—is in a fundamentally different regulatory position than one that relies only on single-point-in-time document checks at onboarding.
The missing layer: What device intelligence does
Most fraud controls at ridesharing platforms today operate at the identity layer or the behavior layer. They do not operate at the device layer in a persistent, cross-session way.
This is exactly the gap that device intelligence fills.
Device intelligence generates a highly accurate identifier that can:
- Persist across app reinstalls, cache clears, and new account creation
- Survive SIM card changes and email address rotation
- Link new account creation attempts back to a device history (including known suspicious patterns and banned users)
- Be connected to a specific and verified identity, account, or record
Device intelligence makes it possible to recognize if someone is using a device to emulate or impersonate another identity. The fraudulent linkage is immediately visible.
For driver-side fraud, this means a deactivated driver's device can be flagged when it attempts to complete onboarding under a new account—even if everything at the identity layer looks legitimate. The ban follows the device, not just the name.
For rider-side fraud, this means a device that has already collected first-trip credits or a referral bonus can thwarted when it attempts to do so again under a fresh account. The farming operation is visible before the payout is made, not after.
The operational value of device-level identification is that it can operate invisibly to legitimate users. There is no additional step in the onboarding flow. There is no extra friction for a genuine new driver or rider. The signal is collected passively, processed server-side, and only surfaced to fraud and product teams as part of their fraud engines and risk scoring models.
This is the key operational difference from identity verification controls, which are an added step to the onboarding process.
Device intelligence adds zero friction to the user experience. It adds zero cost to the growth funnel. It inserts a persistent, cross-session layer of detection underneath the existing identity stack without any UX impact.
What "good" looks like: Where device intelligence works in practice
The ridesharing platforms that are ahead of this problem aren't replacing their identity verification stack. They're adding a critical layer that connects the dots across the full lifecycle of both drivers and riders.
Here are a few areas where the architecture looks like in practice:
- At driver onboarding
A device fingerprint is captured and linked to the verified identity. If the device has a history on the platform—previous accounts, prior deactivations, fraud flags from other sessions—that context is surfaced immediately. Onboarding continues normally for clean devices. High-risk devices are routed for additional review. - During active driver sessions
Session-level device signals can detect behavioral anomalies. For example, if a driver account starts operating from a device that doesn't match the registered fingerprint, this could be a a signal of account sharing or profile rental. A security challenge, like a re-verification prompt, can be served to ensure the legitimacy of the driver. - At rider account creation
New account creation is compared against the device's history. A device that has been associated with multiple accounts, previous credit collection, or referral payouts is flagged for review. Genuine new users with clean device histories proceed without any additional friction. - For referral program integrity
Referral payouts can be gated against device-level uniqueness checks, not just account-level uniqueness. The same device generating multiple referral events is detectable even when the accounts involved are all "new" by every identity signal.
The business case: Cleaner metrics, faster growth
There is a common assumption in fraud and product discussions that tightening fraud controls necessarily means slowing growth. This assumption is wrong.
The platforms that have added device intelligence to their fraud stack report three outcomes consistently:
- Cleaner growth metrics. When multi-accounting and referral farming are suppressed, new user numbers may look smaller—but they reflect actual new users. Customer Acquisition Costs (CAC) becomes more accurate. Cohort retention data becomes meaningful. Marketing attribution works. The growth data is cleaner and clearer.
- Higher promotional ROI. When first-trip credits and referral bonuses go to real new users, they generate real long-term riders. When they're being farmed, they generate nothing but wasted cash outflows. Device-level controls ensure the promotional budget is doing what it was designed to do.
- Reduced driver churn. Fake cancellations, dispute manipulation, and rating fraud all contribute to driver dissatisfaction and churn. Suppressing those behaviors through device-level detection improves driver economics, which improves supply reliability, which improves the rider experience. The effects compound.
The bottom line for fraud, product, and engineering leaders
The fraud challenge facing ridesharing platforms in 2026 is not a problem of insufficient identity verification. Most platforms have adequate controls at the identity layer.
The gap is below that layer, at the device level. This is where the re-entry risk vectors exist, where multi-accounting lives, where referral abuse happens.
Device intelligence doesn't replace the controls you have in place today. It augments them.
Fingerprint can close the re-entry gap that account-level bans leave open, and bring visibility to the cross-account risk patterns that identity-layer controls are structurally blind to.
For ridesharing companies, device intelligence data can strengthen your compliance posture, improve business metrics, and reduce risk exposure for both the driver and rider side of the business.
If you’d like to see how Fingerprint can strengthen your fraud controls, contact our sales team for a personalized demo.
Related reading:
