Settlement dei cicli e cut-off

1) Base comprensibile

Settlement (Settlement) - Calcola tra PSP/Acquirer e il merchant (operatore), in cui il denaro delle transazioni catturate con successo viene trasferito su un conto merchant.
Cut-off è un taglio giornaliero delle operazioni che entrano in un ciclo di calcolo specifico (in genere tempo fisso nel timesone del provider).
T + N è la tipica notazione di ritardo di espletamento: T è la data cut-off, N è il numero di giorni lavorativi prima dell'iscrizione effettiva.

• Carte (Visa/Mastercard): spesso T + 2/T + 3 banking days, cut-off 23:00 UTC (circa).
• A2A/Open Banking: da T + 0 a T + 1.
• SEPA Credit Transfer: T+1/T+2 (Instant — T+0).
• ACH (US): T+2/T+3; Same Day ACH — T+0/T+1.
• RTP (US): T + 0, ma sono possibili cut-off per report.
• Kripto: in realtà T + 0 sulla rete, ma PSP può utilizzare le proprie finestre di funding (T + 0/1).

2) Come funziona cut-off e cosa entra in esso

1. Il provider registra la finestra di raccolta (ad esempio 00: 00-23: 00 UTC).
2. Tutte le transazioni settled/captured in questa finestra finiscono nel batch.
3. Al pacchetto vengono aggregati rimborsi, charjback, correzioni per calcolare gross e net funding.
4. All'arrivo di cut-off viene generato un file settlement e inizia il timer T + N prima dell'iscrizione.

Importante: l'autorizzazione senza capture non viene inserita nel pacchetto. Neanche le conclusioni annullate.

3) Tipi di calcolo: gross vs net, riserve e commissioni

Gross settement - Viene elencato l'importo lordo di capture (meno il prelievo separato delle commissioni).
Net settement - il provider mantiene fees, marcebacks, refunds, rolling reserve e elenca net amount.
Rolling reserve - Trattenere il% del fatturato per N giorni (ad esempio 10% per 180 giorni) per coprire il rischio.
Negative carry-over - Se il «netto» del giorno va in svantaggio, il deficit viene spostato e rimborsato dai seguenti cicli.

Raccomandazione: memorizzare entrambi i piani - operational gross (per transazione) e funding net (per file provider).

4) Timeson, weekend locale e DST

Cut-off è determinato da un provider temporale che può essere diverso dal tuo.
Tieni conto di DST (transizione all'ora estiva) - i tagli possono essere spostati di © 1 ora rispetto all'ora locale.
Festività/fine settimana nella giurisdizione della banca destinatario influisce sulla N in T + N (ad esempio T + 2 banking days si trasforma in T + 4 intorno alle festività).
Pratica: normalizza tutti i tempi tecnici in UTC, memorizza parallelamente «provider _ tz _ cutoff _ at» e «locale _ tz _ posted _ at».

5) Calendario Settlement (funding calendar) e SLA

• cut-off tempo e tz per ogni metodo/PSP,
• T + N standard e eccezioni (vacanze),
• gli importi previsti (previsioni),
• SLA ricezione: ad esempio, «entro le 12:00 Europa/Kyiv nel giorno T + 2».

Eventuali deviazioni SLA e ticket in Ops/Finance.

6) Relazione con Net Deposits e conclusioni

ND (versamenti netti) è considerato per transazioni settled (vedere l'articolo collegato).
Le conclusioni (withdrawals) non partecipano al funding da PSP per i depositi, ma influenzano la cassa merchant.
Pianificazione della liquidità: inflow settment meno outflow per pagamento/tasse/spese operative.

7) Ricomposizione e manufatti dei provider

• 'batch _ id/settlement _ id', data cut-off nel tz provider,
• суммы по типам: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• decriptazione dei metodi/account merchant («MID», «descriptor», «MCC»),
• gli indirizzi delle transazioni («provider _ tx _ id», «rrn», «arn» - se carte),
• file (s) CSV/XML/JSON + statement umano (PDF/HTML).

1. Da transazioni a file (tutto quello che credevamo fosse nel file?)

