Main site

Insurance AI agent · Financial crime

KYC / AML Screening AI Assistant

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.

Typical delivery
4–6 weeks
Deployment
Your stack
Alert decisions
Analyst only
After launch
Agent Care

What this agent does

Assembles the alert, decides nothing

In

  1. 01

    Take the party as presented — applicant, insured, beneficiary, payee or entity, with its identifiers and documents.

  2. 02

    Pull the sources in force at that moment — sanctions, PEP, adverse media, ownership — and stamp each version.

Reason

  1. 03

    Match names across scripts, transliterations, patronymics and shared components, and keep the near-misses.

  2. 04

    Resolve the entity behind the entity — ownership chains, aggregated holdings, and the registry record each step rests on.

  3. 05

    Assemble the alert: which entry matched, on which fields, and what the customer record does and does not confirm.

Decide

  1. 06

    Nothing matched on any source at its current version: the party continues, and the negative result is kept.

  2. 07

    Anything matched, weakly or strongly, goes to a qualified compliance analyst with the evidence, undisposed.

Out

  1. 08

    Hand over an evidence pack — the entry, the fields matched, the ownership path, and every source with its version.

  2. 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

  1. 1Party receivedAn applicant, insured, beneficiary, payee or entity, with the identifiers and documents on file
  2. 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
  3. 3Names and entities matchedAcross scripts, transliterations and name structures, with ownership chains resolved to whoever actually stands behind
  4. 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

  1. 6Analyst disposition recordedThe analyst's own decision and reasons, recorded under their name with the source versions they were read against
  2. 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 required

8 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 boundary

    Agent 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 alert

Illustrative example
Party
Corporate claim payee
Screened at
Before payment release
Sources read
Current, stamped
Alert
Ownership, not name
Confidence
88%
Disposition
None — analyst's

As received

The payee as presented at release, and each source at the version in force at that moment, with the time it was read.

Match evidence

  • Registry chain, two steps
  • Holdings aggregate
  • Name itself does not match

Why it is open

The name is clean. Two holdings behind it aggregate past the threshold today.

What the score decides

How the alert is queued and how hard it is read. It clears nobody and is never shown.

Action

ClearEscalateAsk for more

Value

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 party and payment

From 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.

04

Build 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 & claims

    • Guidewire
    • Duck Creek
    • Sapiens
    • Majesco
    • Broker and MGA platforms

  • Screening data

    • OFAC and UK OFSI
    • EU consolidated
    • PEP data
    • adverse-media sources

  • Identity & ownership

    • Document checks
    • identity data
    • Corporate registries
    • ownership chains

Agent

KYC & AML screening

  • Screens parties
  • Resolves ownership
  • Assembles evidence

  • Case management & payments

    • Alert and case queues
    • MLRO escalation
    • Payment release
    • payee and bank files

  • 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 the model and a disposition

Each control wraps the one inside it. An alert clears every layer before an analyst opens it, and the disposition itself sits outside all six.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Change controlSource, threshold and rule changes are versioned, tested and reversible.Re-approve
L5Disclosure controlNothing about a hit or an escalation can reach customer-facing text.Seal
L4Analyst gateA qualified analyst disposes; the MLRO owns escalation and reporting.Gate
L3No-disposition ruleNo clearing, no suspicion, no report, no risk rating.Withhold
L2Match evidenceNo hit is raised or set aside without the fields it turned on.Cite
L1Source currencyEvery check runs against the version in force at that moment.Pin
Model coreAlert — the entry that matched, the fields it turned on, the ownership path and match confidence
L1 – L2
Decide whether the alert may stand
L3
Keeps a disposition out of the agent
L4
Puts the decision with a qualified analyst
L5 – L6
Keep it confidential, keep coverage honest

How Nestack evaluates it

Evaluate what was raised — and what was never raised at all.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the alert an analyst opens

  1. E1Final-output evaluationDid it raise every hit a seeded true-hit set contains?
  2. E2Match evaluationDoes matching hold up across scripts, spellings and name structures?
  3. E3Tool evaluationDid it read the current version, and screen the right party?
  4. E4Ownership evaluationDid the chain resolve to the party that actually stands behind?
  5. E5Slice evaluationHow does performance change across name cohorts and screening points?
  6. E6Business outcomeAnalyst burden per alert, and whether the packs hold up on review.

