Блекісти та блок-листи в платіжній логіці

TL; DR

Блекіст/блок-лист - це керований шар «жорстких» і «м'яких» заборон у платіжному пайплайні. Його цінність - швидке відсікання свідомо ризикованих ідентифікаторів (карти, IBAN, крипто-адреси, пристрої, IP і т. д.) до дорогих перевірок і спроб списання. Ключ до ефективності - чітка модель даних (терміни дії, джерело, причина, юрисдикція, рівень впевненості), ізольований сервіс з сильним кешем і аудитом, узгоджені політики TTL/амністії, а також метрики «hit-rate ↔ overblock».

1) Терміни та відмінності

Blacklist/Deny-list/Блок-лист - набір ідентифікаторів, при збігу з якими операція жорстко відхиляється (HARD BLOCK).
Stop-list (контекстний) - блокування в конкретному контексті (наприклад, тільки на висновки, тільки в країні X, тільки для суми> € Y).
Watchlist/Greylist - «спостереження»: операція не відхиляється відразу, але переводиться в STEP-UP (3DS/OTP/доп. див. KYC) або Manual Review.
Allow-list/White-list - явна роздільна здатність, яка переважує сірі сигнали (наприклад, VIP, підтверджений банк-аккаунт).
Negative List (внутрішня) - список на основі внутрішніх інцидентів (чарджбекі, бонус-аб'юз, санкційні збіги, мультиаккаунтинг).

💡 Рекомендація: в термінах платформи використовувати Deny (hard), Stop (scoped hard), Observe (soft), Allow (override).

2) Що саме «гортаємо»: ідентифікатори

Платіжні реквізити

Карта: PAN-токен/FPAN-хеш, BIN, емітент/країна (для гео-політик), термін, ім'я носія (опціонально, хеш/фаззі).
Банківські: IBAN/BIC, рахунок/routing (ACH/SEPA), ім'я власника (нормалізований хеш).
E-wallet/фінтех: гаманець (PayPal/Skrill/Neteller тощо), UPI/PIX ID, Open-Banking PISP-платник.
Крипто: адреси L1/L2, мітки (mixer/санкції/високоризик), ланцюжок (ETH/BTC/TON тощо).

Комунікаційні та поведінкові

Email/телефон (з нормалізацією, облік «одноразових» доменів і перерозподілюваних номерів).
Пристрій/браузер-фінгерпринт, клієнтський ключ, mobile-ID.
Мережеві: IP (ASN/проксі/VPN/дата-центр) ,/24-підмережі, гео-локейшн.

Акаунтні та контрагентські

UserID/CustomerID, партнер/афіліат, промо-джерело.
PSP/MID/Acquirer (для операційних блокувань за маршрутами).
Адреса/ПІБ (хеш-нормалізація, fuzzy-matching за токенами).

3) Джерела поповнення списків

Внутрішні події: чарджбеки, фрод-алерти, бонус-аб'юз (мультиаккаунт, скоринг «взяв бонус - вивів без обороту»), санкційні збіги, self-exclusion/MLRO-прапори.
Зовнішні джерела: негатив-листи PSP/еквайєрів, консорціумні бази (shared fraud intel), провайдери за крипто-мітками, BIN-бази, моделі ризику.
Правила та ручне введення: рішення комплаєнсу/ризик-офісу, «freeze» на інцидент.

4) Модель даних (мінімально достатня)

json
{
"key": "card:pan_token:9c4f...e1",
"scope": {
"action": ["deposit","withdrawal","payout"],
"jurisdiction": ["EEA","CA-ON"],
"product": ["casino","sports"]
},
"policy": "deny    stop    observe    allow",
"reason_code": "CHARGEBACK    BONUS_ABUSE    SANCTION_MATCH    MFA_BYPASS    KYC_FAIL    CONSORTIUM_HIT",
"source": "risk_engine    psp_x    mlro    consortium",
"confidence": 0. 92,
"created_at": "2025-10-01T12:30:00Z",
"expiry_at": "2026-01-01T00:00:00Z",
"ttl_days": 90,
"review_after": "2025-12-01T00:00:00Z",
"metadata": {
"case_id": "INC-2025-10344",
"notes": "2 CB in 45 days; bonus cycling through 3 wallets,"
"hash_algorithm": "sha256+salt",
"tenant": "brand_A"
}
}

Обов'язкові поля: `key`, `policy`, `reason_code`, `source`, `created_at`, `expiry_at/ttl`.
Хороша практика: зберігати scope (дія/юрисдикція/продукт) і confidence (для м'яких політик).

5) Архітектура сервісу списків

Виділений сервіс ListService (статус «істини» для всіх мікросервісів).

API:

