EBA remote customer onboarding guidelines — the pre-implementation assessment and the liveness rule

The EBA’s remote onboarding guidelines make the assessment you do before switching a solution on into a supervisory deliverable — and they give you one shortcut that removes most of it. Guidelines EBA/GL/2022/15, applicable from 2 October 2023, set out what credit and financial institutions should do when a customer is onboarded without ever appearing in person. They cover policies, a pre-implementation assessment, ongoing monitoring, document authenticity, identity matching, and the difference between relying on a third party and outsourcing. This walks through the parts that change a build.

1. What the guidelines are, and who they bind

The instrument is the EBA’s Guidelines on the use of remote customer onboarding solutions, reference EBA/GL/2022/15, which apply from 2 October 2023. They attach to the customer due diligence obligations in Article 13(1)(a) and (c) of Directive (EU) 2015/849 — identifying the customer and verifying identity, and identifying beneficial owners — in situations where onboarding happens remotely.

They apply to credit and financial institutions within the scope of the anti-money-laundering directive, which for the payments sector means payment institutions and e-money institutions as much as banks. They are technology-neutral by design: the guidelines do not endorse a method, they set out what any method has to be able to demonstrate.

Two structural features are worth noting before the detail. The guidelines are written around demonstrability — several provisions require the institution to be able to show its competent authority what it assessed and what it did about the outcome. And they apply in full to fully automated solutions: the guidelines state expressly that the monitoring section applies where solutions are highly dependent on automated algorithms, with little or no human intervention.

2. What the policy has to say

The policies and procedures must be risk-sensitive and set out at least five things, and the list is unusually operational for a policy requirement:

• a general description of the solution used to collect, verify and record information throughout the process, including an explanation of its features and functioning;
• the situations in which the solution can be used, taking account of the risk factors identified under Article 8(1) of the directive and in the business-wide risk assessment — including a description of the categories of customers, products and services eligible for remote onboarding;
• which steps are fully automated and which require human intervention;
• the controls ensuring that the first transaction with a newly onboarded customer is executed only once all initial CDD measures have been applied; and
• a description of induction and regular training so staff understand how the solution works, the risks, and the mitigating procedures.

The fourth item is the one that reaches into the payments platform rather than the compliance manual. It is a sequencing control between onboarding completion and transaction capability, and it has to exist as a control, not as an expectation about how the flow behaves.

On governance, the AML/CFT compliance officer should ensure the remote onboarding policies are implemented effectively, reviewed regularly and amended where necessary — and the management body should approve them and oversee their correct implementation.

3. The pre-implementation assessment

Before adopting a new solution, institutions should carry out a pre-implementation assessment, and should set out its scope, steps and record-keeping requirements in their policies. It should include at least:

• an assessment of the adequacy of the solution as to the completeness and accuracy of the data and documents collected, and the reliability and independence of the sources it uses;
• an assessment of the impact on business-wide risks, including ML/TF, operational, reputational and legal risk;
• identification of mitigating measures and remedial actions for each risk identified;
• tests to assess fraud risks, including impersonation fraud, and other ICT and security risks, by reference to the EBA guidelines on ICT and security risk management (EBA/GL/2019/04); and
• end-to-end testing of the solution targeting the customers, products and services identified in the policies.

Institutions should be able to demonstrate to their competent authority which assessments they carried out, the outcome, and how the use of the solution is appropriate in light of the ML/TF risks identified for the customers, services, geographies and products in scope. And they should start using a solution only once satisfied that it can be integrated into the institution’s wider internal control system.

4. Ongoing monitoring, and what a failure obliges you to do

Monitoring is continuous, and the policy must describe the steps taken to be satisfied of the ongoing quality, completeness, accuracy and adequacy of the data collected, the scope and frequency of regular reviews, and the circumstances triggering ad hoc reviews. Four triggers are named as a minimum: changes to the institution’s ML/TF risk exposure; deficiencies in the solution’s functioning detected through monitoring, audit or supervisory activity; a perceived increase in fraud attempts; and changes to the legal or regulatory framework.

The remedial provision is the one with the largest operational tail. Where a risk has materialised, or errors are identified that affect the effectiveness of the solution, the institution should review all affected business relationships to assess whether sufficient initial CDD was applied — prioritising the highest ML/TF risk relationships — and then decide, for each, whether it should be subject to additional due diligence, subject to limitations such as transaction volume limits where national law permits, terminated, reported to the FIU, or reclassified into a different risk category.

