Re-screen counterparties when sanctions lists or ownership change
For: Sanctions or financial crime compliance officer at a trading, shipping or manufacturing group
The pain today
Screening happens at onboarding and then goes stale. Lists change often, ownership changes quietly, and name-matching tools bury the team in false positives while an indirectly owned counterparty slips through.
The ask
“I connected our customer and supplier master, the sanctions lists we must follow and the ownership records we have. Keep re-checking each counterparty when a list or an owner changes, tell me about real matches with the evidence, and explain why you dismissed the rest.”
Plain words, as you would say it to a colleague. Edit it to fit your case before you send it.
What you attach or connect
- Customer and supplier master with identifiers
- Sanctions and restricted-party list updates
- Beneficial ownership records and registry extracts
- Earlier screening decisions and their reasons
The unit of work
One worker task per one counterparty against one list or ownership change.
Why a swarm fits
A list update touches a few names, not the whole book. Each possible match is judged from one counterparty's identifiers and one list entry, and only the counterparties a change could affect are re-screened.
Not for
A short, stable counterparty list an officer can re-check by hand, or payment screening that must answer in real time.
The decision tree
6 typed decisions, each with an action for every answer
At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.
Planner, while planning
Scope checkYes or no, with a probability
Before work starts on a unit
Could this list update or ownership filing affect this counterparty, by name similarity, a shared identifier or a listed owner in its chain?
Sees only: The changed list entry or filing and the counterparty's identifiers and owners
Why: A list update touches a few names, so the whole book is not re-screened.
- Yes: 0.40 or higherthenAccept
- Unsure: 0.10 up to 0.40thenAccept
- No: below 0.10thenSkip this unit
After workers, the judge checks
Evidence checkA choice among options
After a worker answers
Beyond the name, what do the identifiers of the counterparty and the list entry show?
Sees only: The counterparty record and the list entry, side by side
Why: Name-only matching is what buries the team in false positives.
- Two or more identifiers agreethenAsk a person
- An identifier rules the match outthenAccept
- Too few identifiers to tellthenMark unresolved
Evidence checkYes or no, with a probability
After a worker answers
Does the recorded reason for dismissal cite an identifier that actually differs between the two records shown?
Sees only: The dismissal reason and both records
Why: Every dismissal must stand up to a later quality review.
- Yes: 0.90 or higherthenAccept
- Unsure: 0.50 up to 0.90thenEscalate to a strong model
- No: below 0.50thenReject and retry
Reconciler, while merging
Conflict checkA choice among options
While reconciling
Do the registry extract and our own ownership record give the same holders and percentages for this layer of the chain?
Sees only: One layer of the ownership chain from each source, with dates
Why: Aggregate-ownership tests are only as good as each layer.
- Same holders and percentagesthenAccept
- Different, registry is more recentthenReject and retry
- Different, no way to date themthenMark unresolved
Run control, between rounds
Another round?Yes or no, with a probability
Between rounds
Did this list change or filing alter a name, identifier or owner that an earlier decision for this counterparty relied on?
Sees only: The earlier decision's cited identifiers and the changed fields
Why: Earlier decisions are reopened only when their basis moved.
- Yes: 0.40 or higherthenContinue
- Unsure: 0.15 up to 0.40thenContinue
- No: below 0.15thenStop
Accountable person, before anything is settled
Person decidesYes or no, with a probability
Before anything is reported as settled
Is this a potential true match, or a counterparty whose ownership is too incomplete to clear?
Sees only: The case file with match evidence and ownership path
Why: Only a compliance officer blocks, releases or reports.
Accountable: A compliance officer decides every true match, block or release; the swarm never freezes a payment or files a report.
- Yes: 0.20 or higherthenAsk a person
- Unsure: 0.05 up to 0.20thenAsk a person
- No: below 0.05thenAccept
The fleet: who does what
Model tiers by role, not brands: you choose the models. Strong reasoning models plan and reconcile, small fast models do the wide work, and the judge is a decision model from a different family, so it does not share the workers' blind spots.
Planner
A strong reasoning model works out which counterparties each list or ownership change could affect, directly or through owners.
Decisions here:1. Scope check
Workers
Small fast workers from an open-weight family compare one counterparty's identifiers and owners with one list entry.
Designed for 10 to 500 agents, one worker task per one counterparty against one list or ownership change. Each worker receives only its own unit.
Judge, from a different model family
A decision model from a different family decides whether the identifiers support a match, a dismissal or 'cannot tell'.
Decisions here:2. Evidence check3. Evidence check
Reconciler
A strong reasoning model rolls ownership chains up to aggregate-ownership tests and maintains the case file per counterparty.
Decisions here:4. Conflict check5. Another round?
Accountable person
A compliance officer decides every true match, block or release; the swarm never freezes a payment or files a report.
Decisions here:6. Person decides
Checked before anything is accepted
- A match needs agreeing identifiers beyond the name: registration, address, date or owner
- Every dismissal records the identifier that rules the match out
- Ownership percentages are summed in code along each chain
- Earlier decisions are re-opened only when their underlying source changed
What comes back
- Potential true matches with list entry, identifiers and ownership path
- Dismissed hits with the reason recorded
- Counterparties with ownership too incomplete to clear
- Audit trail of what was re-screened after each change
What to measure
- False positives reaching an officer per list update
- True matches first found by another control
- Time from list change to completed re-screen
- Dismissals overturned in quality review
Names of measures only. No result is claimed for this template.
Templates open in the workspace chat with the ask filled in. Nothing runs until you send it.
Get early accessSign in to useMore in Compliance and risk
Map a new regulation to policies and controls, rule by rule
For: Head of compliance or regulatory change manager implementing a new rule
A new regulation arrives with obligations buried in articles, annexes and guidance.
Test control evidence samples against the control description
For: Internal control manager or second-line tester running the annual control testing cycle
Every key control needs sampled evidence checked: was the approval there, by the right person, before the event, for the right amount.
Review vendor assurance packs by security, privacy and resilience
For: Third-party risk manager onboarding or re-assessing critical vendors
Each vendor sends an assurance report, a questionnaire, policies and a penetration test summary.