2. Dai file alle transazioni (tutto quello che c'è nel file è nella nostra vetrina? Gli stati corrispondono?)

8) Specificità dei binari di pagamento (in termini generali)

Mappe: frequenti script presentment delay; Possibili «chargeback» tardivi (fino a 120-540 giorni per valigetta); interchange & scheme fees compaiono nei file e ND non vengono sottratti.
SEPA/ACH: i batch dipendono dalle finestre bancarie; annullamenti/rimborsi hanno codici personalizzati; Le opzioni Same Day sono cut-off separati.
Open Banking/A2A: T + 0/1, ma i file possono andare post-factum; necessità di RPP/ID unico rigoroso per le partite.
RTP/Instant: il denaro viene rapidamente, ma il file di riferimento è programmato.
Kripto: la rete onchain è immediata, ma il provider fa «payout windows»; memorizzare'fx _ at _ settle '.

9) Contabilità, cavi e rapporti (FI/Accounting)

9. 1. Accrual vs metodo cache

Per i report di gestione viene spesso utilizzato l'accrual, riconoscere il ricavato/movimento al momento dì settled _ at ".
Per il Tesoro/DDS - Metodo di cache: ammettiamo il dato di ammissione dì funded _ at ".

9. 2. Cavi tipici (semplificati)

• DT: Contanti PSP (AR: PSP)
• Tac: Obblighi per il giocatore (portafoglio/saldo del giocatore)

• DT: Banca (cassa merchant)
• Tac: Contanti PSP
• DT Spese (PSP fees), DT/Tac: Riserve (se cambiate)

Memorizza il legamento'trasmissione _ id → batch _ id → funding _ id 'per la traccia.

10) Risk management e alert

File Missed: nessun file settlement prima di X: YY - P1.
Funding delay: T + N scaduto, niente soldi - P1.
Delta thresholds: soluzione "our _ gross" vs'file _ gross "> 0. 5% - P2; 'fees'fuori intervallo - P2.
Negative carry-over - Serie di pacchetti netti negativi - indagine.
Impatto Holiday: previsione automatica in base al calendario; se il numero <80% della previsione è ticket.

11) Modello di dati (semplificato)

finance. payment_transactions (
id, user_id, method, provider, mid, mcc,
type, status, amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
authorized_at, captured_at, settled_at,
provider_tx_id, arn, rrn, meta
)

finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)

finance. funding_receipts (
funding_id, provider, bank_account,
received_at, value_date,
currency, amount_received,
batch_id, statement_ref, meta
)

-- Binding showcase:
finance. recon_links (
id, transaction_id, batch_id, funding_id, link_type, created_at
)

12) Modelli SQL di esempio

12. 1. Registrazione del taglio per cut-off

sql
INSERT INTO finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)
VALUES (:batch_id,:provider,:mid,:method,
:cutoff_at,:tz,
:start_at,:end_at,
:gross,:refunds,:cb_deb,:cb_cr,
:fees,:reserve_delta,:net_expected,
:file_name,:file_hash,:file_type,:meta::jsonb);

12. 2. Scorciatoia da transazioni a file

sql
WITH tx AS (
SELECT provider, mid, method,
SUM(CASE WHEN type='DEPOSIT' AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS gross,
SUM(CASE WHEN type='REFUND' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS refunds,
SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_cr
FROM finance. payment_transactions
WHERE settled_at >=:start_at AND settled_at <:end_at
GROUP BY 1,2,3
)
SELECT b. batch_id, b. provider, b. mid, b. method,
tx. gross AS our_gross, b. gross_captured AS file_gross,
tx. refunds AS our_refunds, b. refunds AS file_refunds,
tx. cb_deb AS our_cb_deb, b. cb_debits AS file_cb_deb,
tx. cb_cr AS our_cb_cr, b. cb_credits AS file_cb_cr
FROM finance. settlement_batches b
LEFT JOIN tx
ON tx. provider=b. provider AND tx. mid=b. mid AND tx. method=b. method
WHERE b. provider_cutoff_at BETWEEN:cutoff_from AND:cutoff_to;

12. 3. Bilancio previsto (cash-flow T + N)

sql
SELECT provider, mid, method,
DATE(provider_cutoff_at) AS t_date,
net_funding_expected,
CASE
WHEN EXTRACT (DOW FROM provider_cutoff_at)::int IN (5,6) THEN provider_cutoff_at + INTERVAL '3day' -- conditional example
ELSE provider_cutoff_at + INTERVAL '2 day'
END AS expected_funding_at
FROM finance. settlement_batches
WHERE provider_cutoff_at BETWEEN:from AND:to;

13) Processi e SLO

SLO 1 - Importa i file settlement - T + 0, fino alle 08:00 Europa/Kyiv.
SLO 2: compressione primaria - fino alle 9:00, allerti per discrepanza> 0. 5%.
SLO 3: aggiornamento della previsione cash-flow fino alle 10:00.
SLO 4 - Chiusura della giornata - Tutte le partite di funding sono in DWH.

14) Edge-case e come gestirli

