Політики висновків: терміни і KYC

1) Навіщо формалізувати політику висновків

• знижує рівень тікетів і ескалацій ("коли прийдуть гроші? »);
• забезпечує AML/KYC-відповідність (вік, санкції, SoF/SoW);
• зменшує фрод/чарджбеки та арбітражні спори;
• дає передбачувані SLA для фінансів/саппорту/маркетингу.

2) Класифікація рейок і очікувана швидкість

3) Рівні KYC і вплив на висновки

Принцип: чим вище KYC, тим ширше доступні рейки і вище ліміти/швидкість.

Basic (спрощений): малі ліміти; дозволені тільки «повільні» або внутрішні висновки (на гаманець/обмежений A2A).
Full KYC (ID + Address + Liveness): стандартні ліміти; доступ до банківських рейок, Push-to-Card, локальних швидких схем.
EDD (розширений): великі суми/часті виплати; потрібно SoF/SoW (джерело коштів/стан), білі списки одержувачів, прискорена обробка.

Step-up-тригери: велика сума, новий одержувач, нетиповий пристрій/гео, перевищення velocity, high-risk MCC (iGaming, квазі-кеш), накопичений виграш.

4) Ліміти та антифрод на висновках

• Per-transaction / Daily / Weekly / Monthly caps.
• Velocity: N виплат/год, суми по ковзному вікну, частота зміни реквізитів.
• Нові одержувачі: знижений сар/обов'язковий cooling-off (наприклад, 12-24 год) і step-up.
• Гео/санкції: списки deny/allow, заборона певних країн/банків.
• Профіль ризику: мультиплікатори лімітів по score клієнта/сесії.
• Payout-lock: тимчасове блокування після аномалій/chargeback/ODR, до завершення перевірки.

5) Payout-статуси та операційна модель

• 'requested'- запит користувача
• 'queued'- поставлено в чергу виплат
• 'processing'- в обробці у провайдера/банку
• 'sent'- відправлено в рейку (є UTR/ARN/Trace)
• 'settled'- підтверджений залік у одержувача/немає фінризиків
• 'failed'- відмова рейки/банку
• «reversed/returned» - повернення коштів (ACH R-коди, SEPA return, FPS reject)
• 'on _ hold'- комплаєнс/EDD/SoF перевірка
• 'canceled'- скасовано користувачем/оператором

Артефакти: 'payoutId','requestId'( ідемпотентність),'beneficiaryId','rail','amount/currency','UTR/ARN/Trace', коди відмов.

6) Черга виплат і архітектура ядра

• Orchestrator (state machine): маршрутизація по рейках/лімітах/таймзонах.
• Scheduler: облік cut-off/свят (per-rail/per-country).
• Idempotency: ключ на'requestId'+ дедуплікація подій.
• Webhooks провайдера: підписис/НМАС, ретраї з backoff, DLQ.
• Reconciliation: auto-recon за реєстрами (щоденно) + періодичний full-recon; зберігання UTR/ARN.
• Policy Engine: правила КУС/лімітів/скорингу та причини відмов (explainability).
• Treasury/Liquidity: моніторинг залишків у PSP/банків, префандинг під швидкі рейки, ребаланс.

7) Ліквідність і префандинг

Швидкі рейки (RTP/FPS/PIX/Push-to-Card/e-wallets) часто вимагають префандингу.
Тримайте ліміти на провайдера і авто-ребаланс (sweep) між рахунками.
Касовий розрив: відокремлюйте бухгалтерський облік «обіцяних» виплат від фактичних дебетів.
Введіть автоматичний дерейтинг методу при падінні ліквідності (тимчасово перемикайте на повільні рейки).

8) Комунікації та UX

Показати очікувану дату/час надходження з урахуванням рейки, cut-off і TZ користувача.
Пояснювані статуси: "на перевірці KYC/SoF", "очікуємо банківське вікно", "відправлено: номер UTR/ARN".
FAQ в продукті: ліміти, терміни, підтримувані рейки, що таке SoF/SoW, чому запит відхилений.
Нові одержувачі: попередження про холд/step-up, підтвердження реквізитів (micro-deposit/1-cent check, test payout).
Anti-error UX: маска IBAN/BIC, валідація формату, підказка BSB/Sort code, збереження «шаблонів» одержувачів.
Cooldown: м'яка затримка для високоризикових профілів з прозорою причиною.

9) Комплаєнс: KYC/AML/EDD/SoF/SoW

KYC: ID, адреса, liveness; вік і гео-блоки.
Sanctions/PEP: скринінг при онбордингу і циклічно; перед великими виплатами - повторний чек.
SoF/SoW: підтвердження джерела коштів/стану (банківські виписки, довідки про доходи, контракт).
Case-management: журнал рішень, SLA обробки, audit-trail.
Responsible Gaming (для iGaming): холди на виведення бонусних коштів, перевірки за самовиключенням, денні/тижневі «відповідальні» ліміти.

