Know your customer (KYC) checks are meant to stop criminals opening accounts, but fraudsters now defeat remote onboarding with generated faces, forged documents, synthetic identities and real people paid to pass the checks for them. This page ranks the ten bypass techniques that most often get fraudulent accounts through onboarding at banks, fintechs, crypto platforms and marketplaces, and for each one explains how it shows up, which signals catch it and which controls stop it. It is written from the defender's side: it describes techniques at the level needed to detect them, with no instructions for carrying them out. It is for fraud and financial crime teams, identity verification product owners and the security teams who support them. The fundamentals of proofing (assurance levels, the proofing pipeline, KYC and AML duties) are in the Identity Proofing and KYC Guide; this page is the short list of what goes wrong.
The Top 10 at a glance
| # | Technique | What it defeats | Where it is caught | Primary control |
|---|---|---|---|---|
| 1 | Camera injection of deepfake or replayed media | Selfie match and liveness | Capture pipeline, device signals | Injection attack detection (IAD) |
| 2 | Presentation attacks with photos, screens and masks | Liveness | Sensor and PAD model | Presentation attack detection (PAD) |
| 3 | Forged, altered or generated identity documents | Document verification | Document forensics, chip reading | NFC chip verification, issuer checks |
| 4 | Synthetic identities | Identity resolution and data checks | Attribute linking, consortium data | Multi-source evidence, velocity checks |
| 5 | Stolen identity data of real people | Knowledge and database checks | Biometric binding, victim signals | Biometric comparison to document |
| 6 | Money mules and account farming | The whole check (the person is real) | Post-onboarding behaviour | Mule analytics, device intelligence |
| 7 | Downgrading to a weaker channel or fallback | Strong paths, via the exception route | Channel switch patterns | Equivalent assurance on every path |
| 8 | Tampering with client-side results and APIs | Server trust in the client | Server-side verification records | Server-side decisions, signed results |
| 9 | Insider help in onboarding or review | Manual review and overrides | Reviewer analytics | Four-eyes approval, override monitoring |
| 10 | Re-verification and account recovery abuse | Controls after onboarding | Change-of-details monitoring | Re-proofing to original assurance |
The ranking is an editorial judgement weighing how widely each technique is reported in regulator and standards body publications (FinCEN, NIST, ENISA, FATF) against how hard it is to detect. A crypto platform with fully automated onboarding will rank items 1 and 6 highest; a bank with branch onboarding may see more of items 3 and 9.
1. Camera injection of deepfake or replayed media
How it shows up: the genuine camera is bypassed and media is fed into the capture stream through a virtual camera driver, an emulator, a modified app or an intercepted upload. The payload may be a face swap, a fully generated face or a replay. NIST SP 800-63A-4 notes that generative AI tools are being combined with injection attacks to defeat document checks, biometric checks and visual comparison, and the European standard CEN/TS 18099:2024 defines these attacks and how to test detection. This is MITRE ATLAS AML.T0088 Generate Deepfakes in practice.
Signals: virtual camera or emulator present, rooted or hooked devices, capture metadata that does not fit the device, identical background or lighting across many applications, and the FinCEN red flag of a third-party webcam plugin during a live check.
Controls: injection attack detection on the client and server, captures bound to a server-issued nonce and session so replays fail, signed capture payloads from native apps, and routing high-risk desktop sessions to mobile capture. Ask suppliers for independent IAD test results, not only PAD results. See the Deepfake-Resistant Identity Verification Guide.
2. Presentation attacks with photos, screens and masks
How it shows up: an artefact is held in front of a real camera: a printed photo, a video on a screen, or a mask. These are the attacks liveness was built for, and weak or outdated liveness still lets them through.
Signals: screen moire patterns, reflections, edges of paper or masks, and repeated failures followed by a sudden pass.
Controls: PAD tested to ISO/IEC 30107-3. NIST SP 800-63B-4 sets a target impostor attack presentation accept rate (IAPAR) below 0.07 for biometric PAD, and SP 800-63A-4 applies PAD to remote biometric capture. Limit retries, since attackers iterate until one artefact passes. See the Biometric Liveness and Presentation Attack Detection Guide.
3. Forged, altered or generated identity documents
How it shows up: edited photos or data fields on genuine document images, entirely generated document images, and templates of real document designs. FinCEN alert FIN-2024-Alert004 (November 2024) describes criminals using generative AI to create or alter identity documents for account opening and lists red flags including documents inconsistent with each other or with the customer's apparent age.
Signals: font and layout anomalies, machine readable zone check digits that do not match, the same document number or face across applications, and image metadata showing editing.
Controls: read the NFC chip in electronic passports and identity cards and validate its signature against the issuing state's certificates where possible, which defeats image-only forgery. Where chips are not available, use document forensics plus authoritative source checks with the issuer. Higher assurance levels in NIST SP 800-63A-4 require stronger evidence validation.
4. Synthetic identities
How it shows up: an identity built from a mix of real attributes (often a real national identifier belonging to a child or someone with no credit history) and invented ones. It resolves to nobody in particular, passes each individual check, and is often matured for months before it is used for credit fraud or mule activity. There may be no victim to complain.
Signals: thin or recent credit files, identifiers issued long before the stated address history, shared phone numbers, emails or devices across applications, and addresses with many unrelated applicants.
Controls: strong identity resolution against several independent sources, consortium and cross-institution data, velocity checks on attributes, and verification of identifiers with the issuing authority where a service exists. See the Synthetic Identity Fraud Guide.
5. Stolen identity data of real people
How it shows up: breached personal data, sometimes with photos of the victim's real documents, used to open accounts in the victim's name. Knowledge-based questions and database matches pass because the data is genuine.
Signals: device, network or geography inconsistent with the identity (another FinCEN red flag), email addresses created recently, the identity appearing in known breach data, and victim complaints after the fact.
Controls: bind the applicant to the evidence with biometric comparison against the document or chip photo, and do not rely on knowledge-based verification: NIST SP 800-63A-4 states that knowledge-based verification shall not be used for identity verification, although it may support fraud management. Notify the identity owner through contact details from an authoritative source where possible.
6. Money mules and account farming
How it shows up: real people pass KYC honestly, then sell, rent or hand over the account, or are recruited through fake job offers to move funds. Organised groups open many such accounts. The proofing was correct and the account is still fraudulent.
Signals: accounts dormant after opening and then receiving and forwarding funds within hours, device or login location changing after onboarding, many accounts sharing a device or payout destination, and students or job seekers recruited through social media.
Controls: monitor behaviour after onboarding, not just at the gate; link devices and beneficiaries across accounts; share mule indicators with peer institutions; and include mule typologies in transaction monitoring. See the Money Mule Detection Guide and the AML programme and transaction monitoring guide.
7. Downgrading to a weaker channel or fallback
How it shows up: applicants who fail or avoid the strong automated path are offered an easier one: manual document upload, a call centre route, a video call with an agent, or an exception granted after repeated "technical problems". FinCEN lists a request to switch communication method after repeated glitches as a red flag.
Signals: high fallback rates from particular devices, networks or referral sources, and applicants who fail the automated check and then pass a manual one.
Controls: make every path meet the same assurance level, train agents for remote attended sessions to spot manipulated media (as SP 800-63A-4 expects), and treat a failed automated check as a risk signal on the fallback, not a reset. Measure manual review overturn rates.
8. Tampering with client-side results and APIs
How it shows up: the onboarding app or web page receives a "pass" from the verification provider and forwards it to the back end, which trusts it. An attacker who controls the client can change the result or skip the step. Weak API authorisation can also let one verified session be reused for other applications (OWASP API Security Top 10 2023 API1 Broken Object Level Authorization and API6 Unrestricted Access to Sensitive Business Flows).
Signals: accounts marked verified with no matching record at the verification provider, verification session identifiers reused across applicants, and onboarding API calls out of the expected sequence.
Controls: the back end fetches the verification decision directly from the provider over an authenticated server-to-server channel or validates a signed result, sessions are single use and bound to the applicant, and the onboarding flow is enforced server side. Include the verification flow in application security testing. See the Top 10 API Security Risks.
9. Insider help in onboarding or review
How it shows up: onboarding staff, outsourced reviewers or branch employees approve applications they should reject, override automated declines or bypass checks in exchange for payment.
Signals: one reviewer with an approval rate or override rate far from peers, approvals clustered at odd hours, and accounts approved by the same person later confirmed as fraud.
Controls: four-eyes approval for overrides, analytics on reviewer decisions, sampling of approved cases, and rotation of review queues. See the Top 10 Insider Threat Indicators.
10. Re-verification and account recovery abuse
How it shows up: the account was opened by the real customer, then taken over through a weak recovery or change-of-details process (new phone, new email, new device) that does not re-check identity to the original standard. The KYC record still says "verified" while someone else controls the account.
Signals: contact details changed shortly before large transfers or withdrawals, recovery requests from new devices and networks, and support tickets asking to bypass checks.
Controls: re-proof to the original assurance level for recovery and high-risk changes, hold high-value actions for a cooling-off period after a change, and notify the old contact details. See the Account Takeover Prevention Guide and the Account Recovery and Help Desk Security Guide.
Detection and measurement
Pass rates at onboarding hide most of these failures. Measure what happens after the account opens, and feed confirmed fraud back into rules and supplier assurance.
| Signal | Stage | Techniques it catches |
|---|---|---|
| Virtual camera, emulator, hooking framework detected | Capture | 1 |
| Same face, document number or background across applications | Verification | 1, 3, 6 |
| Chip read failed or not attempted on a chip-enabled document | Verification | 3 |
| Shared phone, email, device or address across unrelated applicants | Resolution | 4, 6 |
| Device or geography inconsistent with the identity | Verification | 5 |
| Automated fail followed by manual pass | Review | 7, 9 |
| Verified flag with no matching provider record | Back end | 8 |
| Dormant then rapid in-and-out funds | Post-onboarding | 4, 6 |
| Contact change followed by high-value activity | Post-onboarding | 10 |
Metrics that show controls are working:
- Early-life fraud rate: share of accounts confirmed fraudulent within 90 days of opening, by onboarding channel.
- Injection detections: number and trend of injection attempts blocked in production.
- Chip read rate: share of chip-enabled documents verified by chip rather than image.
- Manual review overturn rate: share of automated declines approved on manual review, and their later fraud rate.
- Mule account dwell time: median days from opening to detection for confirmed mule accounts.
- Supplier test currency: date of the latest independent PAD and IAD test for each verification supplier.
Common failure patterns
- Testing only for presentation attacks: suppliers show PAD certificates while injection, the bigger risk for remote onboarding, goes untested.
- Measuring conversion, not fraud: onboarding teams rewarded for pass rates loosen thresholds and add fallbacks that fraudsters find first.
- Trusting the client: the back end accepts a "verified" result from the app instead of checking with the provider.
- KYC as a one-off: no monitoring after opening, so mule and farmed accounts run for months.
- Weak recovery after strong onboarding: a high-assurance account recovered with a text message code.
- Fraud and AML teams apart: fraud sees the device links, AML sees the fund flows, and nobody joins them.
Mapping to standards and frameworks
| Technique | Standard or guidance | Control reference |
|---|---|---|
| 1. Injection | CEN/TS 18099:2024; NIST SP 800-63A-4 | NIST SP 800-53 IA-12; ATLAS AML.T0088 |
| 2. Presentation attacks | ISO/IEC 30107-3; NIST SP 800-63B-4 biometric requirements | IA-12 |
| 3. Forged documents | NIST SP 800-63A-4 evidence validation; ETSI TS 119 461 | IA-12 |
| 4. Synthetic identities | NIST SP 800-63A-4 identity resolution | IA-12; CSF PR.AA-02 |
| 5. Stolen identity data | NIST SP 800-63A-4 verification | IA-12 |
| 6. Mules and farming | FATF risk-based approach to customer due diligence | Transaction monitoring; CSF DE.AE-02 |
| 7. Channel downgrade | NIST SP 800-63A-4 remote attended proofing | IA-12 |
| 8. Client and API tampering | OWASP API Security Top 10 2023 API1, API6 | AC-3 |
| 9. Insider help | Segregation of duties | AC-5, PM-12 |
| 10. Recovery abuse | NIST SP 800-63B-4 account recovery | IA-5; CSF PR.AA-01 |
Where to start
- First 30 days: confirm the back end verifies results server to server (item 8), list every fallback path and its assurance level (item 7), and ask each supplier for current PAD and IAD test reports.
- Days 30 to 90: turn on NFC chip reading where documents support it, add device and attribute linking across applications, and set up early-life fraud reporting by channel.
- Days 90 to 180: add mule behaviour models to post-onboarding monitoring, join fraud and AML case data, and bring recovery and change-of-details up to the onboarding assurance level.
- Ongoing: commission authorised testing of the onboarding flow, including injection and attended-session scenarios, after every major supplier or model change.
Smaller fintechs that buy verification as a service should focus on items 7, 8 and 10, which they control directly, and on supplier evidence for items 1 to 3. Large institutions need consortium data and cross-channel analytics to make progress on items 4 and 6.
Practitioner checklist
- Verification decisions are fetched or validated server side; client results are never trusted.
- Every onboarding path, including fallbacks and attended video, meets the same assurance level.
- Suppliers provide independent PAD and IAD test evidence, refreshed after major changes.
- Chip-enabled documents are verified by chip where the platform supports it.
- Applications are linked by device, phone, email, address and face to find clusters.
- Accounts are monitored after onboarding for mule behaviour.
- Manual overrides need a second approver and are analysed per reviewer.
- Recovery and contact changes re-proof to the original assurance level.
- Confirmed fraud cases feed back into rules and supplier reviews.
Standards and references
- NIST: SP 800-63A-4 Digital Identity Guidelines, Identity Proofing and Enrollment
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- FinCEN: Alert on Fraud Schemes Involving Deepfake Media Targeting Financial Institutions (FIN-2024-Alert004)
- CEN: CEN/TS 18099:2024 Biometric data injection attack detection
- ETSI: TS 119 461 Policy and security requirements for trust service components providing identity proofing
- ENISA: Remote Identity Proofing, Attacks and Countermeasures
- FATF: Guidance on Digital Identity
- OWASP: API Security Top 10 2023
Related NHI Mgmt Group resources: Identity Proofing and KYC Guide · Deepfake-Resistant Identity Verification Guide · Synthetic Identity Fraud Guide · Money Mule Detection Guide · Top 10 Financial Services Cyber Threats