TechnoXander: AML Investigation Notes

Traceability Is a Feature: Designing Citations for AML Recommendations

TechnoXander — Fri, 30 Oct 2026 07:40:57 GMT

A recommendation that cannot show its sources is a guess with good manners. If you build investigation tooling, here is how to make traceability a feature, not an afterthought.

The principle

Investigation AI sits at the point an analyst opens the case. Its job is to assemble evidence and propose a next step. Our overview of investigation AI versus detection AI explains the placement. The design question is how each statement connects back to the record it came from.

Five design rules

One source per claim. Each sentence in a summary links to a record: a transaction, a KYC field, a prior case or a policy paragraph.
Show retrieval, not just output. Let the analyst open the retrieved records. This is the idea behind retrieval-grounded AI that generates evidence.
Mark inference. Label suggestions and assumptions differently from facts.
Keep the human step visible. Show who accepted, edited or rejected a recommendation, and when. FATF notes most tools still need people to use and review them.
Log versions. If a summary is regenerated, keep both versions and the reason.

A caution on regulation

Don’t claim the EU AI Act makes all AML AI high-risk. Annex III names credit scoring, and transaction monitoring is carved out of that credit clause. Classification turns on use, so ask your legal team, then design for explainability anyway, as the FCA’s expectations on AML AI models suggest.

Conclusion

Traceable output makes review faster, supports audit and builds the organisational memory that teams otherwise lose. We build for this at TechnoXander. If you’ve shipped citations in a regulated tool, what did analysts click first?

Design the Defence-Request Form to Fail Early

TechnoXander — Wed, 28 Oct 2026 12:37:16 GMT

Most compliance forms accept almost anything. The UKFIU does not. If you build the form that investigators use to prepare a defence request, you can catch most problems before the submission, using the UKFIU’s own rules as your validation list.

The principle

The UKFIU says it is unable to interpret, assume or infer anything, so a request has to be clear, explicit and detailed on all three essential criteria. Your form should therefore refuse to let a draft move forward while any criterion is missing.

Eight rules worth encoding

Grounds for suspicion present. Not empty, and not a copy of the alert rule name.
Property described. A value, which can be an estimate if marked as one, and a location, or a reason why the location is unknown.
A single prohibited act. Either/or alternatives are not considered, so the form should accept one act or a clearly set-out series.
A future date. The date must be in the future and requests cannot be open-ended.
A time limit. Best practice is that ongoing activity should not exceed 12 months.
A destination. The UKFIU may not be able to provide a defence if the destination is not known.
A UK link. Requests without a clear UK nexus cannot be considered.
Correct legislation selected. Choosing the wrong law may mean you don’t get the defence you need, and the request must be marked as a defence request in the portal’s section 7.

Two things a form cannot check

It cannot tell whether the suspicion is sound, and it cannot tell whether the act is within the firm’s control. The second is a legal condition: the reporter must be able to prevent the act during the notice period or after a refusal. Ask for a human confirmation, not a silent default.

Design cautions

Do not hide validation errors until the end. Show them as the investigator types.
Keep wording identical to the SAR Portal’s questions so staff do not translate twice.
Log what changed between drafts. A narrative that changes late is a signal worth reviewing.

Conclusion

A form that fails early saves days later. For the wider problem of how report quality is decided long before the form opens, see our analysis of SAR quality and the legal defence behind it. If you build these tools, what is the one validation rule you would add that no regulator asks for?

Policy Moved the Count: Reading the 23% Fall in UK DAML Requests

TechnoXander — Tue, 27 Oct 2026 07:14:00 GMT

A good analyst never reads a time series without a calendar of events beside it. Here is a clean example from UK financial crime data.

The movement

DAML requests fell 23% to 44,553 in 2025-26, primarily following the reporting threshold rising from £1,000 to £3,000 in July 2025. Total SARs rose 3% to 896,414 in the same year.

Two components of one system moved in opposite directions. A single total would have hidden both.

Four habits this example supports

Annotate the series. Mark policy dates on the chart before explaining anything. The fall in requests lines up with a known rule change.
Separate mechanical from behavioural change. A threshold changes what must be filed. It says little about how suspicious activity itself changed.
Break totals into components. Overall volume rose while one category fell. The composition tells the story.
Pair volume with outcomes. The previous year’s record £382.6m denied through DAML SARs shows results can move independently of counts.

What it means for a firm’s own data

If you track your own SAR numbers, annotate them with internal changes: new templates, new tooling, new team structures. A change in count after a template change might be a quality effect, a policy effect or noise. You cannot tell without the annotation.

One caution

I am not claiming the threshold change caused every part of the fall. I am saying the reported explanation is a policy change, and that any analysis ignoring it would mislead.

For how this connects to what analysts can see when they decide, see why prior cases get lost.