Criteri di conclusione: tempistica e KYC

1) Perché formalizzare il criterio delle conclusioni

• riduce i tessuti e le escalation («Quando arriveranno i soldi?» »);
• Fornisce la conformità AML/KYC (età, sanzioni, SoF/SoW);
• riduce il frodo/charjbeck e le controversie arbitrali;
• fornisce SLA prevedibili per la finanza/sapport/marketing.

2) Classificazione dei binari e velocità prevista

3) Livelli KYC e impatto sulle conclusioni

Principio: più alto è KYC, più ampio è il binario disponibile e più alto è il limite/velocità.

Basic (semplificato): piccoli limiti sono consentiti solo «lenti» o conclusioni interne (per portafoglio/limitato A2A).
Full KYC (ID + Address + Liveness) - Limiti standard; accesso ai binari bancari, Push-to-Card, circuiti veloci locali.
EDD (esteso): importi elevati/pagamenti frequenti; richiede SoF/SoW (origine fondi/stato), elenchi bianchi dei destinatari, elaborazione accelerata.

Step-up-trigger: importo elevato, nuovo destinatario, dispositivo/geo non comune, eccesso di velocity, high-risk MCC (iGaming, quasi-cache), vincita accumulata.

4) Limiti e antifrode nelle conclusioni

• Per-transaction / Daily / Weekly / Monthly caps.
• Velocity: N pagamenti/ora, importi a finestra scorrevole, frequenza di cambio di identità.
• Nuovi destinatari: cooling/cooling-off obbligatorio ridotto (ad esempio 12-24 ore) e step-up.
• Geo/sanzioni: lista deny/allow, divieto di determinati paesi/banche.
• Profilo di rischio: multiplicatori di limiti per punteggio client/sessione.
• Payout-lock - Blocco temporaneo dopo anomalie/conformeback/ODR, prima del completamento del controllo.

5) Stati payout e modello operativo

• «richiested» - Richiesta utente
• «queued» - in coda di pagamento
• «processing» - in elaborazione presso il provider/banca
• «sent» - inviato nel binario (c'è UTR/ARN/Trace)
• «settled» - Accredito confermato dal destinatario/nessun finrisco
• «failed» - guasto del binario/banca
• «reversed/returned» - rimborso (ACH-R, SEPA return, FPS reject)
• «on _ hold» - Compilazione/EDD/SoF
• «canceled» - annullato dall'utente/operatore

Artefatti: «payoutId», «requestId», «beneficiaryId», «rail», «amount/currency», «UTR/ARN/Trace», codici di errore.

6) Pagamenti e architettura core

• Orchestratore (state machine) - Routing su binari/limiti/timsons.
• Scheduler - Contabilità cut-off/festività (per-rail/per-country).
• Idempotency chiave su «requestId» + deduplicazione degli eventi.
• Provider Webhooks: firma/NMAS, retrai con backoff, DLQ.
• Recordation: auto-recon per registro (giornaliero) + full-recon periodico; storage UTR/ARN.
• Policy Engine: regole CUS/limiti/screening e cause di guasto (explainability).
• Treasury/Liquidità: monitoraggio dei residui in PSP/banche, prefanding a binari veloci, rebalance.

7) Liquidità e prefanding

I binari veloci (RTP/FPS/PIX/Push-to-Card/e-wallets) richiedono spesso il prefanding.
Mantieni i limiti per il provider e auto-ricalance (sweep) tra i conti.
Divario di cassa: separa la contabilità dei pagamenti «promessi» dai debiti effettivi.
Immettere un metodo di dereiting automatico in caso di perdita di liquidità (passare temporaneamente a binari lenti).

8) Comunicazioni e UX

Mostra la data/ora prevista per la ricezione in base al binario, cut-off e TZ dell'utente.
Gli stati spiegabili sono: «a controllo», «in attesa di una finestra bancaria», «inviato: numero UTR/ARN».
FAQ nel prodotto: limiti, tempi, binari supportati, che cosa significa, perché la richiesta è stata rifiutata.
Nuovi destinatari: avviso di hold/step-up, conferma di identità (micro-deposit/1-cent check, test payout).
Anti-error UX: maschera VA/BIC, convalida del formato, suggerimento BSB/Sort code, salvataggio dei «modelli» dei destinatari.
Cooldown: ritardo soffice per profili ad alto rischio con causa trasparente.

9) Complaens: KYC/AML/EDD/SoF/SoW

KYC: ID, indirizzo, liveness; età e geo-blocchi.
Sazioni/PEP: screening in modalità onboording e ciclica; Prima dei pagamenti, un nuovo assegno.
SoF/SoW: conferma dell'origine del denaro/stato (estratti conto bancari, redditi, contratto).
Case-management: registro delle soluzioni, elaborazione SLA, audit-trail.
Responciabile Gaming (per il iGaming): colli per il prelievo, controlli di auto-esclusione, limiti diurni/settimanali «responsabili».

