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.
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
AgentHuman
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.
5DecisionSplits on the strength of the match and the deadline running
Elements line up, and a deadline is running
Reaches the analyst at the top of the queue.
Thin overlap, or a match worked before
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 required8 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 boundaryAgent 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 paymentIllustrative example
Hit source
Matched on
Message field
Elements aligned
Confidence
Disposition
Payment screening, pre-release
Name and country only
Ordering customer
Two of five compared
72%
None taken by the agent
As receivedThe hit, the entry as the list publishes it and the message as the sender wrote it — nothing on this side is inferred.
Evidence usedTwo spellings of one nameEntry carries no birth dateOwnership chain unresolved
Why it is ranked firstNo birth date on the entry, so two spellings and a country are the whole overlap.
ActionInvestigateEscalateRefer
What the score decidesWhere the hit sits in the queue and how soon an analyst opens it — not whether it is a match.
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 hit screening raisesPayments, customers and batch rescreens
03Match & evidence
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.
01Approved path
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.
02Human review
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.
04Build 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.
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 defenceInward → L1 · closest to the model
L6Rollback / safe modeHand the queue back to unaided analysts if evaluations or production signals degrade.Roll back
L5TraceabilityRecord the hit, the entry version, the evidence, the rank and the reasons given.Record
L4Disclosure limitsWhat a pack may say, and what may reach a customer, is set in advance.Limit
L3Disposition gateNo hit is cleared and no payment moved without a named sanctions analyst.Gate
L2Identifier testWhere the entry carries no birth date or identifier, the pack says so.Test
L1Match anatomyWhich elements matched is set out, rather than reduced to one score.Set out
Model corePack assembled — the entry, the elements matched, the message, the record and the rank
L1 – L2Show what the match actually rests on
L3Decides who may clear or release
L4 – L5Set what may be said and what is kept
L6Pulls 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
Depth of coverage ▼
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 lifecycleDirection of processing →
01 · Hit intake1 mode
SN-01
Message never reached the pack
The screening extract is shown, not the wire as it was sent.
Stage gathersPayment, customer and batch-rescreen hits
02 · Match anatomy2 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 setsWhich entry matched, and on which elements
03 · Record & ownership2 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 assemblesThe customer file, prior hits and ownership
04 · Queue / handover1 mode
SN-06
A pack that reads like a clearance
The summary invites agreement and the analyst's reasons go unwritten.
Stage handsThe pack to an analyst, with nothing cleared
05 · Change / Version1 mode
SN-07
List moved, ranking not re-tested
A designation round reorders the queue and nobody re-measures.
Stage tracksList updates, matching rules and prompts
Sev-1 · a true match is made to look ordinarySev-2 · a payment strands on a weak matchSev-3 · the analyst decides on a partial pack
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 aggregateIllustrative 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 threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Reopened hits, assurance findings or late list amendments concentrate in one hit cohort.
02Diagnose
Read back against the entry as it stood that day — the elements compared, the message fields used, the register consulted.
03Improve
The comparison set, the ownership rule or the pack template is re-approved by the sanctions officer and version-linked.
04Verify
Re-assembled over hits already disposed of, including the ones a second reviewer disagreed with.
05Learn
The spelling that defeated the comparison is kept as a case, and the cohort it came from is re-tested before release.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Hit-queue discovery and boundary definition.
02Screening access and list-feed versioning.
03Hit taxonomy and pack-template design.
04Payment-message and customer-record retrieval.
05Match-anatomy and element comparison.
06Ownership and control assembly rules.
07Prior-hit history and re-alert handling.
08Held-payment deadlines and queue ordering.
09Pack wording and what may be said of a stop.
10Reopened-hit and assurance evaluation.
11Second-reviewer assurance and case handover.
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 list set, one hit queueProductionProduction queue integrationAdvancedMulti-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 priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed 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 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
01A quarter of hits, with the disposition each one ended at→Hit-queue discovery and boundary definitionWeek 1
02Your list feeds, and how fast a designation reaches them→Screening access and list-feed versioningWeek 2
03The payment message as your systems store it, field by field→Payment-message and customer-record retrievalWeek 2
04The depth your policy expects, and the registers you licence→Ownership and control assembly rulesWeek 3
05A stopped payment, and the deadline that ran while it sat→Held-payment deadlines and queue orderingWeek 4
06The wording an officer permits when a payment is stopped→Pack wording and what may be said of a stopWeek 4
07The hits a second reviewer reopened, and what assurance saw→Assurance-sample evaluation, then second-reviewer handoverWeeks 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 hits your analysts have already disposed of, so nothing live waits on the ranking.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1The hits in scope, who works them and who may clear oneW2Screening access, list feeds and how a designation landsW3Match anatomy, record retrieval and ownership assemblyW4Held-payment deadlines, pack wording and the evaluation suiteW5Hits replayed against dispositions you have already madeW6Second-reviewer assurance on live hits, then handover
Reading the bandOwnership 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 W6Live 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.
DurationSix-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.