10) Помилки і повернення по рейках (що враховувати)

ACH: повернення (R01... R10), вікна NACHA, блок-листи.
SEPA: Reject/Return/Recall; IBAN-валідація, причина коду (AC04, AG01 тощо).
FPS/RTP/PIX: як правило, фінальність; повернення - окремою зустрічною операцією.
Push-to-Card: можливі затримки у емітента/відхилення по лімітах.
SWIFT: комісії кореспондентів, «lifting fees», затримки на комплаєнсі банку-одержувача.

11) Економіка і комісії

Fee модель: фікс/відсоток, пороги по сумах, FX-маржа, окремі тарифи для швидких рейок.
KYC-рівні ↔ тарифи: VIP/EDD - нижче комісії/пріоритет; Basic - вище вартість обслуговування.
Антифрод-витрати: вартість перевірок/інвестігейшнів, частка повернень/відмов.
Оптимізація: угруповання виплат (batch), розклад «повільних» рейок в off-peak, вибір рейки за сумою/країні/часу доби.

12) KPI/метрики для управління

SLA дотримання: % виплат, що прийшли в обіцяний термін.
Time-to-Cash: медіана/95-перцентиль часу до'settled'.
Return/Reject rate по рейках і причинах (кодах).
Share by rail: розподіл за методами та їх approve/settle.
ODR/скарги на затримки/відмови.
Hold/EDD rate: частка виплат, що потрапили в ручну перевірку; середній час вирішення.
Liquidity uptime: час при якому швидкі рейки доступні.
Cost per payout и FX impact.

13) Чек-лист запуску політики висновків

1. Матриця рейок: країни/валюти/ліміти/терміни/cut-off/свята - в конфіг-сервісі.
2. Policy Engine: правила KYC/лімітів/velocity/EDD з explain-логами.
3. Оркестратор виплат: черга, ретраї, ідемпотентність, webhooks з HMAC.
4. Treasury: префандинг швидких рейок, авто-ребаланс, ліміти на провайдера.
5. KYC/AML/SoF/SoW: провайдери, плейбуки, SLA, ескалації.
6. UX/Комунікація: ETA по рейці, статуси, UTR/ARN, зрозумілі причини холдів/відмов.
7. Recon: daily auto-recon + full-recon; альберти на «успіх без реєстру», «aging payouts».
8. Моніторинг: дашборди KPI, тривоги щодо ліквідності/відмов/зростання повернень.
9. Тест-пакет: e2e на кожну рейку (успіх/відмова/повернення), новий одержувач, велика сума, таймаути провайдера.

14) Шаблон розділу політики (для ToS/wiki)

• SEPA: T + 1 BD (до 15:00 CET), SEPA Instant - зазвичай протягом 30 хвилин.
• FPS/PIX/RTP: зазвичай хвилинний режим, але можливі перевірки до 24 год для нових одержувачів.
• ACH: T+1–T+2 BD; Same Day ACH - при подачі до кат-офф банку.

• До € Х/день - Basic, понад - потрібні ID + селфі; понад € Y - SoF/SoW.
• Новий одержувач - до 24 год безпечний холд.

• Per-txn: …, Daily: …, Weekly: … (динамічно за рівнем/ризиком).

• SEPA/FPS — …, SWIFT — … (+ комісії кореспондентів), Push-to-Card -....

• У випадку Reject/Return кошти повернуться на баланс протягом...; причину повідомимо в повідомленні (код/опис).

15) Швидкі відповіді для саппорту

Коли прийдуть гроші? - Для {рейка} чекайте до {ETA}. Ваш UTR/ARN: {код}.
Чому холд? - спрацювали правила безпеки (новий одержувач/сума/гео). Будь ласка, завантажте документ {SoF/ID}.
Можна швидше? - На {швидкий рейка} буде потрібно префандинг/інший ліміт; запропонуємо альтернативний метод.
Чому відмова? - Банк одержувача відхилив (код {X}). Перевірте реквізити або виберіть іншу рейку.

Резюме

Сильна політика висновків = прозорі терміни + передбачувані ліміти KYC + надійна оркестрація рейок. Зберігайте правила в конфігу, використовуйте policy engine з explain-логами, забезпечте ідемпотентність/Recon/Webhooks, керуйте ліквідністю і префандингом і комунікуйте з користувачем точний ETA + UTR/ARN. Так ви знижуєте ризик, підтримуєте комплаєнс і підвищуєте довіру, не жертвуючи швидкістю виплат.