Санкционный комплаенс по платежам

1) Зачем это нужно (рамка риска)

Юридический риск: штрафы/отзыв лицензии за нарушение санкционных режимов.
Финансовый риск: заморозка средств/счетов на коридоре (корреспондент/PSP/схема).
Операционный риск: форс-мажорные возвраты, зависшие транзакции, рост ручных проверок.
Репутация: «санкционные» инциденты бьют по банкам-партнерам и доступу к коридорам.

2) Режимы и принципы

Списки: OFAC (SDN/SSI), EU, UK (OFSI), CA, AU, ООН, локальные.
Гео-эмбарго: полные запреты по странам/территориям.
Секторальные: ограничения по отраслям/срокам финансирования (SSI/Directive).
«50% правило»: если один или несколько SDN владеют совокупно ≥50% — субъект считается заблокированным, даже если не поименован.
Экспорт-контроль/двойного назначения: платеж за запрещенный товар/услугу (важно в А2А/SWIFT ремитах).
Крипто/Travel Rule: передача KYC-атрибутов между VASP при трансграничных переводах.

3) Где и как скринить (платежный контур)

3.1. Депозиты

Плательщик: имя/адрес/дата рождения (если доступны), карта (BIN-гео), кошелек, IP/ASN, девайс.
Провайдер: PSP/MID и их юрисдикция; проверка «чистоты» маршрута.
События: создание профиля (L0), первый депозит (L1), аномалии (velocity/гео-конфликт).

3.2. Выводы

Бенефициар: IBAN/BIC/имя/адрес, карта/кошелек, крипто-адрес (VASP).
Маршрут: same-method/return-to-source, банк-получатель, возможные корреспонденты.
Travel Rule (крипто): обмен originator/beneficiary-данными, проверка VASP-статуса.

3.3. Маршрутизация/коридоры

A2A/SEPA/FPS/PIX/RTP: банк-получатель и его страна/санк-риск.
Push-to-card: банк-эмитент карты (BIN-страна/банк).
SWIFT: банки-корреспонденты (все звенья цепочки).
E-wallets: юрисдикция эмитента/оператора кошелька.

4) Типы скрининга и сигналы

Имя/алиасы/транслитерации (фаззи-матч, редукция диакритики).
Адрес/город/почтовый индекс (гео-триггеры, «санкционные» локации).
Дата рождения/паспорт/MRN (когда доступны из KYC).
Организации/БЕНЕФИЦИАРЫ (UBO): расширенный due diligence.
IBAN/BIC и банк-получатель: страна, «санкционный банк» или подсанкционный UBO.
BIN/эмитент карты: страна/банк, cross-check с санк-перечнями.
IP/ASN/VPN/хостинг: санк-гео, прокси/теневые ASN.
Device-graph/household: пересечения с ранее заблокированными.
Крипто-адреса: метки «санкционные/миксеры/риcковые кластеры» у блокчейн-провайдеров.
Гео-конфликт: KYC-страна ≠ IP ≠ SIM ≠ BIN-гео.

5) Оркестрация скрининга: «где встраивать»

1. Onboarding: легкий скрининг по имени/ДР, country risk.
2. Payment init: синхронный hit-check плательщика/бенефициара, IBAN/BIN, IP/ASN.
3. Pre-routing: deny/hold/step-up (SoF/документы) до отправки в коридор.
4. In-flight: мониторинг статусов от PSP/банков (returns/holds).
5. Post-event: ретроспективный рескрининг при обновлении списков (backfill).

6) Политика решений (risk-based)

AUTO-PASS: нет хитов; низкий риск страны/банка; same-method; ND≥0.
MANUAL REVIEW: fuzzy-хит ниже высокого порога; новый бенефициар; гео-конфликт; высокий country/sector risk.
DENY/BLOCK: точный SDN-хит, «50% правило», эмбарго GEO, санкционный банк/коридор.
STEP-UP: запрос SoF/SoW, подтверждение адреса/имени бенефициара, «name check/IBAN» (где доступно).

7) Снижение ложных срабатываний (precision)

