Synthetic Identity Fraud in Crypto KYC: How AI Helps Fraudsters Bypass Verification

On November 13, 2024, FinCEN issued alert FIN-2024-Alert004 after a sustained rise in suspicious activity reports describing deepfake media used against financial institutions. The filings, which FinCEN says began increasing in 2023 and continued through 2024, described criminals altering or creating fraudulent identity documents specifically to get past identity verification and authentication checks. FinCEN Director Andrea Gacki framed the problem plainly: bad actors are seeking to exploit generative AI "to defraud American businesses and consumers," financial institutions and their customers included. The agency went as far as creating a dedicated SAR key term — FIN-2024-DEEPFAKEFRAUD — so that filings connected to this typology could be tracked as a distinct category.

Here is what this looks like from inside a compliance team. A document arrives and passes authenticity checks. The selfie matches the photo on the document to an acceptable confidence score. Name, date of birth, and address pass consistency checks. Sanctions screening returns nothing. The account is approved in under three minutes, which is exactly what the onboarding funnel was designed to do. Six weeks later, an analyst reviewing an unrelated alert notices that this account shares a device fingerprint with four other accounts, two of which use the same payment instrument, and three of which have withdrawn to the same external wallet.

Nothing in that sequence failed. Every individual check returned an acceptable result. What failed was the connection between them. Artificial Intelligence did not invent identity fraud, and treating it as a brand-new threat category leads to the wrong defenses. What AI changed is the cost and consistency of the supporting material. Producing a document image, a matching face, a plausible video, and a coherent written profile that all agree with one another used to require skill, time, and money. Now the constraint has moved: the hard part is no longer making each element look right individually, but making a whole cluster of accounts survive contact with a system that compares them.

This article covers what a synthetic identity is actually made of, where the gaps open in a standard KYC flow, which red flags appear before and after approval, and why identity verification has to be wired into account and transaction monitoring rather than treated as a gate that closes behind the customer.

What Synthetic Identity Fraud Means in Crypto KYC

Precision matters here, because these typologies require different controls and produce different investigation outcomes.

Synthetic Identity vs. Stolen Identity

A synthetic identity combines genuine and fabricated identity attributes into a single profile that presents itself as one person. Some elements may be entirely real — a name, an address, a tax number, data from a real document, or isolated pieces of personal information. Others are altered, generated, or borrowed from different people. The result is a profile that may not correspond to any single human being, which is precisely what makes it durable: there is no victim to notice the fraud and report it.

A stolen identity normally uses the complete, coherent personal data of a real person without their permission. The data is internally consistent because it belongs to someone; the problem is that the person presenting it is not that someone.

Account takeover is different again. It happens after a genuine user has already been onboarded, when a third party gains control of an existing verified account. In practical terms, this matters for detection design: onboarding controls cannot catch account takeover, and post-onboarding behavioral controls are what surface it.

These categories overlap in practice. Stolen personal data is frequently the foundation on which a synthetic profile is built — one real element gives the profile a verifiable anchor, and the fabricated elements fill in the rest. An investigation that starts by asking "is this real or fake?" will usually get a less useful answer than one asking "which parts of this profile are real, and do they belong to the same person?"

A separate risk arises when the identity is genuine and correctly verified, but the account holder moves funds for another person or hands over control of the account entirely through crypto money mule or account-renting arrangements. There the identity profile is not the problem — the beneficial control of the account is.

Where Deepfakes and AI-Generated Documents Fit

Deepfakes get most of the coverage, but they occupy a specific slot in the attack rather than defining it. Generative tools contribute at several points: creating or altering a face image, morphing two faces into a composite, replacing a photograph inside a document image, producing a selfie or short video consistent with that document, and generating plausible profile text such as an occupation description or a source-of-funds explanation.

The important distinction is that a deepfake is a method of attacking the biometric or video layer. It is not the same thing as a synthetic identity, and treating "deepfake detection" as the answer to synthetic identity fraud narrows the defense to one layer of a multi-layer problem. FinCEN's alert makes the combination explicit: criminals pair GenAI-produced images with stolen or entirely fabricated personal information to construct synthetic identities. The image is one component; the PII, the device context, and the account behavior are the rest.

The Attack Chain: How a Synthetic Identity Reaches Approval

A standard automated onboarding flow runs data capture, document checks, biometric comparison, screening against lists, and then a decision — approve, reject, or route to manual review. That workflow is well established, and it works against most fraud attempts; the mechanics are covered in detail in our guide to how automated KYC verification works. What follows is not a walkthrough of how to defeat it, but a map of which connections between those steps tend to go unexamined.

