The New Compliance Stack: Humans, AI + Automation and Audit trails

There is a mental model that has served compliance teams well for a long time, and it is becoming less adequate with each passing year. The model is simple: compliance is something humans do, supported by systems that help them do it faster. The human is the centre. The technology is the support.

That model is not wrong, exactly. But it misses something important about how modern compliance actually works and, crucially, how the regulatory framework expects it to work. The human is not the centre of a compliance programme in the way they once were. They are one of three active, interdependent components. And the compliance programme is only as strong as the weakest of the three.

The three components of the modern compliance stack are humans, AI and automation. Each has a distinct role. Each is governed by a distinct set of legal requirements. And each depends on the other two in ways that are not always obvious until something breaks.

This article is a thorough breakdown of each component, what it does, what the law requires of it, and how the three work together as a system. It is written for the compliance officer, MLRO, and operations lead who need to understand this architecture clearly, both to build it correctly and to explain it to a management body or banking partner who wants to know how the compliance programme actually functions.

Why "Stack" Is the Right Mental Model

The word "stack" comes from technology. A technology stack is the collection of components that work together to deliver a product: a data layer, a processing layer, a presentation layer. Each layer depends on the others. The database does not know what the user interface looks like. The user interface does not care how the database stores information. But remove either one and the whole system stops working.

The compliance stack works the same way. Audit trails are the data layer. They capture, structure, and preserve the evidence that everything else depends on. AI and automation are the processing layer. They retrieve, analyse, and flag information at a scale and speed that human teams alone cannot match. Humans are the judgment layer. They interpret what the other layers produce and make the decisions that have legal and personal accountability attached.

The reason this framing matters is that it changes how compliance teams think about investment and failure. A gap in the AI layer does not just produce missed alerts. It puts the human layer under impossible strain, because the volume of work that should have been filtered and prioritised arrives unfiltered. A gap in the audit trail layer does not just produce documentation problems. It undermines the human's ability to demonstrate that a decision was made correctly, and the AI system's outputs cannot be retrospectively verified. And a gap in the human layer does not just produce accountability problems. It produces legal violations under frameworks that specifically require human involvement at certain decision points.

Understanding the three layers individually and together is what separates a compliance programme that holds up under scrutiny from one that only appears to.

Layer 1: The Human Role in the Compliance Stack

The human layer in the compliance stack is not simply the layer that does what the machines cannot. It is the layer that carries legal accountability, exercises contextual judgment, and governs the behaviour of the other two layers. All three of those functions are legally mandated, and the first two cannot be delegated to any system.

The Personal Accountability Structure Under the AMLR

The Anti-Money Laundering Regulation (AMLR, Regulation (EU) 2024/1624) is explicit about the human accountability structure it requires. Every obliged entity must appoint a compliance officer with sufficiently high hierarchical standing, who bears personal responsibility for the day-to-day operation of the AML/CFT programme, and who is specifically responsible for reporting suspicious transactions to the Financial Intelligence Unit. One member of the management body must hold designated responsibility for ensuring the entity's compliance with the AMLR. The compliance officer must submit an annual report to the management body on the implementation of internal policies, procedures, and controls.

This governance architecture places named, identifiable human beings at the accountability points of the compliance programme. That is not an accident or a formality. It is a deliberate regulatory design choice, rooted in the understanding that systems can detect suspicious patterns but cannot make the judgment that a pattern constitutes a suspicion, cannot weigh the specific context of a client relationship against a set of facts, and cannot bear the legal and professional consequences of a wrong decision. A compliance officer who delegates those judgments to an automated system is not meeting the AMLR's requirements. They are creating an accountability void where the law requires accountability to exist.

What the EU AI Act Requires From Human Oversight

The EU AI Act (Regulation (EU) 2024/1689) adds a second, parallel framework for human oversight that applies specifically when AI systems are used in compliance contexts. Under Article 26 of the Act, deployers of high-risk AI systems, which includes AI used in AML risk profiling, fraud detection, and automated decisions affecting access to financial services, must assign human oversight to natural persons who have the necessary competence, training, and authority, as well as the necessary support.

What the Act says about what human oversight must actually mean is worth quoting precisely. High-risk AI systems must be designed so that natural persons to whom oversight is assigned are enabled to fully understand the capacities and limitations of the system, to be aware of automation bias, to correctly interpret the output, and to intervene or override the system at any time. A human reviewer who receives the output of an AI-powered screening alert without the information or authority to override it is not providing human oversight as the AI Act defines it. They are providing the appearance of oversight.

