DEV Community: TechnoXander

Dear Product Manager Writing the AML AI Requirements Doc

TechnoXander — Fri, 30 Oct 2026 07:38:32 +0000

Dear product manager,

You’ve been asked to write requirements for “AI in AML”. It’s an easy brief to get wrong, because the phrase hides two different products.

The first is detection AI. It sits upstream and decides which transactions get flagged. The second is investigation AI, which sits where an analyst opens the alert and decides what to do. The distinction is the core of our piece on the two types of AI in AML. Most vendors only sell the first.

Write requirements for the second one too

First screen. The analyst sees customer history, prior dispositions and linked accounts without opening other tabs. That’s the gap behind alerts that arrive without context.
Traceability. Every sentence in a summary points to a record. Read why evidence-grounded AI beats answer-generating AI.
Human decision. The tool recommends, a named person decides, and the log shows who.
Memory. When a case closes, reasoning is kept in a form the next case can use.
Data hygiene. FATF warns that poor or biased data fed into a model can be learned by it, so say how data quality is checked.
sanctionscanner

One requirement to resist

Don’t write “reduce false positives” as the only success measure. It describes detection. If the goal is better decisions, measure what analysts see and how well they can explain the result. That is the argument of the next phase of AML is better decisions.

We work on the investigation layer at TechnoXander, and you can see how at the platform page.

Over to you

What is the first line of your AI requirements doc, and does it mention the analyst?
Should traceability be a hard requirement or a nice-to-have?
Hot take: a requirement that can’t be tested in a demo isn’t a requirement. Agree, or fight me?

Warm regards,
Sonal

Dear Engineer Building the Alert Screen

TechnoXander — Tue, 27 Oct 2026 07:04:24 +0000

Dear engineer,

Somebody just walked over with a request that sounds simple: “Analysts need more context when an alert opens. Can you add it to the screen?”

I’m writing because I’ve seen how this goes. It starts with good intentions and ends with a screen that scrolls for a page and a half. So here are a few things I wish someone told every team at the start.

First, what decision does this screen support?

An AML analyst opening an alert is trying to decide one thing: is this activity explained, or does it need to go further? Every item on the screen should help with that decision. If a field wouldn’t change what the analyst does, it’s decoration.

Ask three analysts to cross out the fields they never use. You’ll be surprised how little survives.

Second, “nothing found” has two meanings

This is the one that bites developers hardest. Imagine the screen shows “Previous cases: 0”.

Does that mean there are none? Or that the search couldn’t find them, because the earlier case was filed under a trading name and your query used the legal name?

A human reading “0” will assume the first. So the screen quietly teaches analysts that no history exists, when it only means none was found.

My suggestion: give every section three honest states: found, none found and could not check. Make “could not check” visible and boring, a small grey label. It takes ten minutes to build and prevents a lot of false comfort.

Third, show how sure you are

Entity matching is messy. Two records might be the same customer, or they might not. Don’t merge them silently, and don’t hide them either. Show “possible match”, show the evidence behind it (same address, same phone number), and let the analyst confirm or reject.

Their answer is data too. Store it, so the next analyst doesn’t redo the same check.

Fourth, order by consequence, not by database

Put what changes decisions at the top: how this activity compares with the customer’s normal pattern, the outcome of the last case, any open questions. Keep raw records one click away.

Think in three layers: the verdict frame, the supporting evidence, the drill-down. If a field lives in the top layer, it should earn its place.

Why I care about this

When context is hard to see, analysts do what anyone would. They open other tabs, search again, copy identifiers and rebuild a picture the institution already holds. Better detection doesn’t fix that. A better first screen does.

I wrote about the compliance side of the problem here: why alerts arrive without context.

Over to you

I’d really like to hear how you’d approach this, especially if you’ve built something similar.

Have you built an internal tool where “no data” was ambiguous? How did you handle it?
If you could show only five things at the top of an investigation screen, what would they be?
Hot take: a screen that shows less but is trusted beats a screen that shows everything. Agree, or fight me?

Warm regards,
Sonal

Dear MLRO, Put Case Ownership Before Closure Counts

TechnoXander — Mon, 19 Oct 2026 13:35:39 +0000

At 2.15 pm, an investigator opens a case that looks straightforward. The customer profile describes one type of business activity, but the available transaction history suggests another. A previous review contains a useful observation, buried in an older case file.

Before the investigation can progress, the analyst must find the missing information, reconcile the discrepancies and establish what requires further review.

None of that work is visible in a closure target.

Dear MLRO,

Your investigators are expected to make decisions that withstand scrutiny. But the quality of those decisions depends on more than individual judgement. It also depends on how information is organised, how responsibility is assigned and how the investigation process supports the people doing the work.

Clearer instructions and additional training have value. They cannot, however, solve problems caused by fragmented information, unclear ownership or inefficient escalation.

The question is whether your operating model gives investigators the conditions they need to make sound decisions.

