Политики выводов: сроки и 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 выплат/час, суммы по скользящему окну, частота смены реквизитов.
• Новые получатели: снижен cap/обязательный 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 провайдера: подписис/HMAC, ретраи с backoff, DLQ.
• Reconciliation: auto-recon по реестрам (ежедневно) + периодический full-recon; хранение UTR/ARN.
• Policy Engine: правила KYC/лимитов/скоринга и причины отказов (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 — при подаче до кат-офф банка.

• До €X/день — 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. Так вы снижаете риск, поддерживаете комплаенс и повышаете доверие, не жертвуя скоростью выплат.