Banks run monitoring systems that raise alerts when account activity looks unusual. Most alerts turn out to be harmless. Analysts still have to review each one, decide what it means, and write up their findings. At large volumes, this review is slow and costly, so banks look to AI to help sort alerts and check write-ups.
AI learns from past reviews. Good AML alert annotation means labeling what happened to each alert, and why, the same way every time. This post explains what the work covers, why it is hard, and what finance and banking AI training data needs to get right.
Annotation for alert reviews usually has four parts:
Models trained on these labels can rank alerts for review, suggest closure reasons, and check write-ups for gaps. This is the basis of alert outcome labeling.
Past reviews were written by many analysts under time pressure.
Annotators need written rules for each of these. Without them, two people label the same case differently, and the model learns the disagreement.
The outcome list is the heart of the project. It should follow the bank’s own review process, not a generic list. A strong scheme separates the stages: closed at first review, closed after deeper review, and escalated for further action.
Each outcome needs a definition and examples. The guide should also say which record decides the label, such as the final case status or the analyst’s last note. If a case was reopened, the rule should say whether the first or last outcome counts. Where the record does not say, annotators should mark “outcome unclear” instead of guessing.
These two labeling jobs look related but ask different questions.
Alert outcome labeling asks what the decision was. The answer is usually one label from a fixed list, and reviewers check it against the case record. Narrative labeling asks how well the decision was explained. The answer covers completeness, clarity, and whether each claim is backed by evidence, and reviewers need judgment, not just a record check.
A single guide for both would blur these differences. Each needs its own examples and its own reviewers.
A good narrative tells a reader who was involved, what the activity was, why it drew attention, what the analyst checked, and why the case ended as it did. Annotators can label each of these elements as present, partly present, or missing.
Useful labels include:
The aim is to teach a model what a complete write-up looks like, so it can point out gaps for a human reviewer. The model should support the analyst, not replace the decision.
Alert records contain names, account details, and amounts, so decide early what is masked, who may view raw cases, and how access is logged. Labels should record case elements only as far as the task needs.
Some cases will stay unclear even after review. Give annotators clear options, such as “insufficient information” or “needs expert review,” and keep these cases in a separate group. Forcing a label on them teaches the model false confidence on the cases that most need human attention.
Review practices change. Rules are updated, new patterns appear, and teams change how they write cases. A label that was right last year may not fit this year’s process. Each batch should record the guideline version and the period of the cases, and reviewers should compare labels across teams, not only within one. Calibration rounds, where everyone labels the same sample and compares, help keep the team aligned.
Alert reviews often draw on customer history, past complaints, and earlier contacts. Matching them depends on clear, consistent case labels, which we explain in our guide to bank complaint and dispute classification, where categories and root causes need the same careful separation.
People who have worked in financial crime review read these cases differently. They know what a complete write-up looks like, how alerts are usually closed, and which details an experienced reviewer would expect to see. They can tell a thin narrative from a thorough one, and a reasoned closure from a rushed one.
Specialists write the outcome definitions, set the narrative scale, and review doubtful cases. This reflects Globik AI’s approach of using verified domain experts for work that depends on judgment, where a generalist would be guessing.
Before starting an alert review project, settle these points:
An alert review is a decision and an explanation, and both need honest labels. Strong AML alert annotation uses clear outcome definitions, separates the decision from the quality of its write-up, gives annotators a way to flag unclear cases, and relies on reviewers who know how investigations work. With that foundation, models can help analysts spend their time on the cases that matter.
It is the labeling of past alert reviews by outcome, reason, and write-up quality so AI can help sort and check new alerts. Annotators follow written rules built with financial crime experts.
It is assigning each alert a label that shows how the review ended, such as closed, closed with a reason, or escalated. The label list should follow the bank’s own review stages.
It is judging whether an analyst’s write-up is complete, clear, and supported by evidence. Annotators label each element as present, partly present, or missing so models can point out gaps.
Mark them as insufficient information or send them for expert review instead of guessing. Keeping them in a separate group stops false confidence from entering the training data.
Specialists know what a complete write-up looks like and how alerts are normally closed. They write clear definitions and review doubtful cases.
