Sanctions screening (sankční prověrka)

Definice a přehled

Sankční prověrka (sanctions screening) je regulatorní proces systematického porovnávání fyzických osob, organizací, plavidel, adres a dalších subjektů s oficiálními sankčními seznamy, které vedou státní a nadnárodní orgány. Hlavními seznamy jsou konsolidovaný sankční seznam Evropské unie, seznam SDN (Specially Designated Nationals) amerického úřadu OFAC (Office of Foreign Assets Control), seznam britského úřadu OFSI (Office of Financial Sanctions Implementation) a konsolidovaný seznam Rady bezpečnosti OSN. Proces identifikuje sankcionované subjekty, politicky exponované osoby (PEP) a subjekty podléhající restriktivním opatřením, včetně zmrazení majetku, zákazů cestování, zbrojních embarg a obchodních omezení.

Sankční prověrka stojí na průsečíku regulatorního souladu, prevence finanční kriminality a národní bezpečnosti. Organizace, na něž se sankční předpisy vztahují – finanční instituce, pojišťovny, zprostředkovatelé obchodu a stále častěji i technologické firmy –, musí před navázáním obchodního vztahu nebo zpracováním platby prověřit protistrany, zákazníky, skutečné majitele a transakce proti příslušným seznamům. Nesplnění povinností přináší přísné sankce včetně trestního stíhání, vysokých pokut (u závažných porušení v řádu miliard dolarů) a poškození pověsti. V České republice provádění mezinárodních sankcí upravuje zákon č. 69/2006 Sb., o provádění mezinárodních sankcí.

Prismatic Platform implementuje sankční prověrku jako integrovanou součást své pipeline OSINT a fúze zpravodajských informací a využívá model souběžnosti Elixiru k paralelní prověrce proti více seznamům s odezvou pod sekundu. Výsledky prověrek vstupují přímo do bezpečnostních hodnocení a posouzení souladu a dávají jednotný pohled na riziko subjektu v regulatorní, bezpečnostní i provozní dimenzi.

Pro Kompendium je sankční prověrka pojmem z kontextu platformy. Kniha se jí dotýká tam, kde rozhoduje o lidech: shoda jména na seznamu je hypotéza, ne zjištění, a neopatrné závěry mohou poškodit nevinné osoby se stejným nebo podobným jménem (viz EA × OSINT: Sankční seznamy a atribuční bias).

Historický kontext a regulatorní prostředí

Moderní sankční režim má kořeny v americkém zákoně Trading with the Enemy Act z roku 1917 a v sankcích Společnosti národů proti Itálii v roce 1935. Sankční prostředí v dnešní podobě však vzniklo hlavně po útocích z 11. září 2001, kdy byl globální finanční systém mobilizován jako zbraň proti financování terorismu. Zákon USA PATRIOT Act z roku 2001 výrazně rozšířil pravomoci OFAC a rozsah povinností finančních institucí v oblasti sankčního souladu.

V Evropě vyvinula Evropská unie vlastní sankční rámec prostřednictvím rozhodnutí v rámci společné zahraniční a bezpečnostní politiky (SZBP), prováděných nařízeními Rady, která jsou přímo použitelná ve všech členských státech. Sankční prostředí EU se dramaticky zkomplikovalo po ruské anexi Krymu v roce 2014 a po plnohodnotné invazi na Ukrajinu v roce 2022, která vyvolala nejrozsáhlejší sankční balíčky v dějinách EU – více než deset po sobě jdoucích balíčků s tisíci individuálních označení osob a subjektů.

Odchod Spojeného království z EU vytvořil třetí velký sankční režim; jeho právním základem je zákon Sanctions and Anti-Money Laundering Act 2018 a vymáhání finančních sankcí má na starosti OFSI při britském ministerstvu financí. Rada bezpečnosti OSN vede vlastní konsolidovaný seznam, který jsou členské státy povinny provádět, ale který se rozsahem a výkladem může od národních provedení lišit.

Tato víceúrovňová složitost napříč jurisdikcemi je základní technickou výzvou sankční prověrky. Subjekt může být sankcionován jedním orgánem, a jiným ne, nebo sankcionován v různých programech s různými omezeními. Prismatic Platform to řeší paralelní prověrkou proti všem hlavním seznamům a konsolidovaným posouzením rizika, které zohledňuje konkrétní regulatorní povinnosti prověřující organizace.

