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.
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
AgentHuman
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.
5DecisionSplits on the evidence and the time left to act
Evidenced, and money can still be stopped
Reaches the analyst at the top of the queue.
Thin signal, or an ordinary pattern
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 required8 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 boundaryAgent 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 alertIllustrative example
Alert source
Payee
Device
Case type
Confidence
Restriction
Payment monitoring, pre-send
First payment, new account
Unrecognised
Authorised push payment
87%
None applied by the agent
As receivedThe alert, the session it fired on and the payee as the instruction named them — nothing on this side is inferred.
Evidence usedPayee first seen this weekRemote-access tool liveNo match to prior pattern
Why it is ranked firstThe customer sent this payment themselves, so their own device proves nothing.
ActionInvestigateCloseRefer
What the score decidesWhere the case sits in the queue and how fast an analyst opens it — not whether it is fraud.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every alert raisedCards, payments, sessions and credits
03Case & context
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.
01Approved path
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.
02Human review
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.
04Build 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.
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 defenceInward → L1 · closest to the model
L6Rollback / safe modeReturn the queue to unaided analysts if evaluations or production signals degrade.Roll back
L5TraceabilityRecord the alert, the signals gathered, the rank, the decision and the outcome.Record
L4Disclosure limitsWhat a case note may say, and what may not leave it, is set in advance.Limit
L3Restriction gateNo card, account or payment is restricted without a named fraud analyst.Gate
L2Authorisation testWhether the customer sent the payment themselves is established first.Test
L1Pattern baselineA signal is read against this customer's own history, and thin history is marked.Compare
Model coreCase assembled — the signals that fired, the customer's pattern, the payee history and the rank
L1 – L2Decide whether a signal means anything
L3Decides who may restrict an account
L4 – L5Bound what is said and keep the record
L6Pulls 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
Depth of coverage ▼
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 lifecycleDirection of processing →
01 · Alert intake2 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 gathersCard, payment, session and inbound-credit alerts
02 · Case assembly2 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 assemblesPattern, device, payee history and related alerts
03 · Ranking1 mode
FT-05
Ranked below the clock
A recoverable payment is worked after the money moved on.
Stage ordersThe queue by exposure and the time left to act
04 · Handover / write1 mode
FT-06
Card blocked mid-shop
A false positive leaves a customer with no way to pay.
Stage handsThe case to an analyst, with nothing restricted
05 · Change / Version1 mode
FT-07
Threshold moved, queue changed
A rule change reorders the queue and nobody re-measures.
Stage tracksModel, prompt, rule and threshold changes
Sev-1 · a customer is cut off from moneySev-2 · money leaves while a case waitsSev-3 · the queue misleads the analyst
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 aggregateIllustrative 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 threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
A confirmed fraud, a late claim or a reversed restriction traces back to an alert this queue ordered.
02Diagnose
Opened at the alert as it stood — the signals gathered, the pattern used, the payee history and the rank.
03Improve
The signal set, the ranking or the case template is re-approved by the fraud lead and version-linked.
04Verify
Re-run in both directions — the frauds confirmed later and the restrictions a customer had lifted.
05Learn
The pattern nobody had seen is written into the case template, beside the customer stopped for nothing.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Alert discovery and automation-boundary definition.
02Fraud-monitoring and core-system assessment.
03Alert taxonomy and case-template design.
04Customer-pattern and payee-history retrieval.
05Device, session and channel signal joins.
06Alert joining and duplicate-case rules.
07Queue ranking by exposure and time left.
08Disclosure limits and case-note wording.
09Two-sided error and slice evaluation suite.
10Analyst handover and restriction routing.
11Case-management and queue integration.
12Observability, deployment and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal 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 tierPilotOne alert type, one queueProductionProduction queue integrationAdvancedMulti-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 priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed 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 buildBuild 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 bringWe build with it
01The alerts you get today, and who works them→Alert discovery and automation-boundary definitionWeek 1
02What your analysts need in front of them to decide→Alert taxonomy and case-template designWeek 1
03Access to fraud-monitoring, core and payment systems→Fraud-monitoring and core-system assessment, then integrationWeek 2
04The device, session and channel signals you already keep→Customer-pattern, payee-history and signal joinsWeek 2
05The scams you saw last year, including the ones you missed→Evaluation suite, slices and regression casesWeek 4
06What may be said to a customer, and what may not→Disclosure limits and case-note wording rulesWeek 4
07Named analysts, and who may block a card or freeze an account→Handover, restriction routing, then supervised queuesWeeks 5–6
Nothing else is requiredDeployment, 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.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1The alerts in scope, who works them and who may restrictW2Monitoring, core and payment access, and the signals you keepW3Pattern, payee and device joins, and alert groupingW4Queue ranking, disclosure limits and the evaluation suiteW5Alerts replayed against last year's outcomes, nothing restrictedW6Analysts work the live queue under review, then handover
Reading the bandDisclosure 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 W6Analysts have worked live cases from the agent's queue, and every restriction later reversed has been counted, then Agent Care takes over monitoring.
DurationSix-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.
