Main site

Transportation AI agent · Sanctions screening

Sanctions & Denied-Party Screening AI Agent

Screen every party named on the movement against the lists you configure, keep the list version behind each result, and stop on a possible match — a named compliance officer decides what clears.

Typical delivery
4–6 weeks
Deployment
Your stack
Officer sign-off
Pre-clearance
After launch
Agent Care

What this agent does

Runs the screen, not the decision to clear

In

  1. 01

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

  2. 02

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

Reason

  1. 03

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

  2. 04

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

  3. 05

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

Decide

  1. 06

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

  2. 07

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

Out

  1. 08

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

  2. 09

    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

  1. 1Parties receivedBill of lading, air waybill, booking or customs record
  2. 2Names normalisedLegal names, aliases, transliterations, addresses and identifiers, each with its source
  3. 3Lists screenedCandidate entries, list version, confidence
  4. 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

  1. 6Screening systems updatedOnly where write access and approval policy allow it
  2. 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 required

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

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

Illustrative example
Party
Consignee, third country
Candidate entry
Name and address matched a listed entry at the configured threshold
List version
v2026.08.14
Source list
Configured list set
Confidence
88%
Result
Possible match — stopped, not cleared

As received

Taken 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 stop

A possible match is a stop and a review — it is never weighed and let through.

What the score decides

Below the configured threshold the pack picks up a second read before the officer sees it.

Action

No matchConfirm matchEscalate

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

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

04

Build 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 lists

    • OFAC SDN & consolidated
    • EU, UK, UN and national lists

  • Screening services

    • Descartes
    • Dow Jones Risk
    • LexisNexis
    • World-Check

  • Ownership data

    • Orbis
    • Bureau van Dijk
    • Dun & Bradstreet

Agent

Sanctions & denied-party screening

  • Reads the parties
  • Screens the lists
  • Stops on a hit

  • TMS and workflow

    • McLeod
    • MercuryGate
    • Revenova
    • Turvo

  • 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 the clearance

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

L6 · Outermost — last line of defence

Inward → 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 – L2
Test whether a result may stand
L3
Puts the clearing in an officer's hands
L4 – L5
Hold the result and the list version behind it
L6
Falls 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

  1. E1Final-output evaluationDid the screen raise the entries a known-listed party should raise?
  2. E2Step-level evaluationDid the agent use the right lists, the right version and the right regimes?
  3. E3Tool evaluationDid it read the correct party and write the correct movement record?
  4. E4Confidence calibrationDo low-confidence results actually contain more confirmed matches?
  5. E5Slice evaluationHow does recall change across specific party types?
  6. 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 lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • BC-03

      Clean screen, later listing

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

    Stage gathers

    Parties, identifiers, list versions and regime rules

  2. 02 · Reasoning

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

    The candidate entries, the list version and the confidence

  3. 03 · Tool / write

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

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • BC-01

      Hit cleared without evidence

      A possible match is dismissed with nothing recorded behind it.

    Stage returns

    The result the officer reads and the decision made

  5. 05 · Change / Version

    1 mode

    • BC-07

      Silent threshold regression

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

    Stage tracks

    Model, 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 aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Transliterated party names9.7%3.8×Review
Indirect ownership chains6.4%2.5×Review
Newly listed parties3.6%1.4×Watch
Long-standing counterparties1.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 stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Recall drops in one party cohort.

  2. 02

    Diagnose

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

  3. 03

    Improve

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

  4. 04

    Verify

    Nothing ships until the affected cases pass a second time.

  5. 05

    Learn

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

  6. Learn → Detect

    The 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

  1. 01Screening workflow discovery and boundary definition.Week 1
  2. 02List, regime and data-source assessment.Week 1, Week 2
  3. 03Regime, list-set and re-screening-event rule mapping.Week 1, Week 2
  4. 04Party ingestion and name normalisation.Week 2
  5. 05Match logic and evidence binding.Week 2, Week 3
  6. 06Threshold tuning and hit routing.Week 3
  7. 07Officer clearance workflow.Week 3, Week 4
  8. 08TMS and screening-service integration.Week 5
  9. 09False-negative regression cases.Week 4, Week 5
  10. 10Guardrails and clearance controls.Week 4
  11. 11Screening-trail instrumentation.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 entity, one list setProductionProduction screening systemsAdvancedMultiple 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 priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, transaction 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.

  1. 01Your party records and screening touchpoints

    Party ingestion and name normalisation

    Week 1

  2. 02Representative screened movements

    Match baseline, list binding and threshold configuration

    Week 2

  3. 03Your list set and the regimes you screen under

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

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    List, ownership and TMS assessment, then integration setup

    Week 2

  5. 05Clearances you would not want given

    Recall cases and the evaluation suite

    Week 4

  6. 06What must reach an officer before a hit is cleared

    Threshold tuning, hit routing, guardrails and clearance controls

    Week 3

  7. 07Named compliance officers to clear held hits

    Officer clearance workflow, then pilot and production validation

    Weeks 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

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – 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 band
The bars follow real work rather than a plan, which is why week 5 carries two kinds rather than padding.
At the end of W6
Once the cycle validates, Agent Care owns the running agent.
Duration
Six-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.

Typical delivery
4–6 weeks
Deployment
Your screening stack
Officer sign-off
Pre-clearance
After launch
Agent Care available

Nestack Agents · Sanctions & denied-party screening

AGT-TR-14 · Agent Care available after launch

Build a sanctions-screening agent

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

About you
Your screening

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