Sanctions & Denied-Party Screening AI Agent

What this agent does

Runs the screen, not the decision to clear

Ingesting the parties, goods description and routing from bills of lading, air waybills and supported TMS sources.

Normalising names, addresses and identifiers, including transliterated forms, so spelling alone cannot defeat a screen.

Reason

Screening every party, signatory and representative named on the movement against the lists you configure.

Recording the list version each result ran against, because a clearance is only as good as that version.

Re-screening at the events you define, since lists change without notice and a cleared party may have been listed since.

Decide

Stopping on a possible match and holding the movement — a hit is a stop and a review, never a weighted number.

Flagging ownership questions a name list cannot answer, since an owned entity can be unlisted.

Out

Assembling the review pack — the party, the candidate entry, the list version and the evidence — for the officer.

Executing write actions only inside the approval boundaries agreed during implementation.

→ Product statement

The agent screens and stops; a named compliance officer decides whether a hit clears and files what the fixed statutory clock requires.

Example workflow

One party, screened end to end

AgentHuman

1Parties receivedBill of lading, air waybill, booking or customs record

2Names normalisedLegal names, aliases, transliterations, addresses and identifiers, each with its source

3Lists screenedCandidate entries, list version, confidence

4Controls appliedConfigured regime and list rules, threshold checks, re-screening events and ownership flags

No human action required

Stages 1 to 4 run unaided and clear nothing — liability here attaches without knowledge or intent, so the clearing act stays with a person.

5DecisionBranches at the confidence threshold

High confidence

Goes to the named officer to decide.

Low confidence

Adds a second compliance read first.

Officer clearance

The movement is held with its candidate entries, the list version and the confidence.

No match · Confirm match · Escalate

Cleared — released by the officer▼

6Screening systems updatedOnly where write access and approval policy allow it

7Outcome evaluatedRecall on seeded cases, review load, clearance outcomes and what re-screening later caught

Overrides

Every override is attributed, reasoned and retained.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required8 items

Clearing a possible match against a list entry.

Releasing a movement the screening has stopped.

Filing a blocking or rejection report on the clock.

Deciding whether ownership crosses the threshold.

Automation boundaryAgent acts unaided

✓Screen every party and signatory named against.

✓Record the list version and the time each result ran against.

✓Stop the movement on a possible match and hold it for the officer.

✓Assemble the review pack — candidate entry, evidence and version.

Any write happens inside the boundaries agreed at implementation, never ahead of clearance.

Judging which regimes and lists apply to a route.

Accepting a counterparty's account of its owners.

Deciding what a confirmed hit means for a contract.

Changes to match thresholds or list configuration.

Example output

One screened party, annotated

Everything the agent reports is attached to the list version that produced it.

Screening output · single partyIllustrative example

Party

Candidate entry

List version

Source list

Confidence

Result

Consignee, third country

Name and address matched a listed entry at the configured threshold

v2026.08.14

Configured list set

88%

Possible match — stopped, not cleared

As receivedTaken from the configured lists and the party record — the agent has not decided that this is the same person.

Evidence in the pack Normalised name forms Address and identifiers List entry and version

Why this is a stopA possible match is a stop and a review — it is never weighed and let through.

ActionNo matchConfirm matchEscalate

What the score decidesBelow the configured threshold the pack picks up a second read before the officer sees it.

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 partyFrom the booking or shipment file

03Screening

Match against the configured lists

Draw on the lists each regime requires. The US blocks on ownership; the EU and UK also reach control, and the thresholds differ.

01Approved path

A hit stops, it does not score

A possible match stops the movement and opens a review, never a number that lets it move.

02Human review

Send review where liability sits

Possible matches, ownership questions and stale list versions are marked, so the officer's read starts where the exposure is.

04Build an evidence trail

The screening result, the list version behind it and the officer who cleared it stay on the party record.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

Sanctions and denied-party listsOFAC SDN & consolidated
EU, UK, UN and national lists

Screening servicesDescartes · Dow Jones Risk
LexisNexis · World-Check

Ownership dataOrbis · Bureau van Dijk
Dun & Bradstreet

Agent

Sanctions & denied-party screening

Reads the parties
Screens the lists
Stops on a hit

TMS and workflowMcLeod · MercuryGate
Revenova · Turvo

Observability & evaluationOpenTelemetry · 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 the clearance

Every layer wraps the next. What none of them catches is in the map below.

L6 · Outermost — last line of defenceInward → L1 · closest to the model

L6Rollback / safe modePull the agent back to list lookup when evaluation or production signals degrade.Roll back

L5Version monitoringTrack model, prompt, threshold and list-configuration changes.Track

L4TraceabilityRecord the list version, the evidence and the officer, and retain to the longest applicable regime.Record

L3Officer clearanceHold a hit for the named officer; it governs release, not whether the list itself reaches the owner.Gate

L2Policy guardrailsTest each result against the configured regimes and re-screening events; a stale list version returns it.Restrict

L1Match thresholdsNo regulator endorses a threshold; ours is recorded with its rationale, and what it raises goes to a person.Require review

Model coreScreen run — candidate entries, list version, evidence and confidence

L1 – L2Test whether a result may stand

L3Puts the clearing in an officer's hands

L4 – L5Hold the result and the list version behind it

L6Falls back to manual screening when signals degrade

How Nestack evaluates it

Evaluate the whole screening workflow — not only the final match decision.

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

Surface — the result the officer reads

Depth of coverage ▼

E1Final-output evaluationDid the screen raise the entries a known-listed party should raise?

E2Step-level evaluationDid the agent use the right lists, the right version and the right regimes?

E3Tool evaluationDid it read the correct party and write the correct movement record?