One framing point before the detail. The most rigorous public assessment of this attack surface so far — the World Economic Forum's Cybercrime Atlas report Unmasking Cybercrime: Strengthening Digital Identity Verification against Deepfakes, published in January 2026 — evaluated 17 face-swapping tools and eight camera injection tools collected from underground channels. Its conclusion was notably less alarmist than the marketing around this topic. Genuine real-time face-swapping capability was uncommon, present in only five of the seventeen tools, and only three of those offered a path into a live verification flow. Most attempts still leave detectable traces in timing, lighting, and compression. The researchers deliberately redacted tool names and exploitation steps from the published paper — a convention worth following in any public discussion of this subject, and one this article follows too.

Building a Consistent Identity Profile

The core task for the attacker is not producing one convincing artifact. It is producing a set of artifacts that agree with each other: name and date of birth, document data, address, phone and email, a face image, a device and geographic context, and sometimes a payment method or an explanation of where the money comes from.

In practical terms, this is also where the defensive leverage sits. Each element can be made individually plausible with modest effort. Making eight elements mutually consistent — and keeping them consistent across ten accounts created the same week — is a substantially harder problem. Platforms lose that advantage when every element is validated in isolation and the relationships between them are never scored.

Passing Document Verification

Document risk falls into a few recognizable categories: alteration of an otherwise genuine document, replacement or modification of the photograph, entirely fabricated document images, fields that do not agree with one another, the same document appearing across multiple applications, and mismatches between the visual data, the machine-readable fields, and what the customer entered in the form.

Underneath all of these sits a distinction that document verification alone cannot resolve. Authenticity and ownership are separate questions. A check can conclude that a document appears genuine and internally consistent; it cannot conclude that the person submitting it is the person the document describes. That second question is what the biometric layer is supposed to answer — which is exactly why the biometric layer is where the pressure has moved.

Passing Selfie and Liveness Checks

At a conceptual level, attacks on the biometric layer fall into two families, and the difference between them determines which defenses apply.

A presentation attack shows fake media to a real camera: a printed photograph, a screen replay, a mask, a pre-recorded video played back to the device. The capture path is legitimate; the thing being captured is not.

An injection attack attempts to feed manipulated media directly into the digital capture flow, so that the verification system receives synthetic video without any physical camera involvement at all. Face swaps, face morphing, and synthetic video generation supply the content for either family.

The WEF assessment found that injection tools generally failed against modern SDK-based verification with embedded integrity checks and randomized challenge-response prompts, while performing better against plain browser-based flows. That is an actionable finding rather than a reassuring one: it means the choice of capture architecture materially affects exposure. It also aligns with where the volume is heading — industry telemetry cited in the same report recorded a 783% increase in injection attacks during 2024 and a further 88% year-over-year rise in 2025.

(Source: World Economic Forum, Cybercrime Atlas, Unmasking Cybercrime: Strengthening Digital Identity Verification against Deepfakes, January 2026)

A note on that data, because it affects how much weight it should carry. Nearly all attack-volume statistics in this field originate with identity-verification vendors measuring their own traffic, and those vendors sell detection products. The direction of travel is corroborated across independent sources; the precise percentages should be read as vendor telemetry rather than audited industry figures.

Supporting the Account With Device and Contact Data

The document and the face are only part of what a platform actually receives. An application also carries email and phone history, an IP address and geolocation, a device fingerprint, a payment method, sometimes a proof of address, and an implicit claim that the declared location matches the observed one.

A synthetic account passes more easily when these signals are collected but never compared — to each other, or to what other applications have submitted. In practical terms, a device fingerprint that appears once is nearly meaningless. The same fingerprint appearing across six applications with six different names is one of the strongest signals a platform will ever get, and it costs nothing to look for.

Exploiting Fragmented Decisioning

This is the structural weakness the whole attack depends on:

• The document check sees a document.
• The biometric check compares two images.
• Sanctions screening evaluates the name that was presented.
• The device system assesses a single session.
• Transaction monitoring starts later and typically receives none of the verification context.

Each control returns an acceptable result within its own scope. The full customer profile can remain internally contradictory, and nothing in the architecture is responsible for noticing. This is not a failure of any individual vendor or check, and it is not evidence that automated KYC is easily defeated — it is a consequence of assembling controls that were never designed to talk to each other.

Why Synthetic Accounts Create Crypto-Specific Risk

