Automated decisions under the EU AML Regulation: reading Article 76(5)

Our buyer's checklist for KYC/AML agents and our glossary summarise Article 76(5) of the EU AML Regulation briefly: the decisions it lists need meaningful human intervention. The provision says more than that. It sets three conditions, it sits inside the article on processing personal data, and Article 77 already requires much of the underlying record to be kept. This note reads the whole provision.

The AML Regulation, Regulation (EU) 2024/1624, applies from 10 July 2027. For football agents and for professional football clubs, in respect of certain transactions, it applies from 10 July 2029 (Article 90).

What the provision permits

Article 76(5) opens with a permission, not a ban. Obliged entities may adopt decisions resulting from:

• automated processes, including profiling as defined in the GDPR, Article 4(4);
• processes involving AI systems as defined in Article 3(1) of the AI Act.

They may do so provided that three conditions are met. Each is a separate test.

The provision sits in Article 76, "Processing of personal data". The paragraphs before it set the safeguards for special categories of data and criminal data, including that obliged entities do not take decisions that would lead to biased and discriminatory outcomes on the basis of those data (76(2)(c)). Paragraph 4 limits processing to the prevention of money laundering and terrorist financing and prohibits processing for commercial purposes. A decision system that processes personal data is subject to those rules too.

Condition (a): customer due diligence data only

> the data processed by such systems is limited to data obtained pursuant to Chapter III of this Regulation

Chapter III is customer due diligence. The data a decision system processes has to come from due diligence measures: identification and verification of the customer and beneficial owners, the purpose and intended nature of the relationship, checks against targeted financial sanctions, politically exposed person status, ongoing monitoring and the other measures in Article 20.

In practice, the record of each automated or AI-assisted step should show its inputs and the due diligence measure each input was obtained under. Data gathered for other purposes, such as marketing or product analytics, does not meet that test on our reading. Whether a particular source qualifies is a question for your legal advice.

Condition (b): meaningful human intervention for the listed decisions

> any decision to enter or refuse to enter into or maintain a business relationship with a customer or to carry out or refuse to carry out an occasional transaction for a customer, or to increase or decrease the extent of the customer due diligence measures applied pursuant to Article 20 of this Regulation, is subject to meaningful human intervention to ensure the accuracy and appropriateness of such a decision

Three kinds of decision are listed:

• Relationships: entering, refusing to enter or maintaining a business relationship.
• Occasional transactions: carrying one out or refusing to.
• The extent of due diligence: increasing or decreasing it.

The third is easy to overlook. Under Article 20(2), obliged entities set the extent of due diligence measures on the basis of an individual risk analysis. A risk score that moves a customer from standard to enhanced review, or back, changes the extent of due diligence. On the text, that decision needs meaningful human intervention as much as an onboarding approval does.

The Regulation uses the phrase "meaningful human intervention" once, here, and does not define it. It does state the purpose: to ensure the accuracy and appropriateness of the decision. An intervention that cannot change the outcome, or that is made without seeing what the system relied on, is hard to describe as meaningful for that purpose.

What we would expect a record to show, as a minimum:

• what the system produced and what it relied on;
• who reviewed it, and their authority to change the outcome;
• what they decided, and why, in their own words;
• how often reviewers depart from the system's output, over time.

The last point is about the process, not the case. If reviewers never change an output, that may mean the system is accurate. It may also mean the review is a formality. Only the record can tell the two apart. Our four-eyes review walkthrough shows what a review that can change the outcome looks like in practice.

Condition (c): an explanation the customer can challenge

> the customer may obtain an explanation of the decision reached by the obliged entity, and may challenge that decision, except in relation to a report as referred to in Article 69 of this Regulation

Article 69 is about reporting suspicions. The exception means an institution does not have to explain or open to challenge a decision insofar as it relates to a suspicion report. For every other covered decision, the customer may obtain an explanation and may challenge it.

That has a design consequence. The explanation of an onboarding or due diligence decision has to be producible on its own, without drawing on the assessment of whether to report a suspicion. If the two are kept in one undifferentiated case narrative, separating them under time pressure is risky. Keeping the decision rationale and the suspicion assessment as distinct records, each with its own access rules, makes condition (c) workable.

The records behind all three

Article 77 sets what obliged entities retain, including:

• a copy of the documents and information obtained in performing customer due diligence, including through electronic identification means (77(1)(a));
• a record of the assessment under Article 69(2), including the information and circumstances considered and the results, whether or not it leads to a suspicious transaction report (77(1)(b));
• the supporting evidence and records of transactions needed to identify them (77(1)(c)).

These records must not be redacted. An obliged entity may keep references instead of copies, provided it can supply the information to competent authorities immediately and the information cannot be modified or altered (77(2)). The retention period is five years from the end of the business relationship, the occasional transaction or the refusal, after which personal data is deleted unless other law requires it to be kept. Competent authorities may, case by case, require the records to be kept for a further period of up to five years (77(3)).

A hash-chained record can make a later change to the references detectable, as long as the reference values are kept out of reach of whoever writes the record. Detection is not prevention: Article 77(2) requires that the information cannot be modified or altered. It does not show that the underlying information was right. Our glossary sets out what hashing does and does not establish.

Information-sharing partnerships

Article 75 allows partnerships for information sharing between obliged entities, under conditions. One of them, Article 75(4)(g), applies the same idea to shared outputs: information generated through artificial intelligence, machine learning or algorithms may only be shared where those processes were subject to adequate human oversight.

How it relates to the AI Act and the GDPR

Article 76(5) borrows its definitions. "AI system" comes from Article 3(1) of the AI Act, and "profiling" from Article 4(4) of the GDPR. The obligations stay separate.

Under the AI Act, a system is high-risk if its use is listed in Annex III, among other routes. Annex III does not list anti-money laundering checks as such, so for many AML systems Article 76(5) is the more specific rule on how decisions are made. If the same system also evaluates the creditworthiness of natural persons, that use is listed in Annex III. Our page on EU AI Act documentation covers classification and dates.

The GDPR continues to apply. Article 22 gives people the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them, with exceptions. How Article 22 and Article 76(5) interact for a particular decision is a question for your data protection advice.

How cmpliance approaches this

cmpliance is built on the same division of labour: agents prepare the evidence for review, and officers decide. cmpliance is assembling this operating model around current components for source records and source-linked facts, screening context and dispositions, evidence-quality checks, contradictions, RFIs and reviewer-state controls, with maker, checker and escalation roles and the rationale attached to state changes. The claim here is the operating model and its verified components, not a fully connected production sequence from acquisition to evidence pack. We do not use Customer Data to train public or foundation AI models.

Agents do the work. Humans make the call.

Talk to cmpliance