Late presentment - La transazione è arrivata nel batch seguente - Memorizza il dato di origine ('presented _ in _ batch _ id').
Partial capture: più capture per singola autorizzazione - Aggregare correttamente in batch.
Multi-MID: unico provider, diversi MIDs per geo/brand - non miscelare in un unico lotto.
Riprocessing: versioning dì batch _ revision "e ricompressione completa del file.
Corsi FX a settled _ at; funding in una valuta diversa - Imposta «fx _ at _ funding» e Delta.

15) Dashboard e KPI

Funding ETA - Data/ora prevista per l'arrivo vs dato.
Hit-rate SLA - Percentuale di file arrivati in tempo.
Delta grosse/net per provider, metodi, MIDs.
Fees % of volume, Reserve balance, Negative carry-over streak.
Holiday impact: previsione vs per le settimane con le vacanze.

16) Best practices (breve)

1. Regolate il tempo in UTC, ma memorizzate provider _ tz cut-off.
2. Separare operational gross e funding net; non confondere ND e funding.
3. Implementare il funding calendar con le vacanze bancarie anticipate.
4. Automatizzare l'importazione e la riconciliazione di file settlement + alert su SLA/Delta.
5. Implementare la versioning dei lotti ('batch _ revision') e la reprocess definita.
6. Inserisci il singolo source of truth: connessioni dì transaction n'batch ".
7. Conserva ARN/RRN e i campi equairing per le mappe - critico per i display.
8. Prevedere cash-flow in base a weekend/festività, riserve e commissioni.

17) Assegni di implementazione

Dati e schemi

• Таблицы `payment_transactions`, `settlement_batches`, `funding_receipts`, `recon_links`.
• Campi timeson: UTC + provider _ tz.
• Поля FX: `fx_rate_at_settle`, `fx_at_funding`.

Importazione e convalida

• Parsers CSV/XML/JSON + hash file.
• Validazione di importi/valute/date; match по `provider_tx_id/ARN`.
• Hendler «late presentment», «partial capture», «reversal».

Operazioni e alert

• Monitor SLA cut-off, missed files, funding delays.
• Alert di soglia Delta (gross, fees, net).
• Report su holiday impatto e negative carry-over.

18) FAQ

Q: Perché T + 2 è diventato T + 4?
A: Ci sono stati weekend/festività presso la banca corrispondente o presso la banca destinataria; см. funding calendar.

Q: Il file net è più piccolo del nostro calcolo net. Cosa guardare?
A: Controlla fees, reserve _ delta, refund/conformeback tardivi e correttezza dei corsi.

Come si tiene conto della cripta?
A: Per l'equivalente fieristico di «settled _ at»; funding può venire a USDT/fiat - Memorizza singolarmente «fx _ at _ funding».

Q: È possibile condividere un cut-off per tutti i provider?
A: No, ogni PSP ha una tz/ora. Fate una vetrina di aggregazione sopra i loro tagli.

Riepilogo

• ricontrollare con precisione i provider,
• prevedere la liquidità e coprire i pagamenti,
• adempiere alla SLA e ridurre i rischi operativi,
• Parlare la stessa lingua con la finanza e la compliance.

Con l'implementazione di un unico funding calendar, un modello di dati rigoroso e la riconciliazione automatizzata, si rende il flusso di cassa prevedibile e gestibile.