Talk to usTry the demo

Banking: Remote Customer Onboarding Under the EBA Guidelines (EBA/GL/2022/15)

Regulation and standards

For: Compliance officer, AML officer or product owner at a bank or financial institution in the EU that onboards customers remotely, or at a provider that serves one

A reading guide to the European Banking Authority guidelines on remote customer onboarding: policies, pre-implementation assessment, liveness, outsourcing and what the new AML rules change.

For information; not legal advice.

If a bank or other credit or financial institution in the European Union opens accounts without meeting the customer, the supervisor will read the file against one document more than any other: the European Banking Authority's guidelines on the use of remote customer onboarding solutions. This guide reads that text section by section. It is written for the person who has to turn the guidelines into a policy, a vendor questionnaire or an audit file, and it keeps to what the text says. Where a sentence is an inference, it says so. In this article the Authority means the European Banking Authority, and AMLA means the Authority for Anti-Money Laundering and Countering the Financing of Terrorism.

The EU Anti-Money Laundering Regulation and its rules on electronic identification are covered in the article on the EU AML Regulation and remote customer identification. This article is about the guidelines that sit beside the law today, and about how they relate to the law that comes next.

What the guidelines are, and what they are not

The full title is Guidelines on the use of Remote Customer Onboarding Solutions under Article 13(1) of Directive (EU) 2015/849, reference EBA/GL/2022/15, dated 22 November 2022. They are guidelines, not a law, and they were issued under Article 16 of Regulation (EU) No 1093/2010. Under that article competent authorities and financial institutions must make every effort to comply with them. Competent authorities were asked to tell the Authority by 30 May 2023 whether they comply or intend to comply. The guidelines apply from 2 October 2023.

Three features of the text shape how to read it.

It is technology neutral. The rationale says the guidelines do not favour specific technological solutions and respect the principle of technological neutrality. The consequence for a buyer is that no section names a product class as approved, and none tells you which vendor to choose.

It is about the institution's process, not the vendor's product. The scope is the steps that credit and financial institutions should take when adopting or reviewing solutions to comply with Article 13(1), points (a), (b) and (c) of the Directive, which are identification, beneficial owner identification and the purpose of the relationship. The Authority said in the consultation feedback that the ultimate responsibility lies with the credit or financial institution and cannot be transferred to a third party.

It covers initial due diligence. In answering the Banking Stakeholder Group, the Authority clarified that the guidelines apply when institutions onboard new customers, so remote due diligence for existing customers who buy a new product is outside their scope, although many provisions are relevant there too. Its scope also stops at the institutions the Authority supervises: respondents asked for crypto-asset service providers to be included, and the Authority replied that its founding regulation did not currently allow that.

Why the guidelines exist

The European Commission published its Digital Finance Strategy in September 2020 and asked the Authority to write guidelines on four points: the types of innovative technology acceptable for remote onboarding, the conditions for using them, the acceptable forms of digital documentation, and the conditions for relying on third parties. The Commission's view was that the due diligence rules in Directive (EU) 2015/849 do not give enough clarity on what is allowed in a remote and digital context. The Authority confirmed that supervisory expectations and what institutions do to comply differ across Member States, and called that divergence an obstacle to innovation and to cross-border services.

The Authority consulted publicly between 10 December 2021 and 10 March 2022 and received 58 responses, 43 of them non-anonymous and published.

Section 4.1: policies, governance and the life of the solution

The first block is the one that distinguishes the guidelines from a technical standard. It does not ask how a face is matched. It asks what the institution has written down, who approved it and how it will notice when the solution stops working.

The policy

Paragraph 9 requires risk-sensitive policies and procedures. They must set out at least five things: a general description of the solution and how it collects, verifies and records information; the situations where it can be used, including the categories of customers, products and services eligible for remote onboarding; which steps are fully automated and which need human intervention; the controls that make sure the first transaction happens only after all initial due diligence measures have been applied; and an induction and regular training programme for staff.

Two of those lines are worth underlining for a product team. The line on eligible customers, products and services means the institution has to decide in advance where remote onboarding is acceptable, and the Authority amended the text so that these categories are identified in line with the institution's business-wide risk assessment. The line on the first transaction is a gate in the process: the account can exist, but value should not move before the checks are complete.

Who owns it

The management body approves the policies and procedures and oversees their correct implementation, as paragraph 12 puts it. The AML/CFT compliance officer makes sure they are implemented effectively, reviewed regularly and amended where necessary, according to paragraph 11. This is a point for the audit file: a vendor can show screenshots, but only the institution can show who approved the policy.

The pre-implementation assessment