Нормализация ФИО (перестановка имен/фамилий, отчество, падежи, частицы).
Контекстные атрибуты: дата рождения/город снижают FPR.
White-lists: проверенные бенефициары/банки/IBAN (с TTL и ревалидaцией).
Блэк-лист ASN/VPN: меньше шумных хитов по IP.
Сегментные пороги: строже для high-risk GEO/коридоров, мягче для low-risk.
Auto-разрешение после ручного APPROVE с одинаковым фингерпринтом (device/IBAN).
Журналы объяснимости: почему отклонено/разрешено (скор, правила, поля-совпадения).

8) UX и коммуникации

Прозрачные причины: «Необходима валидация получателя из-за банка/страны».
Сроки: честные ETA для ручной проверки/SoF.
Возвраты: автоматический рефанд в игровой кошелек, ссылка «выбрать другой метод/получателя».
Локализация: юридические тексты, ссылки на политику санкций/поддержку.

9) Инженерия: модель данных (минимум)

sql sanctions.watchlists (
source TEXT,      -- OFAC, EU, UK, UN, etc.
entity_id TEXT,    -- уникальный ID записи entity_type TEXT,   -- person    org    vessel    bank name TEXT, aliases TEXT[], dob DATE, country TEXT,
programs TEXT[],    -- санкционные программы ownership_json JSONB, -- связи для "50% правила"
updated_at TIMESTAMP
);

sanctions.hits (
hit_id PK, user_id, payout_id, deposit_tx_id,
entity_id, source, match_score NUMERIC, match_fields JSONB,
status TEXT,      -- OPEN    APPROVED    DENIED    ESCALATED    FALSE_POSITIVE reviewer TEXT, decided_at TIMESTAMP, created_at TIMESTAMP
);

payments.endpoints (
beneficiary_id PK, user_id, type, -- IBAN    CARD    WALLET    CRYPTO iban TEXT, bic TEXT, bin TEXT, wallet_ref TEXT, crypto_addr TEXT,
bank_country TEXT, bank_name TEXT, verified BOOLEAN,
last_screened_at TIMESTAMP, risk_tags TEXT[]
);

risk.context (
user_id, ip INET, asn INT, device_hash TEXT,
geo_ip TEXT, geo_kyc TEXT, geo_sim TEXT, updated_at TIMESTAMP
);

10) Псевдо-DSL политики

yaml policy: "sanctions_payments_v4"
lists:
sources: [OFAC, EU, UK, UN, CA]
refresh_interval_hours: 6 screening:
on_user_create: true on_deposit_init: true on_payout_init: true on_new_beneficiary: true rescreen_on_list_update: true thresholds:
name_fuzzy_pass: 0.72 name_fuzzy_manual: 0.62 org_fuzzy_pass: 0.80 crypto_risk_max: "MEDIUM"
routing_guards:
deny_if:
- geo in [EMBARGOED]
- bank_sanctioned == true
- ownership_sdn_agg >= 0.5  # "50% правило"
manual_review_triggers:
- fuzzy_hit == true
- new_beneficiary == true AND amount > 1000 EUR
- geo_conflict_score >= 2
- vasp_untrusted == true stepups:
- if: payout_amount > 2000 EUR then: ["name_check_iban"]
- if: crypto == true then: ["travel_rule", "beneficiary_vasp_check"]
audit:
store_feature_snapshot: true store_decision_tree: true exceptions:
whitelist_beneficiary_ttl_days: 180

11) SQL-шаблоны

11.1. Фаззи-поиск по именам/алиасам

sql
SELECT w.entity_id, w.source, w.name,
similarity(unaccent(lower(:full_name)), unaccent(lower(w.name))) AS score
FROM sanctions.watchlists w
WHERE w.entity_type='person'
AND (unaccent(lower(:full_name)) % unaccent(lower(w.name))
OR EXISTS (SELECT 1 FROM unnest(w.aliases) a
WHERE unaccent(lower(:full_name)) % unaccent(lower(a))))
ORDER BY score DESC LIMIT 20;

11.2. Проверка «50% правила» по владению

sql
SELECT entity_id
FROM sanctions.watchlists
WHERE entity_type='org'
AND (ownership_json->>'sdn_agg_share')::numeric >= 0.5;

11.3. Tриггер рескрининга при обновлении списка

sql
INSERT INTO sanctions.hits (user_id, entity_id, source, match_score, status, created_at)
SELECT u.user_id, w.entity_id, w.source, 0.0, 'OPEN', now()
FROM users u
JOIN sanctions.watchlists w ON w.updated_at >:last_run
WHERE u.country IN (:risk_geos);

