Ride-Hailing Fraud in Latin America: Rented Accounts and Promo Farms

Ride-hailing in Latin America runs on a few realities that shape its fraud: a lot of trips are paid in cash, many drivers work on prepaid phones, phones are frequently shared or resold, and platforms compete hard with promotions to win riders city by city. Each of those is reasonable on its own. Together they create fraud patterns that look different from the card-heavy markets most fraud tooling was built for.

This post maps three common patterns, rented driver accounts, rider promo farms and fake trips, to the mobile device signals that expose them, and to responses that do not punish the many drivers and riders doing nothing wrong.

Pattern 1: rented and substituted driver accounts

Onboarding a driver usually involves documents, a background check and a selfie. That makes a verified driver account valuable, and a market forms around it. Someone who passed verification rents the account to someone who could not, or several people drive under one account in shifts.

The risk is not abstract. The person behind the wheel is not the person the platform checked, and riders have no way to know.

What the device history shows. A driver account normally lives on one phone, occasionally changing when the driver replaces it. A rented account behaves differently:

• Device spread. The account appears on a new device, then another, or alternates between devices on different shifts. Prynt’s deviceSpread risk signal and DEVICE_SPREAD reason code capture one account across many devices.
• Account sharing on the device. The renter’s phone often hosts several driver accounts, because renters work with more than one owner. ACCOUNT_SHARING fires when a device carries more than three accounts in 24 hours, and accountsOnDevice lists them all.
• Location inconsistency. The account’s previous device was in one city and the new one starts in another. IMPOSSIBLE_TRAVEL covers movements no real trip explains.

The response. Do not suspend on a device change alone; drivers break and replace phones constantly. Use the change as a trigger for a step-up: an in-app selfie re-check before the next shift, run by your identity vendor. Escalate to review when the new device also hosts other driver accounts. The gig worker identity fraud post covers this flow in more depth, and the same patterns apply to courier and delivery platforms.

Pattern 2: rider promo farms

First-ride discounts and referral credits are a core growth tool. They also invite multi-accounting: a rider creates a new account for every first ride, or a small operation creates hundreds of accounts to harvest referral credits and resell rides.

New identities are cheap. Prepaid SIMs and free email accounts cost little, so phone-number and email uniqueness checks slow abusers down without stopping them.

What the device shows.

• Many accounts, one phone. accountsOnDevice on a promo-eligible signup shows every rider account you have linked to that device. MULTI_ACCOUNT fires when two or more distinct accounts appear on one device within 30 days.
• Emulators and virtual devices. Organized farms avoid buying phones by running Android emulators. The mobile SDKs report emulator detection.
• Cloned apps. App-cloning tools run several copies of your app side by side on one phone, each with its own storage. CLONED_APP flags it.
• Rooted devices and instrumentation. Tools that reset device identifiers or hook your app need root or an instrumentation framework. ROOTED_OR_JAILBROKEN and INSTRUMENTATION cover those, and FAILED_ATTESTATION covers apps that cannot pass platform integrity checks.

The response. Separate account creation from promotion eligibility. A rider on a shared family phone should be able to sign up; they should not get a second first-ride discount. Tie the promo to the device: if the device already has a rider account that redeemed it, the new account rides at full price. Reserve refusal for emulators, cloned apps and devices with many accounts. The device farm detection post covers the industrial end.

Pattern 3: fake trips and GPS spoofing

Fake trips extract money through incentives: bonuses for completing a number of trips, surge pricing, or referral rewards tied to a first completed trip. A driver and a “rider” collude, sometimes the same person with two phones, or one phone running both apps, and the trip happens only on a map.

What the device shows.

• Location spoofing. Mock-location apps and spoofing tools let a phone report positions it never visited. locationSpoofing and the LOCATION_SPOOFING reason code flag it. On Android, spoofing commonly requires either developer options or root, so it tends to co-occur with ROOTED_OR_JAILBROKEN.
• Driver and rider on one device. If the rider account for a trip is linked to the same device as the driver account, or to a device the driver used recently, the trip is not arm’s-length. This is a query over your own data: compare the visitorId history of the two linkedIds.
• Velocity. Many short trips between the same pair of accounts, at bonus thresholds, is a pattern no single trip reveals.

The response. Withhold incentives rather than fares. Holding back a bonus until a trip pattern is reviewed is far less damaging to an honest driver than holding their earnings.

Integrating on mobile

Prynt has mobile SDKs for Android (Kotlin), iOS (Swift Package), Flutter and React Native. The flow is the same as on the web: the app identifies the device at a sensitive moment, such as signup, shift start, promo redemption or trip completion, sends the requestId to your backend, and the backend fetches the event with the secret key:

const event = await prynt.getEvent(requestId);          // @prynt/node
const s = event.smartSignals ?? {};
const rider = {
  multiAccount: event.accountsOnDevice.count >= 1,
  spoofing: Boolean(s.locationSpoofing?.result),
  risky: event.decision === 'block',
};

After signup, attach the account with updateEvent(requestId, { linkedId: String(user.id) }) so future events on that device see it. Use separate linkedId namespaces for driver and rider accounts, for example a prefix, so you can tell the two apart in accountsOnDevice.

Respect the shared-phone reality

In many markets, one phone is used by several family members, and second-hand phones change owners. A rule that treats every multi-account device as fraud will hit real riders. The patterns above work because they look at combinations: many accounts plus an emulator, a device change plus other driver accounts, a trip plus location spoofing. A single signal is a reason to look, not to act.

The fraud rings page shows how linked devices reveal coordinated groups, and the SDKs page lists the mobile packages. Start by logging device history at driver onboarding and promo redemption; those two points alone tend to make the biggest patterns visible.