Pix Fraud in Brazil: Device Signals for Instant-Payment Scams

Pix changed Brazilian payments by making transfers instant, free for individuals and available around the clock. The same properties that made it popular made it attractive to fraudsters: a transfer that settles in seconds leaves almost no time to notice something is wrong, and money that has already passed through two or three accounts is hard to bring back.

For a bank or wallet, that collapses the decision window to the moment before the user presses “confirm.” Everything you know about the session at that point is everything you get to use. This post walks through the main Pix fraud patterns and the device and session signals that help with each, with an honest note on where they do not.

Three patterns, three different signal sets

1. Account takeover, then transfer

An attacker gets into a real customer’s account, through phishing, a SIM swap, leaked credentials or malware, and drains the balance by Pix, often to several destination keys in quick succession.

The tells are about change: the session is on a device the account has never used, from a network that does not match the customer’s history, or on a device that has been tampered with. Useful signals:

• New device for this account. Link your customer id on every login and check whether this visitorId appears in the account’s history before a high-value transfer.
• Emulators and instrumentation. On mobile, emulator detection, rooted or jailbroken devices and instrumentation frameworks such as Frida (reason codes ROOTED_OR_JAILBROKEN, INSTRUMENTATION) are rare among ordinary customers and common in attack tooling.
• Cloned or repackaged apps (CLONED_APP) and failed hardware attestation (FAILED_ATTESTATION).
• Impossible travel (IMPOSSIBLE_TRAVEL) and VPN or proxy use that does not match how this customer normally connects.
• Device spread. One account suddenly accessed from many devices (DEVICE_SPREAD).

The payment fraud device signals guide covers how to weigh these together.

2. Social engineering on the victim’s own device

The “fake relative” message, the fake bank employee call, the fake sale. The victim is persuaded to send the money themselves, from their own phone, on their own network.

Be realistic here: the device is genuine, so device signals will mostly say “this is the customer.” What still helps is context the device can carry:

• A first transfer to a new key right after a change in the account, such as a new device enrolled or a password reset, is worth a pause.
• The receiving side. The destination account is often a mule, and mules have device tells of their own (next section). If you are the receiving institution, or you share signals with it, that is where the scam is most visible.
• Friction proportional to novelty. A cooling-off delay or an explicit warning screen on a large first transfer to a new key does more against social engineering than any device score.

3. Mule receivers

Scam proceeds land in mule accounts: accounts opened with stolen or synthetic identities, or real accounts rented out by their owners, which pass money onward fast. Mule accounts tend to cluster:

• One device, many identities. The same phone or emulator onboarding several accounts with different CPFs. accountsOnDevice at onboarding shows this directly, as long as you link each new customer.
• Emulator farms creating accounts in batches.
• Velocity. Many accounts created, or many logins, from one device in a short window (VELOCITY, ACCOUNT_SHARING).
• Rented accounts that suddenly move to a different device than the one that onboarded them.

The money mule detection guide goes deeper into scoring mule behavior after onboarding.

Scoring before the transfer

The integration pattern is the same on Android, iOS, Flutter or React Native: identify at the sensitive moment with the customer id, then let your server decide before calling the payment rail.

// Android: before showing the Pix confirmation screen
prynt.identify(tag = mapOf("action" to "pix_transfer"), linkedId = customerId) { outcome ->
    when (outcome) {
        is PryntOutcome.Success -> api.preparePixTransfer(transferId, outcome.result.requestId)
        is PryntOutcome.Failure -> api.preparePixTransfer(transferId, null) // server applies its fallback
    }
}

# server: decide before submitting the Pix payment
import os
from prynt import PryntServer
prynt = PryntServer(secret_key=os.environ["PRYNT_SECRET_KEY"])

def check_pix_transfer(request_id, customer_id, amount):
    event = prynt.get_event(request_id)
    # events > 1: this account was seen on this device before the current identification
    known_device = any(a["linkedId"] == customer_id and a["events"] > 1
                       for a in event["accountsOnDevice"]["accounts"])

    if event["decision"] == "block":
        return hold_for_review()
    if not known_device and amount >= HIGH_VALUE:
        return require_step_up()      # in-app biometric, delay, or call-back
    return proceed()

The iOS, Flutter and React Native SDKs follow the same identify-with-linkedId shape; see the SDKs page. The server side is identical regardless of platform. The decision should feed your existing rules on amount, destination key age and transfer history rather than replace them. Device signals tell you who is holding the phone; your payment data tells you what they are trying to do.

Step-up options that fit Pix

Because the transfer is instant, the right response is usually friction, not a decline:

• Biometric re-authentication for transfers from a new or unrecognized device.
• A cooling-off period for the first transfer to a new key above a threshold, applied more strictly when the device is new.
• Lower limits on new devices until the device has some history with the account.
• Out-of-band confirmation for transfers that combine a new device with a recently changed account.

Brazilian regulation already pushes institutions toward limits and controls on Pix, including special refund mechanisms for fraud cases. Device signals let you apply those controls selectively, so a long-standing customer on their usual phone is not slowed down.

Privacy under LGPD

Device intelligence processes personal data, and LGPD applies. Fraud prevention is a recognized purpose, but document your legal basis, keep the data to what security needs, and be ready to honor erasure requests. Prynt supports erasure by visitorId or linkedId, IP minimization and configurable retention. See the LGPD and device fingerprinting guide and our privacy page for details.

Where to start

Start with the mule side, because it is where device signals are strongest: identify at onboarding, link every new customer, and review devices that onboard more than one identity. Then add a pre-transfer identify for high-value transfers from unrecognized devices. The fintech solutions page maps the signals to each step of a banking app.