Denied party screening that stops the booking, not the audit.
Every counterparty on a shipment is screened against restricted and denied party lists before the move is allowed. A match blocks the booking and routes it for review, so a sanctions problem is caught at the decision instead of discovered in a report months later.
What screening covers.
Every party on the shipment
Shipper, consignee, notify party, forwarder, and end customer are all screened, not just the account on the invoice. The parties that create exposure are usually the ones nobody checks.
Configurable list sets
Screen against the sanctions, debarment, and restricted party lists your policy requires, configured per operating entity so each jurisdiction runs its own rules.
Blocking, not advisory
A match holds the booking and routes it for review. The shipment does not move on a warning that somebody was supposed to read.
Audit trail by default
Lists, versions, matches, reviewer, and timestamp are stored against the shipment. The evidence for why a move was allowed sits with the move itself.
Screening API
Call the same screening service from your own order entry, CRM, or forwarding system so one set of lists and one audit trail covers every channel.
A list check nobody runs in time.
When screening lives in its own tool, it happens when someone remembers. Bookings go out ahead of the check, matches surface in a weekly report, and the compliance team spends its time reconstructing what already shipped.
A check the booking cannot skip.
Freightgate screens as part of the workflow that books the shipment. There is no path to execution that bypasses it, so the control is enforced by the system rather than by a habit.
What compliance teams ask first.
Which lists does Freightgate screen against?
Screening runs against the restricted and denied party lists your compliance policy requires, including US, EU, and UN sanctions and debarment lists. The list set is configured per entity, so a company operating under several jurisdictions screens against the right rules in each one.
Can denied party screening be integrated into our quote-to-order workflow?
Yes. Screening is a step inside the workflow rather than a separate system. A counterparty is screened when the quote is raised and again before the booking is committed, so a match stops the order rather than surfacing after the shipment has moved. See Quote Automation for where it sits in the quoting path.
Does it work with our existing TMS or WMS?
Yes. Freightgate connects through EDI, API, and web services and sits above the TMS, WMS, and ERP you already run. Screening results are written back to the shipment record in those systems, so there is no second place to check. See Integration.
Is there a screening API?
Yes. The screening service is available as an API, so counterparties can be checked from your own order entry, CRM, or forwarding system with the same lists and the same audit trail as screening inside Freightgate.
What happens when a counterparty matches?
The booking is blocked and routed for review with the match evidence attached. A reviewer clears or confirms the match, and either way the decision is recorded against the shipment with the user, the timestamp, and the list version used.
How is screening evidence retained for audit?
Every screen is stored against the shipment: which lists ran, which version, what matched, who reviewed it, and when. An auditor asking why a shipment was allowed to move gets the answer from the shipment record itself.
Compliance across the shipment.
See screening block a booking on your own data.
Bring one lane and a counterparty list. We will show you the screen running inside the booking workflow, the hold, the review, and the audit record it leaves behind.