This has a direct practical implication for compliance teams that use AI-powered transaction monitoring, risk scoring, or screening tools. The people reviewing the output of those tools need to understand what the tools are doing, not just what they are producing. They need to know the logic behind a risk score well enough to question it. And they need the authority to act differently from what the AI recommended, with that decision documented.

The Management Body's Governance Role

Under DORA (Regulation (EU) 2022/2554), which has applied to payment institutions and EMIs since 17 January 2025, the management body holds a specific governance role in the compliance stack: it must define, approve, and oversee the ICT risk management framework. This means the board or equivalent governing body is not merely a recipient of compliance reports. It is an active participant in the governance of the technology that powers the compliance function.

For compliance teams, this means the human layer extends upward beyond the compliance officer and the MLRO to the management body itself. A compliance stack whose governance does not reach board level is not a compliant stack under DORA, regardless of how sophisticated the AI layer is or how complete the audit trail layer is.

The Judgment That Humans Contribute That AI Cannot

Beyond the specific legal obligations, there is a genuine capability difference that explains why human judgment is irreplaceable at certain points in the compliance process and not merely legally required.

Humans bring contextual knowledge that goes beyond the data in any single system. A compliance officer who knows that a client's ownership structure recently changed because the founder sold their stake, and who reviews a transaction monitoring alert in light of that recent context, is doing something no algorithm can replicate unless all of that context has been fed into the system and the model has been trained to weight it correctly. Experienced compliance professionals also bring pattern recognition across relationships and across time in a way that is not expressible as a rule. They know when something feels wrong even when the data is clean. They know how to read the space between the facts.

That judgment is not a substitute for structured process and automation. It is the thing that structured process and automation exist to make possible by removing the noise so the signal can be heard.

Layer 2: AI and Automation in the Compliance Stack

The AI and automation layer in the compliance stack exists to handle the volume, speed, and data intensity of compliance processes that human teams cannot manage at scale. Understanding precisely what it does, what the regulatory framework requires of it, and where the risk of poor governance concentrates is as important as understanding what it can achieve.

What AI and Automation Do Well in the Compliance Stack

Automated data retrieval and structuring is the function with the highest return and the lowest regulatory risk. Connecting directly to company registries, retrieving structured beneficial ownership data, matching names against sanctions lists, and capturing every query with a timestamp is almost entirely mechanical. There is no judgment involved. The output is more reliable than manual data collection, the process is faster, and the audit trail is cleaner.

Automated screening at volume is the function that scale makes practically mandatory. The EU Instant Payments Regulation (Regulation (EU) 2024/886) requires PSPs to screen their customer base against the EU consolidated sanctions list at minimum daily. At any meaningful customer base size, that daily cycle cannot be run manually. The requirement exists precisely because the EU legislator understood that sanctions screening at the speed and volume that modern payment services require can only be done by a system.

Transaction monitoring alert generation is the function that transforms a volume of transaction data too large for any human team into a prioritised, manageable queue of cases for human investigation. The rules or models that generate those alerts do not make compliance decisions. They produce the evidence set that the compliance analyst needs to make one.

And automated audit trail capture, discussed in detail in the next section, is the function that transforms the human layer's decisions from a narrative that needs to be reconstructed into a structured record that already exists.

What the EBA's Data Shows About AI Governance Failure

The EBA's July 2025 Opinion on ML/TF risks found that more than half of all serious compliance failures reported to the EuReCA database involved the improper use of RegTech tools, and that 277 material weaknesses were linked to RegTech technologies, systems, and tools across financial institutions in 2023 and 2024. The most common causes were tools deployed without adequate governance, rules not updated as the business evolved, and institutions lacking the in-house expertise to assess whether their tools were functioning as intended.

This finding sits at the heart of understanding the AI layer's role in the compliance stack. The problem is not that AI and automation tools produce unreliable outputs by design. It is that they produce unreliable outputs when they are poorly governed, when their rules do not reflect the institution's current risk profile, or when the humans reviewing their outputs do not understand what the tools are doing well enough to catch the gaps. The AI layer is only as reliable as the governance it operates under, and that governance is a human responsibility.

What the EU AI Act Requires Deployers to Govern