Technický rozbor

Algoritmy porovnávání

Systémy sankční prověrky kombinují více strategií porovnávání, aby maximalizovaly záchyt a zároveň udržely míru falešně pozitivních shod pod kontrolou:

Algoritmus	Přístup	Silná stránka	Slabina	Váha v Prismatic
Přesná shoda	porovnání znak po znaku	nula falešně pozitivních	mine jakoukoli variantu	1,0
Soundex/Metaphone	porovnání fonetického kódu	zachytí výslovnostní varianty	jazykově specifické, vysoká míra FP	0,6
Levenshteinova vzdálenost	editační vzdálenost řetězců	zachytí překlepy a drobné odchylky	výpočetně náročné	0,8
Jaro-Winkler	vážené transpozice znaků	dobré pro porovnávání jmen	citlivé na rozdíly délky	0,85
N-gramy	míra překryvu podřetězců	jazykově nezávislé	vysoká míra falešně pozitivních	0,7
Tokenové	porovnání slov s přeskupením	zvládá různé pořadí jmen	mine částečné shody jmen	0,75

Produkční systémy obvykle kombinují více algoritmů ve skórovací pipeline, v níž každý algoritmus přispívá váženým skóre do složené důvěry shody. Shody nad nastavitelným prahem (ve výchozí konfiguraci Prismatic Platform 0,85) se označí k lidskému přezkumu, jasné neshody projdou automaticky.

Pipeline normalizace jmen

Před porovnáním procházejí jména subjektů normalizační pipeline, která řeší běžné varianty:

defmodule PrismaticIntel.SanctionsScreening.NameNormalizer do
  @moduledoc """
  Normalizes entity names before sanctions matching to improve
  detection rates. Handles transliteration, honorific removal,
  script conversion, and cultural naming pattern normalization.
  """

  @spec normalize(String.t()) :: {:ok, list(String.t())} | {:error, term()}
  def normalize(name) when is_binary(name) do
    variants =
      name
      |> String.trim()
      |> generate_variants()
      |> Enum.map(&apply_normalizations/1)
      |> Enum.uniq()

    {:ok, variants}
  end

  defp generate_variants(name) do
    [
      name,
      remove_honorifics(name),
      remove_diacritics(name),
      transliterate(name),
      reverse_name_order(name)
    ]
    |> Enum.reject(&is_nil/1)
  end

  defp apply_normalizations(name) do
    name
    |> String.downcase()
    |> String.replace(~r/[^\p{L}\p{N}\s]/u, "")
    |> String.replace(~r/\s+/, " ")
    |> String.trim()
  end

  defp remove_honorifics(name) do
    honorifics = ~w(mr mrs ms dr prof sir dame lord lady haj sheikh)
    words = String.split(name, " ")
    filtered = Enum.reject(words, fn w -> String.downcase(w) in honorifics end)
    Enum.join(filtered, " ")
  end

  defp remove_diacritics(name) do
    name
    |> :unicode.characters_to_nfd_binary()
    |> String.replace(~r/[\x{0300}-\x{036f}]/u, "")
  end

  defp transliterate(name), do: name
  defp reverse_name_order(name) do
    parts = String.split(name, " ", trim: true)
    if length(parts) >= 2, do: Enum.join(Enum.reverse(parts), " "), else: nil
  end
end

Správa a příjem seznamů

Sankční seznamy se zveřejňují v různých formátech (XML, CSV, PDF, JSON) s různou frekvencí aktualizací a různými schématy. ListManager platformy převádí tyto různorodé zdroje do jednotného interního formátu:

Seznam	Orgán	Frekvence aktualizace	Formát	Položky (přibližně, v době zápisu)
EU konsolidovaný	Evropská komise	denně	XML	10 000+
OFAC SDN	ministerstvo financí USA	několikrát týdně	XML, CSV, PDF	12 000+
OFSI	ministerstvo financí Spojeného království	týdně	CSV, XML	4 000+
OSN konsolidovaný	Rada bezpečnosti OSN	dle potřeby	XML	800+
Seznamy PEP	různí poskytovatelé	měsíčně	proprietární	1 000 000+

