Use case · Financial crime compliance
Open each alert with the investigation already underway.
AI agents do the gathering that fills most of an analyst's day: KYC records, transaction history, counterparty links and adverse media. Each alert arrives with a cited evidence pack and a draft rationale. Analysts decide the disposition, and suspicious activity reporting stays with your MLRO.
For heads of financial crime and MLROs at banks, fintechs and payment firms running rules-based transaction monitoring.
The queue
Monday morning in a level 1 investigations team.
Overnight, the monitoring system raised another batch of alerts: a burst of inbound payments, a round-number transfer abroad, a dormant account waking up. The rule that fired knows nothing about the customer behind it.
So the analyst starts collecting. The onboarding file sits in one system, the risk rating in another, a year of transactions in a third. Counterparties are searched one by one, and every partial adverse media match has to be read. Only then does the judgement begin.
The alerts that matter look identical in the queue to the ones that don't, and QA keeps finding rationales that say "in line with profile" without saying which profile.
Sample output
What an analyst receives with each alert.
Illustrative, with invented data. Each line links to a source record; what the agent could not confirm is marked.
Rule triggered: R-214, rapid movement of funds (inbound followed by outbound within 48 hours)Customer C-58213: sole trader, catering, onboarded 2023, risk rating medium, declared monthly turnover £8,000–£12,000Transaction pattern: 14 inbound transfers from 9 remitters over 6 days totalling £41,300; £39,800 sent onward to 2 accountsCounterparty link: beneficiary account B-7702 also received funds from 3 other customers alerted in the last 90 daysAdverse media: one partial name match in a 2024 local news article about a licensing disputePrior alerts: one closed in 2025 as seasonal event catering income, with invoices on fileDraft rationale: activity materially exceeds declared profile and shares a beneficiary with other alerted customers. Suggest escalation to level 2.The agent's working method
How an alert becomes a reviewable case.
The agents follow your written investigation procedure and log every source they touch.
Conceptual flow, not a live system or measured result.
Collect the customer picture
When an alert is created, an agent reads the rule that fired and the transactions in scope. It then pulls the customer's KYC file, risk rating, expected activity, previous alerts and their dispositions, and any relationship managers' notes your procedure allows. Each fact is stored with the system, record identifier and timestamp it came from. Where data is missing or contradicts itself, such as an outdated occupation or a closed business address, the gap is noted in the pack rather than filled in.
Trace money and names
Next the agent analyses twelve months of account activity against the customer's declared profile, identifies the counterparties involved and checks whether they appear in other alerts, cases or internal watchlists. It runs names through the screening and adverse media providers you already subscribe to and assesses each hit against date of birth, location and role. Matches it cannot resolve are presented as unresolved. The output is a network view: which accounts connect, how much moved, and when.
Draft, cite, hand over
The agent writes a draft rationale in the structure your QA team expects, with every sentence linked to a source. It suggests close, escalate or request information, and explains which facts drove the suggestion and which would change it. The analyst reviews the pack, edits the rationale and records the disposition in your case management system. Escalated cases carry the full pack forward, so a level 2 investigator or the MLRO starts from evidence, not from a blank screen.
Decision rights
The judgements that never leave your people.
These are fixed in the design, not settings that configuration can relax later.
Analysts record every disposition
A named analyst closes or escalates each alert in your case management system. The agent's recommendation is stored separately, so any disagreement is visible and reportable.
Reporting decisions sit with the MLRO
The agent can assemble facts for a SAR or STR, but the decision to report and the filing itself remain with your MLRO or nominated officer. It has no access to filing portals.
Governed as a model
The agents are inventoried, validated and monitored under your model risk management framework, with independent review before any change to prompts, data sources or thresholds.
Replayable audit trail
Every query, source record, draft and edit is logged with time and user identity, so an auditor can replay how any evidence pack was built.
No customer contact
Agents never message customers about an alert. Requests for information are drafted for an authorised person to send, which guards against tipping-off.
What could go wrong
Failure modes we design against.
Supervisors will ask how each is controlled. The answers should exist before the pilot starts.
A regulator or auditor cannot follow how a recommendation was reached.
Recommendations are built from cited facts, not an opaque score, and documented under your model risk management policies, such as SR 11-7 in the US, to meet your regulator's expectations on explainability.
Customers are treated differently on grounds unrelated to risk, such as name origin or nationality.
Proxy attributes are excluded from recommendation logic where policy requires. Recommendation rates are compared across customer segments before launch and monthly afterwards.
Performance drifts as typologies, products or source data change.
Agreement with analyst decisions is tracked continuously; a sustained shift triggers review. Changes to prompts, models or feeds are validated like the original release.
Analysts accept drafts without real scrutiny.
QA samples agreed alerts as well as overturned ones, and analysts must explicitly edit or confirm the rationale before closing.
The agent states a fact that is not in any source.
Sentences without a source link are blocked from the pack, and quoted figures are checked automatically against the underlying records.
Phased introduction
Earning trust one phase at a time.
Exit criteria are agreed with compliance and model risk in advance. Moving on is a governance decision, not a date.
- Phase 1
Shadow mode
Agents build packs for live alerts while analysts work as today without seeing them. The two are compared afterwards.
Move on whenMLRO has reviewed agreement levels and disagreement reasons; sampled packs contain no uncited statements; validation complete.
- Phase 2
Assisted investigation
Analysts receive the pack and draft rationale with each alert and make every disposition themselves.
Move on whenQA results at or above the pre-pilot baseline; audit trail tested by internal audit.
- Phase 3
Partial auto-close with sampling
Alerts matching narrow low-risk false-positive patterns approved by the MLRO may close on the agent's recommendation, with random QA sampling.
Move on whenOngoing: sample findings stay within the MLRO's tolerance; any adverse finding returns the pattern to human disposition.
Wrong starting point
When other fixes should come first.
- Your monitoring rules fire on almost everything. Tuning the scenarios will cut noise more cheaply than investigating it faster.
- Customer data sits in systems with no reliable shared identifier. The agent will spend its effort reconciling records instead of investigating.
- No model risk framework or governance forum exists to approve an AI system. Build that first; supervisors will expect it.
- An experienced team already clears your alert volumes comfortably. Governance cost would outweigh the time saved.
Compliance and risk questions
What financial crime teams want to know.
Does the agent close alerts on its own?
Not in the first two phases. Analysts make every disposition. Later, your MLRO may approve auto-closure for specific, narrowly defined low-risk patterns, with random QA sampling and a way to revert immediately. You may decide never to enable it; the system is designed to be useful without it.
Where is customer data processed?
Inside your environment. We deploy into your cloud tenancy or data centre, in the region your data-residency obligations require, using model endpoints that do not retain or train on your data. Agents access source systems through service accounts with read-only permissions scoped to the alerts in question.
Which monitoring and case systems does it work with?
We connect through the APIs or database views of the platforms you already run, such as NICE Actimize, SAS, Oracle Financial Crime and Compliance Management, or in-house monitoring. Screening and adverse media come from your existing providers under your licences. The case management system remains the system of record.
How accurate are the recommendations?
We do not quote a figure in advance, because it depends on your rules, data and typologies. Shadow mode measures it on your own alerts: how often analysts agree, where they disagree and why. Those results, reviewed by your MLRO and model risk team, determine whether the pilot proceeds.
How do we explain this to our regulator?
With the documentation any model needs: purpose, data sources, limitations, validation results and monitoring. Because recommendations are built from cited facts, you can show a supervisor exactly which evidence supported any single alert decision. We help prepare that material; the conversation with your supervisor remains yours.
What determines cost?
Alert volume and complexity, the number of source systems to integrate, whether screening data must be re-queried per alert, and your hosting model. Validation and documentation are a real part of the effort, and we scope them explicitly rather than hiding them in the build.
Go deeper
The pieces behind this workflow.
What would you like to move forward?
Start with the outcome that feels closest. We'll help give the next step a useful shape.
One conversation. A clearer direction.
Tell us what you want to improve. A few sentences are enough to start.
shayan@coldai.orgLast reviewed 25 September 2026.