For compliance teams using AI-powered tools in AML risk profiling, fraud detection, or other contexts that fall within the EU AI Act's high-risk AI category, the Act creates specific governance obligations that supplement the AML and GDPR frameworks. Under Article 26, deployers must implement appropriate technical and organisational measures to ensure the system is used in accordance with its instructions, must assign human oversight to qualified individuals, and to the extent they control the input data, must ensure that data is relevant and sufficiently representative for the system's intended purpose.

This last obligation is practically significant. An AI-powered transaction monitoring system whose training data does not reflect the current transaction patterns of the institution's customer base will produce outputs that are not reliable indicators of the risk the institution actually faces. Ensuring the data quality and representativeness of the inputs to AI compliance tools is a deployer obligation under the Act, not just a commercial sensibility. It requires an ongoing programme of monitoring, calibration, and review rather than a one-time implementation exercise.

Layer 3: The Audit Trail as Active Compliance Infrastructure

The audit trail is the component of the compliance stack that is most consistently underinvested in, most commonly treated as a byproduct of processes rather than as active infrastructure in its own right, and most dramatically consequential when it fails.

When a regulator conducts an on-site inspection, the first thing they examine is not the compliance policy. It is the actual record of how individual cases were handled: what information was collected, when, from which source, what decision was made, who made it, and on what basis. The audit trail is the evidentiary layer that either supports or contradicts everything the institution says about its compliance programme.

What a Legally Compliant Audit Trail Must Contain

Under Article 77 of the AMLR, obliged entities must retain documents and information obtained during customer due diligence for five years from the end of the business relationship or the date of the occasional transaction, in a form that is usable for the purposes of any investigation, monitoring, or analysis by a competent authority or FIU. The retention period can be extended by a further five years on the request of a competent authority. Records of transactions must be retained for five years from the date of the transaction.

A compliant audit trail therefore needs to contain, at a minimum: the CDD information collected at onboarding including the sources used and the date of retrieval; the beneficial ownership identification and verification evidence including which registry or document source was used; the risk rating assigned and the reasoning for it; any screening results including sanctions, PEP, and adverse media checks; the dates those checks were run and against which list versions; the decisions made and by whom; any alerts generated and how they were resolved; any EDD steps taken and the approvals obtained; any ongoing monitoring reviews conducted and their outcomes; and any SAR-related investigations and the decision to file or not file.

That is not a passive record. It is a structured, timestamped, retrievable account of every significant compliance decision made in relation to a customer relationship from the moment it began. Building it manually is possible in principle. Maintaining it reliably at the volume that most mid-market and growing regulated businesses operate at is not.

The Difference Between a Performative and a Functional Audit Trail

The most important distinction in the audit trail layer of the compliance stack is the difference between a performative audit trail and a functional one.

A performative audit trail looks complete from the outside. There are documents. There are dates. There are approvals. When a compliance officer assembles the file for a regulatory examination, the narrative looks coherent. The problem is that the narrative was assembled, rather than captured at the time the decisions were made. The documents were collected. The reasoning was added later. The approvals were sometimes obtained after the fact. The dates are the dates the file was compiled, not the dates the decisions happened.

A functional audit trail is one that captures events as they occur. The registry query is logged with a timestamp when it is run. The screening check is recorded with the list version and the date. The risk rating is documented at the moment it is assigned, with the analyst's reasoning in the record. The approval is obtained through the system and the decision flows into the case file automatically.

The distinction matters because regulators examine both, and experienced supervisors know the difference. An audit trail that was assembled retrospectively tells a different story from one that was captured in real time, and the story it tells is one of a compliance process that is reactive rather than systematic.

How DORA Adds a Parallel Audit Trail Requirement

For payment institutions and EMIs, DORA adds an audit trail requirement in the ICT domain that runs parallel to the AML audit trail. The DORA framework requires a complete register of ICT third-party service provider contracts, documentation of major ICT-related incidents including timelines and classification reasoning, evidence of the management body's definition and oversight of the ICT risk management framework, and records of resilience testing outcomes. Under DORA, the audit trail for an institution's technology governance is as important as the audit trail for its compliance decisions.

The practical connection to the broader compliance stack is significant: the AI and automation tools that power the compliance function are ICT systems and ICT third-party service provider relationships for DORA purposes. The audit trail that covers the compliance process and the audit trail that covers the ICT governance of the tools used in that process are separate records that need to be maintained in parallel.

How the Three Layers Work Together as a System

The reason the stack metaphor is accurate is that the three components depend on each other in the specific way that layers of a technology stack depend on each other. Remove any one of them and the system degrades in predictable ways.