E4Confidence calibrationDo low-confidence results actually contain more confirmed matches?

E5Slice evaluationHow does recall change across specific party types?

E6Business outcomeHow many movements were stopped, and how many hits surfaced only later?

Floor — the liability the business carries

Failure modes

Where each failure originates in the agent

Seven failure modes, placed at the stage each one originates.

Agent lifecycleDirection of processing →

01 · Retrieval1 mode

BC-03

Clean screen, later listing

Nothing was on any list; the party is designated later.

Stage gathersParties, identifiers, list versions and regime rules

02 · Reasoning2 modes

BC-04

Ownership blindness

Aggregate indirect ownership blocks an entity on no list.

BC-06

Regime not configured

A list the route and the parties require is not among those run.

Stage proposesThe candidate entries, the list version and the confidence

03 · Tool / write2 modes

BC-02

Threshold tuned for quiet

Fuzzy matching narrowed until true matches stop surfacing.

BC-05

Re-screening not repeated

A party cleared once is never screened against a later list.

Stage writesOnly where write access and approval policy allow it

04 · Output1 mode

BC-01

Hit cleared without evidence

A possible match is dismissed with nothing recorded behind it.

Stage returnsThe result the officer reads and the decision made

05 · Change / Version1 mode

BC-07

Silent threshold regression

A model or rule change narrows what the screen will raise.

Stage tracksModel, prompt, threshold and list configuration

Sev-1 · released outside the boundary Sev-2 · a listed party clears the screen Sev-3 · list source degrades, screen holds

See the complete Transportation failure-mode catalogue →

Affected slices

Aggregate recall can hide one bad cohort

True matches are rare, and rarity is what makes a total useless: a screen can miss most of the hits in one cohort and still read as healthy overall. Nestack reports recall by party type.

Slice performance — reported separately, not only in aggregateIllustrative example

Slice	Failure rate	Lift	Status
Transliterated party names	9.7%	3.8×	Review
Indirect ownership chains	6.4%	2.5×	Review
Newly listed parties	3.6%	1.4×	Watch
Long-standing counterparties	1.8%	0.7×	Normal

Bar: missed-match-rate lift vs. long-standing-counterparty baseline · scale 0–4.0× · tick marks the 2.0× review threshold 2 of 4 slices over threshold

Evidence-linked improvement

Every cycle ends with a recall case

The loop shuts when the miss is a case in the suite, not when it has been explained. That suite is what the next party screened is measured against.

Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn

01Detect

Recall drops in one party cohort.

02Diagnose

The screening record — candidate entries, list version and evidence — is read back until one cause holds.

03Improve

Whatever changes ships against a version, with the screenings that prompted it attached.

04Verify

Nothing ships until the affected cases pass a second time.

05Learn

The suite grows by one case; so does the escalation list.

Learn → DetectThe return edge. The next screen is measured against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, lists, screening workflow, evaluation, integration, then production validation and handover.

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

01Screening workflow discovery and boundary definition.

02List, regime and data-source assessment.

03Regime, list-set and re-screening-event rule mapping.

04Party ingestion and name normalisation.

05Match logic and evidence binding.

06Threshold tuning and hit routing.

07Officer clearance workflow.

08TMS and screening-service integration.

09False-negative regression cases.

10Guardrails and clearance controls.

11Screening-trail instrumentation.

12Deployment, documentation and Agent Care handover.

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 entity, one list set ProductionProduction screening systems AdvancedMultiple entities / regimes

Introduced at Pilot

Screening to your list set✓✓✓

Officer clearance✓✓✓

Screening-recall baseline✓✓✓

Introduced at Production

Reporting by party type—✓✓

Clearance workflow in your systems—✓✓

Approved write-back—✓✓

List-service integration—✓✓

Introduced at Advanced

Multi-regime list rules——✓

Multi-stage compliance review——✓

High screening volume——✓

Multi-regime screening controls——✓

Build price From $5,000 From $8,000 Custom quote

Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction 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

01Your party records and screening touchpoints → Party ingestion and name normalisationWeek 1

02Representative screened movements → Match baseline, list binding and threshold configurationWeek 2

03Your list set and the regimes you screen under → Regime, list-set and re-screening-event rule mappingWeek 1

04Access to relevant APIs, feeds or exports → List, ownership and TMS assessment, then integration setupWeek 2

05Clearances you would not want given → Recall cases and the evaluation suiteWeek 4

06What must reach an officer before a hit is cleared → Threshold tuning, hit routing, guardrails and clearance controlsWeek 3

07Named compliance officers to clear held hits → Officer clearance workflow, then pilot and production validationWeeks 5–6

Nothing else is required Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

The bands follow real work rather than a plan, so evaluation and pilot genuinely share the fifth week.

Phase W1W2W3W4W5W6

Discovery W1

Build W2 – W3

Evaluate W4 – W5

Pilot & Launch W5 – W6

Week focus W1Screening workflow discovery, regime mapping and the automation boundary W2List and ownership-source integration and the match baseline W3Screening workflow, threshold logic and clearance controls W4Evaluation suite, recall cases and failure-mode testing W5TMS and screening-service integration, pilot parties and corrections W6One screening cycle run under compliance, then Agent Care handover

Reading the bandThe bars follow real work rather than a plan, which is why week 5 carries two kinds rather than padding.

At the end of W6Once the cycle validates, Agent Care owns the running agent.

DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Transportation AI agent

Build a sanctions-screening agent around your clearance chain.

Show us your list set, your regimes and who clears a hit. A clean screen is not a defence: parties get listed after the shipment moves, and only your record helps then.

Discuss this agent →

Nestack Agents · Sanctions & denied-party screeningAGT-TR-14 · Agent Care available after launch