Use casesFinancial institutions & fintech

  • Every financial institution

Sanctions and asset-freeze screening review

Name screening of customers and payment parties raises potential matches all day, most of them a shared or similar name; each one waits for an analyst to compare the person with the list entry.

With the systemEach potential match compared attribute by attribute, every line cited; the analyst or compliance decides.

Who decides
Screening analyst

Payment screening · alert · 4 November 2026

Sanctions list entry · individual

Name: M*** A*** H***. Also known as: Mohammed Al-H***; Muhammad Al-H***. Date of birth: 1962. Nationality: not Turkish. Passport: issued abroad.

→ beneficiary born 1987, Turkish ID; the name matches, the birth date does not

Illustrative The document as it arrives. In red, what the system marks for your expert.

1. The work

Today

  1. GatherYour screening engine checks customers at onboarding and the parties of each payment against the United Nations lists, Türkiye's asset-freeze decisions, and the lists your policy applies (OFAC, EU, UK); for every potential match an analyst opens the customer record, the ID copy, the KYC documents, the payment message, and the list entry.
  2. ReadThe analyst reads the list entry in full: its aliases, birth dates, places of birth, nationalities, passport and ID numbers, addresses, and the free-text remarks, often spelled from Arabic or Cyrillic.
  3. CompareThey compare the customer with the entry attribute by attribute: the name across Turkish, Arabic, and Cyrillic spellings, the date of birth, nationality, ID number, and address.
  4. WriteThe analyst writes the reason by hand: why the person is not the one listed, or why the match cannot be ruled out.
  5. DecideUnder your written policy the analyst closes a false positive with its reason; any true or uncertain match goes to the compliance officer, who decides on the freeze and the payment. Meanwhile your engine keeps the payment held under your policy.

With the system

  1. GatherThe agent opens one worker for each potential match in the alert and reads, read-only, the customer or party record, the KYC documents, the payment message, and the list entry in force; it builds one review file, each fact citing its system.Agentic AI
  2. ReadThe SLM reads the list entry's free text and your KYC documents and returns every alias, birth date, place of birth, nationality, and identifier, each with the line it came from.SLM
  3. CompareEach worker runs your written comparison rules, as code, on one entry: birth date, nationality, and ID number compared exactly, the name through your transliteration tables; an attribute that rules the match out is named.Agentic AI
  4. WriteThe SLM writes the comparison in your review template, every line cited, with a draft reason in your policy's codes; points of doubt are marked, and it never closes the match.SLM
  5. DecideThe screening analyst checks the file against the sources and, as before, closes a false positive under your written policy or escalates; any true or uncertain match, any freeze, and the payment's release are the compliance officer's.Person decides

What lands on the desk

The analyst gets both records side by side, every attribute of the list entry read from its remarks, each one compared by your own rules, and the reason drafted with a source for every line. Closing the alert stays the analyst's, and a match that cannot be ruled out goes to the compliance officer.

FIG. 1 · Screening review fileIllustrative
Payment screening · outgoing transfer · 04.11.2026Beneficiary name: one potential match

Agent · the two records, read-only

  • BeneficiaryIndividual, born 1987, Turkish citizen, address in İzmirKYC
  • EntryListed individual, born 1962, three spellings of the namelist entry
  • RemarksAnother nationality and a foreign passport numberlist entry

Code · attribute by attribute

  • flaggedName matches one listed spelling after transliteration
  • Date of birthdiffers
  • Nationality and place of birthdiffer
  • Shared identifiernone

SLM · comparison, every line cited

The name matches one listed spelling, but the birth date, nationality, and place of birth all differ from the entry, and no identifier is shared. Draft reason: false positive, in your policy's code; the analyst decides.

Status

  • Paymentheld by your engine under your policy
  • Dispositionthe analyst's
  • SLM
  • Agent
  • Code

Why a person decidesClosing a false positive is the analyst's under your written policy; any true or uncertain match, and any freeze, is the compliance officer's.

DecidesScreening analyst

2. The system

For your technical team — skip it if you like.

How it works

In

  • The screening alert and its potential matches
  • Customer or payment-party record
  • KYC documents and the payment message

  1. Agent · acts

    Screening review agent

    Coordinator and one worker per potential match; read-only

    Reads

    • Everything under In

    Out

    • Customer: name, birth date, nationality, ID
    • Payment: parties, banks, and countries
    • Each list entry in force, remarks included
    • One review file, each fact cited

  2. SLM · reasons

    List-entry and document reader

    Fine-tuned SLM; reads list remarks, ID copies, and KYC documents

    Reads

    • List entry: aliases, identifiers, remarks
    • ID copies and KYC documents

    Out

    • Every alias, birth date, and place of birth
    • Nationalities, passport and ID numbers
    • Each attribute with its source line

  3. Code · calculates

    Attribute comparison

    Your written comparison rules, run as code; no model

    Reads

    • The customer's attributes
    • Each list entry's attributes
    • Your transliteration tables

    Out

    • Birth date, nationality, ID: same or different
    • The name across its spellings
    • Attributes that rule the match out
    • Attributes missing on either side

  4. SLM · reasons

    Comparison writer

    SLM, in your screening review template

    Reads

    • The comparison and its sources
    • Your review template and reason codes

    Out

    • Attribute by attribute, each line cited
    • A draft reason in your policy's codes
    • Points of doubt marked

  5. Decision

    Screening analyst, then compliance officer

    Reads

    • The review file and the sources

    Out

    • The analyst closes a false positive under your written policy
    • Any true or uncertain match goes to the compliance officer
    • The compliance officer decides on any freeze
    • A held payment is released only by a person
