Restricted-party screening: check trade parties and retain context

Identify each legal party the trade process requires

Restricted-party screening compares transaction parties with selected sources of restrictions. Use SanctionsKit for the buyers, consignees, end users or other identities your policy selects. It supports candidate review; it does not classify goods, determine a license or authorize a shipment.

Create a separate subject for each required party. New screening in the dashboard handles one check; Bulk screening handles a prepared group. A different end user is not a buyer alias. Screening the buyer does not check everyone named in the shipment documents.

Choose the actual trade sources needed

Read U.S. CSL coverage and BIS source notes, then check current availability and supported subject types. us-csl and us-bis-denied are separate IDs. The latter does not mean every BIS restriction is included.

GET /api/v1/sources returns current states under data. In POST /api/v1/screenings, use exactly one of sources or package and the applicable policy. Required unavailable coverage must stop or escalate the checkpoint under your process. It must not quietly disappear from the request.

Keep every result linked to its party and role

Give each request a stable reference and save its screening ID, coverage and versions. Counterparties can link an ongoing relationship, while the transaction system keeps shipment roles and context. For many subjects, use the batch guide and reconcile every row.

A no_match describes only the submitted party and chosen sources. A failed request, accepted batch or missing result does not show that all shipment parties were checked. Keep unfinished rows visible so a group total cannot hide one missing legal party.

Read the underlying restriction after comparing identity

Open each retained candidate in Review queue. Inspect the authority, underlying list, source record and identity evidence. CSL combines sources with different requirements. A single denied flag hides that context. Resolve identity, then record the separate business action.

Use required external checks for the qualified team's goods, destination, end-use, ownership or licensing work when needed. The reviewer records outside evidence and approval. SanctionsKit tracks the task, but does not carry out the legal or technical assessment named in it.

Recheck the party affected by changed instructions

If the buyer, payee, consignee or end user changes, screen the new required identity at the approved checkpoint. Preserve the old result with its role and date. For ongoing relationships, configure Monitoring and inspect later changes through the current linked case.

Start an integration with the quickstart and source discovery. Test a changed end user, an unclear company ID and a required-source failure before linking results to shipment approval. Each should leave the right next action visible.

Keep non-list export questions open until assessed

A party check does not classify the product, establish its destination or end use, assess all ownership rules or supply a license. Each needs its own evidence. A no-match cannot show that the proposed use is permitted.

Keep the underlying list and authority when escalating a CSL candidate. The CSL API tutorials show how to retain source context in the handoff. A screening result supports the review; it does not provide export authorization.

Frequently asked questions