Before adopting a new solution, paragraphs 13 and 14 expect a pre-implementation assessment with a scope, steps and record keeping set out in the policy. At least the following should be in it.

  • An assessment of whether the solution collects complete and accurate data and documents, and whether the sources of information it uses are reliable and independent.
  • An assessment of the effect on the institution's business-wide risks, including money laundering and terrorist financing risk, operational, reputational and legal risks.
  • Mitigating measures and remedial actions for each risk identified.
  • Tests for fraud risks, including impersonation fraud and other ICT and security risks.
  • End-to-end testing of the solution for the customers, products and services named in the policy.

Paragraph 15 gives a shortcut. The institution should consider the first, fourth and fifth items met where the solution uses an electronic identification scheme notified under Article 9 of Regulation (EU) No 910/2014 at assurance level substantial or high, or a relevant qualified trust service. The shortcut is narrow: it does not cover the second and third items, which are about the institution's own risks. The Authority's impact assessment explains why. It considered exempting electronic identification solutions from the governance provisions and rejected that, because using a digital identity under the eIDAS framework does not mean by itself that there are no associated risks to the institution and to the customer. The option it chose lets the institution take into account the assessment already performed by the national competent authority, while the ultimate responsibility for the underlying verification stays with the institution.

Paragraphs 16 and 17 add two duties. The institution should be able to show its competent authority which assessments it carried out and how the use of the solution is appropriate for the risks of its customers, services, geographies and products. It should start using the solution only when it is satisfied that it can be integrated into the wider internal control system.

Ongoing monitoring and remediation

Paragraph 18 requires the policy to describe how the institution stays satisfied of the ongoing quality, completeness, accuracy and adequacy of the data collected, how often it reviews the solution, and what triggers an extra review. The triggers named are changes to the institution's ML/TF risk exposure, deficiencies detected in monitoring, audit or supervisory work, a perceived increase in fraud attempts, and changes to the legal or regulatory framework.

Paragraph 19 deals with the case where something has gone wrong. The procedures should include a review of all affected business relationships, with priority for the highest-risk ones. After that review, the institution should decide whether each relationship needs additional due diligence, limits such as transaction volume where national law permits, termination, a report to the financial intelligence unit, or reclassification into another risk category.

Paragraph 20 lists means of monitoring the solution: quality assurance testing, automated critical alerts and notifications, regular automated quality reports, sample testing and manual reviews. Paragraph 21 says the section applies also to fully automated solutions that depend on algorithms with little or no human intervention. For a vendor, that is a reason to expose measurable output: counts, rejection reasons, review queues.

Section 4.2: acquiring the information

Paragraph 24 sets three conditions. The information obtained must be up to date and adequate for initial due diligence. Images, video, sound and data must be captured in a readable format and with enough quality that the customer is unambiguously recognisable. The identification process must not continue if technical shortcomings or unexpected connection interruptions are detected. The last point is a concrete design requirement: when a connection drops or a technical fault appears, the process must stop and not carry on as if nothing had happened. The text says that the process does not continue; it does not say what happens next. Whether the journey is discarded, resumed from a saved point or restarted from the beginning is a design choice of the institution. The guidelines cover restart and redirection further below, for evidence of insufficient quality, which is a different trigger. A stricter policy, such as discarding any interrupted session and starting again, is one defensible choice, and it is the institution's own rule and not a requirement of the guidelines.

Paragraph 26 covers records. Documents and information collected remotely that must be retained under Article 40(1), point (a) of the Directive should be time-stamped and stored securely, and the content, including images, videos, sound and data, should stay readable so that later verification is possible.

Paragraphs 27 and 28 ask the institution to define which information the customer types in, which is captured automatically from the documentation, and which comes from other sources, and to have mechanisms to make sure the automatically captured information is reliable. The controls should address, among others, the obfuscation of the location of the customer's device, spoofed IP addresses and services such as VPNs.

For legal entities, paragraphs 29 to 31 ask the institution to define which categories of legal entity it will onboard remotely, taking into account the money laundering risk of each category and the level of human intervention needed. The solution must have features to collect the data to identify the legal person, the data to verify that the natural person acting for it is entitled to act, and the information on the beneficial owners. The article on business verification and company registers explains what those registers do and do not show.

Paragraph 32 puts a timing rule on the purpose and intended nature of the relationship: the relevant actions should be complete before the remote onboarding process ends.

Section 4.3: is the document real

This is the part of the guidelines closest to a document check, and it is worded as a set of questions to answer about a reproduction of an original document. Paragraph 33 applies where the institution accepts a reproduction and does not examine the original. It should establish at least five things.

  • Whether the reproduction includes the security features of the original and whether the specifications of the document, such as type, size of characters and structure, are valid, by comparing them with official databases such as PRADO.
  • Whether the personal data has been altered or tampered with, and whether the picture embedded in the document was replaced.
  • Whether the algorithm used to generate the unique identification number of the document holds, where the document has a machine-readable zone.
  • Whether the quality and definition are sufficient to make the relevant information unambiguous.
  • Whether the reproduction has been displayed on a screen from a photograph or scan of the original.

