Settlement-Zyklen und Cut-Off

1) Konzeptionelle Basis

Settlement - Eine Abrechnung zwischen PSP/Acquirer und Merchant (Operator), bei der Geld für erfolgreich erbeutete Transaktionen auf ein Merchant-Konto überwiesen wird.
Cut-off ist ein täglicher „Schnitt“ von Operationen, die in einen bestimmten Abrechnungszyklus fallen (normalerweise eine feste Zeit in der Zeitzone des Anbieters).
T + N ist die typische Notation für die Verzögerung der Mitteldiversität: T ist das Cut-Off-Datum, N ist die Anzahl der Arbeitstage vor der tatsächlichen Einschreibung.

• Karten (Visa/Mastercard): oft T + 2/T + 3 Banktage, Schnitt 23:00 UTC (ungefähr).
• A2A/Open Banking: T + 0 bis 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, aber Cut-off durch Berichte möglich.
• Krypto: Tatsächlich ist T + 0 über das Netzwerk, aber die PSP kann ihre eigenen Funding-Fenster anwenden (T + 0/1).

2) Wie das Cut-off funktioniert und was hineinfällt

1. Der Anbieter legt das Erfassungsfenster fest (z.B. 00: 00-23: 00 UTC).
2. Alle settled/captured Transaktionen in diesem Fenster fallen in das Paket (batch).
3. Retouren, Chargebacks, Korrekturen werden zum Paket aggregiert, um Gross und Net Funding zu berechnen.
4. Nach dem Beginn des Cut-Offs wird eine Settlement-Datei gebildet und der T + N-Timer vor der Einschreibung gestartet.

Wichtig: Die Berechtigung ohne Capture landet nicht im Paket. Annullierte Befunde auch nicht.

3) Berechnungsarten: gross vs net, Reserven und Provisionen

Gross settlement - Der Bruttobetrag des Kapitals wird übertragen (abzüglich einer separaten Abschreibung von Gebühren).
Net settlement - der Anbieter hält fees, chargebacks, refunds, rolling reserve und listet net amount auf.
Rolling Reserve - Halten Sie% des Umsatzes für N Tage (z. B. 10% für 180 Tage), um das Risiko abzudecken.
Negative Carry-Over - Wenn das „Netto“ pro Tag ins Minus geht, wird das Defizit übertragen und in den nächsten Zyklen zurückgezahlt.

Empfehlung: Speichern Sie die Entschlüsselung beider Ebenen - operational gross (für Transaktionen) und funding net (für Providerdateien).

4) Zeitzonen, lokale Wochenenden und DST

Der Cut-off wird von einem Zeitzonen-Anbieter bestimmt, der sich von Ihrem unterscheiden kann.
Berücksichtigen Sie DST (Sommerzeit) - Schnitte können sich ± 1 Stunde relativ zur Ortszeit verschieben.
Feiertage/Wochenenden in der Gerichtsbarkeit der Empfängerbank beeinflussen N in T + N (z.B. T + 2 Banktage werden in T + 4 um Feiertage).
Übung: Normalisieren Sie alle technischen Zeiten in UTC, speichern Sie parallel 'provider _ tz _ cutoff _ at' und 'local _ tz _ posted _ at'.

5) Siedlungskalender (Funding Calendar) und SLA

• cut-off Zeit und tz für jede Methode/PSP,
• Standard T + N und Ausnahmen (Feiertage),
• erwartete Beträge (Prognosen),
• SLA des Empfangs: z. B. „bis spätestens 12:00 Uhr Europe/Kyiv am Tag T + 2“.

Alle SLA-Abweichungen → Alert und Ticket in Ops/Finance.

6) Relation zu Net Deposits und Schlussfolgerungen

ND (Nettoeinzahlungen) werden für settled Transaktionen gezählt (siehe verlinkter Artikel).
Leads (withdrawals) sind nicht an der Finanzierung von Einlagen durch die PSP beteiligt, beeinflussen jedoch die Kasse des Merchants.
Liquiditätsplanung: inflow nach Settlement minus outflow nach Zahlungen/Steuern/Betriebskosten.

