Argentina Fintech Fraud: Mule Accounts in Virtual Wallets

Argentina’s virtual wallets made opening a payment account a matter of minutes: download the app, photograph your DNI, take a selfie, and you have a CVU that can send and receive transfers immediately. Payment service providers that offer these accounts operate under Banco Central (BCRA) rules, and the identity checks are real. Yet KYC answers one question, “is this a real person?”, and mule operators have learned to live inside that answer.

This post covers the two kinds of abusive account that slip through wallet onboarding, the device signals that expose them, and how to act without slowing down the honest majority.

Two shapes of mule account

Accounts opened with someone else’s identity

Stolen or purchased DNI images, sometimes with doctored selfies, are used to open accounts that the real person never knows about. These accounts receive scam proceeds and move them on quickly. They are often opened in batches by the same operator, from the same handful of devices, sometimes from Android emulators with camera input injected.

Rented accounts

Here the identity is genuine and the owner is complicit. Someone opens a wallet, passes KYC honestly, then rents access to an operator, often through informal channels and for a small payment. To the onboarding team the account is clean. The abuse is visible only in how it is used: the account starts operating from a different device, on a different network, receiving transfers from many unrelated people and forwarding them fast.

Both shapes defeat document checks. Both leave device evidence.

Signals at onboarding

Identify during onboarding, verify on your server, and link the new customer id to the event. Then these become available:

Device reuse across identities

The single most useful check. accountsOnDevice lists every account you have linked to the device. A phone that has onboarded three different DNIs in a month is either a family sharing one device, which you can review gently, or an operator, which you want to stop. On paid plans, the risk engine also raises multiAccount at two or more distinct accounts on a device in 30 days, and accountSharing above three in 24 hours.

import os
from prynt import PryntServer
prynt = PryntServer(secret_key=os.environ["PRYNT_SECRET_KEY"])

event = prynt.get_event(request_id)
other_accounts = event["accountsOnDevice"]["accounts"]   # identities already on this device

if event["decision"] == "block":
    decision = "reject"
elif len(other_accounts) >= 2:
    decision = "manual_review"        # third identity from one device
elif len(other_accounts) == 1:
    decision = "enhanced_kyc"         # e.g. liveness re-check, lower limits
else:
    decision = "approve"

customer = create_customer(form, status=decision)
prynt.update_event(request_id, linked_id=str(customer.id))

The update_event call at the end is what makes the next onboarding from this device see this customer. Skip it and the count stays at zero; see why linking linkedId matters.

Emulators and tampered devices

Batch onboarding runs on emulators and modified phones. The Android SDK collects emulator tells (QEMU and goldfish/ranchu builds, Genymotion, missing sensors), root indicators such as Magisk and su binaries, Frida instrumentation, and side-loaded or repackaged builds. The server turns those into signals and reason codes like ROOTED_OR_JAILBROKEN, INSTRUMENTATION and CLONED_APP. On iOS, jailbreak and instrumentation checks plus App Attest play the same role.

A genuine customer onboarding from an emulator is rare enough that “emulator at onboarding” justifies manual review on its own.

Velocity

Operators work in bursts. Many onboarding attempts from one device in minutes (VELOCITY), or many accounts on one device in a day, indicate a production line rather than a person. Keep your own counters too: onboardings per device per day, and failed KYC attempts per device. A device that failed KYC twice under two different names and then succeeded under a third is telling you something.

Network and location

vpn, proxy and residentialProxy signals, plus locationSpoofing when the device’s stated location and its network disagree, help with operators who hide behind infrastructure. Treat them as amplifiers, not verdicts: plenty of honest users run VPNs.

Signals after onboarding: catching rented accounts

Rented accounts pass onboarding cleanly, so the evidence arrives later. Identify on login and on sensitive actions with the customer id as linkedId, and watch for:

• Device change after a quiet period. The account was opened and used from one phone, goes quiet, then becomes active on a different device that has its own history of other accounts.
• Device spread. One account accessed from several devices in a short window (DEVICE_SPREAD), typical when an operator and the owner both use it, or when access is passed around.
• The operator’s device. The device now operating the rented account often already appears in accountsOnDevice for other wallets. That cluster is your mule network.

Combine these with transaction patterns: many small incoming transfers from unrelated senders followed by rapid outflows. The money mule detection guide covers the transactional side in depth.

Acting without punishing real customers

A shared family phone, a parent onboarding an elderly relative, or a customer replacing a lost device all produce some of these signals. Calibrate the response:

• Reject only on clear automation, emulation or Prynt block decisions.
• Enhanced verification (a new liveness check, a call) for second identities on one device.
• Lower initial limits for accounts opened from devices with any reuse, raised as the account builds normal history.
• Manual review for clusters: devices with three or more identities, or devices that operate multiple accounts that receive from the same senders.

Record confirmed mule outcomes through POST /v1/outcomes so those devices are recognized as known abusers on their next attempt.

Data protection

Argentina’s personal data protection law applies to device data. Scope collection to fraud prevention, document it in your privacy notice, and support access and deletion requests. Prynt supports erasure by visitorId or linkedId, IP minimization and retention limits; see our privacy page.

Where to start

Add an identify call to the onboarding flow, link every new customer, and spend two weeks reviewing devices with more than one identity before turning anything into an automatic rejection. The patterns you find there tell you which thresholds to set. The neobank onboarding velocity guide and the fintech solutions page cover the next steps.