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

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 дней (с пересмотром).
Санкции: бессрочно с периодической синхронизацией списков.
Амнистия: после успешного KYC/истории «чистой» игры ≥ 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 c подтвержденным 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

Коммуникационные и поведенческие

Аккаунтные и контрагентские

Свяжитесь с нами

Быстрая связь

Видео скоро обновится

Мы сейчас очень загружены проектами