How the agent's work is arrangedOrchestrator–workers

Orchestrator–workers

Each alert brings its own potential matches, often several list entries for one name, so a coordinator plans one worker per entry and assembles their comparisons into one file.

How the models are trained and tested

Your expert writes the test first. A step the test does not need is skipped, and we say why.

Show the training steps

Small language model (SLM)

  1. Test set

    200–400 past alerts with your senior analysts' attribute-by-attribute reviews and dispositions, true matches and hard false positives included, graded before any training.

  2. Dataset

    Past alerts, list entries, KYC documents, and the reviews your team wrote; personal data masked in training copies where the test allows.

  3. Continued pre-training (CPT)If needed

    Only if the base model fails the test on list remarks and names transliterated from Arabic or Cyrillic.

  4. Supervised fine-tuning (SFT)

    On reading attributes from list remarks and ID documents, and on your review template and reason codes.

  5. Reinforcement learning (RL)Skipped

    Skipped: reading attributes and writing to a template are taught by fine-tuning, and the comparison itself is code.

  6. Retrieval

    The list versions in force, your transliteration tables, and your screening policy are retrieved at each review; lists change, so they never sit in the model's weights.

  7. Monitoring

    The analyst corrects every file, compliance samples closed false positives, and every correction joins the next test.

Where the agentic system stops

Under your written policy, the screening analyst closes a false positive with its reason; any true or uncertain match goes to the compliance officer, who decides on any freeze and on the payment held meanwhile.

Show its tools, limits, and record
Tools and access
Reads the alert and the list entries from your screening system, the customer record from core banking, the KYC and document store, and the payment message from the payment system; runs your comparison code; read-only otherwise; writes only the review file.
May not
Close or dispose of any match, mark a false positive, hold, release, or return a payment, freeze or unfreeze assets, change a list, a threshold, or an exemption list, report to MASAK, contact the customer, or grant itself any access.
Who decides and the written limit
Screening analystUnder your written policy, the screening analyst closes a false positive with its reason; any true or uncertain match goes to the compliance officer, who decides on any freeze and on the payment held meanwhile. A sanctions or asset-freeze match never closes automatically, the system never holds, releases, or returns a payment, never freezes assets, and never reports to MASAK.
Stops when
An identifier that matches exactly, a name that matches with the same birth date or nationality, or any match on a Turkish asset-freeze decision: the file goes to the compliance officer at once, marked; a list entry or document it cannot read with confidence, or missing customer data: to the analyst, marked.
Record
Every source read, each list entry with its list version, each attribute compared and the rule version, each draft, who closed or escalated and why, and any freeze or release and who decided it.

How agentic systems stay inside limits

3. Value and conditions

Where the time goes, and what your institution will measure.

Where the value comes from

  1. Analyst time per potential match.
  2. False positives closed with a consistent, cited reason.
  3. True and uncertain matches reaching the compliance officer sooner.
  4. Payments held no longer than the review needs.

What your institution measures

  • Potential matches reviewed per analyst per day
  • Time from alert to disposition
  • Time a held payment waits
  • Escalations the compliance officer sends back
  • Closed false positives a quality sample reopens
Published elsewhere
LSEG reports that in its survey of about 400 senior compliance leaders, 32% of respondents said that in a typical month they see false-positive rates of 20–30% in their sanctions and AML screening.

LSEG Risk Intelligence, "Why you need better screening data" (April 2025) · vendor-reported

Measured in the Decision Blueprint

Analyst minutes per potential match and the time from alert to disposition, from your case log, set the baseline; your institution sets the target.

Conditions

The rules, the data, and the known error, with its guard.

  • Freezing decisions for people and entities listed under the United Nations Security Council resolutions Law 6415 names are published by Presidential decision in the Resmî Gazete and applied without delay (art. 5); a national freeze is decided jointly by the Minister of Treasury and Finance and the Minister of the Interior (art. 7/3). A decision takes effect on publication, and any transaction against it is void (arts. 12/1 and 10).
  • Those who hold a receivable from or owe a debt to a person under a freeze report its amount and basis to MASAK within thirty days of publication (Law 6415 art. 12/3).
  • Under Law 7262 (proliferation financing), the assets in Türkiye of people and entities named in the Security Council's resolutions, and their vessels, are frozen by Presidential decision published in the Resmî Gazete, without delay, and the final lists are published on the relevant public bodies' websites (art. 3).
  • Lists change, so each review reads the list version in force; OFAC, EU, and UK lists apply only as your policy says. No machine-learning model is needed: the comparison is written in your policy and run as code. Data stays on your servers.

Start here

We replay a recent month of potential matches with your screening analysts and compliance officer, time each comparison, collect your transliteration tables and reason codes, and test the reader on your own list entries and KYC documents before anything is built.

Who builds it Every engagement is led by an engineer who has built machine-learning models that real decisions run on since 2012, and language models and agentic systems in production since 2024. About eqlx

Request a Decision BlueprintWhat the Decision Blueprint covers

Equalize the gap.

Bring work that takes expertise. Leave knowing the first step.

A short description of the work is enough; no confidential records.

  1. You send a short descriptionNo confidential records, credentials, or production data
  2. The engineer checks whether it fits, and what it would needA model, a small language model, an agent, or none
  3. A proposed first step, or an honest “not a fit”A technical conversation with the engineer
Start with a Decision BlueprintTalk to the engineer

https://eqlx.ai/use-cases/sanctions-screening · Printed copy; the website is the current version.