Development of a sanctions screening system for crypto businesses

Sanctions screening development: where screening breaks

Counterparty screening in crypto breaks not at integration, but at the moment when a payment has already been initiated.

Address screening runs synchronously with fund withdrawal, while external lists — OFAC, EU, local regulators — respond with different delays and under different rules. The operation queues up, the client sees that the payout has not arrived, and support receives the first ticket.

The second failure point is false positives. A last-name match during transliteration, an address linked to a mixer through a fifth counterparty, an exchange wallet with a heterogeneous deposit history — all of this goes to an analyst for manual review.

With a flow of hundreds of operations per day, the queue grows faster than the team can close it, and screening turns into a permanent bottleneck at the output.

The cost is predictable: payout delays, corporate clients moving to places where checks are unobtrusive, manual labor at scale.

Separately, there is regulatory risk: during a regulatory review, you need to show not the mere fact that screening exists, but the rationale for every decision, including those where a hit was deemed false and the payment was allowed through.

Sanctions screening development is precisely about separating these knots: screening before payment initiation, risk assessment by level and amount, transparent escalation rules instead of manual “by eye.” Below, we break down exactly where the boundary lies between an automated decision and an analyst’s work.

What an in-house screening loop provides

An in-house screening loop is built around data we control: address labels from Chainalysis, official sanctions lists, and internal stop lists are consolidated into a single stream, while matching rules are described by configuration rather than a side script.

Screening automation stops being a black box — the share of decisions without human involvement becomes a measurable and manageable value.

In practice, 85-95% of screenings are closed automatically, and this is not a set-it-and-forget-it configuration: sensitivity thresholds change along with the platform’s risk profile.

Risk scoring filters out false matches — if the name matches, but the country, date of birth, and document differ, the hit is cleared without an engineer. Cases with real uncertainty remain for a human.

The manual review queue receives not a raw stream but ranked cases: with the reason for the hit, the transaction chain, and the address history.

As a result, reviewing a single match takes one pass, not three systems in a row, and time per hit drops from tens of minutes to single digits.

A separate class of failures — the most expensive one — is also addressed: screening that silently stops catching an address after a directory format change.

Every matching rule is versioned and run against accumulated hits before production deployment — regressions are visible in advance, not after a review.

Every decision stores its rationale: who, when, and under which rule cleared or confirmed the risk — this trail is what regulators request during a review.

Ways to connect lists and matching rules

Lists can be obtained directly from the holder, through a consolidated source, or maintained as your own curated copy — this affects update latency, the volume of manual review, and coverage completeness.

Export formats differ (XML, CSV with a custom schema), so we keep the loading layer separate from the matching layer: a schema change should not break search rules.

We pull updates as delta files on a schedule; when the structure changes, a full snapshot reload with versioning is performed, so the log records which version of the list was used to make a decision about a client.

Matching modes and threshold

Name matching starts with normalization: case, diacritics, transliteration, “last name — first name” reordering, initials, dates of birth, and citizenship as additional attributes.

Then fuzzy comparison with a match threshold follows: too low a threshold produces a stream of false positives; too high a threshold risks missing a record.

We set thresholds separately for blocking and other lists, and hits above the second threshold go to an analyst for review rather than being blocked automatically.

List update frequency is chosen based on the risk profile: a daily delta poll covers most scenarios; on blocking lists, the interval is shorter.

Implementation stages: from process audit to handover

Screening implementation begins not with code but with an audit of compliance processes: it is important to understand where a sanctions match is currently caught, which lists are connected and how often they are updated, who stops an operation, and what gets logged.

The audit shows which checks are duplicated, where data is lost between systems, and which points in the flow must be covered. After that, work proceeds in iterations — from design to production handover.

1. Compliance process audit. We review current checks: data sources, manual steps, timeframes for reviewing hits, and the history of rejections and incidents. We record which operations currently pass without any screening at all.
2. Screening design. We identify integration points — client onboarding, incoming and outgoing transactions, and fund withdrawal. We agree on event formats, roles and permissions, and system behavior when an external list is unavailable.
3. Rule and threshold configuration. We select name comparison logic: transliteration, part reordering, fuzzy matching, and match weight. We configure risk levels and manual review queues so the analyst sees only significant hits.
4. Historical test run. We run the accumulated array of operations, compare the result with compliance officers’ decisions, and calculate the share of false positives and misses. We use this comparison to calibrate thresholds, not “by eye.”
5. Screening procedure. We describe the review workflow: response times, escalation criteria, grounds for blocking, and mandatory decision logging. The procedure is aligned with current policy and forms the basis for team training.
6. Production handover. We deliver configurations, the integration design, analyst instructions, and a metrics dashboard. We support the first weeks until the team reaches an independent mode.

The key readiness criterion is not a launched service but predictable operation: it is known how many operations go to manual review and why. Discuss your task — we will come back with an estimate and a stage-by-stage plan.

Deliverable set of designs, procedures, and access permissions

After launch, the client’s team retains not only a working screening loop but also a complete set of artifacts: a new engineer or compliance specialist can be onboarded into the system using them without contacting us.

Documentation is tied to changes — editing rules or connecting a new list source updates the description with the same change.