Give investigators the right information

An alert is a reason to investigate, not a complete account of customer activity.

Analysts may need transaction history, due diligence records, screening results and previous case decisions to assess what has happened. When these sources are disconnected, investigators spend time reconstructing the case before they can analyse it.

This creates delays and increases the risk that relevant information will be overlooked or previous decisions misunderstood.

Measure more than the time taken to close an alert. Consider how much effort is required to assemble the necessary evidence and whether the information available supports a defensible decision.

The objective is not to provide more information indiscriminately. It is to make relevant evidence accessible and explain its significance and limitations.

Make ownership and escalation clear

An open case should have a clear next action, an identified owner and an understandable reason for any delay.

Responsibility may pass between investigators, supervisors and specialist teams. What matters is that the reasoning behind the current position travels with the case. The next person should not have to reconstruct what has already been examined or which conclusions remain provisional.

Escalation also needs defined boundaries. Analysts should know which decisions they can make independently, when additional review is required and who has authority to decide.

Without clear criteria, routine uncertainty can generate unnecessary referrals, while cases needing specialist input may remain with the wrong person.

Use quality assurance to improve the process

When a case is returned for additional work, correcting the case is only the first step. You should also understand why the problem occurred.

Was evidence difficult to find? Were internal requirements unclear? Did the recorded rationale fail to support the decision?

Track recurring causes of rework and respond accordingly. Improve information access where evidence is missing, clarify standards where expectations differ, and use targeted coaching where analytical skills need development.

Investigators remain accountable for their work. Management is equally responsible for the tools, standards and processes that support it.

Make technology reduce friction

Technology should help investigators find relevant evidence, understand case history and identify unresolved questions without replacing professional judgement.

Automation can organise records, prepare summaries and highlight relationships for review. Material statements should remain traceable to their sources, and conflicting or missing information should be clearly identified.

The TechnoXander AML investigation platform provides a reference point when evaluating whether a more structured investigation workflow could address these operational problems. Any solution should fit your firm's policies, data controls and oversight requirements.

The question I would ask your team

Do your analysts spend most of their time assessing evidence, or finding it, reconciling it and explaining why information is missing?

The answer should determine what you improve first. Fragmented information, delayed approvals, knowledge gaps and repeated case corrections require different interventions.

Review one difficult investigation from the first alert to the final decision. Record every point where the investigator has to search, wait, reconstruct or seek clarification.

Those findings will give you a practical starting point for improving investigation quality, rather than simply asking your team to close cases faster.

Customer Context Is Part of Every AML Alert

TechnoXander — Mon, 19 Oct 2026 13:24:57 +0000

An alert arrives near the end of a shift. The amount is unusual, the payment reference is incomplete, and the customer's transaction history is difficult to explain.

The analyst must decide whether to search other systems, request information from another team or make a preliminary assessment.

This is where transaction data quality becomes a practical AML investigation problem. Missing information slows reviews, creates repeated requests and weakens the reasoning behind the final decision.

What goes wrong

The analyst sees a transaction but lacks enough context to interpret it. Counterparty details may be missing, expected customer behaviour may be unclear, or previous alerts may sit in another case-management system.

Each gap forces the analyst to reconstruct the picture manually.

Without consistent information, different analysts may reach different conclusions about similar activity. Reviewers may also struggle to understand why a case was closed if the supporting evidence was never recorded.

An alert can therefore be completed without fully resolving the uncertainty that made it difficult.

Why it keeps happening

Customer profiles, payment records and previous investigation decisions often sit across systems with different purposes. Each may work correctly in isolation, yet investigators still have to assemble the full picture themselves.

Ownership is another challenge. When data fails to match or transfer correctly, responsibility may be unclear. Analysts work around the problem to clear their queues, while the underlying defect remains.

Operations reports may track alert volumes and closures without showing how much time investigators spend searching for basic information.

The FCA's Financial Crime Guide highlights the importance of accurate monitoring data, understanding customer relationships and recognising monitoring-system limitations.

How to fix it

Start by identifying the minimum context analysts need to make sound decisions. Depending on the alert, this may include customer profiles, expected activity, transaction details, counterparty information and previous related activity.

Then identify the cause of each data gap. Is the information not collected, incorrectly mapped, missing between systems or simply difficult to find? Each problem needs a different remedy.

Assign ownership for material defects, assess their impact on investigations and retest the data after remediation. Confirm that the information reaches the analyst as expected, rather than relying on an engineering ticket being marked complete.

One practical test is to ask an analyst to explain a recently closed alert using only the retained case record. If the reasoning depends on memory, private notes or undocumented conversations, the record is incomplete.

An effective AML investigation workflow should help analysts connect information, assess anomalies and preserve the reasoning behind decisions.

For your next team review, choose one difficult alert and identify every point at which the analyst had to leave the case file to find essential information.

Fixing that friction may improve investigative quality more than simply asking the team to work faster.