For an exchange, wallet provider, payment processor, broker, or other VASP, an approved synthetic account is not just a bad customer record. It is functioning infrastructure.

What the account provides is access to deposit and withdrawal functionality, a mule or funnel node in a larger network, a cash-out point for scam proceeds, a way to move assets across multiple wallets, a set of related accounts that can operate in coordination, a route around per-account or per-transaction limits, concealment of the person actually in control, and the ability to conduct activity that has nothing to do with the declared customer profile.

It is worth separating two levels of exposure, because they trigger different obligations. Fraud risk is that the platform is serving a fictitious or misrepresented user — a customer-integrity problem. AML risk is that the account is receiving, moving, or extracting criminal proceeds — a financial-crime problem with reporting consequences. Not every synthetic account is laundering money; some exist to abuse promotions or evade limits. But the same account structure serves both purposes, and the platform usually cannot tell which it is dealing with until it looks at the transaction behavior.

One point deserves emphasis, since it cuts against a common assumption about blockchain transparency: a blockchain address is a technical identifier, nothing more. It shows what moved and where, with permanent fidelity. It does not establish who controls the keys. On-chain analysis can demonstrate that several customer accounts share withdrawal infrastructure — an extremely useful finding — but it cannot independently identify the human being behind them.

Red Flags Before and During KYC Verification

The signals below warrant additional review, not automatic accusation. FinCEN's own framing in the deepfake alert is that no single indicator is determinative and that each must be evaluated alongside the surrounding facts and circumstances. In practical terms, a platform that auto-rejects on any one of these will reject a large number of legitimate customers and learn very little.

Identity and Document Inconsistencies

• Multiple documents from the same applicant contain data that does not match.
• The stated age or other profile attributes are inconsistent with the photograph.
• Document information conflicts with the declared address, income, or stated account purpose.
• The photograph appears internally inconsistent — visual artifacts suggesting alteration.
• The same document, photograph, or identity element appears across several applications.
• The customer cannot consistently confirm individual elements of their own profile when asked.

Biometric and Verification-Session Anomalies

• Visual or audio inconsistencies in the submitted media.
• Repeated failures on the same verification prompts, particularly randomized ones.
• Persistent attempts to switch to a different verification channel.
• An unusual volume of reported "technical glitches" during live checks — a pattern FinCEN specifically names, alongside the use of third-party webcam plugins during live verification.
• Indications of replayed or injected media.
• An anomalous webcam configuration or capture environment.
• A biometric result that technically passes but conflicts with other identity attributes.

Device, Network, and Cross-Account Signals

• IP or device location that does not correspond to the submitted documents.
• One device used across several ostensibly unrelated identities.
• Multiple accounts sharing a phone number, payment instrument, or technical attribute.
• Applications submitted in bursts or clusters.
• Related accounts moving through the same sequence of actions in the same order.
• Reuse of destination wallets or withdrawal infrastructure across accounts.

Three cautions on this list. A VPN is not evidence of fraud — a substantial share of privacy-conscious legitimate users route traffic through one. A technical glitch is not proof of a deepfake; connections genuinely drop. And a geolocation mismatch is not a standalone basis for rejection, since people travel, relocate, and use work networks. Hard universal thresholds imported from someone else's blog post are worse than useless, because the right threshold depends on your own customer base and observed base rates.

Red Flags After the User Has Passed KYC

Some synthetic identities are not detectable at onboarding. The profile is coherent, the media is clean enough, and there is simply no contradictory information available yet. The contradictions appear once the account starts behaving.

Activity That Does Not Match the Customer Profile

• High-value activity beginning immediately after approval, with no normal ramp-up period.
• No ordinary usage pattern at all — the account exists only to move value.
• Transaction volumes inconsistent with the declared occupation, income, or stated purpose.
• Deposits followed by near-immediate withdrawals.
• The account functioning purely as a transit point.
• Abrupt changes in geography, device, or behavioral pattern.

FinCEN's alert flags a closely related pattern: a newly opened account, or one with minimal transaction history, showing rapid transaction sequences or high payment volumes toward higher-risk payees.

Linked Accounts and Reused Infrastructure

Detection here has to target the network, not the individual. A single synthetic account is difficult to distinguish from an unusual real customer; six synthetic accounts built by the same operator are much easier to identify, because the operator reuses resources. Look for shared devices, repeated IP ranges, common payment instruments, reused contact data, similar onboarding patterns, shared withdrawal wallets, repeated counterparties, and synchronized behavior across recently created accounts.

