Skip to main content
Baobyte AML Suite

AML analyst

Most of your day is not analysis. It is finding things.

Opening an alert should not be the start of a scavenger hunt across six systems. If the rule trace, the transactions, the customer file, the ownership and the earlier alerts are already on the case, the work becomes what it is supposed to be — judgement, written down once, in the place the MLRO will read it.

  • Queue throughput
  • Subject-consistent cases
  • Rule traces on every alert
  • Drafts without re-keying

What you are measured on

What an analyst is actually assessed against

How many alerts you clear, and how many come back
Volume alone is a bad measure and everyone knows it, which is why the real one is volume net of rework: alerts reopened, cases returned by the MLRO, and drafts sent back for missing context.
Whether your escalations are the right ones
Escalating everything is as much a failure as escalating nothing — it shifts your triage burden onto the MLRO. What is assessed is judgement, and judgement is only visible if the reasoning was written down.
Whether your narrative survives quality assurance
A disposition that says 'no suspicion identified' with nothing behind it fails a QA sample. One that names what was checked, what was found and why it was not suspicious passes — and takes about the same time to write if the evidence is already on screen.
Time from assignment to disposition
Most of which, in practice, is not spent thinking. It is spent finding: pulling the customer record, the last six months of transactions, the earlier alerts and the screening history from wherever each lives.
Whether you can pick up someone else's case
Cover, handover and leave are constant. A case you can resume in five minutes because the reasoning so far is written into it is the difference between a team and a set of individuals.
Whether you were ever put in a position you were not authorised for
Being asked informally to close something you cannot formally close is a real hazard in under-resourced teams. Hard permission boundaries protect you from it.

Where the time goes

Six things you do per alert, and where each one lands

Add up the left-hand column across a week. That total, not detection quality, is what caps how many alerts a team can genuinely investigate.

Per-alert work: how it is usually done, and where it sits in the workspace
TaskTypically todayIn the case workspace
Understanding why an alert firedAsk a colleague, or infer it from the rule nameThe rule, its version and the evaluation evidence are attached to the alert
Gathering transaction contextExport from core banking into a spreadsheetTransactions for the subject are already in the case, in the currency they occurred in
Finding earlier alerts on the same customerSearch by name and hope the spelling matchesAlerts that resolve to the same subject correlate into one case
Checking screening historyOpen the screening tool separatelyHits, decisions and the list version behind them sit on the case
Recording what you didA note in a tracker, an email to the MLROThe narrative lives in the case, attributed and dated, and is what the MLRO reads
Producing a draft reportRetype the narrative into a templateGenerated from the case with a field-level trace back to source records

The loop

Triage, investigate, record, escalate

  1. Triage

    Work a prioritised queue scoped to your org unit. Alerts on the same subject arrive as one case rather than as four separate items competing for your attention.

  2. Investigate

    Everything the decision needs is on the case: the rule trace, the transactions, the customer file, ownership, screening evidence and prior history.

  3. Record

    Write the reasoning where it will be read — in the case, attributed to you and dated. This is the artefact that quality assurance and any later examination will sample.

  4. Escalate or draft

    Escalate with the case intact, or draft the report from it. Approval and filing sit with the MLRO; your draft carries its own trace so nothing has to be rebuilt.

Quality assurance

What a QA sample of your work will find

  • The reasoning behind every alert you dispositioned, dated and attributed, retrievable without your help.
  • The rule version that raised each alert, so a disposition can be read against what was being monitored at the time.
  • The full assignment history of a case, including every hand-over.
  • Screening decisions with the list source and version as at the moment you made them.
  • The draft report and its field-level trace back to the source records it was generated from.
  • A record of what you were permitted to see, and what was withheld — which protects you as much as it constrains you.

Proof

Throughput figures

The most tempting numbers on this entire site, and the ones most often published without a method.

Placeholder — no throughput measurements have been collected from a live deployment. Replace with sourced, approved content before this page is made public.

Throughput — awaiting measured figures with a stated baseline

Investigation-time and alert-per-analyst claims are only meaningful with a defined population, a baseline period and a named owner for the data. Until a real deployment has produced those, this stays a shell rather than a plausible percentage.

—

Alerts per analyst per day

Awaiting a defined population and period.

—

Median investigation time

Awaiting an agreed start and end point for the measure.

—

Rework rate

Awaiting a definition of what counts as rework.

Questions

What analysts ask first

Why can I not close my own case?
Where policy requires four eyes, closure is an MLRO action and the maker cannot be the checker. This is not a comment on your judgement — it is what keeps a closure that is later questioned from being attributed solely to the person who investigated it. Everything up to that point, including the recommendation, is yours.
Do I have to re-key anything into the report?
That is the specific thing the reporting design is meant to eliminate. A report is generated from the case using a governed mapping, and every field keeps a trace back to the source record that produced it. Where a value genuinely has to be entered by hand, it is recorded as a manual input rather than being indistinguishable from a system-derived one.
What happens when four alerts are really one situation?
They correlate into one case where they resolve to the same subject, within a defined correlation boundary that is tested rather than assumed. You investigate the situation once, and the case shows all four alerts as part of it.
Will I be able to see the customer's identifiers?
Only what your permissions allow, and a reveal of a sensitive identifier is an audited event with an accountable approver behind it. When something is withheld you are told that it is withheld rather than shown a blank — an unexplained empty field is how analysts end up recording that something did not exist.

Start the conversation

Ask to see the alert, not the dashboard

If you are on the evaluation, the question worth asking is simple: open one alert and count how many other systems you would still have to visit. That number is the one that will decide whether your week gets better.