Цепочки выплат и приоритизация

1) Понятие цепочки выплат

Цепочка выплат (payout chain) — упорядоченный список рельсов/провайдеров, по которым оркестратор последовательно пытается выполнить выплату, пока не получит подтверждение отправки (`sent`) или зачисления (`settled`).
Цель — минимизировать время до денег при заданных ограничениях: KYC/AML, лимиты, ликвидность, стоимость, кат-оффы, гео/валюта, риск профиля.

• Primary rail (предпочтительный рельс для сегмента).
• Fallbacks (альтернативы по SLA/стоимости/доступности).
• Rules (условия переключений) и Constraints (жесткие запреты/лимиты).
• Health signals (approve/settle/latency/ошибки) и Liquidity (балансы/префандинг).

2) Критерии приоритизации рельсов

1. SLA/скорость: мин/часы/банковские дни; наличие 24/7 (RTP/FPS/Pix) против D+N (ACH/SEPA).
2. Стоимость: фикс + %, FX-маржа, провайдерские сборы; внутренний cost-model.
3. Ликвидность: доступный остаток у провайдера/корсчета, требования префандинга.
4. Совместимость: валюта/страна получателя, формат реквизитов (IBAN/CLABE/Routing/Sort/PIX-ключ).
5. Лимиты: per-txn/daily/weekly у провайдера и у получателя (банк/кошелек).
6. Риск/KYC: уровень клиента, SoF/SoW, санкции/PEP, velocity, новый бенефициар.
7. Надежность: текущие метрики отказов, задержек, возвратов (reject/return).
8. Кат-оффы и календари: локальные праздники, cut-off банка; TZ отправителя/получателя.
9. Предпочтения продукта: VIP/аффилиаты/джекпоты — отдельные профили.

3) Матрица оркестрации (пример логики)

≤ €1k, EU, Full KYC → SEPA Instant → (фолбэк) SEPA SCT → (после cut-off) следующий BD.
≤ £250k, UK, 24/7, VIP → FPS (primary), при задержках > P95 — переключение на провайдера №2.
US ≤ $5k → RTP; если банк получателя не поддерживает — Same Day ACH; если окно закрыто — ACH Next Day.
BR → Pix (primary); при ризиках/лимитах банка → Pix с пониженным трешхолдом или e-wallet payout.
Карта (глобально) → Push-to-Card (OCT) для быстрых, но дорогих и лимитируемых отправок.
Кросс-бордер → локальный e-wallet (где есть) → иначе SWIFT с расчетом общих сборов и ETA.

Все численные пороги и списки — в конфигурации, а не в коде.

4) Архитектура оркестратора цепочек

• Decision Engine (policy) — применяет правила выбора рельса и фолбэков (декларативные политики, версионирование).
• Payout Orchestrator — state machine: `requested → queued → processing → sent/failed → settled/returned`.
• Liquidity/Treasury — балансы провайдеров, префандинг, авто-ребаланс, лимиты на провайдера/день.
• Calendar/Scheduler — cut-off, праздники по странам/валютам, слоты отправки батчей.
• Provider Adapter Layer — унификация API, маппинг статус-кодов, идемпотентность.
• Reconciliation — авто-сверка реестров/выписок, загрузка UTR/ARN/Trace.
• Compliance — KYC/AML/санкции/SoF/SoW и case-менеджмент.

• Идемпотентность (`requestId`), дедуп событий, DLQ/ретраи c backoff/jitter.
• Observability: трассировка, события оркестрации, пер-провайдерные таймеры.

5) Фолбэк, деградация и «серые» сценарии

Time-based fallback: если `processing` превысил порог (например, 90-й перцентиль) — переключить на следующий рельс (с отменой/void первой попытки, если допустимо).
Health-based: при росте `reject/return` или падении approve — дерейтинг провайдера.
Liquidity-based: нехватка префандинга → временно скрыть быстрые рельсы, предложить медленный.
Risk-based: на высоком риске — запрет fast-rails, обязательный холд/step-up.
Grey window: вечера/праздники → автопланирование на ближайшее окно; честный ETA в UI.

6) Стоимость и рейтинг рельсов

• `eff_cost = fixed_fee + percent_fee amount + FX_margin + failure_cost fail_prob + support_cost`.

• `score = w_slaSLA + w_cost(1/eff_cost) + w_reliabilitysuccess_rate − w_riskrisk_score − w_opsoperational_load`.
• Весá — конфигурируемые; сравнивайте по сегментам (гео/сумма/VIP).

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

