Ланцюжки виплат і пріоритизація

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. Ризик/КУС: рівень клієнта, SoF/SoW, санкції/РЕР, 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; до надання - «повільна» рейка.
Гео/санкції/РЕР → жорсткий 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 і крос-бордера.