Restricted Party Screening

Restricted party screening software checks the people and companies you transact with against government denied, restricted, and sanctions lists to make sure you are not dealing with a prohibited party. It covers the OFAC Specially Designated Nationals and consolidated sanctions lists, the BIS Entity, Denied Persons, and Unverified lists, the DDTC debarred list, and international equivalents. Captain screens customers, suppliers, and consignees in real time at order entry and in batch across your master files, uses fuzzy matching so misspellings and aliases still surface, and logs every screen and decision so the control is both effective and provable when a regulator asks how you performed it.

The platform screens against the core US lists, OFAC's Specially Designated Nationals and Blocked Persons list and its other sanctions programs, the BIS Entity List, Denied Persons List, and Unverified List, and the DDTC list of debarred parties under ITAR, along with the broader Consolidated Screening List that the government maintains. It also covers major international denied and sanctions lists so a party sanctioned by another jurisdiction you operate in is caught too. You scope coverage to the programs and countries relevant to your trade, and the platform keeps each selected list current so a designation added today is in your next screen, not a stale copy.

Trade compliance software is the broad suite: export classification, license determination, destination and end-use controls, and screening together. Restricted party screening is one control within that, the party check specifically, done deeply with multi-list coverage, fuzzy matching, and a resolution workflow. In Captain the screening module is part of the wider trade compliance platform, so a denied-party hit sits alongside the license and classification checks on the same transaction. If you need the whole export-control program, the suite is the answer; if your immediate need is rigorous, auditable party screening, this is the module that does it, and it feeds the suite rather than duplicating it.

Real-time screening runs the instant a party is entered on an order, so a hit stops that transaction before anything ships. Batch screening runs across your entire customer and supplier master on a schedule and whenever a list updates, so a party you already do business with who gets newly designated is caught even though no new order triggered a check. You need both: real time protects the transaction in front of you, and batch protects the relationships you already have when the lists change underneath them. Captain runs both automatically, so a designation published today surfaces in your masters without anyone remembering to re-run a check.

Sanctioned parties rarely appear under a clean, exactly spelled name; names are transliterated from other scripts, misspelled, abbreviated, or hidden behind aliases and AKAs. Exact-match screening misses all of that. Fuzzy matching uses phonetic and edit-distance techniques to catch near matches, and it corroborates with address and country data to separate a genuine near match from noise. The trade-off is more candidate hits to review, which is why the resolution workflow matters: a reviewer clears the false positives with a documented reason and escalates the real ones. Tuning the match threshold lets you balance catching everything against a manageable review load.

When a screen returns a hit, the transaction is held and the match routes into a resolution workflow. A reviewer sees the party, the list and program that flagged it, the match score, and the corroborating data, and decides: clear it as a false positive with a documented rationale, or confirm it as a true match, which blocks the transaction and escalates per your policy. Nothing releases while a hit is open, so a genuine designated party cannot ship by default. Every step, the hit, who reviewed it, what they decided and why, is recorded, so a cleared false positive is as defensible as a confirmed block if the decision is ever questioned.

Government lists change frequently, sometimes multiple times a week, and a screen is only as good as the list behind it. The platform refreshes each covered list automatically when the issuing authority publishes an update, and it monitors freshness so you can see that coverage is current rather than assuming it. When a list changes, the platform rescreens your master files against the new version and raises anyone newly designated, so the gap between a designation being published and your catching it is closed automatically. That is the difference between screening as a point-in-time check and screening as a continuous control.

Yes, and that is central to the value. Every screen is timestamped and linked to the exact list version and match score that produced it, and every resolution carries the reviewer and their documented rationale. When OFAC, BIS, or an internal auditor asks how a specific party was screened on a specific date, you produce a record that was built as the order moved rather than reconstructed after the fact. This matters because export-control enforcement weighs whether you had a reasonable, documented screening process, so a complete, attributable trail is not just good hygiene, it is the evidence that supports your compliance posture.

Yes. During onboarding the platform runs a full baseline batch screen across your existing customer, supplier, and consignee masters, so you start from a known state rather than only screening new orders going forward. That baseline surfaces any already-listed parties in your book of business and lets you clear the inevitable false positives once, so ongoing screening starts clean. From then on the masters are rescreened on every list update, so the baseline stays current. This catches the common blind spot where a company screens new orders diligently but never re-checks the relationships it already had when the lists move.

Yes. The platform connects to your order management, CRM, and ERP through API integration, so party data flows in for screening and results flow back to the transaction automatically. Real-time screening fires at order entry inside the systems your team already uses, so screening is not a separate step someone has to remember, it is a gate the order passes through. Results, holds, and clearances post back so the order status reflects the screening outcome. Because it consumes the party data you already maintain, there is no duplicate master to keep in sync and no screening that runs on stale contact records.

A focused rollout can be live in about two weeks: a few days to connect your order and party data, configure list coverage, match thresholds, and country scope, and run the baseline batch screen of your masters. The main effort is tuning the match threshold and clearing the initial batch of false positives so your team is not buried in noise on day one. Programs with large master files, many jurisdictions, or strict escalation policies take a bit longer to configure. As with the rest of the platform, the gate is usually data quality: clean, complete party names and addresses make screening sharper and the false-positive load lighter.