11.4. IBAN/банк-получатель: риск-гвард

sql
SELECT e.beneficiary_id,
(e.bank_country = ANY(:embargo_geos)) AS embargo_hit,
(e.bic IN (SELECT bic FROM ref.sanctioned_banks)) AS bank_hit
FROM payments.endpoints e
WHERE e.beneficiary_id=:bid;

11.5. Crypto Travel Rule (упрощенный контроль)

sql
SELECT v.vasp_id, v.trust_level, tx.crypto_addr
FROM crypto.transfers tx
JOIN ref.vasps v ON v.domain = tx.beneficiary_vasp
WHERE tx.payout_id =:pid;

12) KPI и дашборды

Hit Rate: доля транзакций/бенефициаров с санкционными хитами.
False Positive % и Manual Approve %.
Manual TAT p50/p95 (время решения).
Denied % по режимам/гео/коридорам/банкам.
Rescreen backlog после обновления списков.
Returns/holds % по санк-кодам от PSP/банков.
Travel Rule coverage % (крипто).
Whitelisted TTL breach % (протухшие «доверенные» без ревалидации).

13) Алерты

List Update Spike: резкий рост хитов после обновления списков.
FPR Surge: False Positive % > порога d/d.
Manual Backlog: открытые кейсы > лимита или p95 TAT > SLA.
Embargo Route Hit: попытки провести платежи по запрещенным гео/банкам.
Travel Rule Missing: крипто-переводы без обмена данными VASP.
Policy Drift: транзакции без снапшота правил/решения.

14) Плейбуки инцидентов

A. Массовые хиты после обновления OFAC/EU

1. Заморозить авто-роутинг на риск-коридорах → MANUAL.
2. Приоритет по сумме/ETA, быстрое обучение операторам новых алиасов/орфографий.
3. Коммуникация PSP/банкам: предупредить о временном росте ручных.

B. Возвраты со стороны банка-корреспондента

1. Нормализовать код причины, собрать образцы (BIC, коридор).
2. Временно исключить банк/коридор из каскада, reroute.
3. Пост-мортем: обновить справочник «санк-банков», усилить precheck.

C. Крипто без Travel Rule

1. Блокировать выводы на непроверенных VASP, запросить данные.
2. Включить «only trusted VASP» до исправления интеграции.
3. Ретест и отчет регулятору при необходимости.

15) Best practices (коротко)

1. Policy-as-code с версиями и снапшотами признаков/решений.
2. Скрининг в нескольких точках (профиль, init, pre-route, post).
3. Учитывайте 50% правило и UBO-связи, а не только поименные записи.
4. Name normalization и контекст (ДР/город) для снижения FPR.
5. Белые списки проверенных бенефициаров/банков с TTL и ревалидaцией.
6. Сегментируйте пороги по GEO/методу/коридору.
7. Логи объяснимости и аудит-трейл: «кто/когда/почему».
8. Договоритесь с PSP/банками о кодах возвратов и SLA ручных.
9. Travel Rule и реестр доверенных VASP для крипто.
10. Регулярные пост-инциденты и тюнинг правил.

16) Чек-лист внедрения

• Источники списков и частота обновления (OFAC/EU/UK/UN/локальные).
• Политика «50%» и UBO-граф.
• Скрининг на onboarding/deposit/payout/new beneficiary/rescreen.
• Интеграции: PSP/банки/васпы, коды возвратов.
• Пороговая матрица (pass/manual/deny), сегменты GEO/методов.
• Белые/черные списки (beneficiary/bank/ASN/IP) с TTL.
• Логи объяснимости, снапшоты признаков/решений, отчеты для лицензий.
• Дашборды KPI и алерты; SLA ручных.
• Плейбуки (обновление списков, возвраты, Travel Rule).
• Обучение операторов (алиасы/транслитерации, country-редкости).

Резюме

Санкционный комплаенс по платежам — это оркестрация правил, данных и маршрутов, а не просто «пробить по списку». Встраивайте скрининг в ключевые точки платежного пути, учитывайте UBO и 50% правило, управляйте коридорами/банками, снижайте ложные срабатывания через нормализацию и контекст, храните объяснимые решения и версии политик как код. Так вы сохраните доступ к коридорам, снизите операционные издержки и выдержите требования лицензий без убийства конверсии.