Paragraph 34 adds that where optical character recognition or machine-readable zone verification is used, the institution should take the steps needed to make sure the tools capture information accurately and consistently. Paragraph 36 says that, where available, the security features embedded in the document, such as holograms, should be verified as proof of authenticity.

Paragraph 35 deals with chips. Where the device allows collecting data held in the chip of a national identity card and it is technically feasible, the institution should consider using it to check consistency with the information from other sources. The consultation feedback shows how this was softened: the Authority amended the text to clarify that using chip data is not mandatory. The word is consider, not require, and the article on how NFC chip verification works describes what a chip read can and cannot prove.

Paragraph 37 is the financial inclusion clause. The policy should say how documentation requests will be adjusted for financial inclusion, and where weaker or non-traditional documentation is accepted, the institution should add controls or increased human intervention to understand the risk of the relationship.

Section 4.4: is it the same person

The minimum

Paragraph 38 sets the minimum that the solution must allow as part of verification: a match between the visible information of the natural person and the documentation provided; for a legal entity, that it is publicly registered where applicable; and that the person who represents it is entitled to act.

Biometric matching

Paragraph 39 applies where biometric data is used. The institution should make sure the data is sufficiently unique to be unequivocally linked to a single natural person and should use strong and reliable algorithms to verify the match between the biometric data on the submitted identity document and the customer. Where the solution does not provide the required level of confidence, additional controls should be applied. Paragraph 40 adds that where evidence is of insufficient quality and creates ambiguity, the process should be interrupted and restarted, or redirected to a face-to-face verification. The text does not set a numeric threshold, and the Authority said in the consultation feedback that the technical details of using biometric data are outside the scope of the guidelines. How a score is read is a separate question, covered in the article on reading a face recognition evaluation.

Unattended and attended solutions

The guidelines split solutions by whether an employee is present.

Paragraph 41 covers unattended solutions, where the customer does not interact with an employee. The institution should make sure that photographs or video are taken in adequate lighting and with the required clarity, that they are taken at the time the customer performs the verification, that liveness detection is performed, and that strong and reliable algorithms match the photograph or video with the picture retrieved from the official document. The text describes liveness detection in two ways: procedures where a specific action from the customer is required to show presence in the session, or procedures based on analysis of the received data that need no specific action.

The impact assessment records how this requirement was reached. The Authority weighed three options: no mandatory liveness detection, mandatory liveness detection for all unattended situations, and mandatory liveness detection in all cases. It rejected the last as disproportionate, because liveness detection may be costly and is not by itself the only key safeguard, and it chose the middle option. The consultation draft had tied liveness to increased risk; the Authority agreed with respondents that this left room for different interpretations and changed the text so that liveness detection is included in all unattended situations irrespective of the level of ML/TF risk.

Paragraph 42 covers attended solutions, where the customer interacts with an employee. Image and audio quality must allow proper verification. The employee must have sufficient knowledge of the AML/CFT rules and of the security aspects of remote verification, and be trained to anticipate and prevent deception techniques and to react when they occur. The institution should develop an interview guide that defines the steps and the employee's actions, including guidance on observing psychological factors or other features that might characterise suspicious behaviour.

Randomness and extra controls

Paragraph 43 asks, where possible, for randomness in the sequence of actions the customer performs, to guard against synthetic identities or coercion, and for random assignment of the responsible employee to avoid collusion between customer and employee. Paragraph 44 adds optional controls that the institution should use one or more of where commensurate with the risk. They include a first payment from an account in the customer's name at a regulated institution in the European Economic Area or in a third country with comparable requirements, a single-use and time-limited passcode sent to the customer, biometric data compared with other independent and reliable sources, telephone contact and direct mailing.

The later sections: vendors, security and national schemes

Reliance and outsourcing

Paragraph 46 requires the policy to say which functions the institution performs, which a third party performs and which an outsourced service provider performs. Paragraph 47 covers reliance on third parties: the institution should be satisfied that the third party's remote onboarding process and the data it collects are sufficient and consistent with the guidelines, and should ensure continuity of the customer relationship in case of shortcomings.

Paragraph 48 covers outsourcing. Before and during the relationship, the institution should ensure that the provider implements the institution's policies, through regular reporting, ongoing monitoring, on-site visits or sample testing; assess that the provider is equipped for the task, including staff training, technology fitness and data governance; and make sure the provider tells the institution about proposed changes to the process or modifications to the solution.

Paragraph 49 applies where the provider stores customer data such as photographs, videos and documents. Only necessary data should be collected and kept for a clearly defined retention period, access should be strictly limited and registered, and appropriate security measures should protect the data. For a vendor this is a short list of audit questions: retention period, access log, storage protection. The article on retention and erasure of identity data goes into the second of these in practice.