Floor — the true hit that was never raised

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 →

  1. 01 · Source pull

    1 mode

    • KY-01

      Screened on a stale version

      The list moved between the check and the release.

    Stage pins

    The sanctions, PEP and media versions in force

  2. 02 · Name matching

    2 modes

    • KY-02

      Transliteration never matched

      The same name in another script reaches nothing.

    • KY-03

      Shared-component flood

      Volume rises until the queue closes by shape.

    Stage matches

    Names across scripts, spellings and structures

  3. 03 · Ownership

    1 mode

    • KY-04

      Ownership lands on a namesake

      The chain resolves to a different firm, same name.

    Stage resolves

    The parties actually standing behind an entity

  4. 04 · Alert & handover

    2 modes

    • KY-05

      Thin entry read as noise

      A real match set aside because the entry held little.

    • KY-06

      The hit reaches the customer

      Servicing text explains why the payment stopped.

    Stage assembles

    The evidence pack an analyst opens, and its gaps

  5. 05 · Config / Version

    1 mode

    • KY-07

      Coverage narrows unnoticed

      A rule change drops a source or a field nobody misses.

    Stage tracks

    Threshold, source and rule changes to screening

  • Sev-1 · a real hit passes, or a hit is disclosed
  • Sev-2 · the analyst is handed a weaker case
  • Sev-3 · noise rises and the analyst absorbs it
See the complete Insurance failure-mode catalogue

Affected slices

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 aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Non-Latin script names6.8%3.8×Review
Transliterated and patronymic names4.7%2.6×Review
Thin list entries3.3%1.8×Watch
Latin-script individual names1.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 threshold

2 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 stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Recall, false-positive burden or source currency moves in one cohort.

  2. 02

    Diagnose

    Traced to the version pulled, the match rule, the chain or the pack.

  3. 03

    Improve

    The rule, threshold or source is changed, re-approved by the MLRO and version-linked.

  4. 04

    Verify

    Re-run against seeded true hits and every alert an analyst reopened.

  5. 05

    Learn

    The missed match becomes a seeded case the matcher must keep catching.

  6. Learn → Detect

    The 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.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Workflow discovery and automation-boundary definition.Week 1
  2. 02Screening scope and payment points.Week 1, Week 2
  3. 03Policy-admin, claims and case APIs.Week 1, Week 2
  4. 04Source versioning and update monitoring.Week 2
  5. 05Name matching across scripts and structures.Week 2, Week 3
  6. 06Ownership resolution and registry sourcing.Week 3
  7. 07Alert assembly and the evidence-pack format.Week 3, Week 4
  8. 08Confidentiality and tipping-off controls.Week 4
  9. 09Analyst triage workflow and MLRO escalation.Week 4
  10. 10Seeded true-hit and false-positive evaluation.Week 4, Week 5
  11. 11Screening at the payment point, and case handover.Week 5, Week 6
  12. 12Deployment, documentation 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 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 price
Confirmed 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 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.

  1. 01The parties and payment points you screen today

    Workflow discovery and automation-boundary definition

    Week 1

  2. 02Your list sources, licences and update arrangements

    Source versioning and update monitoring

    Week 2

  3. 03Access to policy admin, claims and case management

    Screening at onboarding, at change and before release

    Week 2

  4. 04The scripts and name structures your book actually holds

    Name matching across scripts and name structures

    Week 3

  5. 05Your registry and beneficial-ownership sources

    Ownership resolution to the party that stands behind

    Week 3

  6. 06Alerts you closed wrongly, in both directions

    Seeded true-hit set, regression cases and failure-mode testing

    Week 4

  7. 07Your MLRO, the escalation policy and the disclosure rules

    Analyst triage, escalation routing and tipping-off controls

    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. Nothing reaches an analyst's live queue before week 6 — the matcher runs in shadow first.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Parties, payment points and who disposes an alert

W2List sourcing, versioning and update monitoring

W3Name matching, ownership resolution and the evidence pack

W4Seeded true-hit evaluation, cohort slices and failure-mode testing

W5Shadow screening on your own book, and the analyst queue

W6Analysts dispose live alerts from agent evidence, then handover

Reading the band
Bars 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 W6
Analysts have disposed live alerts from agent evidence packs, and every clear, escalation and report in that period was a person's.
Duration
Six-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.

Typical delivery
4–6 weeks
Deployment
Your onboarding and payment stack
Alert decisions
A compliance analyst, always
After launch
Agent Care available

Nestack Agents · KYC & AML screening

AGT-INS-03 · Agent Care available after launch

Build a screening assistant

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your setup

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.