AI for fraud review: working the alert queue without losing the analyst

Most conversations about AI and fraud start with the model that spots the fraud. That is the wrong end of the problem for almost every bank we speak to. Between a rules engine, a scoring model and a vendor feed you already generate more alerts than your team can work. The pain is downstream. An analyst opens an alert, then spends twenty minutes pulling transaction history from one system, device data from another, KYC records from a third and prior case history from the case manager. Only then does the thinking start, and it usually takes two minutes.

That ratio is the opportunity. The useful work for AI agents in fraud is case assembly, evidence gathering, narrative drafting and disposition support, so analysts spend their time deciding rather than fetching. It applies equally to card fraud, payments fraud, application fraud and AML alert review, because all four share a shape: an automated trigger, a manual investigation, a documented outcome, and a regulator who may ask about it years later.

The queue is the problem, not the model

Ask a fraud operations lead what keeps them up and you will rarely hear "our detection rate". You will hear about backlog, alerts ageing past service levels, analysts leaving because the job is data entry with occasional adrenaline, and false positive volume nobody can reduce because tightening a threshold means accepting risk nobody will sign off.

The shape varies by product, but most alerts close with no action and the cost of that majority is analyst hours rather than losses. An agent that cuts handling time on the alerts that close as nothing, while leaving genuine cases fully human, changes your unit economics without changing your risk appetite. That is a better first pitch than promising fewer alerts.

Case assembly and evidence gathering

The first agent to build packs the case file. When an alert lands, it works a defined evidence checklist for that alert type and gathers everything an analyst would gather by hand.

For a card fraud alert, that means the disputed authorisation, surrounding transaction history, prior history with that merchant, the cardholder's usual geography and spend pattern, device indicators, recent credential changes and open cases on related cards. For an application fraud alert, it means the application data, identity verification responses, velocity checks, links to other applications sharing an address, phone or bank account, and prior declined attempts. For an AML alert, it means the transaction chain either side of the trigger, counterparty details, the expected activity profile captured at onboarding, screening results, and the disposition and rationale of every prior alert on that customer.

The output is a single case pack with every item sourced. Not a summary saying "the customer has prior alerts", but a line stating that three prior alerts exist, citing their case numbers and how each was dispositioned. Provenance is what makes the pack usable as evidence, and it is what an examiner will test.

Getting the plumbing right

Most of the build effort goes here, into read access and rate limits across core banking, the card processor, case management and the screening vendor, not into anything clever in the model layer. Where a system is unavailable, the pack must say so rather than present an incomplete picture.

Drafting the analyst narrative

Once the evidence is assembled, the agent drafts the narrative an analyst would otherwise write from scratch: what triggered the alert, what the customer's normal behaviour looks like, how the flagged activity differs, and what corroborating or exculpating evidence the file holds.

The draft follows your house template and terminology, because a narrative that reads differently from the rest of your case files creates its own review problem. It states facts and cites them. It flags what it could not establish. It does not reach a conclusion, because in a well built process the narrative and the decision are separate artefacts with separate approvals. Analysts edit these drafts, and what they change tells you where the agent is weak more precisely than any offline benchmark.

Disposition recommendation with visible reasoning

The agent can propose a disposition: close as false positive, escalate to a senior analyst, refer for SAR consideration, block the card, decline the application. What matters is that the recommendation arrives with its reasoning in a form a human can check in seconds: the evidence for it, the evidence against it, the typology the case maps to, and how similar cases were dispositioned historically. A recommendation an analyst has to reverse engineer is worse than none, because it invites rubber stamping.

Keep the human as the decision maker in the system of record, not just in policy documents. The disposition field should only ever be written by an authenticated human action, with agent output stored separately as a recommendation and the human's acceptance or override recorded against it. Then measure override rate by alert type. That number tells you where the agent has earned trust.

SAR and escalation preparation

For AML, the agent prepares the suspicious activity report package: structured fields, the activity summary drawn from the case pack, the transaction schedule, subject and counterparty details, supporting documents. A human investigator reviews, edits, decides whether to file, and files.

