CPF Farming and Synthetic Identities in Brazilian Onboarding

In Brazilian onboarding the CPF does a lot of work. It’s the key the tax authority uses, the key for credit bureaus and the key Pix uses for many transfers. For a digital bank, a wallet, a betting site or a marketplace, the CPF is effectively the customer’s identity. So when CPFs can be bought, the identity layer can be bought too.

CPF farming is the practice of using many real CPFs, belonging to other people, to open accounts controlled by one operator. It drives signup bonus abuse, mule (“laranja”) networks for moving fraud proceeds, credit bust-outs, and bypassing per-person limits. This article covers why the usual checks miss it and how linking CPFs to devices exposes it early.

Where the CPFs come from

You don’t need a statistic to know the supply exists. Brazilian data leaks have been widely reported over the years, and CPF lookup panels are sold in the same places stolen card data is. The main sources:

• Leaked records. CPF plus name, birth date and mother’s name: often enough to pass basic data matching.
• Rented or sold identities. People paid to hand over their CPF, a selfie and sometimes access to their phone. These pass liveness because a real person really is behind them.
• Synthetic blends. A real CPF combined with a different phone, email and address controlled by the operator. That’s the classic synthetic identity pattern, adapted to a CPF-keyed system.
• Identities of the deceased or inactive, where registry status hasn’t caught up.

Why CPF-level checks pass

The standard stack checks the CPF itself:

1. Check digits. The last two digits of a CPF are computed from the first nine. This catches typos and invented numbers, not stolen ones.
2. Registry status. Whether the CPF is in good standing with the Receita Federal. A leaked CPF usually is.
3. Name and birth-date match. Leaks contain both.
4. Document and liveness. Defeated by rented identities, where the real owner takes the selfie, and sometimes by injected or replayed media.

Each of these asks “is this a real person?”, and the answer is honestly yes. The question they can’t answer is whether this same operator has submitted forty other real people this month. That question is about the submitter, not the identity, and the submitter’s most stable trait is the device they work from.

The device view

A farm processing many CPFs reuses a small set of devices: a few laptops, a rack of phones, a set of emulators. When each onboarding carries a device identification, the pattern is obvious from the device side:

• One visitorId with many distinct CPFs attempted.
• A handful of devices sharing a hardware profile, all onboarding at office hours from the same ASN.
• Emulator, cloned-app or root signals on the “phone” doing the selfie step.
• Residential proxy or datacenter IPs on the web flow, with an IP country that doesn’t match the device timezone.

In Prynt terms, each attempt is identified in the app or browser and then verified on your server. After the account is created, your internal customer id (never the raw CPF) is attached as linkedId. The next attempt from that device sees every earlier account in accountsOnDevice:

const event = await prynt.getEvent(requestId);

const priorAccounts = event.accountsOnDevice.count;   // your customer ids on this device
const ss = event.smartSignals || {};
const riskyEnv = ss.emulator?.result || ss.clonedApp?.result ||
                 ss.residentialProxy?.result || ss.tampering?.result;

// One earlier account on a shared family phone is normal; see "Handling false positives".
if (priorAccounts >= 2 || riskyEnv || event.decision === 'block') {
  return routeToManualReview({ reason: 'device_reuse_or_untrusted_env', visitorId: event.visitorId });
}

Use your own customer id as the linkedId, not the CPF. The CPF is personal data under LGPD, and a high-value one for fraudsters. Nothing in the device check needs it in a third-party system.

Counting attempts, not just accounts

accountsOnDevice counts accounts that were actually created and linked. Farms also probe: they submit CPFs that fail checks and move to the next one. Track those yourself. Store each attempt’s visitorId with a hash of the CPF tried, and count distinct CPF hashes per device over a rolling window. A device that tried twelve CPFs this week is a farm even if only two of them made it through.

Put the check before the paid steps

Onboarding in Brazil often includes steps you pay for per call: bureau queries, document OCR, liveness, sometimes background checks. A farm pushing many identities through your funnel runs up that bill even when every attempt fails.

Reorder the funnel so the cheap check comes first:

1. CPF entry → device check (included in your identification plan).
2. Device clean → bureau query and data match.
3. Data match passes → document and liveness.
4. Account opened → attach linkedId.

A device that has already submitted several CPFs, or that runs in an emulator, can be held for review before step 2. That saves the per-call fees and keeps your vendor match rates from being polluted by farm traffic. The same reordering shows up in KYC bypass at neobank onboarding.

Finding the ring after the fact

Some farms pace themselves carefully, one CPF per device per week across many devices. Then the signal moves from one device to the links between devices. Accounts that share a device, devices that share accounts, and accounts that share a receiving Pix key or address form a graph. The connected components of that graph are the rings. Identity graphs for fraud rings shows how to build and read one. On Prynt’s Scale plan, the identity graph is part of the product.

Report confirmed outcomes back so they inform future decisions. Labeling a case as fraud through POST /v1/outcomes or the console feeds Prynt’s reputation for that device.

Handling false positives

Shared devices are common in Brazil. Families share one phone, and lan-house-style shared computers still exist in some areas. A second CPF on a device isn’t fraud by itself. Common practice:

• First extra CPF on a device: allow, with closer monitoring of the account.
• Several CPFs on a device in a short window, or any CPF from an emulated or cloned environment: hold for review.
• Device already labeled as fraud: block.

Keep messages neutral, in Portuguese, with a clear support route.

Wrap-up

CPF checks prove an identity exists. They can’t show that one operator is submitting many of them. Link every onboarding attempt to its device, count CPFs per device, and run that check before the steps you pay for. Prynt’s fintech page covers the other onboarding signals.