Suggested monitoring means include quality assurance testing, automated critical alerts and notifications, regular automated quality reports, sample testing and manual reviews. Institutions should be able to demonstrate which reviews they carried out and what remedial steps they took across the lifetime of the solution.

Facts: six months after launch, an institution finds that a document-reading step silently failed for a subset of onboardings, so identity data was recorded from a low-quality image without the expected checks. Roughly 4,000 customers are affected and most are low risk.

What the rule says: the finding is a detected deficiency, which is itself an ad hoc review trigger. The remedial obligation is a review of all affected relationships against Article 13(1)(a), (b) and (c), highest risk first, with a documented decision per relationship from the listed options — up to termination and FIU reporting.

What the practitioner does: scopes the affected population from system logs rather than by sampling, runs the review in risk order, and records the per-relationship outcome. Concluding “low risk, no action” is available, but it has to be a recorded decision for each relationship rather than a blanket judgement about the cohort.

5. Documents, and the screen-replay test

On document authenticity and integrity, the guidelines require institutions to satisfy themselves that a reproduction of an identity document is of sufficient quality and definition to make relevant information unambiguous, and — the provision that most directly rules out a category of attack — that the reproduction has not been displayed on a screen based on a photograph or scan of the original document.

Where features automatically read information from documents, such as optical character recognition or machine-readable-zone verification, institutions should take the steps necessary to ensure those tools work reliably.

For unattended solutions, where the customer does not interact with an employee during verification, four requirements apply: any photograph or video must be taken under adequate lighting conditions with the required properties captured clearly enough to verify identity; it must be taken at the time the customer is performing the verification; the institution must perform liveness detection, which may require a specific action from the customer or may be based on analysis of the received data without any customer action; and strong and reliable algorithms must be used to check that the photograph or video matches the picture from the customer’s official document.

The liveness requirement is where the guidelines are least willing to be flexible. The stated purpose is the ability to verify whether the video, picture or other biometric data belongs to a living person at the moment of capture; where an institution does not use live videoconference, it can meet this through active or passive liveness detection — but not by omitting it.

Facts: an institution’s flow asks the customer to upload a photograph of their passport and a separate selfie, and its provider performs a face-match between the two. There is no liveness step, on the reasoning that the face-match algorithm is strong.

What the rule says: the match requirement and the liveness requirement are separate limbs. Strong and reliable matching algorithms address whether the face corresponds to the document; liveness addresses whether the captured image belongs to a living person present at the moment of capture. The guidelines also require the image to be taken at the time the customer is performing the verification, which an uploaded file does not evidence.

What the practitioner does: moves capture in-session rather than accepting uploads, and adds passive liveness if the product cannot tolerate an active challenge. A face-match on two supplied files satisfies neither the timing nor the liveness limb, however accurate it is.

6. Reliance on a third party is not outsourcing

The guidelines keep two arrangements apart, and the distinction decides who carries what. Reliance on third parties operates under the AML directive’s own regime for that purpose. Outsourcing of CDD is a delegation of execution in which the institution retains responsibility.

Where CDD is outsourced, the guidelines require that the institution be informed of any proposed changes to the remote onboarding process or any modification made to the solution by the provider — a notification right that has to be in the contract, because it will not be volunteered. And where the provider stores customer data, including photographs, videos and documents, the institution should ensure that only necessary data is collected and stored, in line with a clearly defined retention period.

For a Luxembourg institution the outsourcing route also engages the national outsourcing circular, including its notification lead time — see our note on outsourcing under Circular CSSF 22/806. The guidelines also require ICT and security risk management to be applied to the solution itself.

7. FAQ

8. What to do, today

• Find the pre-implementation assessment for your current solution. If it was adopted before October 2023 and never assessed against these criteria, that gap is the first thing an examiner will look for.
• Check the first-transaction control exists in the platform, not just in the policy — a sequencing gate between CDD completion and transaction capability.
• Write down which steps are automated and which are human. The guidelines require it explicitly and it is usually undocumented.
• Test the screen-replay case: can your flow accept a photograph of an identity document displayed on a screen? If yes, that is a named defect.
• Pre-agree the remediation playbook — population scoping from logs, risk-ordered review, per-relationship decision options. Designing it during an incident is how the review ends up sampled rather than complete.
• Put the change-notification right in the provider contract, along with a defined retention period for photographs, videos and documents.

Related: Outsourcing under Circular CSSF 22/806 · The DNB SIRA integrity risk analysis · The AML representative across the EU · The EU Digital Identity Wallet · The EU AML package — AMLR, AMLD6 and AMLA