When the human layer is under-resourced relative to the volume that the AI layer is processing, the human review becomes a bottleneck or, worse, a rubber stamp. Alerts are closed without genuine investigation. SAR decisions are made without adequate reasoning being documented. The oversight that the regulatory framework requires becomes nominal rather than meaningful.

When the AI layer is poorly governed, the quality of information reaching the human layer degrades. Alerts are generated by rules that no longer reflect the institution's risk profile. Screening produces a false-positive rate so high that analysts stop trusting the output and start dismissing matches without adequate investigation. Registry data is pulled from sources that have not been updated and the verification records show dates that do not reflect the current state of the business.

When the audit trail layer is incomplete or performative, the human layer's decisions cannot be demonstrated. The AI layer's outputs cannot be verified against the decisions that followed from them. The compliance programme that exists in practice has no reliable record, and the compliance programme that exists on paper describes a process that cannot be substantiated.

The three layers are strongest when they are designed together rather than assembled separately. The AI layer should be configured to capture its outputs in a form that feeds directly into the audit trail. The human layer's decisions should be made within a system that captures them as they are made rather than requiring the analyst to document them separately. And the audit trail should be maintained in a form that can be retrieved coherently for a full business relationship history at any time, not just at examination time.

Where the Stack Breaks Down and How to Prevent It

The most common failure point in the compliance stack is the connection between the AI layer and the human layer. Specifically, the failure happens when the AI layer generates outputs that the human layer cannot act on effectively. This happens in two directions.

In the first direction, the AI generates too much noise. Alert volumes grow beyond the team's capacity to investigate genuinely, and the human review becomes a clearance exercise rather than an investigation. In the second direction, the AI generates outputs that the human cannot interpret or override. The analyst sees a risk score but does not understand the model that produced it. They see a match but cannot assess whether the matching logic is accurate for the specific case in front of them.

Both failure modes are directly addressed by the EU AI Act's deployer obligations. Assigning oversight to individuals with the necessary competence, training, and authority, and ensuring those individuals have the information they need to understand and override the system, are obligations that exist precisely because these failure modes are common and consequential.

The second most common failure point is between the human layer and the audit trail layer. Decisions that are made but not documented, or documented in a way that does not capture the reasoning, create a gap that becomes visible only when something goes wrong and the institution needs to demonstrate that its decision was sound. The solution is structural: the audit trail must be designed to capture the human decision as it is made, not as a separate documentation task that happens afterward.

Detailed Comparison: What Each Layer Does, Cannot Do, and Is Required to Do

About SpeedyDD

SpeedyDD is a KYB and due diligence platform built on the belief that all three layers of the compliance stack need to function properly for any of them to function well. An institution whose compliance officer is excellent but whose data-gathering process is manual and whose audit trail is assembled from emails is not a well-designed compliance programme. An institution whose AI-powered tools are sophisticated but whose human oversight is nominal and whose records are incomplete is not one either.

SpeedyDD's role in the compliance stack is in the data-gathering and audit trail layers, specifically the functions that should be automated by design: connecting to more than 3000 corporate registry data sources across more than 200 countries and territories, retrieving structured KYB and UBO data with automatic timestamping, and logging every verification, decision, and approval as it happens rather than requiring it to be documented separately. Every check that SpeedyDD runs and every decision that flows from it becomes part of an audit trail that exists in the form that the AMLR's five-year retrievable record requirement demands.

For compliance officers and MLROs who carry personal accountability for the accuracy and completeness of their CDD and ongoing monitoring records, SpeedyDD is built to make the data they need available in structured, documented form so the judgment they apply to it is the value they add, not the retrieval work they do before they can apply it.

Frequently Asked Questions

What are the three layers of the modern compliance stack?

The modern compliance stack consists of three interdependent layers. The human layer carries legal accountability, exercises contextual judgment, governs the other layers, and makes the decisions that the regulatory framework requires to be made by named, qualified individuals. The AI and automation layer handles data retrieval, detection, screening, alert generation, and ongoing monitoring at the volume and speed that human teams alone cannot sustain. The audit trail layer captures, structures, timestamps, and preserves the evidence of every compliance decision and process step in a form that can be retrieved and demonstrated to a regulator, banking partner, or auditor years later. Each layer depends on the other two, and a gap in any one of them degrades the system as a whole.

