Identity impersonation

What identity impersonation is

Identity impersonation is the use of a real person's data and document by a third party to operate in their name. The person exists, their data is correct, and their document is genuine or a convincing copy of a genuine one. The only false thing is who is on the other side.

On the organization's side, the problem isn't one of data. Every field that gets validated comes back fine, because the data belongs to a real person. What isn't validated by default is the question that matters: whether whoever presents that document is its holder.

That's the difference between checking that a digital identity is consistent and checking that it belongs to whoever is using it.

Three different things get called impersonation

The term is used as an umbrella, and that complicates project conversations, because the three cases are stopped at different moments and with different controls.

• Impersonation at signup — the attacker uses a real person's identity to open something new: an account, a loan, a phone line, a procedure. The victim has no prior relationship with the organization and usually finds out when the debt or the notification shows up. It's what this page covers.
• Account takeover — the attacker gets into an account that already exists and already belongs to that person. There's no signup to verify: identity was verified at the time, and what failed is access control.
• Synthetic identity — there's no real person behind it. The identity is built by combining data, which is why nobody ever shows up to complain.

The separation isn't academic. In impersonation there's a victim who complains, and that complaint is both the highest operational cost and the main source of detection. In synthetic identity there's no complaint, which is why it's discovered much later.

How the attack runs, step by step

The sequence takes place almost entirely before the organization sees anything, and it ends in a signup that, from the system's side, looks like any other.

1. Gather the person's data. Accumulated leaks, social engineering, lost or stolen documents, public information from social networks. Name, ID number and date of birth are usually enough to start.
2. Get an image of the document. A photo of a real document, a stolen physical document, or a forgery built on the country's template. The quality needed is whatever the control on the other side demands, no more.
3. Choose the weakest entry point. Between channels of the same organization, or between organizations. A fully remote signup, a phone support channel or a branch with visual verification don't offer the same resistance, and the attacker tries wherever it costs least.
4. Pass document validation. If the control checks that the fields are consistent and the format correct, the document passes: the data belongs to a real person.
5. Pass the biometric comparison. It's the step that separates a simple fraud from a prepared one. A photo of the holder may be enough if there's no presence control. If there is, the attacker needs a synthetic face, and at that point the vector becomes a deepfake.
6. Operate in the holder's name. Receive funds, take credit, activate a line, access a benefit. The relationship is formally established.
7. The victim shows up. Weeks or months later, when the debt, the report to a credit bureau or the official notification arrives. The cost at this stage is one of management, not fraud: investigation, reversal, response to the claim and exposure before the regulator.

Steps 4 and 5 are the only ones the organization controls. Everything before them happens beyond its reach.

Who it affects and what it costs

The damage is double and lands at different moments. The impersonated person carries a problem they didn't cause. The organization carries the decision it made.

• Financial services — account opening and credit taken in a third party's name. Beyond the loss, the account is usually reused to receive funds from other frauds, which drags the entity into an anti-money-laundering problem.
• Telecommunications — lines signed up in another person's name, which then enable SIM swapping on the victim's accounts.
• Betting and gaming — age and identity verification evaded, which is a licensing problem before it's a financial one.
• Government — access to procedures and benefits in another person's name, with the peculiarity that the affected party is also the body that has to respond.
• Background screening — a false identity in a hiring or accreditation process.

The cost that shows up on no spreadsheet is the most expensive one: after the incident, the organization can't tell apart in its database those who were actually verified from those who only appear to be. Looking backward is always more expensive than the control that would have prevented it.

What controls stop it

The controls are spread across three different questions, and no provider covers all three. Naming them in full is what makes the list useful.

Whether the document is genuine.

• Verification of the country's template — checking against the current official design of the document: typefaces, positions, security features.
• Reading data zones and cross-checking them — MRZ, PDF417 and the printed fields must match each other and what was declared. A good forgery fails on internal consistency before it fails on appearance.
• Reading the NFC chip — where the document has one, it's the strongest evidence of authenticity, because the chip is signed by the issuer.
• Querying the issuing source — checking the data against the records of the body that issued the document. It's the most decisive control and the one least dependent on image quality. Its availability varies by country and by integration.

Whether the person presenting it is its holder.

• Biometric comparison — the captured face against the document's. It answers a question of resemblance, and nothing more.
• Liveness detection — establishes whether a real person is present at the moment of capture. It's what turns the comparison into a proof of ownership.
• Injection attack detection — identifies virtual cameras, emulators and substitution of the video stream. It's a control distinct from liveness detection, not a variant of it.
• Biometric deduplication — checks whether that face is already registered in the database under another identity.

Whether the context is coherent.

• Querying credit bureaus and third-party data sources — existence, age and consistency of the history. Provided by bureaus, not by identity providers.
• Device and network signals — device reputation, use of the same device for several identities, signs of automation.
• Phone carrier signals — age of the line and match between the line's holder and the applicant. Bought from telecom data aggregators.
• Case management and manual review — for the signups left in a gray zone. It's process and team, not product.
• Claim channels and preventive blocking for the victim — what the organization offers the impersonated person. It's the part that most defines how the incident is perceived and the one no technical control solves.

A good part of what decides a safe signup, the bureaus, the telecom data and the team that reviews doubtful cases, isn't bought from an identity verification provider. A team that plans its defense counting only on what its biometrics provider sells will find the gap on the first gray case.

How VU approaches it

VU works on the first two questions, which are the ones that take place inside the signup flow.

Verify reads the document, cross-checks the data zones against each other, compares the captured face against the document's and applies liveness detection in the same flow, without adding a separate step for the user. Where an integration with the issuing body exists, the data is checked against the source rather than against the image.

Liveness detection is certified by iBeta at Level 2 of its testing program, which applies the methodology of the ISO/IEC 30107-3 standard. It's evidence produced by an accredited third party, not a claim by the manufacturer. Its scope is presentation attacks.

On the third question, that of context, VU contributes risk signals from Protect against fraud, and the rest keeps coming from bureaus and third-party data.