The same thing keeps happening in the onboarding teams I work with.
An analyst looks at a document image, sees nothing wrong, and approves. Months later somebody asks why. The honest answer is that nothing was visible. That is not carelessness. A control stopped working, and nobody told the person operating it.
This article is about what to retrain on, not about how the fraud is committed. I have written nothing here that would help anyone produce or pass off a false document or identity, and the verification section sets out exactly how that rule was applied. The credit bureaus and the Federal Reserve have explained the crime well. Nobody has published a plan for the team that has to catch it.
What is synthetic identity fraud? Definition, and how it differs from identity theft
Key point: a synthetic identity is a fabricated person built from a mixture of real and invented data, so there is no victim to complain.
The Federal Reserve, through its FedPayments Improvement programme, published an industry definition. Read at fedpaymentsimprovement.org on 30 August 2026:
"The use of a combination of personally identifiable information (PII) to fabricate a person or entity in order to commit a dishonest act for personal or financial gain."
PII means personally identifiable information. That wording is framed for the United States payments system, so treat it as a definition, not a description of how the risk behaves in your market.
A stolen identity belongs to somebody. That person eventually notices and disputes, and the complaint surfaces the fraud. A synthetic identity belongs to nobody, so nothing surfaces from the customer's side. Detection has to come from yours. That single difference is why retraining matters: your controls were built assuming a wronged person exists somewhere. In the fraud taxonomy, the distinction is usually drawn between third-party fraud, where a real person's identity is used without their consent, and first-party fraud, where a real person misrepresents their own position. A synthetic identity sits outside both, because the person named does not exist to be either victim or liar.
It is also an anti-money laundering problem, not only a fraud loss. Anti-money laundering, or AML, and counter-terrorist financing, or CFT, obligations attach to knowing who your customer is. Customer due diligence, or CDD, cannot be satisfied against a fabricated person. Where the applicant is a company, the ultimate beneficial owner, or UBO, cannot be identified either, because the natural person named at the end of the chain does not exist to be identified. Everything downstream then inherits the defect: the customer risk rating describes nobody, the monitoring profile is built against invented expected activity, and the review cycle is scheduled for a person who will never walk into a branch. If you need the boundary set out properly, we cover the difference between AML and KYC separately. Know your customer, or KYC, teams are measured on throughput and fraud teams on loss, which is often why nobody owns this.
What has changed for a KYC reviewer now that AI generated documents pass inspection
Key point: the artefact you inspect is now cheap to produce convincingly, so it carries far less evidential weight than it did.
What changed is the cost of producing a convincing artefact, and the change is worth stating at the level a practitioner needs and no further.
Documents and face images produced with artificial intelligence, or AI, now pass visual inspection routinely. I am not going to describe how they are produced, which tools do it, or what makes one output more convincing than another. None of that helps you review a file.
What follows from it is the useful part.
A clean-looking document is no longer evidence of much. It used to be weak evidence. Taken alone it is now close to none.
The absence of a visible defect is not a finding. Analysts have been trained for years to write "no anomalies observed" and move on. That sentence now means only that nothing was visible.
Attention has to move outward. Away from the pixels, towards sources, session, history and corroboration.
Speed pressure cuts differently now. When the control was visual, a fast reviewer was slightly riskier. When the control is a set of checks against outside sources, a fast reviewer who skips them is not operating the control at all.
Why visual document inspection is no longer sufficient for KYC and identity document verification
Key point: keep visual inspection, but demote it from the decision to a filter.
I am not telling you to stop looking at documents. A supervisor would rightly ask why you dropped a control. I am telling you to change what the look is for.
Visual inspection is a cheap first filter. It catches careless submissions and confirms the file matches the application in front of you. It is no longer good at telling you the person exists.
There is a consequence for the write-up. A file note saying the document appeared genuine records an opinion about an image. It does not record verification. Those are different things, and a reviewer will notice.
Liveness detection, presentation attacks and injection attacks in deepfake KYC fraud, in plain language
Key point: a face check proves either that something happened in front of a camera, or that something reached your system claiming to be a camera. Your control has to know which.
Every remote onboarding flow now has some form of face check. Practitioners call the whole problem deepfake KYC, which is shorthand rather than a definition. Two terms come up and are usually explained badly.
Liveness is a check that tries to establish that a real person was physically present at capture, rather than a still image or a recording. That is all it claims.
A presentation attack is the category where something is shown to the camera instead of a live person. The control point is the capture environment.
An injection attack is the category where the camera is bypassed and prepared content is delivered into the verification flow as though it came from one. The control point is the integrity of the channel and the device, not the picture.
I am not going to describe how either is carried out. The distinction is what matters operationally, because it tells you where the control has to sit. If your flow can only assess the image it receives, it can say something about presentation and almost nothing about injection. That is a question for your technology owner rather than your analyst. But the analyst should know which question was answered, because it changes what their approval means.
Two rules for any procedure. No control type "stops" this, and a claim that one does is marketing. And a liveness result is one input to a decision, never the decision.
The identity verification hierarchy: weakest to strongest evidence in remote onboarding
Key point: rank evidence by how hard it is for the applicant to control, not by how modern it sounds.
Ranking evidence by how hard it is for the applicant to control is the structure I teach. It is simple on purpose, because it has to survive contact with a queue on a busy afternoon.
Table 1 sets out five levels. Each row names the check, what that check genuinely proves, and what it does not prove, which is the column most procedures leave out. The most common mistake is to treat the levels as a ladder and stop climbing once one of them returns a green result.
| Level | What it is | What it proves | What it does not prove |
| 1 | Visual inspection of a submitted artefact | The file is legible and matches the application | That the document is genuine, or that the person exists |
| 2 | Automated document authentication | The artefact behaves like a document of that type under machine checks | That the identity behind it is a real person with a real history |
| 3 | Liveness and biometric binding | A capture behaved like a live person and matched the document image | That the underlying identity is genuine, or that the channel was trustworthy |
| 4 | Verification against an authoritative source | The identity data matches a record held by a body that issued or registers it | Who presented it, unless the check is bound to the session |
| 5 | Corroboration across independent data the applicant does not control | The identity has a footprint that was not created for this application | Nothing on its own. It raises or lowers confidence, it does not certify |
Two things to notice.
The levels combine, they are not a ladder you climb and stop. Level 4 without level 3 tells you a real record exists but not who is holding the phone. Level 3 without level 4 tells you a live human was captured but not that the identity is real. Either alone is a gap.
The strength comes from who controls the evidence. At level 1 the applicant controls everything you are looking at. At level 5 they control almost none of it. That logic holds even as the technology changes.
Cabinet Resolution No. 134 of 2025, Article 9, clause 1, puts the same idea in legal terms. Firms must verify identity:
"using original documents, data, or information obtained from a reliable and independent source"
Read those two words as a test you apply at every level. An image supplied by the applicant is neither.
The Financial Action Task Force, or FATF, made a related point in its Guidance on Digital Identity, published in 2020 and read at fatf-gafi.org on 30 August 2026:
"Reliable, independent digital ID systems with appropriate risk mitigation measures in place may be standard risk, and may even be lower-risk."
Useful when somebody argues that remote onboarding should simply be treated as high risk. Confirm the current version before relying on it in a policy document.
Synthetic identity fraud detection: the red flags and signals that still work at onboarding
Key point: the signals that still work are the ones an applicant cannot manufacture at the moment of application.
Everything below is written from the reviewer's side. Each item says what to check and why the answer is informative.
Signal 1: source verification against an authoritative source
Verification against an authoritative source is the strongest signal at onboarding because it tests identity against a record the applicant did not create. Check whether the identity data has been matched against the body that issues or registers it, and record which check ran, not just that one passed. Check whether the match was bound to the session or run afterwards as a separate lookup. An unbound match tells you a record exists somewhere and nothing about who submitted the application.
Signal 2: history and independent footprint
A footprint that predates the application is informative because a fabricated identity has to be built shortly before it is used. Check how far back the identity has a footprint, and in what. An identity with no past proves nothing on its own. It is a question that has to be answered, and the answer may be innocent: a young applicant, a recent arrival, a person outside formal financial systems. Record the absence as a finding. "No corroborating history located, searches run as follows, applicant explanation obtained" is a real file note. Silence is not.
Signal 3: device, session and behavioural signals
Device and session data describe the context of the application rather than the artefact submitted, and the applicant controls far less of it. Check what the platform captured about the session and whether anyone looked at it. Most firms collect this and never surface it to the reviewer. Check whether the same session characteristics recur across other applications in the same period.
Signal 4: relationship and network signals, or cross-application clustering
Cross-application clustering is the signal that catches volume rather than individuals, because identities produced in batches share attributes that genuine single applications do not. Check whether attributes of this application appear on others: shared contact details, addresses, payment instruments, referrers. Volume applications leave patterns that single applications do not. This is a system capability. If your firm cannot run it, say so in the risk assessment rather than pretending the control exists.
Signal 5: consistency across the whole KYC file
Whole-file consistency is the one signal a firm can run without any platform, because it tests whether the KYC file describes a coherent life rather than a set of matching documents. Check whether the stated purpose of the relationship, expected activity, employment information and source of funds hang together as a story about one person's life. Consistency alone is not clearance. But an explanation that does not hold together is a reason to ask for more, and a reason you can write down.
No single signal decides an application. A procedure that turns one into an automatic decline will produce unfair outcomes, and one that turns any into an automatic approval will produce losses.
| Signal | What it tells you | Reliability trend | Human or system |
| Visual appearance of a document image | Whether the file is usable and matches the application | Degrading | Human |
| Machine document authentication | Whether the artefact behaves like that document type | Holding, with a narrowing margin | System |
| Liveness and face match | Whether a capture behaved like a live person and matched | Contested, depends on channel integrity | System |
| Authoritative source match | Whether the identity record exists at the issuing body | Strengthening | System, human interprets |
| Session and device data | Whether the application context is ordinary or shared | Strengthening | System, human interprets |
| Cross-application clustering | Whether this application is one of many | Strengthening | System only |
| Depth of independent footprint | Whether the identity has a past predating the application | Holding | Human, with search tooling |
| Internal consistency of the file | Whether the story about the person holds together | Holding | Human only |
| Response to an evidence request | Whether the applicant can and will produce more | Holding | Human only |
The fairness rule that has to be written into the onboarding control
Key point: no red flag may be tied to nationality, ethnicity, name origin or the country that issued a document. Put that in the procedure, because a team building its own flags will otherwise drift there.
Proxy discrimination belongs in the body of an article like this, not in a footnote. It is a real failure mode in onboarding controls, and almost nobody writes the rule against it into a procedure.
When a team is told that visual inspection no longer works and is not given a replacement, it improvises. The improvisations are predictable, and they are usually about where the applicant is from, what their name looks like, or which country issued their document. That is a proxy, not a risk indicator. It is discriminatory, and it will not survive a supervisory review or a complaint.
Three rules I would put in writing.
Flags are behavioural, structural and evidential. What happened in the session. How the file is put together. What corroboration exists. Never who the applicant appears to be.
Country risk is an institutional control, not an analyst's impression of a passport. Cabinet Resolution No. 134 of 2025, Article 23, requires enhanced due diligence proportionate to risk from countries the National Committee identifies as high risk. That is a defined, published process applied through your risk assessment.
Test your own decline data. If declines cluster by nationality or document origin rather than by the behavioural and evidential signals in your procedure, the control has drifted. Better that you find out than somebody else.
What to do when the identity document looks perfect: a six step escalation procedure
Key point: you need an escalation route that does not depend on finding a visual defect, because there may not be one.
The question onboarding analysts actually ask is what to do when nothing looks wrong at all. Practitioners in open forums repeatedly say the same thing in different words: the documents look real now, so what am I supposed to do. "Look harder" is not an answer. The procedure below is the one I teach.
Establish which levels of the hierarchy were actually satisfied. Not which checks ran. Which returned a result that speaks to existence and to session binding. Write it down.
If level 4 or level 5 is missing, escalate. Nothing needs to look wrong. The absence of independent evidence is the trigger.
Request one item of evidence the applicant does not control the creation of. Something issued or held by a third party, rather than something they produce.
Ask a question that requires knowledge rather than a document. About the purpose of the relationship, expected activity, or source of funds. You are testing whether a coherent person sits behind the file.
Treat a refusal, abandonment or substitution as information. Not proof of anything. A fact about the application that belongs in the file.
Decide, name yourself, write the reasoning. A decision nobody signed is not a decision.
One caution on step 5. Some genuine customers cannot complete some checks: accessibility needs, poor connectivity, an older device, no national digital identity. Build an alternative route. A control that quietly excludes people is a different kind of failure.
Can a synthetic identity pass enhanced due diligence (EDD)?
Yes, if enhanced due diligence is operated as a request for more documents. EDD, meaning enhanced due diligence, adds assurance only where it adds evidence the applicant does not control: an authoritative source match bound to the session, corroboration from independent data the applicant did not create, and questions that test knowledge rather than paperwork. A checklist that asks a fabricated identity for three further artefacts from the same source produces volume, not assurance. If your EDD procedure names document types rather than evidence properties, it will pass a synthetic identity that a level 4 or level 5 check would have stopped.
The six steps add minutes to a file, not hours, but they land on a queue that is already measured on throughput. If you are planning this into a real onboarding rota rather than a policy document, what an AML analyst actually does all day is the honest picture of the time you are competing for.
Writing the KYC decision up so it survives QA review
Three elements, in this order. What you verified and at which level, with named checks and sources. What you could not verify and what you did about it, including the evidence request and the response. Why you decided as you did, in one plain paragraph a stranger to the file can follow.
Quality assurance, or QA, reviewers send files back for the second element far more than the first. Most analysts record what they found. Very few record what they looked for and did not find, which is the part that shows a control was operated. Cabinet Resolution No. 134 of 2025, Article 25, requires firms to retain due diligence records, account files, correspondence and the "results of any analysis conducted". Your reasoning is part of that analysis.
A worked hypothetical: the remote onboarding application that passes every document check
Key point: every document-level control can return green and the file can still be the one you should escalate.
This is an illustrative hypothetical. It describes no real person, customer, case, institution or document. No real names, numbers or jurisdictions are used.
A remote application arrives for a personal account. The document image is clean, machine authentication passes, and the face check returns a match with a live result. Every document-level control is green. Under the old procedure this file is approved in four minutes.
The analyst instead runs the hierarchy check. Levels 1, 2 and 3 are satisfied. Level 4 has not been run, because the applicant's identity data belongs to a jurisdiction where the firm has no source verification route. Level 5 returns nothing: no independent footprint predating the application by more than a few weeks. Under the old procedure that is a shrug. Under the new one it is the escalation trigger, and nothing looked wrong to produce it.
The analyst requests one item of third-party evidence and asks two questions about purpose and expected activity. The answers are inconsistent with the employment information already on file. The evidence request is not completed and the application is abandoned.
The write-up records four things. Which levels were satisfied and which were not. That no source verification route existed for that jurisdiction, which is a control gap and not a fact about the applicant. The inconsistency, quoted. And the abandonment, dated. The file then goes to the Compliance Officer to consider whether a report is required.
The AML obligation: what UAE law requires on customer due diligence and reporting
Key point: an abandoned or declined application is not automatically outside the reporting duty, because the reporting text reaches an attempted transaction.
Where synthetic identity fraud meets customer due diligence (Article 6)
"Financial Institutions, DNFBPs, and Virtual Asset Service Providers shall verify the identity of the Customer and the Beneficial Owner before or during the establishment of a Business Relationship or the opening of an account, or prior to carrying out a Transaction for a Customer with whom no such relationship exists."
DNFBP means designated non-financial business or profession: real estate agents, dealers in precious metals and stones, corporate service providers, auditors and lawyers within scope. Article 7, clause 1, also requires CDD measures where "there are doubts as to the accuracy or adequacy of Customer identification data previously obtained". That is your hook for a KYC remediation lookback on files approved under a control you now know was weakening. Scope by exposure rather than volume, and record the trigger in the file, because a remediation with no explainable basis is hard to defend later.
When you cannot complete customer due diligence (Article 14)
"Financial Institutions, Designated Non-Financial Businesses and Professions, and Virtual Asset Service Providers shall be prohibited from establishing or continuing a Business Relationship or executing a Transaction where they are unable to apply Customer Due Diligence measures, and shall consider submitting a Suspicious Transaction Report to the Unit whenever necessary."
A prohibition, paired with a duty to consider a report. The Unit is the Financial Intelligence Unit, or FIU. A suspicious transaction report is an STR.
When a declined application becomes a suspicious transaction report (STR) consideration (Article 18)
"Where Financial Institutions, Designated Non-Financial Businesses and Professions, and Virtual Asset Service Providers suspect, or have reasonable grounds to suspect, that a Transaction or attempted Transaction, or funds, in whole or in part, constitute proceeds, are related to the Crime, or are intended to be used therein, regardless of their value"
"Attempted Transaction" is the phrase that matters to an onboarding team. A rejected application is not automatically reportable, and suspicion still has to be formed on reasonable grounds. But the drafting does not stop at completed business, so "we declined them, so there is nothing to report" is not a safe default. Article 19, clause 1, also prohibits disclosing to a customer or anyone else that a report has been or is about to be submitted, which has a direct effect on your decline messaging templates.
This is a genuine legal question and the position differs by jurisdiction. Take the text to your own counsel and your supervisor's published guidance rather than relying on this page. If you file in the UAE, our guide to registering and filing on goAML covers the mechanics.
Who owns the reporting decision: Compliance Officer, MLRO or BSA Officer
The new technology clause, which cuts both ways (Article 24)
"Financial Institutions, Designated Non-Financial Businesses and Professions, and Virtual Asset Service Providers shall identify and assess the risks of Money Laundering, Financing of Terrorism, and Proliferation Financing that may arise from the development of new products and new business practices, including new service delivery mechanisms and the use of new or developing technologies for both new and pre-existing products."
Clause 2 requires that assessment be conducted "prior to the launch or use of products, practices, or technologies", with measures to manage and mitigate what it finds.
Outward, a remote onboarding channel is a new service delivery mechanism, and you must assess and document the risk that an identity presented through it is fabricated, rather than absorb it. Inward, the verification technology you buy to solve the problem is itself a new technology under the same article. Assessing an artificial intelligence-based identity tool before switching it on is a legal step in the UAE, not a procurement preference. On that decision, our article on choosing AI screening for your business sets out the questions to ask.
Remote onboarding without an identity verification platform: what a small firm can do
Key point: a small firm cannot replicate a platform and should not pretend to. It can change what it accepts, what it asks for, and when it declines to onboard remotely at all.
Most writing on this assumes a bank's technology budget. A large share of regulated firms in the Gulf are brokerages, dealers in precious metals and stones, corporate service providers and audit practices with a two-person compliance function.
What a small firm can still do without a verification platform
Run the whole-file consistency check properly, every time. Request one item of third-party evidence on every higher-risk file. Record negative findings. Ask knowledge questions rather than asking for more documents. Keep a simple register of shared attributes across applications, even in a spreadsheet, because clustering is the best free signal a small firm has. Structured open source intelligence, or OSINT, research also carries more weight here than in a bank, because it is the corroboration layer you can actually run. We set out an OSINT workflow for KYC and enhanced due diligence step by step, and our course on enhanced due diligence and OSINT practice covers it with exercises.
What you should not attempt manually
Do not authenticate a document by eye and record that as verification. Do not build a liveness judgement from a video call and treat it as a control. Do not construct informal flags about where an applicant is from. If you cannot run a level 4 or level 5 check, the honest entry in your risk assessment is that the control is absent, mitigated by other measures you name.
When the answer is not to onboard remotely at all
For higher risk relationships, where no source verification route exists and the exposure is material, an in-person step is a legitimate control choice. "We could not verify remotely, so we did not onboard remotely" reads well in an inspection.
Where UAE identity infrastructure helps: Emirates ID and UAE PASS
Emirates ID is issued by the Federal Authority for Identity, Citizenship, Customs and Port Security, at icp.gov.ae. UAE PASS is described on the official UAE government portal, read at u.ae on 30 August 2026, as:
"The first national digital identity and signature solution that enables users to identify themselves to service providers through a smartphone-based authentication."
That is a level 4 route where it is available, and a genuine regional advantage. Two limits. It covers only people who hold it, which isn't every applicant a UAE firm onboards, and non-residents won't have one. And authentication tells you an account was used, which is strong but not the same as certifying which human was present. Check what your integration actually returns and write that down.
The retraining plan for a KYC and onboarding team: six modules
Key point: this is a curriculum, not a memo. Six modules, each aimed at changing one behaviour, each with an exercise and an assessment.
Publish it, adapt it, run it. It is here ungated because the market keeps saying "train your staff" and then stopping.
AML training is also a written obligation in the UAE. Cabinet Resolution No. 134 of 2025, Article 22, clause 4, makes it a duty of the Compliance Officer:
"Developing, implementing, and documenting ongoing programs and training plans for employees of the establishment regarding all matters related to the Crime and methods of combating it."
| Module | Objective | Content | Exercise | Assessment |
| 1. What a document can and cannot prove | Move the analyst off the artefact as the decision | Evidential weight of a submitted image; why "no anomalies observed" is not a finding; what visual inspection is still for | Re-review five previously approved files and mark what was actually verified in each | Analyst can state, for any file, which claim the document supports and which it does not |
| 2. The verification hierarchy in your own process | Map the five levels onto the real flow | Walk the actual onboarding journey; identify which levels the firm runs and where the binding gaps are | Draw the firm's own hierarchy map with gaps marked | Analyst can name which levels a given file satisfied without opening the system |
| 3. Reading signals outside the document | Build the outward-looking habit | Source, history, session, network and consistency signals; recording negative findings; why absence is a question, not a verdict | Work three live files using only non-document evidence, then compare with the system decision | Analyst produces a file note recording what was looked for and not found |
| 4. Escalation and evidence requests | Give a route that needs no visual defect | The six step procedure; what third-party evidence to request; how to ask without tipping off; handling refusal and abandonment | Role play two evidence requests, one cooperative and one abandoned | Analyst escalates correctly on a file where nothing looks wrong |
| 5. Writing the decision up | Make the file survive QA and inspection | The three elements; plain language reasoning; record-keeping expectations under Article 25 | Rewrite two of the analyst's own past file notes to the three element standard | A reviewer who has not seen the file can follow the reasoning unaided |
| 6. Fairness and control design | Prevent discriminatory drift | Why nationality, ethnicity, name origin and document country are not risk indicators; how country risk is applied properly; reviewing your own decline pattern | Audit a sample of the team's declines for proxy drift | Team can explain every decline in the sample by a behavioural, structural or evidential reason |
How to assess whether the retraining worked
How often to retrain onboarding staff
What the next two years look like for identity verification
Key point: this is my practitioner view, not a forecast to build a budget on.
Verification is moving from documents towards infrastructure. Where a country has a national digital identity a firm can verify against, the document becomes a fallback rather than the primary evidence. The UAE is further along that road than most markets.
Two consequences I would prepare for. A gap will open between applicants who have an infrastructure identity and applicants who do not: non-residents, new arrivals, people from countries with no equivalent scheme. If your process quietly becomes harder for that group, you have built an exclusion problem while solving a fraud problem.
And the analyst's job moves further towards judgement and write-up. The checks get automated. Deciding what to do when checks disagree does not. That is the direction we describe in what AI is actually changing about AML work and in the AI competencies onboarding teams need. I do not know how fast this moves, and anyone giving you a date is guessing.
Where to build the capability: AML training on remote customer onboarding
We sell AML training, so here is our interest in this
I would rather state this plainly than bury it.
Pro AML Training sells applied AML and CFT training, including a course on remote customer onboarding. This article argues that onboarding teams need retraining, which is an argument for something we sell. Factor that in.
Two things to weigh against it. The retraining plan is published in full and ungated, so you can run it without buying anything from us. And no vendor or product is named or endorsed anywhere on this page, including in the sections where a product would be the obvious commercial recommendation. Judge the argument on the law quoted above, on whether the hierarchy matches your own process, and on what your QA reviewers keep sending back.
Frequently asked questions about synthetic identity fraud and AI generated documents
