Banking AI agent · Sanctions
Sanctions-Alert Adjudication-Support AI Agent
Assemble what a screening hit turns on — the matched list entry, the message as sent, the customer record and the ownership position — with clearing, holding and release left to a sanctions analyst.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Clearing a hit
- Named analyst
- After launch
- Agent Care
What this agent does
Explains the match, clears nothing
In
- 01
Take the hits your screening raised — payment, customer and batch rescreen — with the list entry each one matched.
- 02
Attach the payment message as sent, and the bank's own record for the party that message names.
Reason
- 03
Set out which elements matched: name, spelling and script, birth date where the entry carries one, address, identifier.
- 04
Pull the history of the same match — what was found last time, and what has changed on the entry since.
- 05
Where the party is an entity, assemble the ownership and control position from the registers in scope.
Decide
- 06
Order the queue on the strength of the match and the deadline behind it, and mark what could not be settled.
- 07
Route clearance, hold, release and report decisions to the named person who owns each.
Out
- 08
Hand the analyst a pack — the entry, the elements, the message, the record and what is still unresolved.
- 09
Retain the hit, the evidence gathered, the rank, the analyst's decision and the reasons they gave for it.
Product statement
The agent assembles and orders. Clearing a hit, confirming a match, holding, releasing, rejecting or returning a payment, and reporting a match to any authority stay with named bank staff.
Example workflow
One screening hit, end to end
- 1Hit receivedA payment, a customer record or a batch rescreen against the lists in scope
- 2Match set outWhich entry matched, on which elements, and how the list spells the name against the message
- 3Record and history pulledThe bank's own file for the named party, and what the same match returned when it was last worked
- 4Ownership position assembledWhere the party is an entity, who owns and controls it in the registers in scope, and where the chain stopped
No human action required
Stages 1 to 4 run before an analyst opens the queue — the entry, the message, the record and the ownership position are assembled first. Nothing in that stretch clears a hit, confirms a match or moves a payment either way.
Reaches the analyst at the top of the queue.
Waits in the queue, exactly as screening left it.
Sanctions analyst or sanctions officer
Reads the pack, decides whether the hit is a match, and owns the hold, the release, the report and anything said to the customer.
Investigate · Escalate · Refer
Disposition recorded — handed back
- 6Analyst decides, agent recordsOnly what a named person decided, with the reasons they gave, written where access and policy allow
- 7Outcome evaluatedHits a second reviewer reopened, payments released late, time to disposition and the reporting deadlines met
Reopened hits
A hit discounted that a later review reversed is counted as a failure.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Clearing a hit or discounting a match.
- Confirming that a party is a listed person.
- Releasing a payment that is held or blocked.
- Holding, blocking or returning a payment.
Automation boundary
Agent acts unaided
- ✓Set out which entry matched, and on which elements.
- ✓Show the message as sent beside the bank's own record.
- ✓Assemble the ownership position and the earlier hits on this entry.
- ✓Rank the queue on match strength and the deadline running.
Write actions run only inside the approval boundaries agreed during implementation. Neither clearance nor release is one.
- Reporting a match to any authority.
- Telling a customer why a payment stopped.
- Deciding an entity is owned or controlled.
- Changing lists, matching rules or ranking.
Example output
One hit on one payment, annotated
Everything the agent assembles is attached to the hit and the message it came from.
Screening hit · single payment
Illustrative example- Hit source
- Payment screening, pre-release
- Matched on
- Name and country only
- Message field
- Ordering customer
- Elements aligned
- Two of five compared
- Confidence
- 72%
- Disposition
- None taken by the agent
As received
The hit, the entry as the list publishes it and the message as the sender wrote it — nothing on this side is inferred.
Evidence used
- Two spellings of one name
- Entry carries no birth date
- Ownership chain unresolved
Why it is ranked first
No birth date on the entry, so two spellings and a country are the whole overlap.
What the score decides
Where the hit sits in the queue and how soon an analyst opens it — not whether it is a match.
Action
InvestigateEscalateReferValue
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 hit screening raises
Payments, customers and batch rescreens
Show what the match rests on
Which entry matched and on which elements, how the list spells the name against the message, what the same match returned before, and who owns the party where it is an entity.
Work the hits holding money first
Hits are ordered on the strength of the match and on the payment sitting behind them, so the ones stranding somebody's money reach an analyst first.
Name what could not be established
The identifiers the entry does not carry, the spelling that differs, the ownership layer that did not resolve — written into the pack rather than left to be noticed.
Build an evidence trail
Retain the hit, the entry version it matched, the evidence assembled, the rank, the analyst's decision and the reasons they gave — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Screening & filtering
- Fircosoft
- Bridger Insight
- Actimize
- Oracle Watchlist
- hit queues
Lists & list feeds
- OFAC SDN
- UK OFSI
- EU consolidated
- UN
- list-distribution feeds
Payments & core
- Swift MT and ISO 20022
- FIS
- Fiserv
- Temenos
- repair queues
Agent
Sanctions-alert adjudication
- Sets out the match
- Assembles the record
- Orders the queue
Customer & ownership data
- KYC records
- corporate registries
- Ownership sources
- case management
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers around a hit the agent cannot clear
Each control wraps the one inside it. The agent does not screen — it works the hits screening produced — and no hit leaves these layers cleared, held or released.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Show what the match actually rests on
- L3
- Decides who may clear or release
- L4 – L5
- Set what may be said and what is kept
- L6
- Pulls automation back when signals degrade
How Nestack evaluates it
Evaluate what the analyst was not told — not only what the pack contained.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the pack the analyst opens
- E1Pack-quality evaluationDid the pack hold what the analyst needed to decide the hit?
- E2Match-anatomy evaluationWere the elements that matched, and those that did not, set out correctly?
- E3Retrieval evaluationDid it read the right entry version, message fields and customer record?
- E4Ownership evaluationWhere the chain stopped, was that stated rather than assumed?
- E5Slice evaluationHow does performance change across specific hit cohorts?
- E6Business outcomeTime to disposition, payments released late, and hits reopened on review.
Floor — the match not dressed as ordinary, and the payment not stranded
Failure modes
Where each failure originates in the agent
Seven failure modes plotted against the five stages of the agent lifecycle. Screening itself sits upstream of all five — the agent works the hits it produced, so nothing here claims a miss was caught.
Agent lifecycle
Direction of processing →
01 · Hit intake
1 mode
- SN-01
Message never reached the pack
The screening extract is shown, not the wire as it was sent.
Stage gathers
Payment, customer and batch-rescreen hits
02 · Match anatomy
2 modes
- SN-02
One name, two transliterations
List spelling and message spelling read as two parties.
- SN-03
No birth date to separate them
A common name meets an entry that carries no identifiers.
Stage sets
Which entry matched, and on which elements
03 · Record & ownership
2 modes
- SN-04
Ownership stops at the named party
An unlisted company majority-owned by a listed one reads clean.
- SN-05
Last disposition reused
The entry gained aliases since the same match was worked.
Stage assembles
The customer file, prior hits and ownership
04 · Queue / handover
1 mode
- SN-06
A pack that reads like a clearance
The summary invites agreement and the analyst's reasons go unwritten.
Stage hands
The pack to an analyst, with nothing cleared
05 · Change / Version
1 mode
- SN-07
List moved, ranking not re-tested
A designation round reorders the queue and nobody re-measures.
Stage tracks
List updates, matching rules and prompts
- Sev-1 · a true match is made to look ordinary
- Sev-2 · a payment strands on a weak match
- Sev-3 · the analyst decides on a partial pack
Affected slices
The same person, spelled two ways
An exact hit on a domestic customer is close to a records check — one spelling, one file. What comes back unresolved is the name that crossed scripts on the way in, and the company nobody listed. 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 |
|---|---|---|---|---|
| Transliterated and romanised names | 6.4% | 4.6× | Review | |
| Ownership and control hits | 3.9% | 2.8× | Review | |
| Cover payments, truncated fields | 2.7% | 1.9× | Watch | |
| Exact hits, domestic customers | 1.1% | 0.8× | Normal |
Bar: under-evidenced-hit lift vs. exact-hit baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
Nothing later proves a discounted hit was right
So the second pair of eyes is the evidence — the assurance sample, the entry amended after the fact, and the examiner who reads the same pack cold.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Reopened hits, assurance findings or late list amendments concentrate in one hit cohort.
- 02
Diagnose
Read back against the entry as it stood that day — the elements compared, the message fields used, the register consulted.
- 03
Improve
The comparison set, the ownership rule or the pack template is re-approved by the sanctions officer and version-linked.
- 04
Verify
Re-assembled over hits already disposed of, including the ones a second reviewer disagreed with.
- 05
Learn
The spelling that defeated the comparison is kept as a case, and the cohort it came from is re-tested before release.
Learn → Detect
The return edge. Lists are amended after the fact, so each cycle re-reads hits the last one disposed of against entries that have changed since.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, screening and list access, match evidence and ownership, evaluation, the analyst queue, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Hit-queue discovery and boundary definition.Week 1
- 02Screening access and list-feed versioning.Week 1, Week 2
- 03Hit taxonomy and pack-template design.Week 1, Week 2
- 04Payment-message and customer-record retrieval.Week 2
- 05Match-anatomy and element comparison.Week 2, Week 3
- 06Ownership and control assembly rules.Week 3
- 07Prior-hit history and re-alert handling.Week 3, Week 4
- 08Held-payment deadlines and queue ordering.Week 4
- 09Pack wording and what may be said of a stop.Week 4
- 10Reopened-hit and assurance evaluation.Week 4, Week 5
- 11Second-reviewer assurance and case handover.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 list set, one hit queue | ProductionProduction queue integration | AdvancedMulti-entity / round-the-clock |
|---|---|---|---|
| Introduced at Pilot | |||
| Match anatomy, message and record in one pack | ✓ | ✓ | ✓ |
| Ownership position and prior-hit history | ✓ | ✓ | ✓ |
| Queue ranked on match strength and deadline | ✓ | ✓ | ✓ |
| Named-analyst gate on clearing and release | ✓ | ✓ | ✓ |
| Pack wording bounded by disclosure limits | ✓ | ✓ | ✓ |
| Audit trail and baseline evaluation | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Additional lists, channels and message types | — | ✓ | ✓ |
| Case-management and queue integration | — | ✓ | ✓ |
| Observability and evaluation | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-entity and multi-jurisdiction 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 lists and channels in scope, screening and core integrations, message formats, hit 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
01A quarter of hits, with the disposition each one ended at
→Hit-queue discovery and boundary definition
Week 102Your list feeds, and how fast a designation reaches them
→Screening access and list-feed versioning
Week 203The payment message as your systems store it, field by field
→Payment-message and customer-record retrieval
Week 204The depth your policy expects, and the registers you licence
→Ownership and control assembly rules
Week 305A stopped payment, and the deadline that ran while it sat
→Held-payment deadlines and queue ordering
Week 406The wording an officer permits when a payment is stopped
→Pack wording and what may be said of a stop
Week 407The hits a second reviewer reopened, and what assurance saw
→Assurance-sample evaluation, then second-reviewer handover
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 hits your analysts have already disposed of, so nothing live waits on the ranking.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1The hits in scope, who works them and who may clear one
W2Screening access, list feeds and how a designation lands
W3Match anatomy, record retrieval and ownership assembly
W4Held-payment deadlines, pack wording and the evaluation suite
W5Hits replayed against dispositions you have already made
W6Second-reviewer assurance on live hits, then handover
- Reading the band
- Ownership assembly and the pack template finish before evaluation starts, because a pack that changes mid-test cannot be measured. The bars show that dependency, not a smooth ramp.
- At the end of W6
- Live hits have been worked from the agent's queue under a second reviewer, the entries amended since disposition have been re-read, and 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 an evidence agent around the lists you already screen against.
Show us a month of screening hits, how each one was disposed of and who is allowed to clear one. We'll rebuild that month and mark two things on every hit — the elements the pack could not establish, and the spellings and ownership layers a discounted hit was resting on.
- Typical delivery
- 4–6 weeks
- Deployment
- Your screening and core stack
- Clearing a hit
- Named sanctions analyst
- After launch
- Agent Care available
Nestack Agents · Sanctions-alert adjudication
AGT-BK-09 · Agent Care available after launch