Pay chains and prioritization

1) The concept of a paychain

Payout chain - an ordered list of rails/providers that the orchestrator sequentially tries to pay until it receives confirmation of sending ('sent') or crediting ('settled').
The goal is to minimize the time to money under given restrictions: KYC/AML, limits, liquidity, value, cutoffs, geo/currency, profile risk.

• Primary rail (preferred rail for the segment).
• Fallbacks (SLA/cost/availability alternatives).
• Rules and Constraints.
• Health signals (approve/settle/latency/errors) and Liquidity (balances/prefanding).

2) Rail prioritization criteria

1. SLA/speed: min/hours/bank days; presence of 24/7 (RTP/FPS/Pix) versus D + N (ACH/SEPA).
2. Cost: fix +%, FX margin, provider fees; internal cost-model.
3. Liquidity: available balance from the provider/correspondent account, prefanding requirements.
4. Compatibility: currency/country of recipient, format of details (IBAN/CLABE/Routing/Sort/PIX key).
5. Limits: per-txn/daily/weekly at the provider and at the recipient (bank/wallet).
6. Risk/CCM: client level, SoF/SoW, sanctions/PEP, velocity, new beneficiary.
7. Reliability: current metrics of failures, delays, returns (reject/return).
8. Cut-offs and calendars: local holidays, cut-off bank; Sender/Receiver TZ.
9. Product preferences: VIP/affiliates/jackpots - individual profiles.

3) Orchestration matrix (logic example)

≤ €1k, EU, Full KYC → SEPA Instant → (folback) SEPA SCT → (after cut-off) next BD.
≤ £250k, UK, 24/7, VIP → FPS (primary), with delays> P95 - switching to provider No. 2.
US ≤ $5k → RTP; if the recipient's bank does not support - Same Day ACH; if the window is closed - ACH Next Day.
BR → Pix (primary); at the risks/limits of the bank → Pix with a reduced three-hold or e-wallet payout.
The card (globally) → Push-to-Card (OCT) for fast but expensive and limited shipments.
Cross-border → local e-wallet (where available) → otherwise SWIFT with calculation of total fees and ETA.

All numerical thresholds and lists are in configuration, not code.

4) Chain orchestrator architecture

• Decision Engine (policy) - applies the rules for selecting rails and folbacks (declarative policies, versioning).
• Payout Orchestrator — state machine: `requested → queued → processing → sent/failed → settled/returned`.
• Liquidity/Treasury - provider balances, prefanding, auto-rebalance, provider limits/day.
• Calendar/Scheduler - cut-off, holidays by country/currency, butch sending slots.
• Provider Adapter Layer - API unification, status code mapping, idempotency.
• Reconciliation - auto-reconciliation of registers/statements, loading UTR/ARN/Trace.
• Compliance - KYC/AML/sanctions/SoF/SoW and case management.

• Idempotence ('requestId'), event dedup, DLQ/retrai c backoff/jitter.
• Observability: trace, orchestration events, per-provider timers.

5) Folback, degradation and gray scenarios

Time-based fallback: if 'processing' has exceeded the threshold (for example, 90th percentile) - switch to the next rail (with cancellation/void of the first attempt, if permissible).
Health-based: with the growth of'reject/return' or the fall of approve - derating of the provider.
Liquidity-based: lack of prefanding → temporarily hide fast rails, offer slow.
Risk-based: at high risk - fast-rails ban, mandatory hold/step-up.
Grey window: evenings/holidays → autoplanning to the nearest window; honest ETA at UI.

6) Cost and rating of rails

• `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`.
• Weights - configurable; compare by segment (geo/amount/VIP).

7) Liquidity and Prefanding

Fast rails require prepayment: keep minimums on providers' accounts.
Auto-rebalance: rules of sweeps between wallets/banks on thresholds.
Circuit-breakers: at the remaining <threshold - automatic dereiting of the method in the chain.
Cashbook: separate the accounting of the promised payments from the actual debits; cash gap control.

8) Scheduling: Batches, cutoffs and calendars

Batching reduces the cost of SWIFT/ACH/SEPA SCT, but increases latency - adjust by amount/priority.
Cut-off aware: if the request came after cut-off, immediately show ETA to the next BD.
Holiday API: Keep regional holidays; for cross-TZ, show the receiver's local time.

9) Risk and KYC in chains

New beneficiary/large amount → cool-off + step-up, fast-rails ban.
Threshold amounts → SoF/SoW requirement; before provision - "slow" rail.
Geo/sanctions/PEP → hard deny, no alternative routes.
Velocity: N payouts/day/week; exceeding the downgrade → of the rail in the chain.

10) Statuses and artifacts

• `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) Reconciliation and logging

Daily auto-recon: loading registers, matching by 'payoutId/UTR/amount/date'.
Full-recon: periodic end-to-end control (registers/statements/GL).

Alerts: "success without a registry," "aging processing," "double send," "provider silence."

12) UX and communication

Showing ETA by rail and reason for selection ("faster/cheaper/after cut-off").
Transparent statuses with UTR/ARN/Trace.

For folback - explicit notice: "switched to {rail} due to delay/liquidity; a new ETA...."

For VIP - the option "accelerate" (other rail/commission).
For new recipients - hold/step-up warning.

13) KPI и SLO

On-time rate (% of payments received before the promised ETA).
Median/P95 time-to-settle on rails/providers/geo.
Reject/Return rate and cause distribution.
Fallback rate and its impact on SLA/value.
Liquidity uptime.
Cost per payout and FX share.
Support load (tickets/1k payments) and NPS by conclusions.

14) Chain start-up checklist

1. Rail catalogue: countries/currencies/limits/commissions/ETA/cut-off/holidays.
2. Policy Engine: declarative prioritization rules + explain reasons for the decision.
3. Provider health: metrics, health tests, auto-rating.
4. Treasury: prefunding, limits on the provider, auto-rebalance.
5. Idempotency and DLQ: double/repeat protection, safe retreats.
6. Webhooks/HMAC: signature verification, timeouts, repeat delivery.
7. Recon: daily + full, alerts for out of sync.
8. UX: ETA, statuses, UTR/ARN, folback/hold reason texts.
9. KYC/AML: step-up on new beneficiaries/large sums, SoF/SoW procedures.
10. Test set: success/refusal/return, time/liquidity folback, cut-off/holidays, degradation of the provider.

15) Solver Mini Pseudo Code

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)

Summary

Paychecks are intelligent routing between speed, price, risk and operational readiness. Store rules and metrics in a config, decide on the basis of a scoring function, taking into account the liquidity and health of providers, ensure idempotency, folback and an honest ETA. This way you reduce cost and returns, keep SLAs and user trust - especially in sensitive segments like iGaming and cross-border.