Banking AI agent · Fraud triage
Fraud-Alert Triage & Case-Assembly AI Agent
Gather the device, session, payee and pattern evidence behind a fraud alert, group related alerts into one case and order the queue — blocking, freezing and reporting stay with named fraud staff.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Block decision
- Fraud analyst
- After launch
- Agent Care
What this agent does
Orders the queue, hands over a case
In
- 01
Take alerts from card authorisation, payment monitoring, device and session signals, and credits arriving in the account.
- 02
Attach the customer's own pattern — how this account normally pays, from where, at what hour and to whom.
Reason
- 03
Set the payee against its history: first payment, recently opened, or already named in another alert on the book.
- 04
Read the device, session and channel signals — a new device, a changed number, a remote-access tool live.
- 05
Join the alerts that belong to one case, so a single takeover is not seven separate items in the queue.
Decide
- 06
Rank by exposure and by the time left to stop the money, and mark the payments the customer authorised themselves.
- 07
Route block, freeze, hold and reporting decisions to the named person who owns each.
Out
- 08
Hand the analyst a case — the signals that fired, the ones that did not, and what the customer's record shows.
- 09
Retain the alert, the evidence gathered, the rank, the analyst's decision and what the case turned out to be.
Product statement
The agent gathers, ranks and hands over. Calling a customer's activity fraud, blocking a card, freezing an account, holding a payment and any suspicious activity report stay with named bank staff.
Example workflow
One alert, end to end
- 1Alert raisedCard authorisation, payment monitoring, a device or session signal, or a credit arriving in the account
- 2Case assembledThe customer's own paying pattern, the device and session behind the request, and the payee's history
- 3Related alerts joinedAlerts on the same customer, device, payee or receiving account worked as one case rather than separately
- 4Queue orderedRanked on exposure, on the time left to stop the money, and on whether the customer made the payment themselves
No human action required
Stages 1 to 4 run before an analyst opens the queue — the evidence, the joining and the ranking finish first. Nothing in that stretch calls a customer a fraudster or restricts anything they hold.
Reaches the analyst at the top of the queue.
Held in the queue with nothing restricted.
Fraud analyst or financial-crime investigator
Reads the case, the signals that fired and the ones that did not, then decides what is restricted and owns anything said to the customer.
Investigate · Close · Refer
Decision recorded — handed back
- 6Analyst acts, agent recordsOnly what a named person authorised, for the stop they set, and written where access and policy allow
- 7Outcome evaluatedConfirmed fraud, alerts closed that came back as claims, restrictions a customer had reversed, and time to first action
Reversed restrictions
A block lifted after the customer called is counted as a failure.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Blocking a card, a wallet or a channel.
- Freezing, restricting or closing an account.
- Holding or cancelling a customer's payment.
- Deciding that a customer is committing fraud.
Automation boundary
Agent acts unaided
- ✓Gather the device, session and channel signals behind the alert.
- ✓Set the request against this customer's own paying pattern.
- ✓Check the payee's history and join the alerts that belong together.
- ✓Rank the queue on exposure and on the time left to act.
Write actions run only inside the approval boundaries agreed during implementation. No block or freeze is one of them.
- Filing or disclosing a suspicious activity report.
- Saying anything to a customer about a restriction.
- Raising a fraud marker against a customer.
- Changing alert rules, thresholds or ranking.
Example output
One alert on one payment, annotated
Everything the agent gathers is attached to the alert and the session it came from.
Triage case · single alert
Illustrative example- Alert source
- Payment monitoring, pre-send
- Payee
- First payment, new account
- Device
- Unrecognised
- Case type
- Authorised push payment
- Confidence
- 87%
- Restriction
- None applied by the agent
As received
The alert, the session it fired on and the payee as the instruction named them — nothing on this side is inferred.
Evidence used
- Payee first seen this week
- Remote-access tool live
- No match to prior pattern
Why it is ranked first
The customer sent this payment themselves, so their own device proves nothing.
What the score decides
Where the case sits in the queue and how fast an analyst opens it — not whether it is fraud.
Action
InvestigateCloseReferValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every alert raised
Cards, payments, sessions and credits
Read the account's own pattern
Set the alert against this account's own paying pattern, the device and session behind it, the payee's history and the alerts already open on the same customer.
Order the queue by the clock
Alerts are ranked on what can still be stopped and how long is left to stop it, so the analyst opens the case where an hour changes the outcome.
Hand over a case, not a score
The signals that fired, the ones that did not, the customer's own pattern and the payee history arrive together, so the decision starts from evidence.
Build an evidence trail
Retain the alert, the signals gathered, the rank it was given, the analyst's decision, what was restricted and what the case was later confirmed to be — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Fraud monitoring
- FICO Falcon
- NICE Actimize
- Feedzai
- Featurespace
- alert queues
Core & payment rails
- FIS
- Fiserv
- Jack Henry
- Temenos
- card and faster-payment feeds
Device & session signals
- Device ID
- behavioural biometrics
- Telephony signals
- channel logs
Agent
Fraud-alert triage
- Gathers the case
- Joins related alerts
- Orders the queue
Case, CRM & intelligence
- Case management
- CRM
- Fraud databases
- inter-bank feeds
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between an alert and a blocked card
Each control wraps the one inside it. An alert clears every layer before it reaches the queue, and the decision to restrict anything sits outside all six.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Decide whether a signal means anything
- L3
- Decides who may restrict an account
- L4 – L5
- Bound what is said and keep the record
- L6
- Pulls automation back when signals degrade
How Nestack evaluates it
Evaluate both errors — the fraud missed and the customer stopped.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the case the analyst opens
- E1Case-quality evaluationDid the case hold the evidence the analyst needed to decide?
- E2Step-level evaluationDid it read the right customer, payee, device and time window?
- E3Ranking evaluationDid the money that could still be stopped reach the top?
- E4Two-sided error ratesWhat was missed, and who was restricted without cause?
- E5Slice evaluationHow does performance change across specific alert cohorts?
- E6Business outcomeTime to first action, restrictions reversed, and alerts that returned as claims.
Floor — the money stopped, and the customer not cut off
Failure modes
Where each failure originates in the agent
Seven failure modes plotted against the five stages of the agent lifecycle.
Agent lifecycle
Direction of processing →
01 · Alert intake
2 modes
- FT-01
Inbound credit never watched
The receiving account is looked at after the funds have left.
- FT-02
Wages held as a mule signal
An unusual credit freezes a thin-file customer's only account.
Stage gathers
Card, payment, session and inbound-credit alerts
02 · Case assembly
2 modes
- FT-03
Own device, own credentials
The customer sent it themselves, so the session reads clean.
- FT-04
Case with no reasoning in it
The narrative never says what was ruled out, or why.
Stage assembles
Pattern, device, payee history and related alerts
03 · Ranking
1 mode
- FT-05
Ranked below the clock
A recoverable payment is worked after the money moved on.
Stage orders
The queue by exposure and the time left to act
04 · Handover / write
1 mode
- FT-06
Card blocked mid-shop
A false positive leaves a customer with no way to pay.
Stage hands
The case to an analyst, with nothing restricted
05 · Change / Version
1 mode
- FT-07
Threshold moved, queue changed
A rule change reorders the queue and nobody re-measures.
Stage tracks
Model, prompt, rule and threshold changes
- Sev-1 · a customer is cut off from money
- Sev-2 · money leaves while a case waits
- Sev-3 · the queue misleads the analyst
Affected slices
The hardest alerts are the ones the customer made themselves
A card alert on a well-used account is close to a pattern check. What defeats the queue is the payment the customer authorised themselves, and the credit into an account with no history behind it. Nestack reports by slice, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Authorised push payments | 6.6% | 4.1× | Review | |
| Inbound credits, possible mule | 4.2% | 2.6× | Review | |
| Newly onboarded customers | 3.1% | 1.9× | Watch | |
| Routine card spend at home | 1.3% | 0.8× | Normal |
Bar: mis-triaged-alert lift vs. routine-card baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
The truth about an alert arrives weeks later, from the customer
A closed alert is not a correct one. What it was is settled by the claim that follows, the reversal a customer asks for, or the report another bank sends.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
A confirmed fraud, a late claim or a reversed restriction traces back to an alert this queue ordered.
- 02
Diagnose
Opened at the alert as it stood — the signals gathered, the pattern used, the payee history and the rank.
- 03
Improve
The signal set, the ranking or the case template is re-approved by the fraud lead and version-linked.
- 04
Verify
Re-run in both directions — the frauds confirmed later and the restrictions a customer had lifted.
- 05
Learn
The pattern nobody had seen is written into the case template, beside the customer stopped for nothing.
Learn → Detect
The return edge. Labels arrive late here, so each cycle re-scores alerts already closed against outcomes nobody had when they fired.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, alert and signal access, case assembly and ranking, evaluation, the analyst queue, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Alert discovery and automation-boundary definition.Week 1
- 02Fraud-monitoring and core-system assessment.Week 1, Week 2
- 03Alert taxonomy and case-template design.Week 1, Week 2
- 04Customer-pattern and payee-history retrieval.Week 2
- 05Device, session and channel signal joins.Week 2, Week 3
- 06Alert joining and duplicate-case rules.Week 3
- 07Queue ranking by exposure and time left.Week 3, Week 4
- 08Disclosure limits and case-note wording.Week 4
- 09Two-sided error and slice evaluation suite.Week 4, Week 5
- 10Analyst handover and restriction routing.Week 5
- 11Case-management and queue integration.Week 5, Week 6
- 12Observability, deployment and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne alert type, one queue | ProductionProduction queue integration | AdvancedMulti-entity / round-the-clock |
|---|---|---|---|
| Introduced at Pilot | |||
| Case assembled from your own signals | ✓ | ✓ | ✓ |
| Related alerts joined and the queue ranked | ✓ | ✓ | ✓ |
| Named-analyst gate on any restriction | ✓ | ✓ | ✓ |
| Case notes bounded by disclosure rules | ✓ | ✓ | ✓ |
| Audit trail of alerts, ranks and decisions | ✓ | ✓ | ✓ |
| Baseline evaluation | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Additional alert sources and channels | — | ✓ | ✓ |
| Case-management and queue integration | — | ✓ | ✓ |
| Observability and evaluation | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-entity and multi-brand controls | — | — | ✓ |
| High volume and round-the-clock cover | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on the alert sources and channels in scope, fraud-monitoring and core integrations, signal availability, alert volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01The alerts you get today, and who works them
→Alert discovery and automation-boundary definition
Week 102What your analysts need in front of them to decide
→Alert taxonomy and case-template design
Week 103Access to fraud-monitoring, core and payment systems
→Fraud-monitoring and core-system assessment, then integration
Week 204The device, session and channel signals you already keep
→Customer-pattern, payee-history and signal joins
Week 205The scams you saw last year, including the ones you missed
→Evaluation suite, slices and regression cases
Week 406What may be said to a customer, and what may not
→Disclosure limits and case-note wording rules
Week 407Named analysts, and who may block a card or freeze an account
→Handover, restriction routing, then supervised queues
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy. Week 5 replays alerts you have already closed, so no live customer is restricted on the agent's ranking.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1The alerts in scope, who works them and who may restrict
W2Monitoring, core and payment access, and the signals you keep
W3Pattern, payee and device joins, and alert grouping
W4Queue ranking, disclosure limits and the evaluation suite
W5Alerts replayed against last year's outcomes, nothing restricted
W6Analysts work the live queue under review, then handover
- Reading the band
- Disclosure limits and the ranking evaluation finish in week 4, before an analyst works a live case from this queue in week 5. The bars show that order, not a smooth ramp.
- At the end of W6
- Analysts have worked live cases from the agent's queue, and every restriction later reversed has been counted, then Agent Care takes over monitoring.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Banking AI agent
Build a triage agent around the alerts your analysts already work.
Show us a month of fraud alerts, what each one turned out to be and who is allowed to block a card. We'll replay that month against your own outcomes and give you both numbers — the confirmed frauds this queue would still have reached too late, and the customers it would have stopped for nothing.
- Typical delivery
- 4–6 weeks
- Deployment
- Your fraud and core stack
- Block decision
- Named fraud analyst
- After launch
- Agent Care available
Nestack Agents · Fraud-alert triage
AGT-BK-03 · Agent Care available after launch