What fraud prevention requires in Argentina
Let us start with what does not exist: Argentina has no single regime that says "prevent identity fraud this way". The obligation comes through three separate routes, and each one looks at a different part of the problem.
- Through the anti-money laundering regime. The UIF requires identifying and knowing the customer before they transact and monitoring afterwards. A false identity accepted at sign-up breaks everything that comes after, so the impersonation control is, in practice, a condition of the regime even though it is not named as such.
- Through the regulation of electronic channels. For financial institutions, the BCRA regulates how their digital channels operate, including remote onboarding and the security of logins.
- Through the personal data protection regime. It imposes proportionate security measures on the data processed. An identity fraud is almost always a data incident as well.
Added to that is the criminal route, which punishes the conduct after it has happened and does not help prevent it.
The practical consequence of the requirement being spread out is that nobody receives a list of controls to implement. Each obligated party has to derive its own controls from the risk it declared, and then be able to explain why it chose them. It is the same risk-based approach as the rest of the regime, applied to a problem that moves faster than the rules.
Identity fraud appears at two moments, and they are different problems:
- At sign-up. Someone registers using another person's identity, or a synthetic identity assembled by mixing real data with invented data. The account is born fraudulent and no later monitoring will flag it as anomalous, because it behaves as it was designed to behave.
- At login. Someone takes control of a legitimate account that already exists, through credential theft, through deceiving the holder or through hijacking their phone number.
What VU automates in fraud prevention
VU works on identity fraud, which is one part of fraud and not all of it. The distinction defines clearly what it covers.
- Presence control at capture — liveness detection, which prevents a photo, a video or a generated face from passing for a person. It is the control with independent evidence: it is certified by iBeta at Level 2 of its testing program, which applies the ISO/IEC 30107-3 methodology for presentation attacks.
- Document verification — so that an identity built on an altered document does not get in.
- Device recognition — browser and phone signals that make it possible to see when the same device appears behind many different sign-ups.
- Strong authentication at login — several factors available at the moment of login and of recovery, which is where account takeover concentrates.
- Orchestration of controls — running the checks before, during or after an action, in series or in parallel, with defined retries and timeouts.
And what VU does not do, which on this topic is half the conversation:
- It does not do transaction monitoring. Detecting an anomalous transaction by its amount, destination or frequency is a control over business data that lives in the obligated party's systems.
- It is not a card fraud rules engine or a payment scoring engine. That is a neighboring, distinct category.
- It does not decide blocks on its own. It produces signals and evidence; what is blocked, what is routed to review and what is let through is risk policy.
- It does not solve first-party fraud. When the real holder is the one lying, the identity is properly verified and the problem is a different one. It has its own page.
- Injection attacks are a separate category. A synthetic video inserted directly into the channel, without going through the camera, is not a presentation attack, so the independent test described above says nothing about it. Stopping it requires integrity controls on the capture channel, which is separate work.
Use cases in Argentina
Where this problem shows up in the real operation of the Argentine market.
Mass sign-ups on wallets and betting platforms. Products with fast registration and a low entry threshold, which attract automated registrations and accounts created to be used by third parties.
Accounts created to move someone else's money. The sign-up is done with a real identity, sometimes that of the holder who lends it out, and the account works as a link in a chain.
Synthetic identities that mature. A profile assembled from partially real data that operates normally for months before being used, and that no monitoring flags because there is no victim to complain.
Access recovery as a way in. The point where an attacker who already knows the victim's data tries to replace the authentication factor, and the one that usually gets the least design attention.
Leaked personal data in circulation. Document numbers, DNI photos and contact details available in volume, which make any control based on knowing a piece of data useless.
Impersonation aided by generation tools. Synthetic faces and documents that no longer require specialized equipment, and that raise the floor of what a control has to withstand.
Frequently asked questions
There is no single regime that sets it out in one place. The requirement comes through three routes: the anti-money laundering regime enforced by the UIF, which requires identifying and knowing the customer before they transact; the BCRA's regulation of how financial institutions and their digital channels operate; and the personal data protection regime, which imposes security measures on the data processed. The practical consequence is that nobody hands out a list of mandatory controls: each obligated party derives its own from the risk it declared and has to be able to explain that decision.
At sign-up, the account is born fraudulent: someone registers with another person's identity or with a synthetic identity, and from day one it behaves exactly as it was designed to behave, so later monitoring does not flag it as anomalous. At login, the account is legitimate and the attacker takes control of it through credential theft, deceiving the holder or hijacking their phone number. They are two different problems with different controls: the first is tackled in identity verification, the second in authentication and session signals.
It is an identity built by mixing real data, often obtained from leaks, with invented data, so that the resulting profile does not correspond to any existing person. It is hard to detect for a structural reason: there is no victim to complain. Nobody calls to report that an account was opened in their name, because that person does not exist, and the account can operate normally for months before being used. That is why the effective control is at sign-up, checking that there is a real, present person behind the registration, and not in later monitoring.
No, and presenting it that way is a common mistake. Liveness detection answers a specific and valuable question: whether a real person is present at the moment of capture. It does not say who that person is, which is settled by matching against the document; it does not validate that the document is authentic; and it says nothing about what happens after sign-up. A prevention program is built from several linked controls, and the useful question about each one is exactly which attack it stops.