• Integration design: connection points to the transaction loop and external list sources, request and response formats, behavior when a source is unavailable.
• Screening flow design: the path from operation occurrence to decision, queues, logging points, and result retention periods.
• Screening documentation: matching rules — thresholds, transliteration, fuzzy match review, and tests on historical hits.
• Access matrix: roles of analyst, senior reviewer, rules administrator, and auditor — what each can read, change, and confirm.
• Match review procedure: response times by risk level, case card composition, escalation conditions, and who makes the final decision.
• Rule change log: who changed thresholds or the exception list and why, with configuration rollback to the previous revision.
• Shift instructions: duty schedule, actions when a source is blocked, and handover of unresolved hits.

We test the artifacts in drills: we set up a test environment, run scenarios with an unavailable source and a stream of false positives. If a decision can be made according to the instructions within the allotted time, we consider the set accepted.

Case study: how false positives were cut in half

The client — a crypto exchange with an operation flow across several networks — could no longer cover the volume with manual screening.

Matching was hard-coded: any name or address match went to an analyst, review took up to 40 minutes, and the queue grew faster than it could be processed.

We rebuilt the screening route in three steps: checking against sanctions lists (OFAC SDN, EU, OFSI, UN), enriching addresses with Chainalysis data, and calculating a risk score using configurable weights.

Thresholds and review rules are moved into configuration, so sensitivity can be changed without releasing a new version.

Metrics before and after

False positives were cut in half: name matches cleared by date of birth or country go to automatic approval with a log entry. Every decision stores which rule and which list version produced it — this removes questions during regulatory reviews.

Continuous monitoring was also enabled: when a list is updated, the entire client base is rechecked, and matches arrive in the queue automatically. Previously this was done selectively and manually, so some matches surfaced with a delay.

How does a one-time address check differ from continuous monitoring?

A one-time address check is a snapshot on a specific date: a single query to analytics registries, sanctions lists, and illegal service lists, the result of which is recorded in the client card.

For an incoming payment or onboarding, such a snapshot is sufficient: it confirms that the address was clean on the check date and leaves a trail for audit.

But a label is not a property of a wallet; it is a state: an address that was clean at onboarding may later be linked to a mixer, be added to a new jurisdiction’s list such as OFAC SDN, or receive a transfer from a cluster that was retroactively deemed fraudulent.

A one-time check looks backward and does not track changes. Therefore, where client relationships last for months, continuous wallet monitoring is introduced: addresses are rechecked on a schedule and on events — a large transaction, a jurisdiction change, or a list update.

Each repeat check compares the current risk profile with the previous snapshot and raises an alert on the delta: the risk category increased, a direct or indirect link to a sanctioned address appeared, or the cluster owner changed.

The second mode is not for everyone. It is mandatory for licensed exchanges and custodial services, work with client deposits, long-term relationships, and high limits — there, abandoning repeat checks means the first signs of risk will appear only at the regulator.

A one-time check is justified for a one-off payment with no further obligations: monitoring there provides nothing but extra noise.

From an engineering standpoint, monitoring is built as an add-on to screening: delta comparison of verdicts so the entire base is not rerun on every registry update, a label cache with an as-of date, an alert queue, and a log of all decision versions — when the regulator requests it, it is clear exactly what and when we knew about the client. Next, we break down how such a loop is assembled.

Technical concerns: matches, load, and enhancements

Engineering concerns at this stage are almost always the same: will screenings be lost during an operation spike, will name checking turn into an endless queue of false positives, can rules be changed without redeploying the service, and how will this fit the client’s accounting system. This needs to be designed before the first release — redoing it later is more expensive.

We briefly address four points below; we will cover the rest together with our engineer on a call based on your process design.

Will the system handle peak load?

Screenings go into a queue: workers pull tasks and are added as queue depth grows, so a spike causes increased latency rather than lost records. Requests to external lists are rate-limited and cached for a short period to avoid hitting the quota.

How can rules be enhanced after launch?

Rules are data, not code: a new list, a changed threshold, or an additional attribute is added to configuration and versioned. Before activation, the rule is run in shadow mode on historical data — you can see how many hits and false flags it will add.

How does integration with the accounting system work?

We work both through a real-time API and via scheduled file exchange — the choice depends on how the operation flow is structured.

Requests are idempotent; if a connection breaks, the task is retried; the screening status is returned to the accounting system, and decisions with rationales go into an immutable audit log.

Let’s discuss your task and come back with an estimate and plan

For the scope estimate to be substantive rather than an industry average, we need a short input from your team. If some points are still open, that is fine — we will go through them together on a call.

• Which assets and networks you serve: blockchains, token types, wallet and contract addresses.
• Where transactions come from: exchange, custodial service, payment gateway, exchanger.
• How screening is arranged now: at what stage the address is checked, and whether there are manual review queues.
• Regulator requirements and internal rules: reporting, data retention periods, and who is responsible for blocks.
• Where to integrate the result: operator interface, your API, or accounting systems.
• Who on the client side handles disputed cases and approves threshold risk scoring rules.

In response, we come back with a scope estimate and implementation plan: stages, dependencies, team composition, and points where your decision is needed.

We also show options to choose from — from a quick address screening launch to a full loop with investigations and reporting — so you can compare timelines and depth of control.

Production handover is a separate stage: procedures for reviewing disputed cases, false positive control, and operator training. Describe your task — we will discuss the details and come back with a plan.