Тюнінг антифроду і правил

TL; DR

Антифрод - це не «ловля зловмисників», а оптимізація прибутку: мінімізуємо Expected Loss (EL) від фроду і чарджбеків при обмеженні Cost of Friction (CoF) і AR_net. Базова схема: скоринг (ML) → поріг/драбинка step-up → правила (policy & velocity) → ручна верифікація. Успіх дають: чисті лейбли, стабільні фічі, економічно калібрований поріг, канарські релізи, сувора ідемпотентність і керованість правил.

1) Економічна постановка

• `EL = P_fraud(tx) × Exposure(tx)`; зазвичай'Exposure = captured_amount'.

• `CoF = (Abandon_on_Friction × LTV_new/ret) + Opex_review + Fees_stepup`.

• `Profit = GGR − Cost_payments − EL − CoF`.

Оптимальний поріг «τ»: вибираємо score-cutoff так, щоб'd (Profit )/d τ = 0', або по сітці min ('EL + CoF'). На практиці - cost-sensitive ROC/PR з вагами: `w_fraud = Exposure`, `w_fp = LTV_loss + opex`.

2) Драбинка автентифікації (step-up ladder)

1. Auto-approve (низький ризик): миттєвий прохід, 3DS frictionless де можна.
2. Step-up A: 3DS challenge / SCA / device-challenge / reCAPTCHA.
3. Step-up B: легкий KYC (doc selfie/face-match, liveness).
4. Manual review: кейс у аналітика (SLA, reason-codes).
5. Auto-decline: високий ризик/санкції/мули/ваучерні аномалії.

Поріг/гілка залежать від скорингового бала, суми ('ticket _ size'), країни, BIN/issuer, поведінкових фіч і контексту (бонус-кампанії, нічні вікна, velocity).

3) Сигнали і фічі (мінімальний базис)

Платіжні: BIN/IIN, issuer_country, ECI/3DS flow, AVS/CVV match, soft-decline коди, повернення/disputes в історії.
Поведінкові: швидкість подій (velocity: 'cards/device/ip/email'), час доби, first-seen/last-seen, «топологія» акаунтів (граф-зв'язку: загальні пристрої/карти/гаманці).
Пристрій/мережа: device fingerprint, емулятори/джейл/рут, проксі/VPN/TOR, ASN/хостинги.
Анти-бонус: реферали-синдикати, «прокачування» бонусів, аномальні патерни depozit→vyvod без гри.
Виплати/гаманці/ваучери: повтори PIN, гео-місматч, «швидкісні» редими, мулінгові каскади.
KYC/KYB: рівень, валідації, SoF/SoW прапори.
Санкції/РЕР/блок-листи: збіги за списками, фуззі-матч ПІБ/адрес.

4) Стек: ML + правила

5) Метрики якості (з чіткими базами)

AR_clean = `Auth_Approved / (Auth_Attempted − Fraud_preblocked − Abandon_3DS)`

Fraud Rate (по захопленнях) ='Fraud _ captured _ amount/ Captured_amount'

Chargeback Rate ='Chargeback _ count/ Captured_Tx' (або за сумою)

False Positive Rate (FP) = `Legit_declined / Legit_attempted`

Step-up Rate = `StepUp_tx / Auth_Attempted`, Abandon_on_StepUp

Auto-approve %, Manual review %, Review SLA/TtA

Net Profit uplift після тюнінгу (AB-різниця EL + CoF vs контроль).

Орієнтири: FP у нових користувачів ≤ 1-2% (за обсягом), Fraud (за сумою) - в цільовому коридорі ліцензії/схем.

6) Пороги і політика правил

6. 1 Калібрування порогу

Будуємо cost-curve: для кожного «τ» рахуємо «EL (τ) + CoF (τ)».
Вибираємо'τ'з мінімумом. Для high-ticket - окремий'τ _ hi'.

6. 2 Типові правила (псевдокод)

yaml
- name: SANCTIONS_HIT when: sanctions_match==true action: DECLINE reason: "Sanctions/PEP match"

- name: BIN_RISKY_3DS when: bin in RISKY_BINS and score in [τ_low, τ_mid)
action: STEPUP_3DS

- name: DEVICE_VELOCITY_LOCK when: device_id in last_10min.deposits > 3 action: DECLINE_TEMPORARY ttl: 2h

- name: BONUS_ABUSE_GUARD when: (bonus_received and gameplay_turnover < Xdeposit_amount) and payout_request action: HOLD_REVIEW reason: "Turnover not met"

6. 3 Динамічні ліміти

Ліміт суми та кількості транзакцій за рівнем ризику (risk-tier): `R1/R2/R3`.
Адаптивні ліміти для нових акаунтів, прогрівши при хорошій історії.

7) Життєвий цикл правил (governance)

DSL/реєстр правил з версіями, власником і описом ефекту.
Shadow mode → canary (5–10%) → full rollout.
RACI: Owner (Payments Risk), Approver (Compliance/Legal), Consulted (Support/Treasury), Informed (Ops).
Аудит-лог: хто/коли змінив, які метрики/АВ, відкат.
Термін придатності правила і переоцінка (наприклад, 30/60 днів).