7) Überleitung (Reconciliation) und Anbieter-Artefakte

• 'batch _ id/ settlement_id', cut-off-Datum im tz-Anbieter,
• суммы по типам: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• Entschlüsselung nach Methoden/Merchant-Konten („MID“, „Descriptor“, „MCC“),
• Transaktionsreferenzen („provider _ tx _ id“, „rrn“, „arn“ - falls Karten vorhanden),
• Datei (en): CSV/XML/JSON + menschenlesbares Statement (PDF/HTML).

1. Von Transaktionen zu Dateien (alles, was wir dachten, fiel in eine Datei?)

2. Von Dateien zu Transaktionen (alles in einer Datei ist in unserem Schaufenster? Sind die Zustände gleich?)

8) Besonderheiten auf den Zahlungsschienen (allgemein)

Karten: häufige Szenarien presentment delay; spätes „Chargeback“ ist möglich (bis zu 120-540 Tage pro Fall); interchange & scheme fees erscheinen in den Dateien, in ND werden sie nicht subtrahiert.
SEPA/ACH: Batches hängen von Bankfenstern ab; Stornierungen/Rücksendungen haben ihre eigenen Codes; Same Day Optionen sind separate Cut-offs.
Open Banking/A2A: T + 0/1, aber Dateien können post-factum gehen; die Notwendigkeit strenger RPP/Unique IDs für Spiele.
RTP/Instant: Das Geld kommt schnell, aber die Meldedatei ist termingerecht.
Crypto: Das Onchain-Raster ist sofort, aber der Anbieter macht „Windows-Auszahlung“; speichern 'fx _ at _ settle'.

9) Buchhaltung, Buchungen und Reporting (FI/Buchhaltung)

9. 1. Accrual vs Cache-Methode

Für die Managementberichterstattung wird häufig accrual verwendet: Wir erkennen den Umsatz/die Bewegung zum Zeitpunkt des' settled _ at'.
Für Treasury/DDS - Cash-Methode: Wir erkennen die Einnahmen von „funded _ at“ an.

9. 2. Typische Buchungen (vereinfacht)

• Dt: Zahlungsmittel in Abwicklung mit PSP (AR: PSP)
• KT: Verpflichtungen gegenüber dem Spieler (Geldbeutel/Spielerbilanz)

• Dt: Bank (Verkaufskasse)
• KT: Bargeld in Abrechnungen mit PSP
• Dt: Ausgaben (PSP fees), Dt/Kt: Rückstellungen (falls geändert)

Sie bewahren das Bündel ' transaction_id → batch_id → funding_id ' für die Trassierung.

10) Risikomanagement und Alerts

Fehlende Datei: keine settlement-Datei vor X: YY - P1.
Funding delay: T + N abgelaufen, kein Geld - P1.
Delta thresholds: Diskrepanz' our _ gross' vs' file _ gross'> 0. 5% - P2; 'fees' außerhalb des Bereichs - P2.
Negative Carry-Over: Eine Reihe negativer Nettopakete - Untersuchung.
Holiday impact: automatische Vorhersage unter Berücksichtigung des Kalenders; wenn die Tatsache <80% der Prognose ein Ticket ist.

11) Datenmodell (vereinfacht)

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) Beispiele für SQL-Vorlagen

12. 1. „Slice“ -Registrierung 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. Überleitung von Transaktionen zu Dateien

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. Umsatzprognose (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) Prozesse und SLO

SLO 1: Import von Siedlungsdateien - T + 0, bis 08:00 Europa/Kyiv.
SLO 2: primärer Abgleich - bis 09:00 Uhr, Alerts bei Abweichungen> 0. 5%.
SLO 3: Aktualisierung der Cash-Flow-Prognose - bis 10:00 Uhr.
SLO 4: Feierabend - alle Funding-Matches werden im DWH ausgetragen.

14) Edge-Fälle und wie man sie verarbeitet

