Transaction monitoring alert triage: a checklist for your first ninety days
Most new analysts are taught the system before they are taught the sequence. The result is hours spent reading customer records with no idea what question they are answering. This note sets out the triage order I teach in the first ninety days, and how to write a closure rationale that survives the next review cycle.
The sequence matters more than the system
Every induction I have sat through in about twenty years has front-loaded the tooling. Here is the case manager, here is where you click to disposition, here is the narrative box. Two weeks of that and a new analyst can navigate the screens perfectly while still having no method for deciding what an alert is actually asking.
So I want to start somewhere else. Not with the software, but with the order of operations. In the teams I have run, the analysts who improve fastest are the ones who follow a fixed sequence for the first few months, even when it feels slow. The sequence buys you two things: it stops you from wandering, and it makes your work legible to whoever reviews it.
The order is short. Read the alert. Commit to a test in one sentence. Then, and only then, open the customer record. Verify. Write the rationale so that it answers the question you posed, not the questions you happened to stumble across.
Read the alert before you open the customer
This is the discipline most new analysts skip, and it is the one that costs the most time.
An alert is the output of a rule. Somebody defined a pattern — a value band, a velocity, a counterparty geography, a deviation from a modelled expectation — and the engine found activity matching it. Before you look at anything else, you should be able to say in plain words what the rule noticed. Not what it means. What it noticed.
If you cannot articulate that, you are not ready to look at the customer, because you will read the customer record looking for something interesting rather than something relevant. And customer records are full of interesting. Someone has three addresses across two countries. Someone's occupation field says "consultant" with no further detail. Someone opened an account eleven days before the alerted activity. None of that is an answer to a question you have not yet asked.
Practically, that means spending three or four minutes on the alert itself. Which rule fired, and what is its stated logic. What the alerted transactions were: amounts, dates, direction, channel, counterparties. Whether the alert covers a single event or an aggregation across a period. Whether this rule has fired on this customer before, and what happened last time.
That last one is worth its own paragraph. A repeat alert on the same rule and the same customer is a different piece of work from a first-time alert. If the pattern was reviewed and understood three months ago and nothing has changed, your job is largely to confirm continuity and note it clearly. If something has changed — the volumes have doubled, the counterparties have shifted, the stated rationale no longer fits — that change is the whole story, and you should be building your review around it.
One sentence, then verify
Before opening the customer file, write down what you are going to test. One sentence. I ask juniors to type it into a scratch note or even the case narrative draft.
Something like: I am testing whether the twelve inbound payments totalling around forty-two thousand are consistent with the salary and rental income described at onboarding. Or: I am testing whether the third-party counterparty in this transfer has a documented relationship to the customer. Or, quite legitimately: I am testing whether the rule fired on activity that the customer's business model would predict, because the SIC code suggests high transaction volume is normal here.
The sentence does two jobs. It gives you a stopping condition, so you know when you are finished. And it forces you to hold the alert as arithmetic rather than as an implied accusation. The engine performed a calculation and the calculation crossed a line somebody drew. That is all that has happened so far. Nobody has done anything wrong, and your sentence should read like a question, not a charge.
Then you verify. Open the record, pull the KYC profile, look at the transaction history around the alerted period rather than only the alerted transactions themselves. I usually want a window of at least three months either side for a value-based alert, longer for anything behavioural. You are asking whether the alerted activity is continuous with the customer's established pattern, or a departure from it. Departures are not suspicious in themselves. People change jobs, sell cars, receive inheritances, start businesses. But a departure needs an explanation you can point to in the file, and if there isn't one there, you have found the thing worth taking further.
Closing a false positive so it stays closed
Here is where I see the most avoidable rework. An analyst does a competent review, reaches a sound conclusion, and then writes a rationale so thin that the same alert gets reworked from scratch six weeks later.
A closure rationale is a document written for a stranger. Assume the reader is a colleague on a different shift, an internal audit reviewer eighteen months from now, or a regulator with the file in front of them and no memory of the context. Nothing about the customer's history is obvious to that reader, and nothing you held in your head at the time survives unless you wrote it down.
What a durable rationale contains:
- The test you set. Restate it, in the same terms you drafted before you opened the file.
- What you looked at — named documents, date ranges, specific transaction references, systems consulted. "Reviewed KYC" is not evidence of anything; "reviewed the onboarding profile dated 14 March, the employer verification letter on file, and inbound credits from January to June" is.
- The finding, expressed as a match or mismatch against expected activity, with the numbers in it. This is the sentence that stops the rework, because it lets the next reader see immediately whether their alert is the same one or a new one. If you write that inbound credits averaged around three thousand eight hundred a month across six months and the alerted month was four thousand one hundred, the next analyst can tell in five seconds whether the pattern has moved.
- What you did not resolve. Open questions belong in the file, not in your head.
Avoid the phrases that carry no information. "No adverse findings." "Activity appears consistent with profile." "Nothing further identified." I have read thousands of these and they tell me only that someone clicked a button. If the activity is consistent with the profile, say which parts of the profile and how you know.
Case note
A payments firm I supported had a rule firing monthly on the same small-business customer — a wholesale food distributor — for aggregate outbound volume. The alert had been opened and closed eleven times across fourteen months. Each closure said some version of "volumes consistent with trading activity, no concerns". Nobody had recorded what the expected volumes were.
When a new analyst took the twelfth alert and actually built the baseline, the picture changed. Monthly outbound had run between about eighty thousand and ninety-five thousand from the previous January through to the following March. From April it stepped to roughly one hundred and forty thousand, and by August it was over two hundred and ten thousand, with the growth concentrated in payments to four newly added counterparties in a jurisdiction the customer had never previously traded with. None of the earlier reviews were wrong on their own terms. But because none had written down a number, the drift was invisible eleven times over. The case went to enhanced review, the relationship manager obtained updated trading documentation, and the file ended up in a materially better place. It cost about nine hours of analyst time that could have been ninety minutes spread over the previous year.
Timeboxing, and knowing when to stop digging
Give yourself a budget before you start. For a routine value-band alert on a well-documented retail customer, I would expect twenty to thirty minutes end to end once you are past your first few weeks. For a behavioural alert on a business customer with complex counterparty flows, ninety minutes or more is reasonable.
The point of the budget is not speed. It is the checkpoint. When you hit the number, stop and ask one question: do I lack information, or do I lack authority?
If you lack information that you can obtain — a document that exists in another system, a note from the relationship manager, a payment reference you have not yet pulled — carry on. Reset the clock and keep going.
If you lack information that only the customer can provide, or you have found something your grade does not cover, escalate. New analysts tend to interpret escalation as failure and keep digging in the hope of resolving it themselves. That is the wrong instinct, and it is the one I spend the most time correcting. Escalation is a routing decision, not a verdict on your competence. An analyst who escalates a case at ninety minutes with a clear summary of what is known and what is missing has done better work than one who spends four hours arriving at the same place with a tired narrative.
Escalate when the alerted activity has no explanation you can locate in the file. When you find a pattern the rule did not catch but which now concerns you. When there is a possible sanctions or PEP nexus, which usually sits with a specialist function. When the file shows signs of having been reviewed superficially several times before. And when your own reading of the case has shifted and you cannot articulate why — that instinct is worth surfacing rather than suppressing.
The three alert types most often mishandled
Structuring-style alerts
Rules that look for a series of transactions sitting just under a reporting or reference threshold. New analysts either treat any sub-threshold cluster as inherently damning, or dismiss it because "the amounts are small". Both are wrong. The question is whether the amounts show deliberate shaping — repeated values very close to a line, unusual granularity, timing that spreads activity across days or branches without commercial logic. Note also that the relevant thresholds and the reporting duties attached to them differ substantially between jurisdictions, so check what applies to the entity you are working for rather than importing a figure you read somewhere.
Round-amount and rapid-movement alerts
Funds arriving and leaving quickly, often in round numbers. Frequently benign: people move money between their own accounts, settle invoices, fund investments. What matters is whether the account is functioning as a destination or as a corridor, and whether the onward destination bears any relationship to the documented purpose of the account. A round amount on its own tells you almost nothing.
Third-party and unrelated-counterparty alerts
The trap here is stopping at "the counterparty has a different surname". Different surnames are extremely common and prove nothing. The real question is whether there is any documented basis in the file for the relationship, and whether the pattern of third-party involvement is occasional or systematic. A single payment from a friend is not the same shape of thing as an account receiving credits from fifteen unconnected individuals each month.
Building the habit
None of this is complicated. It is a sequence, a sentence, a verification and a rationale a stranger can read. What makes it hard is that the sequence feels slower than diving into the record, and for the first fortnight it genuinely is.
Then it stops being slower, because you stop reading things you do not need. By month three the good analysts on my teams were closing routine alerts in half the time of month one, with rationales twice as useful. That is not talent. It is order of operations.
The point here: An alert is arithmetic, and your job is to state the test, do the test, and write it down so nobody has to do it again.