Home/Offers/Legal, Compliance & GovTech/Trade Compliance Screening API

Legal, Compliance & GovTech

Trade Compliance Screening API

Screening a counterparty is a list lookup until the lists disagree, the name is transliterated, and the owner is 49% sanctioned.

Trade compliance software
Freight forwarders and customs brokers
Manufacturers and exporters
ERP vendors
Marketplaces shipping cross-border

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Export control and sanctions compliance is unglamorous, unavoidable and done badly by most companies shipping internationally. The obligations are concrete — screen the parties, classify the goods, check the destination and end use, keep records — and the penalty for getting it wrong includes personal liability for individuals, not just corporate fines. Yet a great deal of it is still handled by someone pasting a name into a free web search tool once per shipment.

The screening problem is harder than list matching suggests. Names transliterate several ways, lists use different conventions, aliases and former names matter, and the restriction may attach not to the named counterparty but to an entity that owns part of it. Ownership-based rules mean a party absent from every list can still be restricted because of who controls it. And when thresholds and aggregation rules differ between regimes, the same shipment may be fine under one and prohibited under another.

Classification is a different kind of difficulty. Assigning a tariff code or an export control classification requires reading the goods against the schedule, and the schedule is a legal text with notes, exclusions and interpretive rulings. Software can shortlist candidates, surface the relevant notes and prior rulings, and explain the reasoning. It cannot assume responsibility for the declaration, because that responsibility is assigned by law to the filer and cannot be contracted away.

Who buys this

Trade compliance software, Freight forwarders and customs brokers, Manufacturers and exporters, ERP vendors, Marketplaces shipping cross-border

Category: Legal, Compliance & GovTech

What the API returns

What comes back

Screening results per party against the restricted-party lists in scope, with the matched record
Match basis and score, including which name variant or alias matched and how
Ownership-based restriction analysis using resolved ownership chains
Destination and end-use flags with the governing regime named
Candidate tariff and export control classifications, ranked with reasoning
Relevant schedule notes, exclusions and published rulings for each candidate
Licence requirement indicators per regime, destination and classification
Immutable screening record for every check, which is itself a compliance obligation

Endpoints

Method	Path	Returns
POST	/v1/screening/parties	Screen one or more parties against lists in scope
POST	/v1/screening/ownership	Ownership-based restriction analysis for a party
POST	/v1/classification/suggest	Candidate classifications with reasoning and citations
GET	/v1/classification/{code}/notes	Schedule notes, exclusions and rulings for a code
POST	/v1/shipments/assess	Combined party, destination, end-use and licence assessment
GET	/v1/lists	Lists in scope, their sources and last update time

Request and response

illustrative

Request

{
  "shipment_ref": "shp_71204",
  "parties": [
    { "role": "consignee", "name": "Kelmore Vostok OOO", "country": "KZ" },
    { "role": "end_user", "name": "R. Vasiliev", "country": "KZ" }
  ],
  "destination": "KZ",
  "goods": [
    { "description": "stainless steel pressure vessel, 40 bar, 2.5m3",
      "value": 61000, "currency": "EUR" }
  ],
  "regimes": ["EU", "US", "GB"],
  "resolve_ownership": true
}

Response

{
  "shipment_ref": "shp_71204",
  "screened_at": "2026-10-21T11:14:02Z",
  "party_results": [
    {
      "party": "Kelmore Vostok OOO",
      "direct_match": null,
      "ownership_restriction": {
        "status": "likely_restricted",
        "basis": "52% held via Kelmore Holdings BV by a listed person",
        "regime": "EU", "threshold_rule": "majority_ownership_or_control",
        "ownership_confidence": "medium",
        "trail_ends": 0
      }
    },
    { "party": "R. Vasiliev", "direct_match": null,
      "possible_matches": [ { "list": "EU_CFSP", "name": "Vasiliev, Roman",
                              "score": 0.78, "basis": "transliteration_variant",
                              "requires_human_review": true } ] }
  ],
  "classification_candidates": [
    { "code": "7311.00", "scheme": "HS", "confidence": 0.61,
      "reasoning": "Containers for compressed or liquefied gas, steel",
      "notes": ["Chapter 73 note 1 excludes vessels of heading 8419"] },
    { "code": "2B350", "scheme": "EU_dual_use", "confidence": 0.44,
      "reasoning": "Chemical manufacturing vessel thresholds may apply",
      "action": "verify pressure rating and corrosion resistance against control text" }
  ],
  "licence_indicators": [
    { "regime": "EU", "indicator": "licence_may_be_required",
      "reason": "possible dual-use control + destination risk" }
  ],
  "responsibility_note": "Classification candidates are assistance only. The filer determines and declares the classification."
}