ICT and security

Paragraph 51 expects secure communication channels, secure protocols and cryptographic algorithms in line with industry practice. Paragraph 52 asks for a secure access point to start the process based on qualified certificates for electronic seals or for website authentication, and for the customer to be told which security measures to take. Paragraph 53 asks for a secure environment for the execution of software code on the customer's device where a multi-purpose device is used.

National schemes

Paragraph 54 lets institutions use trust services and electronic identification processes regulated, recognised, approved or accepted by national authorities under Article 13(1), point (a) of the Directive. The institution should assess how far such a solution complies with the guidelines and mitigate remaining risks, in particular the risk in authentication and impersonation fraud, the risk that the customer's identity is not the claimed identity, and the risk of lost, stolen, suspended, revoked or expired identity evidence.

How this relates to standards

During the consultation, respondents asked the Authority to align the draft with ETSI TS 119 461, the technical specification on identity proofing for trust services. The Authority described that specification as a relevant set of standards and agreed to align the guidelines with it where possible. The ETSI identity proofing article reads version 2.1.1 of that specification. The specification defines liveness detection as a subset of presentation attack detection, which is the vocabulary used in the article on presentation attack detection testing.

What changes with the AML Regulation

The guidelines were written against Directive (EU) 2015/849. Regulation (EU) 2024/1624 applies from 10 July 2027, and Article 89 says that references to the 2015 Directive are to be construed as references to the Regulation and to Directive (EU) 2024/1640, read with the correlation table. Whether and how the Authority or AMLA will update or replace the guidelines is not settled by anything in the texts read for this article, and a reader should ask the supervisor instead of inferring it.

Three developments bear on remote onboarding.

Electronic identification is written into the Regulation. Article 22(6) lets obliged entities verify identity by an identity document or by electronic identification means that meet the requirements of Regulation (EU) No 910/2014 at assurance level substantial or high, and relevant qualified trust services. The recitals say that electronic identification should be taken into account and accepted for the identification process and that, with appropriate mitigation, it can reduce the risk level to standard or even low.

Technical standards fill in the detail. Article 28(1) required AMLA to develop draft regulatory technical standards by 10 July 2026, covering, among others, the information to be collected, the reliable and independent sources for verification, and the list of attributes that electronic identification means and qualified trust services must feature. AMLA published a factsheet on the draft standards. It says that the draft still has to be reviewed by the European Commission and becomes definitive only on publication in the Official Journal. According to the factsheet, the draft allows alternative verification solutions where an identity document cannot be submitted in a face-to-face context and the person cannot use electronic identification, provided they use reliable and independent sources and include the safeguards listed in Article 7 of the draft. It also describes a reduced set of identification data for low-risk situations. The factsheet is a summary and says the draft standards take precedence over it, so the draft text itself should be read before relying on any detail.

Reliance gets its own guidelines. Article 50 requires AMLA to issue, by 10 July 2027, guidelines on the conditions for relying on information collected by another obliged entity, including in remote due diligence. That is the topic of paragraphs 46 to 48 of the Authority's guidelines today.

Questions to take to a vendor and to your own file

  • Where in the policy is the list of customers, products and services eligible for remote onboarding, and who approved it?
  • What did the pre-implementation assessment record for each of the five items in paragraph 14, and where are the test results?
  • Which steps are automated and which need a person, and what is the escalation path when a person is needed?
  • What does the solution do when the connection drops or the evidence is of poor quality?
  • Which of the document questions in paragraph 33 does the document step answer, and which stay with the institution?
  • How is the liveness step described in the policy, and is that consistent with a requirement for all unattended journeys?
  • What is reported back to the institution so that monitoring under paragraph 20 is possible?
  • What does the provider store, for how long, who can access it, and how is that recorded?
  • If the institution uses a national or eIDAS-based scheme, which risks in paragraph 54 are still addressed by the institution itself?

Where this sits in a verification flow

A verification flow built on NeuroVision KYC places the identity steps in one session: document, selfie, liveness and face match, with the scenario assembled in an editor. The document step detects, classifies and reads IDs, including printed and handwritten text and the machine readable zone with its checksum. Document anti-fraud checks, covering screen photos, photocopies, printouts, glued photos, drawn-on elements, erasures, edited images and logical data errors, are included in every package. The face match step compares the selfie with the portrait on the document in a one-to-one comparison, and includes foreign-face detection and an age check against the date of birth. The liveness step is active: the person moves the face closer through two ovals. This article does not state that any product meets the guidelines. The institution carries that assessment, as the guidelines themselves make clear.

To see how these steps look in your own scenario, contact the team.

Sources

All sources were fetched on 27 October 2026.

Ready to talk?

Tell us what you are building and we will help you plan the integration.

Talk to us