The economics explain why this works. Building genuinely independent infrastructure for every account destroys the profitability of the scheme. Reuse is not carelessness; it is the business model.

Wallet and Transaction Risk Changes

On-chain behavior frequently reveals what onboarding could not: interaction with fraud-linked or otherwise high-risk wallets, rapid movement through a sequence of addresses, repeated deposit-and-withdrawal cycles, multiple customer accounts converging on shared wallets, and new risk indicators attaching to addresses that were clean at the time of the original check.

This is the practical reason identity verification and transaction analysis cannot remain separate systems — the relationship between how KYC and KYT work together in crypto compliance is not a conceptual nicety but the mechanism by which post-onboarding evidence reaches the identity record.

Why Document Verification or Liveness Alone Is Not Enough

Each control in the stack answers one narrow question well:

• Document verification asks whether the document appears authentic and internally consistent.
• Face matching asks whether the submitted face image resembles the photograph.
• Liveness asks whether a live subject, or a live-like capture, is present.
• Sanctions screening asks whether the presented identity appears on a list.
• Device analysis asks whether the technical context is anomalous.
• Transaction monitoring asks whether subsequent behavior fits the profile.

None of them, alone, establishes that the identity exists, that all the submitted data belongs to one person, that the applicant is the rightful owner of the document, that one operator is not running several approved accounts, or that later activity will match what was declared.

That is a statement about scope, not about quality. Liveness detection works — it meaningfully raises the cost of presentation and replay attacks, which is why attackers moved toward injection. The failure mode is not weak controls; it is the assumption that stacking more independent checks produces proportionally more security. It does not, if none of them share context. Two connected signals frequently outperform five isolated ones.

A Layered Control Model for Synthetic Identity Fraud

What follows is an architecture, not a feature list. The value is in the connections.

Verify the Document, Person, and Verification Session

The onboarding layer combines document authenticity and validity checks, consistency across document fields, face-to-document matching, selfie or video verification, liveness controls, session and capture integrity, address or supporting-document verification where the risk profile calls for it, and deeper checks for higher-risk cases.

In practical terms, most platforms already run some version of this — the difference between implementations is whether the components share a session record and whether higher-risk cases actually route somewhere different. A multi-layer onboarding process built on automated KYC and KYB verification can cover document, face, video, address, payment method, and source-of-funds checks together with ongoing screening, which matters less because any single check is decisive and more because the results end up in one place.

Link Signals Across Accounts

This is entity resolution, and it is the control most commonly missing. The system should be looking for repeated documents, reused face or biometric patterns, shared devices, phone and email reuse, common payment methods, overlapping IP and geographic data, shared wallets and counterparties, and repeated application behavior.

The mental shift is from scoring applicants to finding clusters. A risk engine that only ever evaluates one applicant against a policy will never see the pattern that makes synthetic identity fraud economically viable in the first place.

Connect Identity Risk to Transaction Monitoring

The connection has to run in both directions. KYC risk attributes should feed into transaction monitoring, so that behavioral thresholds reflect what the customer said about themselves. The customer account should be linked to its known deposit and withdrawal wallets. A suspicious transaction alert should be capable of triggering an identity re-review rather than just a transaction decision. A newly discovered link between accounts or wallets should update the customer risk rating. And a compliance case file should contain both the identity evidence and the on-chain activity, because a reviewer assessing either one alone is working with half the picture.

Because wallet risk is not static — addresses that were unremarkable at onboarding acquire exposure later, and sanctions designations arrive after the fact — this only functions on top of real-time crypto transaction monitoring tied to specific customer profiles rather than to anonymous addresses.

Use Risk-Based Re-Verification and Manual Review

Certain events should trigger step-up verification: a significant change in transaction behavior, a newly identified link to other accounts, a device or geography change, a wallet risk escalation, or a screening hit that arrives after approval.

Two design details make the difference between real re-verification and theater. First, the re-check should use an independent or stronger verification path rather than simply repeating the flow that already produced a questionable result — running the same check twice mostly tests whether the attacker can repeat themselves. Second, manual overrides need their own controls: who can override, on what basis, and with what record. Every case should retain the inputs, the system outputs, the reviewer's actions, and the final decision, and re-verification should incorporate the transaction and device information that has accumulated since onboarding.

This is ordinary risk-based practice applied to a specific trigger set, and it sits inside the broader discipline of ongoing customer due diligence in crypto — the principle that a customer risk profile is a living record rather than a snapshot taken at signup.

Test the Workflow Against New Attack Types

