Skip to content

Use cases/Financial services/AML alert triage

AI for AML alert triage in Australian banking

AML alert triage means each transaction monitoring alert reaches the analyst with the customer history, linked accounts and similar past alerts already pulled together, and a draft case note. For a suspicious matter report, the narrative is drafted in the fields AUSTRAC asks for. The analyst and the compliance officer decide whether to report.

Talk to our team →
Supports
AML analyst
Reads
Monitoring alerts, Customer history, Linked accounts, Past case notes
Runs on
Your servers, on premises
Connects to
NICE Actimize, LSEG World-Check, Chainalysis, FrankieOne
Decides
A person, every time

Architecture

Everything runs on your servers

We build it on an open-weight model such as Llama or Mistral, served with vLLM on NVIDIA GPUs inside your own environment. Case history is indexed in PostgreSQL with pgvector or Elasticsearch, alerts arrive over Kafka or from your monitoring system directly, and every draft is logged with the records it read.

  1. SourcesMonitoring alerts / Customer history / Linked accounts / Past case notes
  2. Your serversPull customer history → Find similar alerts → Draft the case note
  3. ReviewAML analyst
  4. OutputOne case summary per alert / Similar past alerts / Draft case note / SMR narrative in AUSTRAC fields

It takes four jobs off the AML analyst

  1. 01

    One case summary per alert

    The customer profile, linked accounts and related transactions are pulled from separate systems into one view. The analyst starts with the facts instead of a search.

  2. 02

    Similar past alerts

    Earlier alerts with a similar pattern are found, with how each was closed and why. The analyst sees the precedent beside the new alert.

  3. 03

    Draft case note

    A case note is drafted from the records, with each statement linked to the transaction or document behind it. The analyst edits it and records the decision.

  4. 04

    SMR narrative in AUSTRAC fields

    When a case goes to a report, the narrative is drafted from the case file in the fields AUSTRAC asks for. The compliance officer decides whether to report and lodges it.

It goes live in five steps

  1. Step 01

    Collect closed alerts and case notes

    Past alerts with their case notes, outcomes and any reports lodged. This is the test set, and access to it is restricted to the people who already have it.

  2. Step 02

    Map the systems an analyst opens

    We sit with the analysts and list every system they open for an alert. Each one becomes a source the case summary reads.

  3. Step 03

    Test against closed alerts

    The system builds summaries for alerts that already have an outcome. Analysts compare the summary with what they pulled by hand and mark what was missing.

  4. Step 04

    Run in shadow

    Analysts work alerts as usual while the summaries are built beside them. Nothing reaches the case record until an analyst accepts it.

  5. Step 05

    Analyst decides and the log records it

    The analyst closes, escalates or refers each alert. The compliance officer decides on reports, and the log records what the system read and drafted.

Software or a custom build

Your monitoring system keeps raising alerts, and a custom build does not replace it. NICE Actimize and the other monitoring products carry their own case management, and screening comes from LSEG World-Check, FrankieOne, Sumsub or Equifax IDMatrix. Use the case tools in your monitoring product first if your alert volume is low. A custom build earns its cost when the history sits in several systems, when case notes are written from scratch, or when case files cannot leave your environment.

NICE Actimize / LSEG World-Check / Chainalysis / FrankieOne / Sumsub / Equifax IDMatrix / GBG greenID / Salesforce

In practice

We build this on servers you own. The model, the case index and the logs sit inside your environment, and customer and transaction data is not sent to a public AI service. The retrieval pattern is covered in RAG on private infrastructure, and the build falls under AI agents and workflow automation.

The AUSTRAC guidance on suspicious matter reports sets the deadlines. A report goes in within 3 business days after the day the suspicion forms, or 24 hours where it relates to terrorism financing. A report that a system generates must name the person accountable for completing and submitting it, so the draft carries that name and a person lodges it.

An example engagement shows how we run a private model inside a bank network, with the source cited on every answer. How the output is checked is covered in LLM evaluation and observability. The wider picture for banking and payments and fintech has its own page.

Questions

What is AML alert triage?

It is the work an analyst does between an alert and a decision. The system pulls the customer history, linked accounts and similar past alerts into one summary and drafts the case note. The analyst closes or escalates the alert, and the compliance officer decides on reports.

Does the AI decide whether to lodge a suspicious matter report?

No. The analyst and the compliance officer form any suspicion and decide whether to report. The system drafts the narrative from the case file, and a named person completes and lodges the report with AUSTRAC.

Does this replace our transaction monitoring system?

No. Your monitoring system keeps raising alerts on the rules and scenarios you set. What we build reads each alert, pulls the history together and puts one case summary in front of the analyst.

How is tipping off kept under control?

Case files stay inside your environment and access follows the permissions staff already hold. Sharing the details of a report is a criminal offence if it could prejudice an investigation, so we restrict who can open report drafts and log every access.

Tell us where your hours go.

We map the work, size the hardware and price what is worth automating.

Talk to our team →