← Back to Work
Process file · Finance Finance

What’s inside: audit trail · monitoring

An MLRO, a queue of alerts, mostly noise

The question this file answersHow many of the alerts my MLRO opens each week were never going to end in a report?

Fits: banks, payment firms and fintechs where compliance files are still assembled by hand.

Typical day

What the desk looks like today

Typical pattern, not a measured desk; the finance playbook calls suspicious-activity investigation human work and gives no alert volume. Alerts, repeat false positives and true suspicion share one queue; the MLRO's hours go on opening, not deciding. It hurts when a genuine pattern has sat under noise all week.

What changes

What Monday looks like after

When the MLRO sits down, the queue holds the cases worth a decision, each with history and transactions already laid out, and the noise closed with a logged reason the regulator can read. Filing remains a name on a form — the MLRO's.

Typical, not a measured client result. Every figure here comes from the playbook source named below.

Logged

the same assembly build as KYC onboarding — no published figure for monitoring alerts

Before: the MLRO's time goes to opening files, not deciding. After: known noise closes with a logged reason and suspicion arrives assembled. No percentage — the KYC figure is about onboarding.

No published figure for this desk. The range lives on the parent file: KYC: documents scored before the officer opens the file →

How this file is built

McKinsey KYC study (2023) is about onboarding case time; transaction monitoring is a different desk, so the 50–70% remains with the KYC file; this desk shows none. We will not write a detection rate.

What we install

What we put in front of the systems you already run

Your monitoring and core systems stay — Temenos, FIS, Finastra and your transaction-monitoring tool, or the ones you run. This is the same evidence-assembly build as our KYC onboarding, pointed at monitoring:

  1. alerts that match a known low-risk pattern are closed with the reasoning written into the log
  2. anything unusual, repeated or above threshold has the customer history and the triggering transactions assembled into one file
  3. that file goes to the MLRO, who decides.

No model writes or files a suspicious activity report.

What stays human — and what this will not do

The suspicious activity report. The customer. The regulator. No model files.

We will not write a detection rate.

What can go wrong — and what we do about it

Automatic closure of any alert is a regulatory question before it is a technical one — the closure rules and the log format must be signed off by compliance, and until they are, nothing closes without a person. If your monitoring tool exports alerts only as reports or screens, assembly runs on exports and is slower.

What it costs to get there

The path: free 60-second estimate → free 20-minute review → paid audit of this one process (€1.5–3K, typically two weeks) → pilot with your people in the loop (€10–20K, weeks, not quarters). No transformation programme. Prices are public, on the services page →

Scoped in the audit — the playbook has no estimate for this exact desk.

This is about you if…
What does this mean in euros?

That depends on your volumes and wage costs — this page will not invent the number. The free 60-second estimate runs that calculation from your answers, with every multiplier sourced.

Get your free savings estimate 60 seconds · no sales call Or write first → Map a finance process like this one — free, 60 seconds →

Not a named Aperanda client. Process file · Finance.

Short process file. Same build as its parent file; the playbook has no separate volume or benchmark for this desk.

All process files