Catene di pagamento e priorità

1) Concetto di catena di pagamento

La catena di pagamento (payout chain) è un elenco ordinato di binari/provider per i quali l'orchestratore tenta di effettuare il pagamento in sequenza finché non riceve la conferma di invio o di iscrizione ('settled').
Lo scopo è di ridurre al minimo il tempo a denaro con le limitazioni definite: KYC/AML, limiti, liquidità, costo, kat off, geo/valuta, rischio profilo.

• Primary rail (il binario preferito per il segmento).
• Fallbacks (alternative SLA/costo/disponibilità).
• Rule (condizioni di commutazione) e Constrains (restrizioni rigide/limiti).
• Health signals (approve/settle/latency/errori) e Liquidità (bilanci/prefanding).

2) Criteri di priorità dei binari

1. SLA/velocità: min/ore/giorni bancari; 24/7 (RTP/FPS/Pix) vs D + N (ACH/SEPA).
2. Costo: fix +%, margine FX, incassi di provider; costo-model interno.
3. Liquidità: residuo disponibile per il provider/corsetta, requisiti di prefanding.
4. Compatibilità: valuta/paese del destinatario, formato di identità (VA/CLABE/Routing/Sort/PIX).
5. Limiti: per-txn/daily/week presso il provider e il destinatario (banca/portafoglio).
6. Rischio/CUS: livello del cliente, SoF/SoW, sanzioni/RER, velocity, nuovo beneficiario.
7. Affidabilità: le metriche correnti di guasti, ritardi, ritorni (reject/return).
8. Cat off e calendari: feste locali, cut-off banca; TZ del mittente/destinatario.
9. Preferenze del prodotto: VIP/affiliati/jackpot - profili separati.

3) Matrice di orchestrazione (esempio di logica)

≤ €1k, EU, Full KYC → SEPA Instant → (folback) SEPA SCT → (dopo cut-off) la prossima BD.
250k, UK, 24/7, VIP FPS (primary), in caso di ritardo> P95 - cambio al provider numero 2.
US ≤ $5k → RTP; se la banca del destinatario non supporta - Same Day ACH; se la finestra è chiusa, ACH Next Day.
BR → Pix (primary); nelle risaie/limitazioni della banca di → Pix con basso livello o e-wallet payout.
Scheda (globale) → Push-to-Card (OCT) per spedizioni veloci, ma costose e limitate.
Il cross-border l'e-wallet locale (dove c'è) altrimenti SWIFT con il calcolo delle tasse totali e ETA.

Tutte le soglie numeriche e gli elenchi sono configurati, non nel codice.

4) Architettura della catena orchestrale

• Decision Engine (policy) - Applica le regole di selezione dei binari e dei folback (criteri dichiarativi, versioning).
• Payout Orchestrator — state machine: `requested → queued → processing → sent/failed → settled/returned`.
• Liquidity/Treasury - bilanci dei provider, prefanding, auto-ricalance, limiti per provider/giorno.
• Calendar/Scheduler - cut-off, vacanze per paese/valuta, slot invio battelli.
• Provider Adatter Layer - Unificazione API, mapping stato-codici, idampotenza.
• Recordation - Controllo automatico dei registri/estratti, caricamento UTR/ARN/Trace.
• Compliance - KYC/AML/sanzioni/SoF/SoW e management case.

• Idampotenza ('requestId'), dedotto eventi, DLQ/retrai con backoff/jitter.
• Osservabilità - Traccia, eventi di orchestrazione, timer per provider.

5) Falback, degrado e scenari «grigi»

Time-based fallback: se «processing» ha superato la soglia (ad esempio, 90 ° percento) - passa al binario successivo (annullando/void il primo tentativo, se consentito).
Health-based - Durante la crescita dì reject/return "o la caduta di approve - Dereiting provider.
Liquidity-based - La mancanza di prefanding consente di nascondere temporaneamente i binari veloci e suggerire un lento.
Risk-based: ad alto rischio - proibizione fast-rails, colld/step-up obbligatorio.
Grey window: sere/festività per l'autolavaggio alla finestra più vicina; L'ETA onesto in UI.

