Settlement boucles et cut-off

1) Base conceptuelle

Settlement (settlement) : Calcul entre PSP/Acquirer et le merchant (opérateur), dans lequel l'argent des transactions saisies avec succès est transféré sur un compte merchant.
Cut-off est une « coupe » quotidienne des opérations qui entrent dans un cycle de calcul particulier (généralement un temps fixe dans le temps du fournisseur).
T + N est la notation typique du retard de diversité des fonds : T est la date cut-off, N est le nombre de jours ouvrables avant l'inscription effective.

• Cartes (Visa/Mastercard) : souvent T + 2/T + 3 jours bancaires, cut-off 23:00 UTC (environ).
• A2A/Open Banking : de T + 0 à 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, mais il est possible de couper-désactiver les rapports.
• Crypto : en fait T + 0 sur le réseau, mais PSP peut appliquer sa propre fenêtre de funding (T + 0/1).

2) Comment fonctionne cut-off et ce qui y entre

1. Le fournisseur enregistre une fenêtre de collecte (par exemple 00 : 00-23 : 00 UTC).
2. Toutes les transactions settled/captured de cette fenêtre entrent dans le paquet (batch).
3. Les retours, les chargbecks, les corrections sont agrégés au paquet pour calculer gross et net funding.
4. À l'arrivée de cut-off, le fichier de réglage est généré et le minuteur T + N démarre avant l'enrôlement.

Important : l'autorisation sans capture n'entre pas dans le paquet. Les conclusions annulées ne sont pas non plus.

3) Types de règlement : gross vs net, réserves et commissions

Gross settlement - le montant brut de capture est transféré (moins les frais distincts).
Net settlement - le fournisseur retient fees, chargebacks, refunds, rolling reserve et liste net amount.
Rolling reserve - maintien du % du chiffre d'affaires pendant N jours (par exemple 10 % pendant 180 jours) pour couvrir le risque.
Negative carry-over - si le « net » par jour passe à moins, le déficit est reporté et remboursé par les cycles suivants.

Recommandation : stocker le décryptage des deux plans - operational gross (par transaction) et funding net (par fichier fournisseur).

4) Temps, week-end local et DST

Cut-off est déterminé par le fournisseur de temps qui peut être différent du vôtre.
Tenez compte du DST (passage à l'heure d'été) - les tranches peuvent être décalées de ± 1 heure par rapport à l'heure locale.
Les jours fériés/week-ends dans la juridiction de la banque bénéficiaire affectent N en T + N (par exemple, les jours fériés T + 2 sont convertis en T + 4 autour des jours fériés).
Pratique : normaliser tous les temps techniques en UTC, stocker en parallèle 'provider _ tz _ cutoff _ at'et' local _ tz _ posted _ at'.

5) Calendrier d'installation (calendrier de funding) et SLA

• temps de coupe et tz pour chaque méthode/PSP,
• T + N standard et exceptions (jours fériés),
• les montants attendus (prévisions),
• SLA de réception : par exemple, « au plus tard à 12h00 Europe/Kyiv le jour T + 2 ».

Tout écart de SLA → alert et ticket dans Ops/Finance.

6) Interconnexion avec Net Deposits et conclusions

ND (dépôts nets) sont considérés comme des transactions settled (voir article lié).
Les conclusions (withdrawals) ne sont pas impliquées dans le funding de PSP sur les dépôts, mais affectent la caisse du merchant.
Planification des liquidités : inflow par settlement moins outflow par paiements/impôts/dépenses d'exploitation.

7) Rapprochement (reconciliation) et artefacts des fournisseurs

• 'batch _ id/ settlement_id', date cut-off dans le fournisseur tz,
• суммы по типам: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• décryptage par méthodes/comptes merchant ('MID', 'descriptor', 'MCC'),
• les références des transactions ('provider _ tx _ id', 'rrn', 'arn' - si les cartes),
• Fichier (s) : CSV/XML/JSON + Déclaration (PDF/HTML).

1. Des transactions aux fichiers (tout ce que nous comptions dans le fichier ?)

2. Des fichiers aux transactions (tout ce qui est dans le fichier est dans notre vitrine ? les statuts correspondent-ils ?)

8) Spécificité des rails de paiement (en termes généraux)

Cartes : scripts de présentation fréquents ; « chargeback » tardif (jusqu'à 120-540 jours par case) ; interchange & scheme fees apparaissent dans les fichiers, ne sont pas déduits dans ND.
SEPA/ACH : les batchies dépendent des guichets bancaires ; les annulations/retours ont leurs propres codes ; Same Day variantes - cut-off séparé.
Open Banking/A2A : T + 0/1, mais les fichiers peuvent aller post-factum ; la nécessité d'un RPP/ID unique rigoureux pour les matchs.
RTP/Instant : l'argent arrive rapidement, mais le fichier de rapport est programmé.
Crypto : onchain-setlment est instantané, mais le fournisseur fait « payout windows » ; stocker 'fx _ at _ settle'.

9) Comptabilité, affichage et reporting (FI/Comptabilité)

9. 1. Accroal vs méthode cache

Pour les rapports de gestion, l'accrual est souvent utilisé : reconnaître les revenus/mouvements au moment "settled _ at'.
Pour le Trésor/DDS, la méthode cache : nous reconnaissons le fait de recevoir "funded _ at'.

