Screen parties against sanctions, PEP and adverse-media sources at onboarding and again before payment, match names and assemble the evidence — an analyst decides, and nothing about a hit reaches the customer.
Take the party as presented — applicant, insured, beneficiary, payee or entity, with its identifiers and documents.
02
Pull the sources in force at that moment — sanctions, PEP, adverse media, ownership — and stamp each version.
Reason
03
Match names across scripts, transliterations, patronymics and shared components, and keep the near-misses.
04
Resolve the entity behind the entity — ownership chains, aggregated holdings, and the registry record each step rests on.
05
Assemble the alert: which entry matched, on which fields, and what the customer record does and does not confirm.
Decide
06
Nothing matched on any source at its current version: the party continues, and the negative result is kept.
07
Anything matched, weakly or strongly, goes to a qualified compliance analyst with the evidence, undisposed.
Out
08
Hand over an evidence pack — the entry, the fields matched, the ownership path, and every source with its version.
09
Retain the versions, the match logic, the analyst's own disposition and their reasons, on both paths.
→Product statement
The agent screens, matches and assembles evidence. Whether an alert is a false positive, an escalation, or a matter for the MLRO is a qualified compliance analyst's decision — and nothing about a hit, an escalation or a report is disclosed to the customer, on any tier and in any configuration.
Example workflow
One alert, end to end
AgentHuman
1Party receivedAn applicant, insured, beneficiary, payee or entity, with the identifiers and documents on file
2Sources pulled at their current versionSanctions, PEP, adverse-media and ownership sources as they stand at that moment, each stamped with its version and time
3Names and entities matchedAcross scripts, transliterations and name structures, with ownership chains resolved to whoever actually stands behind
4Evidence pack assembledThe entry that matched, the fields it turned on, and what the customer record confirms, contradicts or is silent about
No human action required
Stages 1 to 4 run without a person in the loop — the source pull, the matching, the ownership work and the evidence pack all finish before an analyst opens the alert. Nothing has been cleared, and nobody has been told anything.
5DecisionSplits on whether anything matched on any source
Nothing matched, on current sources
The party continues, and the versions are kept.
Anything matched, on any source
Goes to a compliance analyst, undisposed.
Qualified compliance analyst
Reads the entry and the customer record themselves and disposes the alert. Escalation to the MLRO, and any report, is theirs alone.
Clear · Escalate · Ask for more
Disposed — handed back▼
6Analyst disposition recordedThe analyst's own decision and reasons, recorded under their name with the source versions they were read against
7Outcome evaluatedRecall against seeded true hits, false-positive burden, match performance by script, source currency and pack completeness
Analyst changes
Every alert an analyst disposes against the match evidence is counted, in both directions.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Clearing a sanctions, PEP or adverse-media hit.
Deciding that any activity is suspicious.
Filing, or deciding to file, a suspicious report.
Telling a customer why a payment is held.
Automation boundaryAgent acts unaided
✓Pull each source at the version in force and stamp it.
✓Match names across scripts, transliterations and name structures.
✓Resolve ownership chains to the party that actually stands behind.
✓Assemble the alert evidence, and draw no conclusion from it.
Write actions run only inside the approval boundaries agreed during implementation. Blocking, rejecting, reporting, rating a customer and saying anything to them about a hit are not among them, on any tier, in any configuration.
Blocking, rejecting or releasing a payment on a hit.
Declining, exiting or de-risking a relationship.
Setting or changing a customer's risk rating.
Changing sources, thresholds or match rules.
Example output
One alert, annotated
Everything the agent marks is attached to the entry and the record field it matched on.
Screening output · single alertIllustrative example
Party
Screened at
Sources read
Alert
Confidence
Disposition
Corporate claim payee
Before payment release
Current, stamped
Ownership, not name
88%
None — analyst's
As receivedThe payee as presented at release, and each source at the version in force at that moment, with the time it was read.
Match evidenceRegistry chain, two stepsHoldings aggregateName itself does not match
Why it is openThe name is clean. Two holdings behind it aggregate past the threshold today.
ActionClearEscalateAsk for more
What the score decidesHow the alert is queued and how hard it is read. It clears nobody and is never shown.
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 party and paymentFrom onboarding, policy admin and claims
03Sources & versions
Screen against the sources as they stand now
Sanctions, PEP, adverse-media and ownership sources at the version in force at the moment of the check — read at screening time and stamped, because a payment authorised yesterday leaves today.
01Approved path
Clear the unambiguous, and record it
A party with nothing against it on any current source continues without an analyst opening it, and the negative result is kept with the versions it was read against.
02Human review
Put evidence in front of a person
Every hit and near-miss arrives as the entry, the fields it turned on and what the record does and does not confirm. It is not a finding, not a risk rating and not a recommendation to report.
04Build an evidence trail
Retain the source versions read, the match logic, the ownership path, the analyst's own disposition and their reasons — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Policy admin & claimsGuidewire · Duck Creek · Sapiens Majesco · Broker and MGA platforms
Screening dataOFAC and UK OFSI · EU consolidated PEP data · adverse-media sources
The misses sit where the names do not fit the matcher
A threshold tuned by country or name origin is a proxy for a protected characteristic, and the same name cohorts carry the misses and the false positives that leave customers waiting. 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
Non-Latin script names
6.8%
3.8×
Review
Transliterated and patronymic names
4.7%
2.6×
Review
Thin list entries
3.3%
1.8×
Watch
Latin-script individual names
1.5%
0.8×
Normal
Bar: missed-true-match lift vs. Latin-script individual-name baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
The name the matcher could not hold comes back
A true hit that was never raised is rarely a reasoning failure — it is usually a name the matcher could not hold, or a source that had already moved.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Recall, false-positive burden or source currency moves in one cohort.
02Diagnose
Traced to the version pulled, the match rule, the chain or the pack.
03Improve
The rule, threshold or source is changed, re-approved by the MLRO and version-linked.
04Verify
Re-run against seeded true hits and every alert an analyst reopened.
05Learn
The missed match becomes a seeded case the matcher must keep catching.
Learn → DetectThe return edge. Every cycle re-reads the configuration itself — a threshold or exclusion that narrowed coverage without a signature is put back where it was.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, source and version handling, matching and ownership, evaluation, analyst workflow, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Workflow discovery and automation-boundary definition.
02Screening scope and payment points.
03Policy-admin, claims and case APIs.
04Source versioning and update monitoring.
05Name matching across scripts and structures.
06Ownership resolution and registry sourcing.
07Alert assembly and the evidence-pack format.
08Confidentiality and tipping-off controls.
09Analyst triage workflow and MLRO escalation.
10Seeded true-hit and false-positive evaluation.
11Screening at the payment point, and case handover.
12Deployment, documentation 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 party type, shadow onlyProductionLive screening, one bookAdvancedMulti-entity / multi-jurisdiction
Introduced at Pilot
Sanctions and PEP name screening✓✓✓
Source version pinning and stamping✓✓✓
Match evidence and alert assembly✓✓✓
Shadow mode — screens, disposes nothing✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Adverse-media screening—✓✓
Beneficial-ownership resolution—✓✓
Screening before payment release—✓✓
Analyst triage and MLRO escalation—✓✓
Introduced at Advanced
Multi-jurisdiction source sets and scripts——✓
Enterprise controls and audit packs——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on the parties and payment points in scope, the list and registry sources you licence, policy-admin, claims and case-management integrations, screening volume, the scripts and languages covered, 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 parties and payment points you screen today→Workflow discovery and automation-boundary definitionWeek 1
02Your list sources, licences and update arrangements→Source versioning and update monitoringWeek 2
03Access to policy admin, claims and case management→Screening at onboarding, at change and before releaseWeek 2
04The scripts and name structures your book actually holds→Name matching across scripts and name structuresWeek 3
05Your registry and beneficial-ownership sources→Ownership resolution to the party that stands behindWeek 3
06Alerts you closed wrongly, in both directions→Seeded true-hit set, regression cases and failure-mode testingWeek 4
07Your MLRO, the escalation policy and the disclosure rules→Analyst triage, escalation routing and tipping-off controlsWeeks 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. Nothing reaches an analyst's live queue before week 6 — the matcher runs in shadow first.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Parties, payment points and who disposes an alertW2List sourcing, versioning and update monitoringW3Name matching, ownership resolution and the evidence packW4Seeded true-hit evaluation, cohort slices and failure-mode testingW5Shadow screening on your own book, and the analyst queueW6Analysts dispose live alerts from agent evidence, then handover
Reading the bandBars span only the weeks their work is named in. Shadow running in week 5 is real — the agent screens and nothing it raises is actioned.
At the end of W6Analysts have disposed live alerts from agent evidence packs, and every clear, escalation and report in that period was a person's.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Insurance AI agent
Screen the parties, and leave the decision where it belongs.
Show us where a party is screened today — at quote, at issue, at change of control and before a payment leaves — the sources you licence, and who disposes an alert. We'll assemble one alert the way an analyst would want it, agree what it may never conclude, and write down what may never be said to the customer.
