A consumer and SME banking group operating across several European markets looked at its financial crime function and found familiar arithmetic. More than 95 percent of the alerts its monitoring produced were not fraudulent. Every one of them still had to be worked by a person, and working one meant checking four or more systems by hand: core banking, cards, the watchlist, the CRM. The reflex when a false-positive rate reads like that is to go back to the detection model and make it fire less often. The use case designed here leaves the threshold where it is. It puts an agent between the alert and the analyst.
The challenge
The two problems named in the pack are separate, and only one of them is a modelling problem.
The first is noise. At a rate above 95 percent, almost the entire alert queue is work that ends in nothing. The second is that data sits in silos, so an analyst cannot assess an alert without leaving the alerting system and assembling the picture manually from at least four others. That second cost is paid on every alert, including the 95 percent that are going nowhere. It is the multiplier that turns a tuning problem into a capacity problem.
Retuning attacks the first and leaves the second untouched. It also has a cost the pack states plainly in its own risk section: sophisticated fraudsters test model boundaries, structuring transactions just below the threshold. A threshold moved to suppress noise is a threshold that has been advertised. The design treats detection sensitivity as something to preserve and treats the investigation itself as the thing to automate.
The approach
The workflow has three steps: alert triggered, agent investigation, analyst decision. The agent sits in the middle and pre-investigates every alert before a human sees it.
Its job is evidence assembly. It constructs a network graph around the entity and runs graph-based anomaly detection over it, and it automatically retrieves beneficial ownership rather than waiting for an analyst to go and find it. What arrives on the analyst's screen is not an alert. It is a case: a risk score, the reasoning behind it, and a recommended action.
The worked example in the pack shows the shape of that output. Risk score 85 out of 100, classified High. The reasoning cites an entity connected to a known mule account through a shared device fingerprint, with a structuring pattern detected in the last 48 hours. Recommended action: freeze. The analyst still decides. The use case is filed as Level 3, augmented intelligence, on the deliverable's own autonomy ladder, and Level 3 means the human makes the call on every case.
The design also carries its own counter-argument, which is rarer than it should be in a pack like this. Under the heading of adversarial AI, it names the failure mode that this architecture invites: fraudsters probing model boundaries by structuring just below thresholds. Its mitigation is periodic random sampling of the transactions the model called safe. That is a deliberate budget line for looking at negatives, which is the population almost no monitoring programme funds and the only place a boundary-probing attacker leaves a trace.
The outcome
Two figures sit on the page as uplift tiles: a 40 percent reduction in false positives and a 60 percent improvement in investigation speed. Both are targets. The interface they accompany is labelled Simulated View. Nothing here has been measured in production, and the honest description of what was delivered is a use case design with two numbers attached to it as goals.
That distinction matters more now than it did back when this kind of work was called digital transformation. The older version of this project was a data integration programme: connect core banking, cards, the watchlist and the CRM so an analyst has one screen instead of four. That build pays off only when the last integration lands, and what it buys the analyst is navigation, not judgement. What changes now is that the retrieval, the graph construction and the write-up of the reasoning are themselves the automatable work. The agent does not need the four systems merged. It needs read access to them and a place to put what it found.
Read access is where the timeline collapses, and it is also where this design is harder than it looks on the slide. The four systems an analyst opens by hand do not hand back tidy fields. A watchlist hit is a name string with a scanned identity page sitting behind it. The ownership chain is registry extracts and shareholder registers filed as images. The CRM note explaining why the same entity alerted last quarter is a PDF somebody attached and nobody indexed. Computer vision is what turns that pile into evidence an agent can cite, and it is the whole distance between an agent that retrieves beneficial ownership and one that reads it. Wire the steps end to end and the three boxes on the workflow diagram stop describing a queue. The alert fires, the graph builds, the documents are read, the ownership chain resolves, the case assembles with its citations, and the disposition the analyst chose writes back to the place the next alert will read from. Those would be interconnected automated pipelines, and across a queue where more than 95 percent of the work ends in nothing, they would carry a real share of how the financial crime function runs while the freeze decision stays exactly where Level 3 put it.
That is also why the build horizon for a design like this is shorter than a pack written in transformation-programme language implies. Loop and harness engineering is nearly all of it. The loop is the part that pulls the alert, assembles the evidence, scores it, checks its own reasoning against what the case file actually supports, and comes back round. The harness is the part that fixes which systems it may read, under whose identity, what it may never do without a human, and what gets written down every time it acts. Neither is a research problem. Both are build work, and build work moves at the speed of an integration list, not the speed of a modelling programme. Agentic AI does the investigation. Autonomous AI belongs only where the deliverable already put it, in the volume work: freezing a card in milliseconds during an active attack, and the random sampling of transactions the model called safe, which is a loop that runs on its own once and forever rather than a rota nobody wants to staff.
The rest of the same deliverable shows where that leads, and it is disciplined about the ceiling. Its SME underwriting case runs at the same Level 3, with the agent drafting a risk memo and a human reviewing 100 percent of cases, and only moves to Level 4 with auto-approval restricted to low-risk exposures below 50 thousand euro and a 10 percent random sampling audit standing in for per-case review. Full automation is held further back still: 0 percent of decisions run at that level today, about 5 percent is the target a year out, and the work nominated for it is not credit judgement at all. It is high-volume, low-value micro-decisions: lending under 1 thousand euro, collections outreach, and blocking an address or freezing a card in milliseconds during an active attack. Three preconditions gate the whole tier, and not one of them is model accuracy: mature MLOps with real-time drift detection, regulatory sandbox approval, and a 99.9 percent data accuracy SLA. The pattern across all of it is that autonomy is granted to volume, not to consequence.
Three governance mechanisms in the pack transfer directly to a fraud build. The first is sampling what you did not look at, which appears twice in different clothes: random sampling of safe transactions in the fraud case, and the 10 percent audit sample in underwriting. Both exist because an agent that clears cases silently produces no evidence of its own errors unless you go and buy some. The second is shadow scoring, listed among the safeguards on the full-automation tier: a champion and challenger pair kept running in parallel so the deployed model is never the only opinion on record. That is also the only honest route to the two uplift numbers on this page, since running the agent's investigation alongside the analyst's and comparing dispositions is how a projection becomes a measurement. The third is the pack's treatment of the credit early-warning use case, which it classifies as high risk under the EU AI Act because it informs credit decisions, and then attaches three controls to: a human review threshold, full audit logging, and bias testing. A fraud agent recommending an account freeze is not the same regulatory object, but those three controls are what make its recommendation defensible when a customer disputes it.
The last thing an executive should take from this page today is what the pack does not claim. Agentic AI here changes coverage and cost of investigation, not detection accuracy. The 40 and 60 percent tiles are hypotheses about analyst throughput and queue noise, and only one of the two baselines they need actually exists on the page. The share of alerts that end in nothing is stated, at above 95 percent. The time from alert to disposition, which is the quantity the 60 percent tile is a claim about, is nowhere in the pack. The first job of any build against this design is to instrument both numbers before the agent goes anywhere near the queue, so that the targets stop being projections and start being a result.