`GET /v1/list/check? key =... & ctx =...'- синхронна перевірка (p99 <5-10 мс з Redis).
'POST/v1/list/upsert'- масовий/одиничний запис з валідацією і аудитом.
'POST/v1/list/bulk'- завантаження CSV/NDJSON з dry-run.
`POST /v1/list/review/:id'- розмітка/амністія/продовження.
Сховище: Redis (гарячий кеш, TTL) + Postgres (історія/аудит) + DLQ/лог-шина (Kafka) для event-sourcing і реплікації.
Доступи: write - тільки ризик/комплаєнс/MLRO через RBAC + 4-очний контроль на чутливі ключі (банківські/крипто).
Надійність: ідемпотентні upsert, версіонування записів, exactly-once в конвеєрі подій, шифрування KMS/HSM.

6) Де вбудовувати перевірки

1. Реєстрація/прив'язка платіжного засобу - ранній Deny для «спалених» реквізитів.
2. Депозит (ініціація) - швидкий Deny/Stop до 3DS/OTP, щоб не платити за авторизацію за свідомо поганими ключами.
3. Висновок/виплата - окремі списки для payout-реквізитів (IBAN/крипто-адреса); часто суворіше, ніж на вхід.
4. Зміна реквізитів - step-up + check; захист від «зміни рахунку перед виведенням».
5. Бонусні операції - observe/stop за схемами аб'юзу (мультиаккаунт, ланцюжки пристроїв).

7) Політики (HARD/SOFT) і TTL

HARD (deny/stop) застосовуйте при: санкції, підтверджений фрод, повторні чарджбеки, вкрадені карти, мули.
SOFT (observe/step-up) при: слабкі сигнали (новий IP/пристрій, «холодний» e-mail-домен, high-velocity), «сумнівні» BIN/ASN.

TTL/expiry:

Чарджбек: 180-540 днів (залежно від схем і ризику).
Бонус-аб'юз: 90-365 днів (з переглядом).
Санкції: безстроково з періодичною синхронізацією списків.
Амністія: після успішного КУС/історії «чистої» гри ≥ N днів і без інцидентів - автоматичне зниження до observe або зняття.

8) Рішення та ескалації (Decision Matrix)

Сигнал	Політика	Дія	Приклад
Точний матч санкцій (name + dob + address)	DENY	Відхилити, повідомити MLRO	Виведення на IBAN з санк. країни
Повторний CB по PAN-токену	STOP(deposit,withdrawal)	Блок вхід/вихід, кейс в ризик	2 × CB за 45 днів
Підозрілий IP ASN + новий пристрій	OBSERVE	3DS Step-Up / KYC-Tier raise	Депозит €1000 з дата-центру
VIP з підтвердженим IBAN	ALLOW	Переважує observe	Високий ліміт, чиста історія

9) Псевдокод онлайн-перевірки

python def is_blocked(keys: list[str], ctx: dict) -> Decision:
keys: ["card:pan_token:..", "ip:..", "device:..", "iban:.."]
ctx: {"action":"withdrawal","jurisdiction":"EEA","product":"casino","amount":1000}
hits = list_service. batch_check(keys, ctx) # из Redis + fallback PG if any(h. policy in ["deny","stop"] for h in hits if h. in_scope(ctx)):
return Decision(block=True, reason=top_reason(hits))
if any(h. policy == "observe" for h in hits if h. in_scope(ctx)):
return Decision(block=False, step_up="3DS_or_KYC", reason="OBS_HIT")
return Decision(block=False)

10) Інтеграція з ризик-движком і платіжною шиною

Ризик-рушій спочатку читає ListService, потім - скоринг/ML/правила.
Порядок у пайплайні: `Pre-auth → ListService (hard/soft) → 3DS/OTP → Auth → Clearing`.
Маршрутизація: на рівні PSP-роутингу можна «обнуляти» канали/аквайєрів, якщо'MID '/' BIN'потрапили в блок-листи провайдерів.
Події: кожне рішення ('DENY/STOP/OBSERVE/ALLOW') йде в Kafka для аудиту і дообучения ML.

11) Операції та процеси

Масові завантаження: CSV/NDJSON з валідацією і симуляцією (скільки операцій торкнеться).
Рев'ю: щоденна вибірка для продовження/зняття; SLA на обробку кейсів.
Конфлікти: якщо одночасно'ALLOW'і'DENY', застосовуйте правило most-restrictive, крім явних VIP-override.
Версіонування: будь-яка правка - нова версія запису; старий стан зберігається для розслідувань.
Інциденти: шаблони reason_code, зв'язок з тікетами (Jira/Case-ID).

12) Метрики якості та цілі