9. 2. Câblage type (simplifié)

• Dt : Liquidités dans les paiements avec PSP (AR : PSP)
• Ct : Obligations envers le joueur (portefeuille/solde du joueur)

• Dt : Banque (caisse du merchant)
• Ct : Liquidités dans les paiements avec PSP
• Dt : Dépenses (PFP fees), Dt/Ct : Réserves (si changées)

Gardez le lien 'transaction _ id → batch_id → funding_id' pour le traçage.

10) Gestion des risques et alertes

Fichier missed : Aucun fichier settlement avant X : YY - P1.
Funding delay : T + N expiré, pas d'argent - P1.
Delta thresholds : divergence 'our _ gross' vs 'file _ gross'> 0. 5 % - P2 ; 'fees' hors de portée - P2.
Negative carry-over : une série de paquets nets négatifs est une enquête.
Holiday impact : prévision automatique avec calendrier à l'esprit ; si le fait <80 % de la prévision est un tiquet.

11) Modèle de données (simplifié)

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) Exemples de modèles SQL

12. 1. Enregistrement de la « tranche » par 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. Rapprochement des transactions au fichier

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. Prévisions de recettes (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) Processus et SLO

SLO 1 : importation de fichiers settlement - T + 0, jusqu'à 08h00 Europe/Kyiv.
SLO 2 : rapprochement primaire - jusqu'à 09:00, alertes sur les écarts> 0. 5%.
SLO 3 : mise à jour des prévisions de cash-flow - jusqu'à 10h00.
SLO 4 : fermeture de la journée - tous les matchs de funding sont lancés en DWH.

14) Edge-cases et comment les traiter

Late presentment : la transaction est entrée dans le batch suivant - stockez le « fait source » ('presented _ in _ batch _ id').
Capture partielle : plusieurs captures par autorisation - agrégez correctement dans batch.
Multi-MID : un fournisseur, différents MID par géo/marques - ne pas mélanger dans le même lot.
Reprocessing : Lorsque vous tondez un fichier, vous versionnez 'batch _ revision' et faites un rapprochement complet.
Courses FX : les cours sont sur 'settled _ at' ; funding dans une autre monnaie - entrez 'fx _ at _ funding' et delta.

15) Dashboards et KPI

Funding ETA : date/heure d'arrivée prévue vs fait.
Hit-rate SLA : proportion de fichiers arrivant à l'heure.
Delta gross/net par fournisseurs, méthodes, MIDs.
Fees % of volume, Reserve balance, Negative carry-over streak.
Holiday impact : pronostic vs fait par semaines avec les vacances.

16) Meilleures pratiques (en bref)

1. Normaliser le temps dans UTC, mais stocker le provider_tz cut-off.
2. Séparez operational gross et funding net ; ne confondez pas ND et funding.
3. Mettez en place un calendrier funding avec des vacances bancaires préétablies.
4. Automatisez l'importation et le rapprochement des fichiers settlement + alerts sur SLA/delta.
5. Implémenter la versionation des lots ('batch _ revision') et la reprise déterministe.
6. Entrez une source unique de truth : liens 'transaction ↔ batch ↔ funding'.
7. Gardez ARN/RRN et les champs d'équitation pour les cartes - essentiel pour les disputes.
8. Prédire le cash-flow en tenant compte des week-ends/jours fériés, des réserves et des frais.

17) Chèques-feuilles de mise en œuvre

Données et schémas

• Таблицы `payment_transactions`, `settlement_batches`, `funding_receipts`, `recon_links`.
• Champs temporels : UTC + provider_tz.
• Поля FX: `fx_rate_at_settle`, `fx_at_funding`.

Importation et validation

• Parser CSV/XML/JSON + hachage de fichiers.
• Validation des montants/monnaies/dates ; match по `provider_tx_id/ARN`.
• Hendler « late presentment », « partial capture », « reversal ».

Opérations et alertes

• SLA-monitor cut-off, fichiers envoyés, funding delays.
• Alerts de seuil delta (gross, fees, net).
• Rapport sur l'impact des vacances et le carry-over negatif.

18) FAQ

Q : Pourquoi T + 2 est-il devenu T + 4 ?
A : Il y avait des week-ends/jours fériés à la banque correspondante ou à la banque bénéficiaire ; см. funding calendar.

Q : Le fichier net est plus petit que notre calcul net. Que regarder ?
R : Vérifiez les fees, les reserve_delta, les remboursements tardifs/chargeback, et la justesse des cours.

Q : Comment prendre en compte la crypte ?
A : Par équivalent fiat par 'settled _ at' ; funding peut venir à USDT/fiat - gardez un 'fx _ at _ funding' séparé.

Q : Est-il possible d'avoir une seule coupe générale pour tous les fournisseurs ?
R : Non, chaque PSP a son tz/heure. Faites une vitrine d'agrégation sur leurs tranches.

Résumé

• vérifier avec précision les fournisseurs,
• prévoir la liquidité et couvrir les paiements,
• respecter l'ALS et réduire les risques opérationnels,
• parler la même langue que la finance et la conformité.

En introduisant un calendrier de financement unique, un modèle de données rigoureux et un rapprochement automatisé, vous rendrez les flux de trésorerie prévisibles et gérables.