AI Accountability in Financial Crime Compliance: Who Owns the Decision?

Reading time: ~9 minutes · For AML, fraud, compliance and risk professionals, and the boards that oversee them

AI can flag the risk, but who owns the decision?

1. Who owns an AI-assisted decision

An investigator opens an alert and finds an AI-generated summary waiting for them. It brings together the customer profile, recent transactions and previous case notes, then recommends closing the alert. The explanation reads well, and accepting it would help clear a growing queue.

AI can help investigators work through a case file, but a convincing explanation does not establish that an investigation is complete. Before accepting a recommendation, the reviewer needs to check the supporting evidence and understand what the system may have missed.

Drawing on Marco’s experience across banking operations and financial crime technology, we start with the workflow: the task we want the system to perform, the information it can access and what happens when it gets something wrong. Those choices determine where the governance and board oversight discussed below need to apply.

2. Define the task before choosing the technology

A model that ranks transaction monitoring alerts performs a different task from a generative AI tool that drafts investigation summaries. If a system also has permission to update customer records or close cases, an incorrect output could directly affect how a customer or alert is handled. Testing and review arrangements should reflect those permissions.

We would begin with a specific problem, such as the time investigators spend assembling a transaction chronology. A useful first application could prepare that chronology and link each entry to its source. The investigator can then check whether the relevant activity is included, whether the sequence is accurate and what still needs explaining.

The intended use should specify how far the tool’s role extends. A tool approved to summarise a case file should not automatically be authorised to close it. Similarly, permission to draft a suspicious activity report should not be treated as authority to decide whether the applicable reporting threshold has been met.

Generative AI can produce plausible but incorrect statements, a risk described as confabulation in NIST’s Generative AI Profile [1]. In an investigation, this could mean an unsupported explanation of a payment or a claim that a document confirms something it does not. Source links help reviewers check an output, but the existence of a citation does not prove that the cited material supports the conclusion.

Teams should use approved environments with defined access controls, retention arrangements and rules for handling customer information. Testing should also check whether misleading material or embedded instructions in case documents can influence the AI’s output. Reviewers need to know how the system handles this material and what controls prevent it from changing the assigned task.

3. Governance, accountability and board oversight

Artificial intelligence has developed a rather impressive ability to produce convincing answers to complicated questions, often accompanied by the sort of confident presentation that might once have required three consultants, an expensive PowerPoint template and a remarkably long meeting. Unfortunately, confidence and correctness are not quite the same thing; and in financial crime compliance, the distinction can be rather expensive.

The fundamental governance question is not whether AI can identify financial crime risks, but who takes responsibility for the decisions that follow. An algorithm might flag a suspicious transaction, recommend a customer risk rating or suggest that an alert requires no further investigation; however, the organisation remains responsible for ensuring that those conclusions are appropriate, defensible and consistent with its regulatory obligations. The introduction of sophisticated technology does not introduce an equally sophisticated mechanism for transferring accountability elsewhere.

This is where boards and senior management need to distinguish between automation and delegation. Technology can undertake tasks, process information and support professional judgement, but it cannot replace the governance structures through which decisions are challenged, escalated and ultimately owned. An AI-generated recommendation should therefore sit within an established framework of responsibility, with clearly defined decision-making authority, appropriate escalation procedures and sufficient documentation to explain how conclusions were reached.

Meaningful human oversight is particularly important, although the phrase itself risks becoming one of those reassuring expressions that appears frequently in governance policies and rather less frequently in operational reality. Having a human involved in a process is not necessarily the same as having effective human oversight; particularly if that individual lacks the training, information or authority to disagree with the technology. A compliance officer whose contribution consists of approving an automated recommendation without understanding its underlying assumptions is not exercising meaningful judgement, however efficiently the approval is recorded.

The same principle applies where organisations rely on external technology providers. Outsourcing a system does not outsource regulatory responsibility; boards must still understand what the technology does, where its limitations lie and how its performance is independently assessed. A particularly impressive demonstration from a vendor is not, unfortunately, a substitute for effective due diligence and ongoing assurance.

For boards, the discussion should extend beyond whether the organisation is using AI and towards whether it genuinely understands the consequences. Directors should be asking where AI influences financial crime decisions, who can challenge those decisions, how errors are identified and escalated, and whether management information provides meaningful assurance rather than simply attractive performance statistics. They should also consider whether efficiency targets are creating unintended pressure to accept automated conclusions without sufficient scrutiny.

Infographic: five questions directors should ask about AI, from where it influences financial crime decisions to whether efficiency targets create pressure to accept automated conclusions

Ultimately, effective AI governance should enable innovation rather than obstruct it. The objective is not to insist that every automated decision requires a committee meeting and seventeen signatures, but to ensure that technology operates within a proportionate, transparent and accountable control environment.