Filing decisions carry personal and institutional liability, and the value the agent adds is the two hours of assembly and formatting, not the judgement. The same holds for escalations, law enforcement referrals and customer exit recommendations. Prepare everything, decide nothing.

Triage and feedback into the alert rules

Two further jobs sit either side of the queue. The first is triage: ordering work by case age, exposure at risk, regulatory clock and how strong the assembled evidence looks, so the alerts most likely to matter reach an analyst first rather than in arrival order.

The second is feedback. Because the agent structures the evidence and the human disposition for every case, you can see which rules and score bands produce nothing but noise, which produce confirmed fraud, and which alerts analysts close repeatedly for the same reason. That is valuable input to threshold tuning, and it should stay an input to a governed review rather than an automatic adjustment.

The audit trail an examiner will accept

Build the record to be read by someone hostile and unfamiliar.

Every case should carry a durable log of which systems the agent queried and when, what each returned, which agent version produced each artefact, what it recommended and on what basis, who reviewed it, what they changed and what they decided. Versions matter: if you cannot say which configuration produced a narrative eighteen months ago, you cannot defend that case. Retain the recommendation even when the human overrode it, because override history is your best evidence of effective human control.

Rehearse the examiner question. Show me a case, show me who decided it, show me what they saw. If that takes more than a minute, the controls are not real.

Model risk and governance

In a regulated bank, an agent in the alert workflow will attract model risk attention even though it is not scoring risk. Involve model risk management, compliance and internal audit while you are designing, not once you have built.

Practically, that means documenting intended use and limitations, defining what the agent must never do, ongoing performance monitoring rather than a one time validation, change control for prompts, tools and models, and a fallback so the queue keeps moving manually when the agent is unavailable. Case files hold some of the most sensitive data in the bank, and tipping off rules constrain what can be exposed and to whom.

Evaluating before you trust it

Do not run a pilot on impressions. Build the evaluation before the agent.

Take a sample of historically dispositioned alerts, several hundred at minimum and stratified across alert types, and run the agent blind against them. Measure evidence completeness against your checklist, factual accuracy of every cited claim, agreement with the human disposition, and above all the direction of disagreement. An agent that recommends closing cases your analysts escalated is far more serious than one that escalates cases they closed.

Then run it live in shadow mode, with the agent's output recorded but hidden from analysts. Only then put it in front of the queue, starting with the alert types where it performed best, in draft mode with every output reviewed. Watch handling time, override rate, quality assurance results and analyst feedback together.

Where AI fails here

Agents are poor at genuine novelty. A typology the institution has not seen, an emerging scam pattern, a case where the evidence is technically clean but something about the story is wrong, these are exactly where an agent will confidently recommend closure. Experienced investigators catch them on instinct, and no amount of case history teaches that reliably. Keep a sampling regime that puts human eyes on cases the agent wanted to close.

Agents also inherit your history. If past dispositions were inconsistent, or certain customer segments were escalated more readily for reasons that will not survive scrutiny, an agent prompted on that history reproduces the pattern at higher volume. Test for disparate treatment explicitly. Consistency is only a virtue once the thing made consistent is defensible.

Threshold feedback is harder than it sounds. Using agent assisted dispositions to tune the rules that generate alerts creates a loop that can quietly narrow what you detect. Keep threshold changes on a human governed cadence with model risk oversight, and validate against holdout data rather than the agent's own outputs.

Finally, an agent will not fix a broken queue. If alerts are poorly specified or nobody agrees what a disposition code means, faster processing gives you the same confusion sooner. That cleanup is a prerequisite, not a phase two.

Where to start

Pick one alert type with high volume and a high false positive rate, where the investigation steps are documented and the outcome is low controversy. Card fraud alerts on established customers, or a noisy AML scenario, are usually the right first ground. Build the evidence pack agent and stop there for a while: assembly alone removes most of the drudgery and carries almost none of the governance weight. Add narrative drafting once analysts trust the packs, and disposition recommendations last, only where you can show the evaluation numbers to your second line.

Adopt AI Partners builds these agents inside the client's own systems and stays until the fraud team owns them. Success is not that the agent works. It is that your analysts trust it, your second line signs it off, and both handling time and quality assurance results move the right way.