The check that happens too late: sanctions screening in a cargo book

Most brokers screen. Far fewer screen at a point where the result can still change the outcome.

The common pattern looks like this. Business is written. At some point afterwards, often as part of a monthly routine, somebody runs the names through a screening tool. Nothing comes back. The file is marked as checked and everyone moves on.

That is a report, not a control. A control is something that can stop the thing it is checking. If the screening cannot prevent a bind, then what you have is a record of having looked, which is useful for demonstrating diligence and useless for preventing an exposure.

Why cargo makes this harder than most lines

In a standard commercial line the parties are few and static. You know the insured, and the insured is still the insured next month.

A cargo book has more moving parts and they change per shipment. There is the assured, but also the consignee, the notify party, the forwarder, the carrier, sometimes a bank on a letter of credit. There is a route, which may have changed after booking. There is the commodity itself, which may be dual-use or subject to export control depending on where it is going. And there is the vessel.

Each of those is a potential touchpoint, and they arrive at different times from different people. A screening routine built around the assured only covers the one party least likely to be the problem.

Sanctions regimes have also become faster-moving and less aligned with each other. A broker placing across several jurisdictions can face different lists, different thresholds and different expectations from each regulator and each capacity provider, on the same shipment.

Three questions worth asking about your own process

At what point in the workflow does screening happen, and can its result block anything? If the answer is that a flag generates an email to someone who may be on holiday, that is worth knowing now rather than during an audit.

Which parties are screened? Assured only, or every named party on the declaration? Most books cannot answer this quickly, because the parties live in a document rather than in fields.

And can you reconstruct, for any given transaction, what was checked, against which list, on what date, and what was decided? The ability to reconstruct is what an audit actually tests. Having done the work is not the same as being able to show it.

The underlying problem is usually structural

Where screening is weak, the root cause is rarely indifference. It is that the data needed to screen properly is sitting in an attachment.

If a declaration arrives as a spreadsheet and gets summarised into a policy record, the consignee and the notify party are not fields in a system. They are text in a file. Nothing can screen them automatically because nothing knows they exist. The process becomes manual by default, and manual processes get done monthly rather than per transaction.

Fix the structure and the control becomes possible. Leave the structure alone and you will be buying screening tools that cannot see most of your exposure.

Where we sit

tigerlab BMS treats sanctions and KYC as a gate on binding rather than as a subsequent check, with the parties held as structured data on the declaration. Every check is recorded against the transaction, so the reconstruction question has an answer. The platform is aligned with EU intermediary obligations, AML and DORA controls.

Would your own process survive the reconstruction test? Download The screening reconstruction check: seven questions covering when screening happens, which parties it covers, and what you could produce if asked tomorrow.