10) Errori e restituzioni lungo i binari (cosa da considerare)

ACH (R01... R10), finestre NACHE, fogli di blocco.
SEPA: Reject/Return/Recall; Convalida IBAN, ragione del codice (AC04, AG01, ecc.).
FPS/RTP/PIX: solitamente finalità; Restituzione - singola contropartita.
Push-to-Card: possibilità di ritardi nell'emittente/deviazione dei limiti.
SWIFT - Commissione di corrispondenti, «lifting fees», ritardo sulla compilazione della banca destinataria.

11) Economia e commissioni

Fee modello: fix/percentuale, soglie di importo, margine FX, tariffe separate per i binari veloci.
Livello KYC: tariffe VIP/EDD - sotto commissione/priorità; Basic è un costo di manutenzione superiore.
Costi antifrode: costo dei controlli/investimenti, percentuale di rimborso/rifiuto.
Ottimizzazione: raggruppamento dei pagamenti (batch), pianificazione dei binari «lenti» in off-peak, scelta del binario per importo/paese/ora del giorno.

12) KPI/metriche per il controllo

I pagamenti SLA sono il% dei pagamenti in scadenza.
Time-to-Cash: mediana/95-percentile del tempo fino à settled ".
Return/Reject rate per binari e motivi (codici).
Share by rail - Distribuisce i metodi e le loro approve/settle.
ODR/reclami per ritardi/guasti.
Hold/EDD rate: percentuale dei pagamenti finiti nel controllo manuale; Tempo medio di soluzione.
Liquidity uptime: tempo in cui i binari veloci sono disponibili.
Cost per payout и FX impact.

13) Assegno-foglio di avvio criteri di output

1. Matrice dei binari: paesi/valute/limiti/tempi/cut-off/festività - nel servizio config.
2. Policy Engine: regole KYC/limiti/velocity/EDD con i loghi esplorativi.
3. Orchestratore pagamenti: coda, retrai, idempotenza, webhooks con HMAC.
4. Treasury: prefanding dei binari veloci, auto-ribalance, limiti del provider.
5. provider, playbook, SLA, escalation.
6. UX/Comunicazione: ETA per binari, states, UTR/ARN, comprensibili cause di colline/guasti.
7. Recon: daily auto-recon + full-recon; «Successo senza registro», «aging payouts».
8. Monitoraggio: dashboard KPI, ansia di liquidità/guasti/aumento dei rimborsi.
9. Pacchetto di prova: e2e per ogni binario (successo/rifiuto/rimborso), nuovo destinatario, grande importo, timeout del provider.

14) Modello di sezione criteri (per ToS/wiki)

• SEPA: T + 1 BD (fino alle 15:00 ET), SEPA Instant - solitamente entro 30 minuti.
• FPS/PIX/RTP: in genere modalità minuti, ma è possibile verificare fino a 24 ore per i nuovi destinatari.
• ACH: T+1–T+2 BD; Same Day ACH - al lancio fino al kat-off della banca.

• Fino a € X/giorno - Basic, oltre - richiede ID + selfie; oltre € Y - SoF/SoW.
• Il nuovo destinatario è fino a 24 ore di hold sicuro.

• Per-txn: …, Daily: …, Weekly: … (dinamico per livello/rischio).

• SEPA/FPS — …, SWIFT — … (+ commissione corrispondenti), Push-to-Card -....

• In caso di Reject/Return, i fondi torneranno in saldo entro...; la ragione della notifica (codice/descrizione).

15) Risposte rapide per lo zapport

Quando arriveranno i soldi? Il tuo UTR/ARN è {codice}.
Le regole di sicurezza hanno funzionato (nuovo destinatario/importo/geo). Scaricare il documento {SoF/ID}.
Il cantiere rapido {} richiederà un prefanding o un limite diverso; Possiamo proporre un metodo alternativo.
La banca del destinatario ha rifiutato (codice {X}). Controllare le informazioni o selezionare un altro binario.

Riepilogo

Forte politica delle conclusioni = tempi trasparenti + prevedibili limiti KYC + affidabile orchestrazione dei binari. Conservare le regole in un configh, utilizzare policy engine con i loghi di esplorazione, garantire l'idempotenza/Recon/Webhooks, gestire la liquidità e il prefanding e comunicare con l'utente l'esatta ETA + UTR/ARN. Così si riduce il rischio, si mantiene la compliance e si aumenta la fiducia senza sacrificare la velocità di pagamento.