Späte Präsentation: Die Transaktion hat den nächsten Batch erreicht - speichern Sie die „Quell-Tatsache“ ('presented _ in _ batch _ id').
Partielle Erfassung: Mehrere Erfassungen pro Autorisierung - korrekt in Batch aggregieren.
Multi-MID: ein Anbieter, verschiedene MIDs nach Geo/Marken - nicht in einer Charge mischen.
Reprocessing: Wenn Sie eine Datei zusammenfügen, versionieren Sie' batch _ revision 'und führen Sie einen vollständigen Re-Abgleich durch.
FX-Pferderennen: Kurse - auf 'settled _ at'; Funding in einer anderen Währung - starten Sie' fx _ at _ funding 'und Delta.

15) Dashboards und KPIs

Funding ETA: erwartetes Datum/Uhrzeit des Eingangs vs Tatsache.
Hit-Rate SLA: Der Anteil der Dateien, die pünktlich ankommen.
Delta gross/net nach Anbietern, Methoden, MIDs.
Fees % of volume, Reserve balance, Negative carry-over streak.
Urlaubswirkung: Prognose vs Fakt über Wochen mit Urlaub.

16) Best Practices (kurz)

1. Normalisieren Sie die Zeit in UTC, aber speichern Sie die cut-off- provider_tz.
2. Trennen Sie operational gross und funding net; ND und Funding nicht verwechseln.
3. Implementieren Sie einen Funding-Kalender mit vorgefertigten Feiertagen für Banken.
4. Automatisieren Sie den Import und Abgleich von Settlement-Dateien + Alerts auf SLA/Deltas.
5. Implementieren Sie die Batch-Versionierung ('batch _ revision') und die deterministische Reprocess.
6. Geben Sie eine einzelne Quelle der Wahrheit: link 'transaction ↔ batch ↔ funding'.
7. Speichern Sie ARN/RRN und Acquiring-Felder für Karten - kritisch für Dispute.
8. Prognostizieren Sie Cash-Flow unter Berücksichtigung von Wochenenden/Feiertagen, Reserven und Provisionen.

17) Checklisten zur Umsetzung

Daten und Diagramme

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

Import und Validierung

• CSV/XML/JSON Parser + Datei-Hashes.
• Validierung von Beträgen/Währungen/Daten; match по `provider_tx_id/ARN`.
• Handler „late presentment“, „partial capture“, „reversal“.

Vorgänge und Warnungen

• SLA-Monitor cut-off, fehlende Dateien, funding delays.
• Delta-Schwellenalerts (gross, fees, net).
• Bericht über Holiday Impact und negative Carry-Over.

18) FAQ

F: Warum wurde aus T + 2 T + 4?
A: Es gab Wochenenden/Feiertage bei der Korrespondenzbank oder bei der Empfängerbank; см. funding calendar.

F: Die Datei net ist kleiner als unsere net-Berechnung. Was zu sehen?
A: Überprüfen Sie die Fees, reserve_delta, späten Refund/Chargeback und die Korrektheit der Kurse.

F: Wie kann ich Krypto berücksichtigen?
A: Entsprechend dem Fiat-Äquivalent auf 'settled _ at'; funding kann in USDT/fiat kommen - halten Sie ein separates' fx _ at _ funding'.

F: Ist ein gemeinsamer Cut-Off für alle Anbieter möglich?
A: Nein, jede PSP hat ihre eigene tz/Stunde. Machen Sie eine aggregierende Vitrine über ihre Scheiben.

Zusammenfassung

• genaue Überprüfung der Anbieter,
• Liquiditätsprognose und Deckung der Zahlungen,
• Einhaltung der SLA und Verringerung der operationellen Risiken,
• Sprechen Sie die gleiche Sprache mit Finanzen und Compliance.

Durch die Implementierung eines einzigen Funding-Kalenders, eines strengen Datenmodells und eines automatisierten Abgleichs machen Sie den Cashflow vorhersehbar und überschaubar.