AML/KYC for FDEs: agree terms with compliance before an agent reviews alerts

You have just been asked to put an agent into a bank’s AML alert queue. The agent reads transaction histories, summarises KYC files, recommends whether to close or escalate each alert, and drafts the narrative for a suspicious activity report (SAR). The demo runs smoothly, and the client’s engineering team loves it.

But the engineering team does not decide the go-live date. Compliance does. If you first meet compliance in week six, you will probably have to rebuild much of the architecture.

Projects like this are becoming common. The Wolfsberg Group, an association of large banks that sets standards on financial crime, noted in an August 2025 statement that financial institutions are gradually bringing automation, AI and ML into their strategies for monitoring suspicious activity.

For an FDE, then, the scarce skill is not calling an LLM. It is getting an agent through compliance.

What does compliance actually need to see?

Wolfsberg’s framework for responsible innovation has three pillars: validation when moving to a new tool, balancing model risk against financial crime risk, and explainability, meaning that outsiders can see clearly how much the system covers and how well it works.

Read as an engineer, each pillar is a deliverable you have to hand over, not a slogan.

The second pillar is the one most often misunderstood. Model risk is the chance that the agent gets something wrong. Financial crime risk is the chance that money laundering slips through, either because the agent was wrong or because the old process was too slow to keep up.

Compliance does not demand a perfect agent. They want to see the two risks set side by side, in concrete numbers.

Wolfsberg pillar	Question to ask compliance	What the FDE brings
Validation during transition	What evidence do you need before it can run in parallel with the current process?	A pilot plan on closed alerts, with acceptance thresholds
Balancing the two risks	What is the maximum acceptable miss rate, and what do you get in return?	A table setting time saved against the number of missed cases
Explainability	What does an auditor need to read after each recommendation?	Reasons with cited transactions for every alert, plus an audit log

A pilot, number by number

Suppose you propose running the agent on 200 alerts that investigators closed last quarter. The outcomes are already known, so this is the best eval set you have. Say the agent recommends closing 150 and escalating 50.

The engineering team will look at the 150: three quarters of the queue could be handled faster. Compliance will immediately ask a different question: of the 150 the agent wants to close, how many did investigators escalate?

If the answer is 6, those 6 cases are the centre of the meeting. You need to open each one, explain why the agent missed it and propose a fix.

That is balancing risk with data. You do not say “the agent is 97% accurate”. You say: the agent cuts handling time for this group, at the cost of 6 missed cases that are not yet acceptable at the current threshold, and here is the remedy. Compliance can make a decision on a statement like that.

The same story shows why the agent must not close alerts on its own. The authors of Co-Investigator AI, a 2025 study of an agent that drafts AML narratives, stress that human investigators stay firmly in the loop. In your design, let the agent write “recommendation” and let a human press the “decision” button.

Who decides what gets logged and how it is written?

Three questions that engineers tend to settle themselves in fact belong to the client’s organisation. The first is the narrative template. The Co-Investigator AI study notes that the quality of SAR narratives varies widely between financial institutions. An agent can help standardise them, but compliance must settle which template to standardise on before you write the prompt.

The second is logging. The same study points towards a design with a full audit log for each agent. How much to log, though, depends on what the rules say.

FinCEN and the US banking regulators issued a set of SAR FAQs on 9 October 2025 to spare financial institutions needless compliance work. According to an analysis by the law firm Orrick, the FAQs make clear that there is no legal requirement to document a decision not to file a SAR, nor to re-review a SAR after it has been filed.

So what the agent logs is the client’s policy choice, not yours. Let compliance settle the list of mandatory fields, then have the agent log exactly that list for each recommendation, rather than defaulting to “log everything” or “skip it”.

The third is which policy the agent falls under. On 17 April 2026, the Fed, FDIC and OCC issued SR 26-2 on model risk management, replacing SR 11-7, which had been in use for many years.

According to Baker Tilly, the new guidance does not address generative AI, and AI will be handled through separate guidance or rules. So ask the client’s model governance team directly: under which internal policy will this LLM agent be approved?

In what order?

In week one, ask for a joint meeting with compliance and the model governance team, and bring the three-pillar table above. The goal is to leave with three things agreed in writing: the agent’s scope (it recommends, it does not decide), the acceptable miss threshold, and the model policy that applies to the agent.

Next, ask for the approved narrative template and the list of data fields that must be logged. Only once you have both should you write the prompt and the log schema. Then run the pilot on closed alerts, and bring each missed case to the second meeting rather than a single aggregate number.

The four most common mistakes all come from the same habit: engineers deciding things that belong to compliance.

• Building first and asking for approval afterwards.
• Letting the agent close alerts on its own “to save time”.
• Choosing the logging level without checking policy.
• Assuming the existing model validation process automatically applies to LLMs.

On the career side, if you are aiming for FDE roles in finance, get a firm grip on the concepts in this article: AML, KYC, SARs and model risk management.

If you have taken a system through a control function’s approval process, put it on your CV in terms of outcomes: you designed the pilot, the control function set a given threshold, and the system was approved on given conditions.

When you talk about that experience, start with the missed cases you opened up and how you dealt with them, because that is what shows you understand risk rather than just knowing how to write prompts.