6) Costo e rating dei binari

• `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`.
• Pesá - configurabili; confrontare per segmenti (geo/somma/VIP).

7) Liquidità e prefanding

I binari rapidi richiedono un pagamento anticipato, mantenendo i minimi sui conti dei provider.
Auto-rebalance: regole di swip tra portafogli/banche a soglie.
Circuito-breakers - Quando la soglia è residua, il metodo di dereuting automatico nella catena.
Cashbook: separa la contabilità dei pagamenti promessi dai debiti effettivi; Controllo della rottura di cassa.

8) Pianificazione: batch, kat-off e calendari

Batching riduce il costo SWIFT/ACH/SEPA SCT, ma aumenta la latitanza - regolando in base alla somma/priorità.
Cut-off aware - Se la richiesta è arrivata dopo cut-off, mostra subito ETA alla prossima BD.
Holiday API: conserva le vacanze regionali; per il cross-TZ, visualizzare l'ora locale del destinatario.

9) Rischio e KYC in catene

Nuovo beneficiario/grande importo di →-off + step-up, divieto di fast-rails.
Le soglie di → sono un requisito di SoF/SoW; prima della consegna, un binario lento.
Geo/sanzioni/RER → deny rigido, nessun percorso alternativo.
Velocity: n pagamenti/giorno/settimana; superamento del binario downgrade nella catena.

10) States e manufatti

• `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) Incrociatura e registrazione

Daily auto-recon - Caricamento di registri, matching per «payoutId/UTR/amount/date».
Full-recon - Controllo interattivo periodico (registri/estratti/GL).
«Successo senza registro», «aging processing», «doppio send», «silenzio del provider».

12) UX e comunicazione

Mostra l'ETA su binari e motivi di scelta («più veloce/più economico/dopo cut-off»).
Stati trasparenti con UTR/ARN/Trace.
Per il folback, una notifica esplicita: "È stato spostato a {rail} a causa di ritardo/liquidità; la nuova ETA"...
Per VIP, l'opzione «accelerare» (altro binario/commissione).
Per i nuovi destinatari, un avviso di collina/step-up.

13) KPI и SLO

On-time rate (% dei pagamenti giunti prima della promessa ETA).
Median/P95 time-to-settle per binari/provider/geo.
Reject/Return rate e distribuzione dei motivi.
Fallback rate e il suo impatto su SLA/costo.
Liquidity uptime (tempo di disponibilità dei binari veloci).
Cost per payout e FX quota.
Supporto load (tickets/1k pagamenti) e NPS di output.

14) Assegno foglio di avvio catene

1. Catalogo dei binari: paese/valuta/limiti/commissione/ETA/cut-off/festività.
2. Policy Engine: regole di priorità dichiarative + esplain cause della soluzione.
3. Health provider: metriche, provini health, autoderiting.
4. Treasury: prefanding, limiti per il provider, auto-ricalance.
5. Idampotenza e DLQ: protezione da doppie/ripetizioni, retrai sicuri.
6. Webhooks/HMAC: convalida delle firme, timeout, ripetizione delle consegne.
7. Recon: daily + full, gli alert per le rassincroni.
8. UX: ETA, states, UTR/ARN, testi per motivi di folback/colline.
9. KYC/AML: step-up per nuovi beneficiari/importi elevati, procedure SoF/SoW.
10. Set di test: successo/rifiuto/rimborso, folback in termini di tempo/liquidità, cut-off/festività, degrado del provider.

15) Mini-pseudocode risolutore

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)

Riepilogo

Le catene di pagamento sono un routing intelligente tra velocità, prezzo, rischio e disponibilità operativa. Conservare le regole e le metriche in un configh, decidere sulla base di una funzione di compilazione in base alla liquidità e alla salute dei fornitori, garantire idampotenza, folback e onesta ETA. In questo modo si riducono i costi e i rimborsi, si mantiene la SLA e la fiducia degli utenti - soprattutto in segmenti sensibili come il iGaming e il cross border.