Because when a regulator asks why a significant financial crime risk was overlooked, “the computer said it was fine” is unlikely to be the compelling defence anyone had hoped for.

4. What meaningful review looks like in an investigation

Consider a fictional transaction monitoring case. A customer described as a domestic wholesaler begins receiving payments from several overseas companies and transfers much of the money onwards shortly afterwards. The AI summary suggests that the activity reflects business expansion and recommends closure.

The first question is where that explanation came from. Did the customer provide evidence of new trading relationships? Is the description supported by invoices and transaction details, or has the system filled a gap with a plausible story? Neither overseas payments nor rapid onward transfers alone establish wrongdoing. They do, however, need to be considered against the customer’s expected activity and the rest of the evidence.

We would expect the reviewer to check the underlying records, identify material gaps and document why the activity is or is not adequately explained. Known gaps and limits on the information available should be made explicit. The reviewer remains responsible for checking whether the evidence is sufficient, since the AI may not know what it has not received.

The reviewer must be able to amend or reject the recommendation, request further information and escalate concerns without being penalised for taking longer to complete the case. The case record should distinguish the AI’s proposed explanation from the investigator’s assessment and final rationale.

An unresolved concern should follow the organisation’s established escalation route to someone with the authority and expertise to assess it; depending on the issue, that might involve a senior investigator, the financial crime lead or the MLRO. Where the investigator and closure approver disagree, the concern, supporting evidence and reasons for the eventual decision should remain visible in the case record, with a route for further review where necessary. A material evidential gap should not be treated as resolved simply because the queue is growing or the AI recommendation sounds persuasive. Internal disagreement must also be handled without delaying any applicable reporting obligations.

Infographic: faced with an AI summary recommending closure, the reviewer checks the source of the explanation, checks the records for material gaps, then amends, rejects, requests information or escalates, keeping the AI's proposal separate from their own rationale

5. Test the controls as well as the output

Before introducing an AI tool into a live workflow, we would test it against representative cases, including incomplete records, conflicting information and cases where the correct response is to ask for more evidence. A demonstration built around a clean example tells us little about how the system will behave when an investigation is messy. Testing should also assess whether reviewers have enough time and capacity to check outputs properly under realistic workloads, as well as the authority to challenge them.

For a summarisation tool, we would examine material omissions, unsupported statements and whether the source references support the text. For alert prioritisation, we would assess which cases move down the queue and whether potentially significant activity is being delayed or overlooked. Historical investigator decisions can inform testing, but those decisions also need checking before they are used as the benchmark.

Alongside time saved, we would track substantive corrections, missed information, cases reopened after quality review and the types of errors reviewers encounter. A low rate of reviewers rejecting or changing recommendations could reflect strong performance, but it could also indicate that staff are accepting outputs too readily. Quality checks should test which explanation the evidence supports.

Testing should continue after deployment, particularly when models, prompts, data feeds or workflow permissions change. Teams should retain enough information to review a decision later, including the relevant system version and settings, the evidence used, the output presented and the reviewer’s decision. Access and retention should follow the organisation’s requirements for the information involved. An AI-generated explanation is not a reliable record of how the model internally reached its output.

Infographic: alongside time saved, track substantive corrections, missed information, cases reopened and error types; retain the system version and settings, evidence used, output presented and the reviewer's decision

Before deployment, teams should agree who can restrict or pause the affected function if performance deteriorates, how cases will be handled during an interruption and how they will decide whether earlier decisions need review.

Escalation thresholds should reflect the significance and potential reach of a failure. Repeated unsupported conclusions, missed material risks, ineffective human review or an inability to reconstruct decisions should prompt senior management attention; material incidents, systemic weaknesses and exposure outside agreed risk appetite should reach the board or relevant committee promptly. Before restarting a paused use case, the accountable owner should require evidence that the cause has been understood, corrective measures have been tested and potentially affected earlier decisions have been assessed. Independent challenge should be proportionate to the risk, with residual limitations, restart approval and enhanced monitoring documented. The board’s role is to oversee that assurance, rather than approve every technical adjustment.

6. Start with a defined use case

For an organisation considering adoption, we would start with one defined use case and agree how its performance will be judged before the pilot begins. The people reviewing its outputs need the time, information and authority to challenge them. Expansion should depend on the results of testing and quality review.

When someone asks why a case was closed, a customer’s risk rating changed or a concern escalated, the organisation should be able to explain what information was available, how the AI contributed, what checks were performed and who owned the final decision.

Reference

[1] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024, section 2.2 on confabulation. https://doi.org/10.6028/NIST.AI.600-1

The practical controls proposed in this article are the authors’ recommendations for discussion. The article does not assess jurisdiction-specific legal requirements.