Sanctions Desk

A review desk for sanctions-screening alerts

Sanctions Desk

The desk gathers and checks the evidence for every sanctions-screening alert and recommends an outcome. A person with the right entitlement approves it.

Every review leaves a sealed record, signed receipts and a step-by-step replay. Nothing in it blocks an account, writes to a source system or contacts a customer.

A prototype, audit-ready by design: synthetic customers and payments, public list entries, not in production.

Watch the demo (3:51) See the results

Demo video thumbnail: the model alone said clear; the desk held the case for a person.
A 3:51 walk-through of a live review, the checks, the receipts and the results, with subtitles in English, Hindi, Spanish, Simplified Chinese, Japanese and Portuguese. Pressing play loads the player from youtube-nocookie.com; until then nothing on this page comes from outside this site.

What the committed runs show

How each figure was measured

One alert, start to finish

ALR-0073: the model alone said clear; the desk held it for a person

Exam case EX-064, the alert in the demo video: a synthetic payment whose reference names a watched place.

Nemotron alone

Close as a false positive

at 0.85 confidence, both with the free text and without it: a wrong close

Sanctions Desk

Held for a person

in 3 of 3 full-system runs; the newest run's recommendation: ask for more information

Replay the review step by step Result files: Nemotron alone, with the free text Nemotron alone, without it the desk, newest run

The problem

Many alerts, and the one that is real

A bank's name screening compares every customer and payment with the sanctions lists. The alerts it raises land on a sanctions analyst's desk, and three things make that desk hard to run.

Public enforcement cases (external sources)

These are public facts from official enforcement releases. They are not results of this project. They show the kinds of gaps that have cost banks; they do not show that this desk would have prevented any of them. Each card links to the official release, which opens in a new tab.

  1. 2016OFAC

    Barclays Bank Plc

    owners at 50 percent or more missing from the screening records

    $2,485,890 settlement

    OFAC release, 8 Feb 2016

  2. 2021OFAC

    Payoneer Inc.

    close matches to listed names passed the filter

    $1,385,901.40 settlement

    OFAC release, 23 Jul 2021

  3. 2021NYDFS

    Mashreqbank

    fields left out of interbank payment messages, bypassing other banks' sanctions filters

    $100 million penalty

    NYDFS press release, 9 Nov 2021

  4. 2022OFAC

    MidFirst Bank

    existing customers re-screened only once a month

    Finding of Violation, in place of a civil monetary penalty

    OFAC release, 21 Jul 2022

  5. 2024OFAC

    EFG International AG

    sanctioned clients behind omnibus accounts

    $3,740,442 settlement

    OFAC release, 14 Mar 2024

What the desk does for each alert

Gathers the evidence, checks it, recommends an outcome

Four outcomes are possible: close as a false positive, ask for more information, escalate to a senior reviewer, or recommend a block. Each is a recommendation for a person to approve or override with a reason; the desk blocks nothing, writes to no source system and contacts no customer.

  1. Gathers

    Reads the list entry, the customer, the payment and the ownership chain through Zetaris, one semantic layer, with a read-only role for each step that reads data.

  2. Checks

    Code gives a first finding, a critic re-reads every cited fact from the data (at most three rounds), a challenger argues against a doubtful close, and a policy guard can only add caution.

  3. Recommends

    One of four outcomes (close as a false positive, escalate, ask for more information, recommend a block), with what decided it and what would change it, for a person to approve or override.

Who uses it

Three people, three views of the same record

Every outcome is a recommendation for approval by a person with the right entitlement. Automatic closing is off by default.

The desk in sample mode: a risk signal from a payment reference, with the word Tehran marked and a note that it blocks a close. Open full size

Analyst

works the alert

  • a prepared case: the customer, the listed party, the payment and the data-quality results, with identifier numbers masked
  • the recommendation, what decided it, what would change it, and any risk signal marked in the free text
  • approves it or overrides it with a written reason; a block then waits for a second approval, and an override towards less caution needs an approver
The decision panel on a live review: the desk recommends Escalate to level 2 and waits for a person to approve or override with a reason. Open full size

Senior reviewer

the approver role, with the approval entitlement

  • everything the analyst sees, and the same decision panel
  • gives the second approval of a block: the first may come from an analyst or an approver, the second must be a different person with the approver role
  • may override towards less caution (an override to a close waits for a second, different approver), and can stop automatic closing at once
The review steps of a live review: each model step with the Nemotron model that answered, its receipt id and the signature check. Open full size

Auditor

the read-only viewer role

  • reads everything and changes nothing
  • the sealed decision record of every review, and a signed receipt for every Nightshift answer, checkable against the pinned key
  • a replay of each run event by event, and the audit log of every action, accepted or refused, under the person's id

How it is built

Zetaris for data, Nemotron through Nightshift for models

Zetaris

The only data path: one semantic layer over the sanctions lists, a bank database and a payments service. Each review step that reads data has its own read-only role (5 roles).

How the desk uses Zetaris

Nemotron through Nightshift

Local Nemotron 3.5 Lightning reads the raw free text; Nemotron 3 Ultra in the cloud reasons over structured facts only. Every Nightshift answer carries a signed receipt. The desk pins the mode; which model serves it, and so the Ultra share, is the router's choice.

Nemotron on the desk

Meterless engines

Three engines, each in a working feature: H-MEM (memory of earlier decisions), the World Model (the ownership register the 50 percent rule is evaluated on) and Markovian (re-screening earlier decisions after a list change).

The engines and where they run

Which model does each step

  • Safety guard (inbound)Nemotron 3.5 Lightning · local
  • Free-text screenerNemotron 3.5 Lightning · local
  • DecisionNemotron 3 Ultra · cloud
  • CriticNemotron 3 Ultra · cloud
  • ChallengerNemotron 3 Ultra · cloud
  • Safety guard (outbound drafts)Nemotron 3.5 Lightning · local
  • Backup when Nightshift cannot answerOllama · backup, no receipt

The desk pins the mode it asks for, not the model that serves it. Details on the Nemotron scorecard.

Architecture: the review desk, the desk agents reading through Zetaris, the safety guard and screener on local Lightning, the decision and critic on cloud Ultra, the policy guard, the person and the sealed record.
How a review runs. This and five more diagrams, full size, on the architecture page.

Charts

Every chart and table on the results page

Drawn from the committed evaluation files and receipts.

Bar chart: risk cases wrongly closed in each held-out round, for the full system and three simpler baselines.
Risk cases wrongly closed in each held-out round: full system, deterministic rules, name match and escalate everything.
Chart: which Nemotron model served each review step in the current system's newest 70-case run, local Lightning or cloud Ultra, and the signed receipts verified.
Which model served each step in the current system's newest 70-case run, local or cloud, and the signed receipts verified.

Read

The deck (PDF) the same ground as the video in 15 slides: the problem, how a review runs, the checks, the receipts and the results Recorded runs a read-only replay of six alerts from the committed runs, step by step, with the model that served each call, its verified receipt, the Zetaris reads and why a close was stopped Receipt log every model call in the committed runs, with the Nemotron model that served it; every Nightshift answer has its signed receipt, each signature checked when the site was built, and answers from the local Ollama backup have none by design API reference every route, its parameters and its responses, from the API's own OpenAPI document