Transaction monitoring: rules engine, agent, and audit trail

Transaction monitoring is the operational evidence that a bank has its AML house in order. Regulators, auditors and the board want to know how suspicious transactions are caught, how they're escalated, and how long it takes to resolve them. In 2026, the common failure isn't too little technology. It's the wrong composition of layers.

Three layers should be clearly separated and clearly connected. The rules engine handles alerts that are deterministic and explainable. The machine model catches patterns the rules engine misses. The agent assembles the case before a human decides. The audit trail sits across all three.

Rules engine

Start with the rules engine, because that's where the foundation is built. Traditional AML rules aren't dead in 2026. They're necessary because regulators know what they're doing, and because they give a baseline of false negatives on defined risk scenarios. But if the ruleset only grows and old rules never come out when their value drops, you end up with high alert volume and low precision. The most common failure in Nordic banks is rules engines that are seven years old, where nobody dares to turn off a rule because nobody knows exactly what it catches anymore.

Machine model

The machine model is where pattern analysis lives. With a sufficient set of labelled cases, a gradient boosting model can find signals no rule writer ever thought of. But the model is only safe as long as it's explainable enough to reason about. SHAP values or equivalent are not nice-to-have, they're necessary. If the model flags a customer and the analyst can't see why, you don't have a compliance process. You have an oracle.

The agent layer

The agent is the new layer. When an alert fires, whether from a rule or a model, there's an unavoidable job of pulling context together. The customer's KYC status, transaction history, counterparty information, geographic exposure, twelve months of media findings, comparison against expected behavior. That work typically takes 30 to 90 minutes for an analyst. The agent does the assembly in minutes, presents a structured summary, and proposes a recommendation with reasoning.

The agent doesn't close the case. It lets the human concentrate on the judgement, not the data gathering. In practice, that's the shift that pulls the volume out. Banks doing this well process three to five times more alerts per analyst with no compromise on quality, because the threshold for raising an alert can be set lower when the first round doesn't cost a full hour.

Audit trail

The audit trail is what binds it all together. Every alert has to be followable from trigger to conclusion. Which rule or model version triggered? Which data sources were queried? What did the agent find, and how does that line up with policy? Who approved, who escalated, how long did it take? This isn't an IT requirement, it's a regulatory one. If you can't surface this in seven minutes for an examiner, you have a problem that will cost you.

An undervalued point is how much value sits in how cases are closed. Many banks close false-positive cases with a free-text comment. That's lost training data. If every closed case is structured around which signals were decisive and why, you build a data pool that improves both rules and models. Over six months you can find which rules generate 40 percent of alerts but only 3 percent of real cases, and clean them out with quantitative backing.

Where the agent sits in the org

Where does the agent fit in the org? Our experience in 2026 is that the agent belongs under the AML function, not under technology. The model is an operational resource the AML head has to own and steer. That means the AML function has to build new skills around model review, prompt management and evaluation. It's a competence shift, and banks that don't plan for it end up with an agent nobody knows how to improve.

Three concrete steps

Three concrete things you can do in the quarter after reading this. First, measure rule volume against actual case rate per rule, and clean out the three rules with the worst signal. That frees capacity immediately. Second, build an agent that does context assembly for the most time-consuming case types, and run it in parallel with existing tools for six weeks to validate quality. Third, set up an audit log that covers alert trigger, data sources, agent recommendation and human decision, so the next examination is a conversation rather than an archaeological dig.

What separates a good transaction monitoring function from an average one in 2026 isn't model choice. It's discipline in how the rules, the model, the agent and the audit trail hang together. With that discipline, AML becomes an operational strength that produces genuine insight. Without it, it's expensive noise.