Where the data comes from

Official restricted-party lists	Sanctions, denied-party and entity lists published by the authorities in each regime — the primary and only authoritative source for screening
Tariff and control schedules	HS, national tariff schedules and dual-use control lists, including the notes and exclusions that decide most borderline cases
Published classification rulings	Binding rulings and advance decisions, which are how ambiguous classifications have actually been resolved
Ownership and registry data	Needed for ownership-based restriction analysis, which list matching alone cannot address; see the Corporate Ownership Intelligence API
Licence and exception reference data	General licences, exceptions and de minimis rules, which determine whether an authorisation is actually needed
Your shipment and product master data	Product specifications and party records, which is where classification accuracy is won or lost

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Name matching combining transliteration, phonetic and edit-distance methods with list-specific conventions, tuned per list rather than one global threshold
Alias, former-name and vessel or aircraft identifier handling, since restrictions commonly attach to a name the counterparty no longer uses
Ownership-based restriction evaluation against each regime's own threshold and control test, using resolved ownership chains with confidence and trail ends carried through
Threshold tuning that treats false negatives as the expensive error, with the review burden sized deliberately rather than minimised by accident
Classification assistance built on retrieval over the schedule text, notes and rulings, with every candidate citing the text it relies on and an explicit action where a physical specification must be verified
Hard separation between assistance and determination — the response carries no field that could be filed as a final classification without a human decision
List update monitoring with alerting, and automatic rescreening of open shipments when a list changes, because designation dates matter
Immutable screening records with list versions and timestamps, which is both an audit requirement and the only defence if a designation is added after a shipment moved

What it changes for the business

Screening that catches ownership cases

Ownership-based restriction analysis finds the exposure that direct list matching structurally cannot.

Faster classification work

Candidates with cited schedule notes and prior rulings turn an open-ended research task into a review.

Audit-ready records

Timestamped screening records with list versions are what an enforcement enquiry asks for first.

Rescreening on designation

Automatic rescreening when lists change catches counterparties designated after onboarding.

How it fits into your product

How it embeds

REST screening calls inside your shipment or order workflow, with blocking decisions left to your own rules engine
Webhooks on list updates and on rescreening hits for open shipments and existing counterparties
ERP and customs platform integration so screening happens at order entry rather than at the dock
Review queue endpoints for possible matches, with the match basis presented so a compliance officer can decide quickly
Immutable record export in a form suitable for an enforcement enquiry or internal audit
Deployment inside your infrastructure where counterparty and product data cannot leave

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Will this classify our goods for us?

It assists; it does not classify. The API returns ranked candidates with the schedule text, notes and rulings they rest on, plus the specific physical facts that need verifying. The declaration is the filer's legal responsibility — that is assigned by law and cannot be transferred to a vendor by contract or by API design. We deliberately do not return a single authoritative code, because a field like that gets filed without being read.

Can we rely on the screening result to clear a shipment?

Not on its own. Screening reduces the work and catches what manual checking misses, especially ownership-based restrictions. It cannot account for facts outside the data — end use you were told verbally, a diversion risk your team suspects, or a designation published hours ago. The record it produces is strong evidence that you screened properly, which is a different claim from the shipment being lawful.

Why so many possible matches to review?

Because we tune for false negatives being the expensive error. A missed designated party is an enforcement matter with personal liability attached; an extra review is ten minutes. Thresholds are configurable and we will help you set them, but we would advise against tuning for a quiet queue and we would want that decision recorded as yours.

Does it cover every sanctions regime?

The major regimes and their published lists, with the lists in scope stated and dated in every response. Coverage of smaller national regimes depends on whether the authority publishes a usable list at all, and some do not. Where a regime is not in scope the API says so explicitly rather than returning a clean result that reads like an all-clear.

What about ownership information we cannot obtain?

The ownership analysis carries its trail ends through to the screening result, so 'no restriction found' is distinguished from 'ownership could not be fully resolved'. That distinction is the whole point. Treating an unresolved chain as clear is how firms end up shipping to a majority-owned subsidiary of a designated person.

All Legal, Compliance & GovTech offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers