Onboarding fraud

What onboarding fraud is

Onboarding fraud is the fraud that happens at the moment of signup, when a person joins an organization for the first time and there is still no prior relationship against which to check what they declare.

At any other point of the journey, the organization has something to compare against. It knows which device that customer operates from, at what time, with what amounts, to which recipients. An irregular operation stands out against that background. At signup that background doesn't exist. The first piece of data the organization has about that person is the one the person is handing over at that very moment.

That's why signup concentrates the attack. Not because it's the weakest step by design, but because it's the only one where the attacker competes against a system with no memory.

How the attack runs, step by step

The sequence varies in the technique of step 3 and step 4, and is identical in everything else.

1. Gather the identity material. A document that is stolen, bought on an illicit market, altered, or a synthetic identity built from real and fabricated data. Add an image of the holder, which in many cases is public.
2. Choose the most permissive channel. Between the app, the website and the in-person channel, the attacker tries the one that demands the least. When an organization offers several signup flows with different controls, fraud finds the weakest one before the internal team does.
3. Get past document validation. An altered document, a good-quality copy, or a genuine document that belongs to someone else. It's the step that varies the most depending on what the flow reads: only the printed image, the machine-readable zone, or the chip.
4. Get past the biometric comparison and the presence check. This is where the vectors with their own page come in: a deepfake presented to the camera, or a video injection attack that replaces the feed before it reaches the app. If the flow doesn't check presence, this step doesn't exist.
5. Complete the signup and wait. The account stays open and does nothing for a while. The pause is deliberate: an account that operates immediately raises more signals than one that behaves like a user who hasn't decided yet.
6. Use the account. Receive funds from another fraud as a money mule, take credit and not repay it, build history for a bust-out, or simply operate under an identity that isn't the person's own.

The fraud doesn't end at step 5, it starts there. What gets decided at signup is how expensive it was to get to that point.

The vectors that reach signup

Signup is the hub of the catalog: almost every type of identity fraud passes through here or gets prepared here.

• Deepfake — a synthetic face presented to the camera to get past the biometric comparison.
• Video injection attack — replacing the camera feed, which is the vector with the greatest capacity for automation and the one no liveness detection certification evaluates.
• Synthetic identity — a profile that matches no person, built to pass the controls that query data and not people.
• Stolen or altered document — the oldest vector and still the most frequent in channels that only read the printed image.
• Money mule — when the signup is done to put the account at the service of a network, with the person's own identity or someone else's.
• Bust-out — the signup that looks legitimate, and exists to build history and drain credit months later.

Telling them apart matters because each one is stopped by a different control, and a flow can be well covered against one and wide open to another.

Friction is part of the problem, not a side effect

A signup flow has two ways of failing and both cost.

It can accept someone it shouldn't have, which is the case this page describes. And it can reject a legitimate person, who abandons the process and leaves, without anyone in the organization finding out that user existed. The second error triggers no alert and that's why it gets measured less.

That's the argument a fraud team and a product team have at every review of the flow, and it has no universal answer: it depends on the product, on the risk the organization takes on, and on what regulation requires in each market. What can be stated is that a control that adds steps for the user isn't automatically better than one that works without asking anything of them, and that comparing controls should include both error rates, not just the rate of fraud accepted.

Who it affects and what it costs

• Financial services — signup is where the obligation to know the customer originates and where the risk of the entire subsequent relationship concentrates. The cost includes the investigation, the report and the position before the regulator.
• Betting and gaming platforms — age and identity verification, with immediate regulatory exposure when it fails.
• Fintechs and wallets — fast signup is a product advantage and an attack surface, by the same design.
• Government — procedures and benefits granted in someone else's name, through channels that usually accept a web browser.
• Background screening — a fake identity that enters a hiring or accreditation process.

In every case the operational damage has the same shape: the organization is left with a record that claims to have verified someone, and that record is indistinguishable from the legitimate users'. Everything that comes afterward, the investigation, the report, the collection, rests on a piece of data that wasn't true.

Which controls stop fraud at signup

No control resolves signup on its own, and several of the ones that matter aren't provided by an identity vendor.

• Document validation — reading the document, checking its security features, cross-checking front and back, and reading the chip when the document has one. The deeper the flow reads, the more expensive it is to forge.
• Checks against official sources — verifying the document and the data against the registry that issued them. It's the strongest control against a fabricated identity and depends on the access each agency grants in each country, not on the vendor.
• Biometric comparison — that the face of whoever shows up matches the one on the document. It answers the question of resemblance, not the question of presence.
• Liveness detection — verifying that a real person is present at the moment of capture. It's the control that separates a holder from a photograph or a generated face.
• Injection detection — verifying that the image comes from the device's camera. It's a control distinct from liveness detection, not a variant, and no certification under ISO/IEC 30107-3 evaluates it.
• Device integrity — detecting rooting, emulation and tampering with the runtime environment. It's usually solved with mobile security tools, which are a different market.
• Biometric deduplication — detecting that the same person is trying to open several accounts under different identities.
• Device, network and velocity signals — device reputation, inconsistent geolocation, number of signups from the same origin in the same window. They usually come from a layer other than verification.
• Bureau and restrictive list checks — they add context on the declared profile and are an obligation in several regulated markets.
• Manual review with a case queue — an analyst looking at what the system left in doubt. It's not an outdated control: it's the one that absorbs the edge where no automatic rule should decide alone.
• Post-signup rules — initial limits, an observation period and staged rollout of features. It's a product decision, not a vendor's, and it's what reduces the value of step 5 for the attacker.

Device integrity, checks against official sources and post-signup rules don't depend on the verification vendor. A team that builds its signup defense only with what its identity vendor sells is covering the central part of the problem and leaving out the edges.

How VU approaches it

Signup is the moment where VU's contribution is most direct, because it's where identity is the only data available.

Verify runs document reading, biometric comparison and liveness detection within the same flow, without adding a separate step per control for the user. Liveness detection is certified by iBeta at Level 2 of its testing program, which applies the methodology of the ISO/IEC 30107-3 standard. That evaluation measures presentation attacks, and it's evidence produced by a third party rather than a statement by the vendor itself.

That certification doesn't cover injection attacks, which happen outside the scope of the standard. It's a distinction worth keeping in view when comparing vendors, and it has its own page.

The capability that provides device and session signals during signup is Protect against fraud, which is the material the velocity and repetition rules are built with.

On the full digital onboarding, including the documentary obligations of each market, the detail is on the regulation pages by country.