What does meaningful human oversight actually mean in the compliance context?

The EU AI Act's Article 26 defines what meaningful human oversight requires of deployers. The person assigned oversight must have the competence, training, and authority to understand the AI system's capabilities and limitations, to correctly interpret its outputs, to be aware of the risk of automation bias, and to intervene or override the system where necessary. Meaningful oversight is not a person clicking approve on an automated recommendation without the information or authority to question it. It requires that the reviewer can genuinely assess whether the AI's output is correct and appropriate in the specific case in front of them.

Why is the audit trail described as "active infrastructure" rather than passive documentation?

Because a passive audit trail, one assembled from emails, file attachments, and documents collected before an examination, is not the same thing as a real-time capture of compliance decisions as they are made. Regulators and experienced supervisors can distinguish between the two. A real-time audit trail tells the story of a compliance process as it happened. A retrospectively assembled file tells the story of how the institution wishes it had happened, and the difference is often visible in the consistency of timestamps, the completeness of reasoning records, and the coherence of the sequence of events. The AMLR requires records to be retained in a form that is usable for investigation and monitoring purposes, which is a functional standard, not simply a storage requirement.

What does the AMLR require for record retention and why does it matter for the audit trail layer?

Under Article 77 of the AMLR, obliged entities must retain CDD documents and information for five years from the end of the business relationship or the date of the occasional transaction, and transaction records for five years from the date of the transaction. On the request of a competent authority, the retention period can be extended by a further five years. The records must be retained in a form that is usable for investigation and monitoring purposes, meaning they must be structured, retrievable, and comprehensible rather than simply stored. This requirement defines the minimum standard for the audit trail layer: it must be a retrievable, usable account of the compliance decisions made in relation to a customer relationship across its entire lifespan.

How does DORA relate to the compliance stack described in this article?

DORA creates a parallel audit trail and governance obligation for the ICT systems that power the compliance function. For payment institutions and EMIs, the AI-powered tools that sit in the AI layer of the compliance stack are ICT systems and ICT third-party service provider relationships for DORA purposes. DORA requires a complete register of those contractual arrangements, documentation of the management body's oversight of the ICT risk management framework, and records of major ICT-related incidents including timelines and classification reasoning. The management body's DORA governance obligation makes the human layer responsible for governing the technology infrastructure of the compliance stack, not just the compliance decisions that flow from it.

What are the most common compliance stack failures that regulators find?

The EBA's July 2025 Opinion on ML/TF risks identified that more than half of serious compliance failures reported to the EuReCA database involved the improper use of RegTech tools, with 277 material weaknesses linked to RegTech systems in 2023 and 2024. The most common patterns are: AI and automation tools configured at implementation but not updated as the business evolves; alert volumes that exceed the team's capacity for genuine investigation; human reviewers who lack the competence or authority the EU AI Act requires for effective oversight; and audit trails that are assembled retroactively rather than captured in real time. These failures consistently cluster at the boundary between the AI layer and the human layer, and between the human layer and the audit trail layer.

Does the EU AI Act apply to compliance tools that use machine learning?

It depends on the specific function and context of the tool. The EU AI Act classifies AI systems used in AML risk profiling, fraud detection, credit scoring, and automated decisions affecting access to financial services as high-risk AI systems under Annex III. For compliance teams using AI-powered transaction monitoring, ML-based screening, or AI risk scoring tools, the question of whether those tools qualify as high-risk is one that needs to be assessed against the Act's classification criteria. If they do qualify, the deploying institution has obligations under Article 26 covering human oversight assignment, input data quality, and use in accordance with the provider's instructions. The high-risk AI system obligations under the Act apply from 2 August 2026 for systems already within scope, with some category-specific extensions under the AI Omnibus to December 2027.

How should a compliance officer think about their role within the three-layer stack?

The compliance officer's role in the stack is to operate at the apex of the human layer, carrying personal accountability for the decisions that emerge from the interaction of all three layers. They set the risk appetite and the risk rating criteria that the AI layer is configured to detect against. They review the outputs the AI layer produces and make the judgment calls that the regulatory framework assigns to them. They ensure the audit trail layer captures their decisions in a form that will support scrutiny years later. And they report annually to the management body, which means they are also responsible for making the governance layer of the stack visible to the people who are required to oversee it. The compliance officer who understands the technical functioning of their AI tools, not just the results they produce, is in a significantly stronger position to discharge that accountability than one who treats the tools as black boxes.