Hit Rate (HR) = частка операцій, що потрапили в будь-який список.
Hard-Hit Rate (HHR) = частка жорстко заблокованих.
Overblock Rate (OBR) = частка «помилкових» блокувань (наступний валідний платник).
CB- Uplift↓/Fraud- Loss↓ після впровадження.
Approval Rate (AR) на депозити/висновки.
Time-to-Wallet (TTW) вплив soft-мір (step-up) на швидкість виплат.
Time-to-Decision (p95/p99) для онлайн-чеків.

💡 Цілі: HHR зростає без помітного погіршення AR; OBR ≤ допустимого порогу (напр., <0. 3%); p99 check ≤ 10 мс.

13) Юридичні та приватність

Основа обробки: легітимний інтерес/правовий обов'язок (AML/санкції/фрод-превенція).
Мінімізація: зберігаємо хеші/токени замість первинних даних (PAN/IBAN), солимо, контролюємо доступ.
Терміни зберігання: TTL + загальні політики retention (AML/бухоблік/регуляторика).
Права суб'єктів: процес на DSAR/видалення (з урахуванням комплаєнс-винятків).
Транскордонність: чіткі межі реплікації між регіонами/тенантами.

14) Часті помилки і як їх уникнути

Оверблок по IP/ASN: дата-центри/CGNAT → використовуйте поєднання сигналів (IP + пристрій + поведінка).
Злипання персональних даних: нормалізуйте e-mail/телефон, враховуйте рециклінг номерів.
Рециркуляція карт (реемісія PAN): прив'язуйте за PAN-токеном/крипто-токенізацією, а не за «сирими» даними.
Загальний IBAN домогосподарства: застосовуйте scope (тільки payouts) і observe замість глобального deny.
Крипто-адреси: не блокуйте все підряд; враховуйте мітки/контекст (біржі, кастодіальні гаманці).

15) Зв'язок з бонус-аб'юзом і лімітами

Бонус-патерни: один гаманець/адреса → безліч акаунтів, швидкий вивід без обороту - в stop/deny на payouts.
Ліміти і TtW: «observe» може вимагати підвищений оборот/подовжений TtW до рев'ю.

16) Приклади ключів (канонічні форми)


card:pan_token:<sha256>
iban:<sha256>
wallet:skrill:<normalized_id_hash>
upi:<vpa_hash>
pix:<pix_key_hash>
crypto:eth:<address_lower>
email:<local+domain_hash>
phone:+<E164_hash>
device:<fp_hash>
ip:<ipv4/6 or /24>
asn:<asn_id>
affiliate:<id>
psp:mid:<id>

17) Контрольні списки (чек-лист впровадження)

1. Визначити policy set: deny/stop/observe/allow + reason_codes.
2. Схема даних: ключи, scope, ttl/expiry, confidence, audit.
3. Архітектура: Redis + PG + Kafka, idempotency, 4-очний контроль.
4. Вбудовування в потік: pre-auth check, step-up, payout-hardening.
5. Метрики/дашборд: HR/HHR/OBR/AR/TTW, розрізи по юрисдикціях/каналах.
6. Процеси: рев'ю/амністія, масові завантаження, DSAR, інциденти.
7. Навчання команд: саппорт/ризик/фінанси, плейбуки вирішення конфліктів.

18) Міні-плейбуки

Сплеск CB по BIN X → тимчасовий stop (deposit) по'bin:X'+ reroute на інший еквайєр, рев'ю через 48 год.
Підміна реквізитів перед виведенням → stop (withdrawal) + KYC-step-up + верифікація беніфіціара.
Консорціумний хіт по гаманцю → observe на депозити, stop на payouts до MLRO-рев'ю.
Санкційні новини по країні Y → оновити country-scope, включити deny на payouts, перерахувати списки.

19) Приклад інтерфейсу адмін-панелі (логіка)

Пошук по ключу/масці, фільтри: policy, scope, reason, source, expiry<30d.
Кнопки: Amnesty, Extend TTL, Lower to Observe, Convert to Deny, Add Allow.
Масові дії з dry-run: показати, скільки операцій потрапить під нові правила.

20) Резюме

Блок-листи - це не просто «таблиця заборон», а сервіс рівня платформи: з ясною моделлю даних, сильним кешем, аудіюванням, грамотними TTL і чіткими процесами рев'ю. При правильній інтеграції з ризик-движком вони звузять воронку фроду без руйнування конверсії і прискорять платежі там, де це безпечно.

Блекісти та блок-листи в платіжній логіці

TL; DR

Комунікаційні та поведінкові

Акаунтні та контрагентські

Зв’яжіться з нами

Швидкий зв’язок

Відео скоро буде оновлено

Зараз ми дуже завантажені проєктами