defmodule PrismaticIntel.SanctionsScreening.ListManager do
  @moduledoc """
  Manages sanctions list ingestion, normalization, and caching.
  Lists are fetched from authoritative sources, parsed into a
  unified schema, and cached in ETS for sub-millisecond lookup.
  Automatic refresh ensures lists are never stale beyond the
  configured maximum age.
  """

  use GenServer

  @type list_entry :: %{
    id: String.t(),
    source_list: atom(),
    names: list(String.t()),
    aliases: list(String.t()),
    date_of_birth: Date.t() | nil,
    nationalities: list(String.t()),
    entry_type: :individual | :entity | :vessel | :aircraft,
    sanctions_programs: list(String.t()),
    designation_date: Date.t(),
    last_updated: DateTime.t()
  }

  @spec start_link(keyword()) :: GenServer.on_start()
  def start_link(opts) do
    GenServer.start_link(__MODULE__, opts, name: __MODULE__)
  end

  @impl true
  def init(opts) do
    table = :ets.new(:sanctions_lists, [:set, :public, read_concurrency: true])
    schedule_refresh(Keyword.get(opts, :refresh_interval, :timer.hours(1)))
    {:ok, %{table: table, last_refresh: nil}, {:continue, :initial_load}}
  end

  @impl true
  def handle_continue(:initial_load, state) do
    load_all_lists(state.table)
    {:noreply, %{state | last_refresh: DateTime.utc_now()}}
  end

  @spec get_entries(atom()) :: [list_entry()]
  def get_entries(list_name) do
    :ets.match_object(:sanctions_lists, {list_name, :_})
    |> Enum.map(fn {_list, entry} -> entry end)
  end

  defp load_all_lists(table) do
    [:eu_consolidated, :ofac_sdn, :ofsi, :un_consolidated]
    |> Task.async_stream(&fetch_and_parse/1, max_concurrency: 4, timeout: 60_000)
    |> Enum.each(fn {:ok, {list_name, entries}} ->
      Enum.each(entries, fn entry ->
        :ets.insert(table, {list_name, entry})
      end)
    end)
  end

  defp fetch_and_parse(list_name) do
    # Fetch from authoritative source and parse into unified schema
    {list_name, []}
  end

  defp schedule_refresh(interval) do
    Process.send_after(self(), :refresh, interval)
  end
end

Srovnání s alternativami

Přístup	Pokrytí	Rychlost	Přesnost	Náklady
Vlastní prověrka	přizpůsobitelné	rychlá (lokálně)	závisí na implementaci	vývoj + údržba
Komerční SaaS (Dow Jones, Refinitiv)	úplné + PEP	latence API	vysoká (vyladěné modely)	cena za dotaz
Bureau van Dijk / Moody's	zaměření na finance	střední	velmi vysoká	podniková licence
Jen otevřené seznamy	jen vládní seznamy	rychlá	omezená (bez PEP)	zdarma (seznamy) + vývoj
Integrace v Prismatic	více seznamů + obohacení z OSINT	paralelní, pod sekundu	vysoká (neostré porovnání + slučování)	součást platformy

Komerční poskytovatelé prověrek nabízejí širší pokrytí dat (zejména databáze PEP, negativní mediální zmínky a vlastnické struktury firem), ale přinášejí závislost na API, náklady za dotaz a otázky umístění dat. Vlastní prověrka dává plnou kontrolu a odstraňuje náklady za dotaz, ale vyžaduje významné investice do správy seznamů, vývoje porovnávacích algoritmů a průběžné údržby.

Auditní stopa a dokumentace souladu

Každá operace prověrky vytváří neměnný auditní záznam, který dokumentuje parametry prověrky, výsledky a rozhodnutí:

defmodule PrismaticIntel.SanctionsScreening.AuditLogger do
  @moduledoc """
  Records immutable audit logs for all sanctions screening operations.
  Required by regulatory frameworks for compliance evidence.
  Records are retained for the configured period (minimum 5 years).
  """

  @spec log_screening(screening_result(), keyword()) :: {:ok, String.t()} | {:error, term()}
  def log_screening(result, opts \\ []) do
    audit_record = %{
      screening_id: result.screening_id,
      entity_screened: result.entity,
      lists_checked: result.lists_checked,
      match_count: length(result.matches),
      risk_level: result.risk_level,
      confidence: result.confidence,
      screened_at: result.checked_at,
      screened_by: Keyword.get(opts, :operator, "system"),
      disposition: Keyword.get(opts, :disposition, :pending_review),
      disposition_reason: Keyword.get(opts, :reason),
      retention_until: Date.add(Date.utc_today(), 365 * 7)
    }

    {:ok, audit_record.screening_id}
  end