8) Дані та навчання моделей

Спліти за часом, без витоку (features тільки з минулого вікна).
Цільовий лейбл: confirmed fraud/chargeback; окремі лейбли bonus abuse.
Reweighing класів за сумою (amount-weighted loss).
Drift-моніторинг: PSI для ключових фіч, KS для скорів, baseline stability.
Retrain-тригери: PSI>0. 25, падіння KS, зміна трафіку/юрисдикцій.

9) Пояснюваність і саппорт

Для кожного рішення генеруємо reason_codes (до 5 причин) з людиночитаними підказками.
Саппорт-макроси по step-up/відмовам (3DS, KYC, turnover).
Спори/диспути: зворотній зв'язок потрапляє в labeling pipeline (закриваємо цикл).

10) Комплаєнс і приватність

GDPR/DSAR: право пояснення рішення; мінімізація PII; хешування (salted) ідентифікаторів (email/phone/PAN-токен).
PCI-DSS: PAN-safe потоки, токенізація.
Санкції/AML: окремий контур скринінгу + ескалації MLRO.
Retention: політики зберігання сигналів та обґрунтувань рішень.

11) Моніторинг та алерти (щогодини/щодня)

AR_clean, Fraud (amt%), FP (retention-weighted), Step-up/Abandon, Review SLA, Chargeback Rate (lagged).
Спайки velocity, зростання TOR/Proxy/ASN-хостингів, BIN-деградації, ваучер-редими.
Алерти при: FP> коридору, Fraud> таргета, Abandon> бази + X п.п., дрейф PSI/KS.

12) SQL-зрізи (приклад)

12. 1 Базові метрики

sql
WITH base AS (
SELECT
DATE_TRUNC('day', attempt_ts) d, country, provider, method_code,
COUNT() FILTER (WHERE auth_status='ATTEMPTED') AS attempted,
COUNT() FILTER (WHERE auth_status='APPROVED') AS approved,
COUNT() FILTER (WHERE decision='DECLINE' AND label='LEGIT') AS fp_cnt,
SUM(captured_amount) AS cap_amt,
SUM(CASE WHEN label='FRAUD' THEN captured_amount ELSE 0 END) AS fraud_amt
FROM payments_flat
GROUP BY 1,2,3,4
)
SELECT d, country, provider, method_code,
approved::decimal/NULLIF(attempted,0) AS ar_clean,
fraud_amt::decimal/NULLIF(cap_amt,0)  AS fraud_rate_amt,
fp_cnt::decimal/NULLIF(attempted,0)  AS fp_rate
FROM base;

12. 2 Частка step-up і відмов по швидкій

sql
SELECT
DATE_TRUNC('day', attempt_ts) d,
WIDTH_BUCKET(score, 0, 1, 10) AS bucket,
AVG(CASE WHEN decision='STEPUP' THEN 1 ELSE 0 END) AS stepup_share,
AVG(CASE WHEN decision='DECLINE' THEN 1 ELSE 0 END) AS decline_share,
AVG(CASE WHEN stepup_abandon THEN 1 ELSE 0 END) AS abandon_after_stepup
FROM risk_events
GROUP BY 1,2
ORDER BY d, bucket;

13) Плейбуки тюнінгу

Зростання Fraud (amt%) при стабільному FP → підняти'τ', посилити velocity по пристроях/ASN, включити 3DS-challenge на вразливих BIN.
Високий FP у нових → пом'якшити'τ'для low-ticket, перевести частину в Step-up A замість відхилення.
Abandon на 3DS↑ → домовитися з PSP про 3DS2-параметри, поліпшити UX, звузити step-up на мобільних для low-risk.
Синдивідуальні бонус-мережі → графові фічі, лімітувати «паралельні» виплати, turnover-правила.
Ваучерні аномалії → velocity по PIN/рітейлеру/гео, device-binding, hold до верифікації.

14) Впровадження: чек-лист

• Економічне калібрування порогу ('EL + CoF'), окремі'τ'за сегментами.
• Реєстр правил (DSL), shadow→canary→rollout, аудит і відкат.
• Reason-codes і шаблони комунікацій.
• Моніторинг PSI/KS, дрейф фіч/скорів, регулярний retrain.
• Канал зворотного зв'язку (disputy→leybly).
• Політики KYC/step-up, SLA review і TtA/TtR.
• Приватність: хешування ідентифікаторів, мінімізація PII.

15) Резюме

Тюнінг антифроду - це системна оптимізація прибутку з керованою фрикцією: ML-скоринг + продумана драбинка step-up, жорсткі легальні правила і акуратні velocity-ліміти. Економічне калібрування порогу, чисті лейбли, канарські викладки і сувора керованість дають низький Fraud за сумою, низький FP у нових, високий AR_net - без сюрпризів для комплаєнсу і UX.