Быстрые рельсы требуют предоплаты: держите минимумы на счетах провайдеров.
Auto-rebalance: правила свипов между кошельками/банками по порогам.
Circuit-breakers: при остатке < порога — автоматический дерейтинг метода в цепочке.
Cashbook: отделяйте бухгалтерию обещанных выплат от фактических дебетов; контроль кассового разрыва.

8) Планирование: батчи, кат-оффы и календари

Batching снижает стоимость SWIFT/ACH/SEPA SCT, но увеличивает латентность — регулируйте по сумме/приоритету.
Cut-off aware: если запрос пришел после cut-off — сразу показывайте ETA на следующий BD.
Holiday API: храните региональные праздники; для кросс-TZ показывайте локальное время получателя.

9) Риск и KYC в цепочках

Новый бенефициар/крупная сумма → cool-off + step-up, запрет fast-rails.
Пороговые суммы → требование SoF/SoW; до предоставления — «медленный» рельс.
Гео/санкции/PEP → жесткий deny, альтернативные маршруты отсутствуют.
Velocity: N выплат/день/неделя; превышение → downgrade рельса в цепочке.

10) Статусы и артефакты

• `requested → queued → processing → sent(UTR/ARN) → settled | failed | returned | on_hold | canceled`.
• Храните: `payoutId`, `beneficiaryId`, `rail`, `provider`, `amount/currency`, `fees`, `ETA`, `UTR/ARN/Trace`, reason-codes, `attempts[]`.

11) Сверка и журналирование

Daily auto-recon: загрузка реестров, матчинг по `payoutId/UTR/amount/date`.
Full-recon: периодический сквозной контроль (реестры/выписки/GL).
Алерты: «успех без реестра», «aging processing», «double send», «молчание провайдера».

12) UX и коммуникация

Показ ETA по рельсу и причине выбора («быстрее/дешевле/после cut-off»).
Прозрачные статусы с UTR/ARN/Trace.
Для фолбэка — явное уведомление: «переключили на {rail} из-за задержки/ликвидности; новый ETA…».
Для VIP — опция «ускорить» (другой рельс/комиссия).
Для новых получателей — предупреждение о холде/step-up.

13) KPI и SLO

On-time rate (% выплат, пришедших до обещанного ETA).
Median/P95 time-to-settle по рельсам/провайдерам/гео.
Reject/Return rate и распределение причин.
Fallback rate и его влияние на SLA/стоимость.
Liquidity uptime (время доступности быстрых рельсов).
Cost per payout и доля FX.
Support load (тикеты/1k выплат) и NPS по выводам.

14) Чек-лист запуска цепочек

1. Каталог рельсов: страны/валюты/лимиты/комиссии/ETA/cut-off/праздники.
2. Policy Engine: декларативные правила приоритизации + explain-причины решения.
3. Здоровье провайдеров: метрики, health-пробы, автодерейтинг.
4. Treasury: префандинг, лимиты на провайдера, авто-ребаланс.
5. Идемпотентность и DLQ: защита от дублей/повторов, безопасные ретраи.
6. Webhooks/HMAC: верификация подписей, тайм-ауты, повтор доставки.
7. Recon: daily + full, алерты на рассинхроны.
8. UX: ETA, статусы, UTR/ARN, тексты причин фолбэка/холдов.
9. KYC/AML: step-up на новые бенефициары/крупные суммы, SoF/SoW процедуры.
10. Тест-набор: успех/отказ/возврат, фолбэк по времени/ликвидности, cut-off/праздники, деградация провайдера.

15) Мини-псевдокод решателя

rail_list = rank_by(score(amount, geo, kyc, risk, sla, cost, liquidity, health))
for rail in rail_list:
if violates_constraints(rail, geo, kyc, sanctions, limits): continue if not has_liquidity(rail): continue attempt = send_payout(rail)
if attempt. status in {SENT, SETTLED}: return success(attempt)
if is_retryable(attempt): continue return fail_with_reason(best_reason_collected)

Резюме

Цепочки выплат — это интеллектуальная маршрутизация между скоростью, ценой, риском и операционной готовностью. Храните правила и метрики в конфиге, решайте на основе скоринговой функции с учетом ликвидности и здоровья провайдеров, обеспечьте идемпотентность, фолбэк и честный ETA. Так вы снижаете стоимость и возвраты, удерживаете SLA и доверие пользователей — особенно в чувствительных сегментах вроде iGaming и кросс-бордера.