end

Osvědčené postupy

Kalibrovat prahy shody podle ochoty nést riziko. Příliš nízké prahy vytvářejí zahlcující množství falešně pozitivních shod, příliš vysoké hrozí přehlédnutím skutečných shod. Začít na 0,85 a upravovat podle provozní zkušenosti a regulatorních pokynů.
Aktualizace seznamů uplatňovat neprodleně. Sankční označení nabývají účinnosti okamžitě po zveřejnění. Automatizované pipeline příjmu s ověřením integrity mají aktualizace zpracovat do několika hodin od zveřejnění.
Dokumentovat všechna rozhodnutí z prověrek. Regulátoři očekávají úplné auditní stopy, které dokládají důkladný přezkum shod, zdokumentované zdůvodnění rozhodnutí a uchování záznamů po dobu 5–7 let.
Prověřovat průběžně, ne jen při navázání vztahu. Dávková opakovaná prověrka existujících vztahů při každé aktualizaci seznamů zachytí subjekty označené až po úvodním schválení.
Kombinovat více algoritmů porovnávání. Žádný jednotlivý algoritmus nezachytí všechny typy variant. Víceúrovňová skórovací pipeline platformy pokrývá transliteraci, fonetickou podobnost i typografické odchylky.
Slučovat entity napříč seznamy. Tentýž sankcionovaný subjekt uvedený na více seznamech pod různými variantami jména je třeba sloučit do jediného záznamu, aby bylo posouzení rizika přesné (viz Entity Resolution).

Časté chyby

Prověrka proti zastaralým seznamům: používání starých verzí seznamů vytváří mezery v souladu. Zavést automatickou obnovu s výstrahami při zastarání.
Přílišné spoléhání na přesnou shodu: přesná shoda mine prakticky všechny pokusy o obcházení. Neostré porovnávání je pro smysluplnou detekci povinné.
Přehlížení aliasů a transliteračních variant: sankcionované subjekty používají aliasy, transliterace a záměrné zamlžování. Normalizace a generování variant jsou nezbytnými kroky předzpracování.
Nezohlednění rozdílů písma: arabská, cyrilská a čínská jména mají více platných přepisů do latinky. Porovnávání napříč písmy vyžaduje specializovanou práci s transliterací.
Brát prověrku jako jednorázovou kontrolu: sankční seznamy se průběžně aktualizují. Průběžné monitorování je regulatorním očekáváním, ne volitelným vylepšením.
Zaměnit shodu jména s identitou: každou shodu nad prahem musí potvrdit další identifikátory (datum narození, státní příslušnost, adresa, registrační čísla) – jinak hrozí újma osobám se shodným jménem.

Související

Pojmy v tomto glosáři

OSINT – metodika přístupu k veřejným sankčním datům.
Intelligence Fusion – korelace výsledků prověrek z více zdrojů.
Entity Resolution – technologie deduplikace, na níž stojí přesnost prověrky.
Compliance Framework – regulatorní požadavky, z nichž povinnost prověrky plyne.
Due Diligence – hlavní kontext užití.
Risk Score – skórování rizik, do něhož výsledky vstupují.

Hesla a přehledy platformy mimo tuto knihu

NIS2, Security Rating, Threat Intelligence, Audit Trail, SDN List.
Architektura, Technologie, Aplikace.

Kniha

EA × OSINT: Sankční seznamy a atribuční bias – zkreslení při práci se sankčními daty. regulatorní prověrka v detekci EA.

Autor a zapojení

Autor: Tomáš Korcak (korczis) | Licence: GHL

GitHub | Wiki | LinkedIn | Kontakt
Architektura | O autorovi

Strukturní vazby

Bridge: sanctions-screening – most: jak se tento pojem projevuje v kapitolách knihy

#glossary #compliance #osint #due-diligence

Související pojmy

OSINT (zpravodajství z otevřených zdrojů)osint Intelligence fusion (fúze zpravodajství)osint Entity Resolution (sjednocování entit)intelligence Compliance Framework (rámec souladu)security

Odkazují sem 11

Okolí stránky

Otevřít v Mapě knihy →