Vendor marketing claims are not evidence. The questions worth asking, of a provider and of your own configuration, are: how does it perform against presentation and injection attacks specifically; what are the false acceptance and false rejection rates, measured how and on what population; can it detect duplicates and cross-account reuse; what happens to uncertain results; what is the quality of the manual review layer; how are model updates managed and communicated; what does the audit trail actually capture; is there independent or controlled adversarial testing; and how quickly does the provider respond when a new fraud pattern appears.

The WEF report's recommendation to institutions is a red-team testing cadence rather than a one-time procurement assessment, precisely because the attack surface shifts faster than contract cycles. For the broader evaluation framework, see what to evaluate in a KYC service provider.

Three things this section is not arguing: that a single "AI detector" solves the problem, that more friction always means more security, and that every user should face the maximum verification level. Applying the heaviest controls universally degrades the experience for legitimate customers while giving determined attackers more information about how the system behaves.

What Compliance Teams Should Do When a Synthetic Identity Is Suspected

1. Preserve the evidence. Retain the submitted documents, images, video, session data, device and IP records, timestamps, verification results, and reviewer actions. Evidence that is not preserved at the moment of suspicion is frequently unrecoverable later, and a case built on a reviewer's recollection is not a case.
2. Apply proportionate restrictions. Act according to internal policy — restricting specific account actions or routing transactions to review, rather than treating suspicion as a finding of guilt. The suspicion may be wrong.
3. Run independent re-verification. Use a stronger or alternative verification method rather than re-running the flow that produced the ambiguous result.
4. Identify linked accounts. Check for shared devices, contact details, payment methods, documents, facial matches, IP infrastructure, wallets, and counterparties. A confirmed synthetic identity is rarely alone.
5. Review wallet and transaction activity. Determine whether the account has been operating as a transit, mule, funnel, or cash-out point, and identify which counterparties are involved. This is where the fraud question becomes an AML question. Where the case moves toward restriction or escalation, it should follow the platform's established high-risk transaction review and escalation workflow.
6. Document the decision. Record the evidence, the assumptions, the reviewer's reasoning, the restrictions applied, any escalation, and the final outcome.
7. Escalate or report where required. Whether a SAR or STR is filed, whether the account is closed, how funds are handled, and whether law enforcement is contacted all depend on jurisdiction, the strength of the evidence, and internal procedure. There is no universal rule here, and treating another jurisdiction's threshold as your own is a compliance error in its own right.

Two things not to do: disclose the details of an investigation to the account holder, and move personal data outside the permitted process. Both can compromise the case and create separate regulatory exposure.

How to Measure Whether Synthetic Identity Controls Work

Approval speed and onboarding conversion say nothing about fraud resilience. A system that approves everyone quickly performs superbly on both metrics.

More informative measures include the false acceptance rate, the false rejection rate, the manual review rate, the share of fraud detected only after approval, the number of repeated-document, device, or biometric clusters identified, the re-verification failure rate, the time from first signal to restriction or escalation, the number of linked accounts discovered per confirmed case, transaction losses or suspicious volume attributable to approved accounts, legitimate-user drop-off caused by step-up verification, and the reviewer override rate together with what those overrides subsequently turned out to be.

It helps to separate two levels. Vendor-level metrics describe the quality of an individual document or biometric check — useful for procurement, insufficient for risk management. Workflow-level metrics describe whether the entire onboarding-and-monitoring system detects coordinated fraud. A platform can hold best-in-class vendor scores and still fail at the workflow level, because the failure was never in any single check.

Two interpretations to resist: that a high rejection rate demonstrates strong defenses — it may simply demonstrate a badly calibrated model rejecting real customers — and that a low manual review rate is inherently good. A low manual review rate on a high-risk customer base usually means uncertain cases are being resolved by automation that was not designed to resolve them.

A Passed KYC Check Is a Risk Decision, Not Proof

Synthetic identity fraud attacks the connections between controls rather than any single document or selfie check. Generative AI has made the individual elements of a fabricated profile more coherent and cheaper to produce, which shifts the defensive advantage away from inspecting artifacts and toward correlating them.

Detection consequently depends on document, biometric, session, device, cross-account, and transaction signals being evaluated together. A KYC approval should be understood as the opening of a monitored customer relationship — a documented risk decision made with the information available at that moment — rather than as settled proof of who the customer is. The strongest workflows combine automation for volume, risk-based escalation for exceptions, human judgment for ambiguity, and ongoing monitoring for everything that only becomes visible later.

FAQ