Санкційний комплаєнс по платежах

1) Навіщо це потрібно (рамка ризику)

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

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

Списки: OFAC (SDN/SSI), EU, UK (OFSI), CA, AU, ООН, локальні.
Гео-ембарго: повні заборони по країнах/територіях.
Секторальні: обмеження по галузях/термінах фінансування (SSI/Directive).
«50% правило»: якщо один або кілька SDN володіють сукупно ≥50% - суб'єкт вважається заблокованим, навіть якщо не поіменований.
Експорт-контроль/подвійного призначення: платіж за заборонений товар/послугу (важливо в A2A/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: перетину з раніше заблокованими.
Крипто-адреси: мітки «санкційні/міксери/ризикові кластери» у блокчейн-провайдерів.
Гео-конфлікт: 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 і ревалідацією).
Блек-лист 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. Тригер рескринінгу при оновленні списку

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. Пріоритет за сумою/ЕТА, швидке навчання операторам нових аліасів/орфографій.
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 і ревалідацією.
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% правило, керуйте коридорами/банками, знижуйте помилкові спрацьовування через нормалізацію і контекст, зберігайте пояснювані рішення і версії політик як код. Так ви збережете доступ до коридорів, знизите операційні витрати і витримайте вимоги ліцензій без вбивства конверсії.