DPS
The list changed on Tuesday.
Your spreadsheet did not,
and nobody found out.
DPS screens the party you are shipping to against government denied party and sanctions lists, stops the shipment on a hit, and records every check with its score and the entity it matched. It does not clear anybody. It makes sure a person did, and that you can show which lists they were looking at when they did it.
Three lists named on this page, and no others claimed. Runs on your infrastructure, with no per-query meter.
The problem
What usually happens instead.
The consignee is a company name typed into a form. Somewhere between that and the shipment leaving the building, somebody is supposed to have checked whether you are allowed to send anything to them at all. Frequently nobody has. Where somebody has, it was usually one person, once, with a free web tool open in another tab.
None of that feels like a compliance failure while it is happening. It feels like a normal Tuesday. It only becomes visible later, and by then it is not a process question any more.
It is a browser tab and a judgement call
Somebody pastes the company name into a free web tool, scans the results, sees nothing that looks alarming and books the shipment. Nothing is stored. The next person repeats it, or does not repeat it.
It was done once, when the account opened
A spreadsheet of approved customers, checked at onboarding and never since. That was a true statement on the day it was made. Lists are amended continuously, and a spreadsheet has no way of finding out.
The near miss never surfaces
Parties rarely present themselves under the name a list uses. A transliteration, a trading name, a legal suffix that differs by jurisdiction. An exact-match search returns nothing, and returns it confidently.
Somebody asks about one shipment, a year later
Which party, screened when, against which lists, and who decided the result was fine. The honest answer is usually that it was probably checked. Probably is not a record.
The underlying facts move whether or not anybody is watching them. Lists are amended continuously, ownership changes, designations are added. A party who was genuinely clear last year may not be clear now, and nothing about your records will change to tell you. The exposure is not proportionate to the effort either. One shipment to one party is enough, and the obligation attaches to the company regardless of whether anybody intended it.
Who it is for
Built for the person who signs, and the person who ships.
Screening fails at the seam between those two people. One is accountable and not in the room, the other is in the room and not qualified to judge a near match.
The person who owns the consequences
Trade compliance or export control. You are accountable for parties you will never personally see, on shipments booked by people who do not report to you. What you need is that the check happened on every one, in the same way, and that you can produce it on demand rather than reconstruct it.
The person who just needs it to ship
Operations, logistics, a study coordinator. Screening is not your job, and judging whether a near match is your customer is not something you can reasonably be asked to do. It should happen without you having to remember it, and it should stop you when there is a reason to stop you.
The person evaluating it
Buying, replacing or auditing a screening control. You want the specifics: exactly which lists, how the matching works, what is stored on a check, who can override and what that costs them, and whether any party name leaves your network.
Who it is not for
A screening tool that will not say what it does not cover is a screening tool you have to test yourself. So, plainly:
- It does not clear, certify or approve anybody. It returns a result, a score and the entity it matched. Deciding what that means about your party is a person’s job, and the record exists so that person has something to decide against.
- It is not a sanctions legal opinion. It matches names against published lists. It does not analyse ownership or control, so the fifty percent rule, beneficial ownership and end-use questions stay with you and your advisers.
- It does not cover every list in existence, and any tool that claims to is worth pressing on. The lists it ingests today are named on this page. Others can be added, because ingestion is a source and a parser rather than a sealed box.
- It is not export licence determination or ECCN classification. Those are separate obligations, handled separately in the platform.
- It is not know-your-customer or payments screening. It screens the party on the shipment, at the moment the shipment moves.
- If you ship to two parties, both of them your own sites, and both were screened this morning, this is doing very little for you. The value is in volume, in parties somebody else onboarded, and in being able to produce the check afterwards.
Using it
Nobody has to remember to do it. That is most of the point.
A screening step that depends on somebody choosing to take it is a screening step that gets skipped on the week it matters. This one runs as part of moving a shipment forward, and it is capable of refusing.
It runs without being asked
On submission the platform screens the consignee itself when there is no recent result. It does not stop and tell a scientist to go and screen the party first, because that is not their function and not something they can judge.
A hit stops the shipment
Clear is the only passing state. A match, a near match held for review, a screen that failed to run, or a result too old to rely on all stop submission and approval. There is no setting in which a blank counts as a pass.
A person decides, in writing
A compliance officer reviews the match and either confirms the block or overrides it with a reason. The reason is mandatory, it is attributed, and it lands in the append-only audit trail next to the check it overrode.
What it will not do
DPS does not tell you a party is safe to deal with. It tells you what the lists it holds say about the name you gave it, how close the match was, and where the match came from. Whether that entry is your party, and what to do about it, is a judgement a person makes and puts their name to. Screening a name is also not the whole obligation. Ownership, control and end use sit outside anything a name match can see.
It is one of two products that sit alongside the platform rather than inside it. Determine settles what the material is and how it has to travel. DPS settles who you are allowed to send it to. Different questions, the same discipline about recording how the answer was reached.
The lists
Exactly which lists, named by publisher.
Coverage is the easiest claim in this market to stretch, and the hardest for a buyer to verify from a website. So here is what is ingested today. If a list is not on this page, it is not in the product.
- 01
OFAC SDN
Specially Designated Nationals and Blocked Persons, published by the Office of Foreign Assets Control at the US Treasury. Ingested from the public file, carrying the entry’s sanctions programmes, aliases and remarks through into the record.
- 02
UK OFSI consolidated list
The UK consolidated list of financial sanctions targets, published by the Office of Financial Sanctions Implementation at HM Treasury. Individuals, entities, vessels and aircraft, with the group type preserved.
- 03
EU consolidated sanctions list
The consolidated list of persons, groups and entities subject to EU financial sanctions, published through the European Commission’s financial sanctions files service. Persons, enterprises and vessels.
Each entry becomes a record with its primary name, an entity type, and the aliases, country and sanctions programme where the source publishes them. The aliases do more work than the primary names, because parties do not tend to present themselves under the name a list settled on.
Other lists can be added, and adding one is a source and a parser rather than a rewrite. Every source above is a public file with no key and no per-query fee, which is why none of this needs a meter. For a pharmaceutical operation the usual next additions are export-control lists such as the BIS Entity List, and the healthcare-specific lists, FDA debarment and OIG exclusion. We would rather name three lists we can point at than advertise seven and let you find out later.
Every ingestion writes a version
A dated list version with the record count from that run. The run does not quietly overwrite what came before it.
Superseded entries are kept
Previous entries for that list are marked inactive rather than deleted. What the list said last quarter is still in your database.
A check can be placed against a version
Each check stores the list it matched and the moment it ran, so it reads against the list version that was live at the time. That is what makes an old result defensible rather than merely old.
Refresh is a job, not a live feed
Ingestion runs as a scheduled job inside your own deployment on a twenty-four hour repeat, and an administrator can trigger it on demand. Nothing reaches outside during a screen.
How matching works
Exact matching fails quietly, which is the worst way to fail.
A party is Global Pharma Trading LLC on your form and GLOBAL PHARMA TRADING on the list. It is a transliteration from another script. It is a trading name. It is the same organisation with the legal suffix its own jurisdiction uses. An exact search finds none of those, and reports nothing found. Everything below exists because of that.
- 01
Both names are normalised first
Case is dropped and legal suffixes are stripped, so Ltd, GmbH, S.A.R.L., B.V., N.V., A.G., S.p.A., PLC, LLC, LLP, Inc and Corp stop being part of the comparison, along with their longer forms in several languages. Hyphens and apostrophes become spaces, remaining punctuation goes, whitespace collapses. The list entry and your consignee go through the same treatment.
- 02
Exact names and aliases are treated alike
Once normalised, a name equal to a list entry’s name or to any of its published aliases scores at the top and blocks. At this tier an alias hit is worth exactly what a primary-name hit is worth, which matters because a party rarely presents itself under the name the list settled on.
- 03
Shared significant words are caught next
Names are split into tokens, common filler is discarded, and the proportion of shared tokens is measured against the shorter of the two names. Reordered names and partial names surface at this tier, and exact matching misses all of them.
- 04
Character similarity catches the misspellings
Trigram similarity computed in the database, and separately a Levenshtein edit-distance score blended with token overlap. Typos, transliteration differences and dropped characters land here, as near matches rather than as silence.
- 05
Everything is scored, and the score is stored
A number between zero and one, kept on the check with the entity and the list it came from. The score is not there to look precise. It is there so a reviewer can tell a genuine near miss from a coincidence, and so a later reader can see what the reviewer was looking at.
- 06
Only clear passes
An exact hit blocks. A strong partial or a fuzzy near match is flagged for review, and a flag does not let the shipment through either. A missing result, a screen that errored, or a result older than thirty days does not pass. Clear is the only state that moves a shipment forward.
What the score does not know
The match is on names and aliases. The destination country is recorded on the check but does not currently move the score, and address matching is not performed. That makes the matcher deliberately noisy in the direction of flagging rather than clearing. It is the correct direction for the error to fall, and it is the reason a person reviews rather than a threshold deciding on its own.
The record
A result is not evidence. This is what a check carries.
A screen that produced an answer and kept nothing has not helped you with the question somebody asks a year later. Every screen writes a check row, whether it matched anything or not, and a clear result is stored as positively as a hit.
- The name that was screened
- Exactly as it was submitted, not as somebody later corrected it. A record of what was checked, rather than of what you would prefer had been checked.
- The result
- Clear, flagged, blocked, or a near match held for review. Stored as a value on the check, never inferred later from the absence of a complaint.
- The score, the entity and the list
- The number, the name of the entity it matched, and which list that entity came from. Enough to reconstruct why the system reacted the way it did, without rerunning anything.
- The review and the override
- Who reviewed it, when, what they wrote, and whether they confirmed the block or overrode it. An override needs a compliance officer and a written reason. The reason is not optional and it is not editable afterwards.
- The audit entry beside it
- Written in the same database transaction as the check, into an append-only table. The check and the trail cannot drift apart, because either both were written or neither was.
Not screened is not the same as clear
A shipment with no screening result is not a screened shipment, and a system that lets the blank through produces a tidy-looking record of a check that never happened. Here a missing result blocks exactly as a match does, and a result that has aged past thirty days stops counting at submission. Saved parties carry their own status and their own last-checked date, and the ones that have gone unscreened for ninety days are surfaced as overdue rather than assumed to be fine.
Deployment
Nobody outside your network learns who you ship to.
On your infrastructure
The screen runs where the shipment does
- Matching runs entirely inside your deployment, against lists already sitting in your own database. No consignee name is sent anywhere to be screened.
- There is no per-query call to a third party, so there is no meter, no allowance, and no external service holding a log of who you ship to.
- The only outbound traffic is the ingestion job downloading the public list files, on its own schedule, never during a screen.
- Each list source is configurable, so an air-gapped site points ingestion at an internal mirror and keeps the deployment sealed.
- It also runs on its own, as a container with an HTTP API and no database, next to whatever system you already screen from.
Inside the workflow
A gate, not a dashboard
- Screening is wired into shipment submission and approval, so it is not a step anybody can skip by not opening a particular screen.
- Saved consignees are screened when they are created, can be re-screened on demand by a compliance officer, and carry a dated status on the record.
- Overrides are restricted to a compliance officer or above and land in the same append-only audit trail as everything else.
- Screening records export inside the shipment evidence pack, alongside signatures, generated documents and the audit trail.
How it is bought
In the platform, and never by the query.
How a control is charged for changes how often it gets used, and screening is the clearest example of that anywhere in trade compliance.
Part of the platform
- What it is
- One of the core modules, wired into shipment submission and approval rather than sitting beside them as a service somebody has to remember to call.
- How it is bought
- With the platform, on the same annual agreement, scoped to the volume you actually ship.
- Why it works that way
- Screening bought separately is screening somebody can decide not to renew in a tight year. A control that can be switched off for budget reasons is not really a control.
Not metered
- What it is
- Screening on every shipment, and on saved parties as often as it needs to run.
- How it is bought
- No per-query charge and no query allowance, because the lists are public files sitting in your own database.
- Why it works that way
- A per-query meter creates a quiet reason to screen less, which is precisely the wrong incentive to build into a compliance control. It also produces a year-end overage nobody forecast.
Determine is bought differently, because it is a different kind of thing. Its regulatory content has to be written, dated and maintained, so the engine and the rule sets are separate purchases. Screening lists are public files that refresh themselves on a job inside your own cluster, so there is nothing there to subscribe to. Two products alongside the platform, two honest models.
Questions
The ones we get asked.
Three today: the OFAC SDN list from the US Treasury, the UK OFSI consolidated list from HM Treasury, and the EU consolidated sanctions list from the European Commission. That is what is ingested, and we would rather name three we can point at than advertise a longer set. Others can be added, because each source is a public file plus a parser, with no key and no per-query fee attached to any of them. Export-control lists such as the BIS Entity List, and healthcare-specific lists such as FDA debarment and OIG exclusion, are the usual next additions for a pharmaceutical operation.
Bring a name that nearly matches.
The fastest way to judge a screening control is to watch it react to a near miss, then read what it wrote down afterwards. That is a short conversation rather than a procurement cycle, and you can use one of your own consignees.