Cicluri de decontare și întreruperi

1) Baza conceptuală

Decontare - decontare între PSP/Achizitor și comerciant (operator), în care banii pentru tranzacțiile capturate cu succes sunt transferați în contul comerciantului.
Cut-off - o „felie” zilnică de operațiuni care se încadrează într-un anumit ciclu de facturare (de obicei, un timp fix în fusul orar al furnizorului).
T + N - notație tipică pentru întârzierea detașării fondurilor: T - data întreruperii, N - numărul de zile lucrătoare înainte de înscrierea efectivă.

• Carduri (Visa/Mastercard): adesea T + 2/T + 3 zile bancare, cut-off 23:00 UTC (aproximativ).
• A2A/Open Banking: T + 0 la T + 1.
• Transfer de credit SEPA: T + 1/T + 2 (Instant - T + 0).
• ACH (SUA): T + 2/T + 3; Aceeași zi ACH - T + 0/T + 1.
• RTP (SUA): T + 0, dar cut-off pe rapoarte este posibil.
• Cripto: de fapt T + 0 în rețea, dar PSP poate aplica propriile ferestre de finanțare (T + 0/1).

2) Cum funcționează cut-off și ce intră în ea

1. Furnizorul stabilește fereastra de colectare (de exemplu, 00: 00-23: 00 UTC).
2. Toate tranzacțiile decontate/capturate în această fereastră se încadrează într-un lot.
3. Returnările, taxele, corecțiile sunt agregate la pachet pentru a calcula finanțarea brută și netă.
4. La decupare, este generat un fișier de decontare și cronometrul T + N începe înainte de înscriere.

Important: autorizația fără captură nu este inclusă în pachet. Concluzii anulate - de asemenea, nu.

3) Tipuri de decontare: brut vs net, rezerve și comisioane

Decontarea brută - suma brută de captare este transferată (minus o taxă de comision separată).
Decontare netă - furnizorul deține taxe, chargeback-uri, rambursări, rezervă rulantă și listează suma netă.
Rezervă rulantă - reținerea% din cifra de afaceri pentru zilele N (de exemplu, 10% pentru 180 de zile) pentru a acoperi riscul.
Reportare negativă - în cazul în care „net” merge în minus pe zi, deficitul este transferat și plătit în următoarele cicluri.

Recomandare: stocați decriptarea ambelor planuri - brut operațional (prin tranzacții) și net de finanțare (prin fișiere furnizor).

4) Fus orar, ieșire locală și DST

Cut-off este determinată de fusul orar al furnizorului, care poate diferi de a ta.
Luați în considerare DST (timp de economisire a luminii de zi) - feliile se pot schimba cu ± 1 oră în raport cu ora locală.
Sărbătorile/weekendurile din jurisdicția băncii beneficiare afectează N în T + N (de exemplu, zilele bancare T + 2 devin T + 4 în preajma sărbătorilor).
Practică: normalizați toate timpii tehnici în UTC, stocați simultan 'provider _ tz _ cutoff _ at' și 'local _ tz _ posted _ at'.

5) Calendar de decontare (calendar de finanțare) și SLA

• timp de întrerupere și tz pentru fiecare metodă/PSP
• standard T + N și excepții (sărbători)
• sumele preconizate (previziuni)
• Chitanță SLA: de exemplu, „nu mai târziu de ora 12:00 Europa/Kiev în ziua T + 2”.

Orice abateri SLA → alertă și bilet la Ops/Finance.

6) Relația cu depozitele și ieșirile nete

ND (contribuții nete) se bazează pe tranzacții decontate (a se vedea articolul aferent).
Concluziile (retragerile) nu participă la finanțarea de la PSP privind depozitele, ci afectează casieria comerciantului.
Planificarea lichidității: aflux prin decontare minus ieșire prin plăți/taxe/cheltuieli de funcționare.

7) Reconciliere și artefacte furnizor

• 'batch _ id/ settlement_id', data limită în furnizorul tz,
• суммы по типам: 'captured _ deposits',' restituiri ',' chargeback _ debits', 'chargeback _ credits',' comisioane ',' reserve _ delta ',' net _ financing ',
• decriptarea prin metode/conturi comerciale ("MID'," descriptor "," MCC ")
• referințe de tranzacție ('provider _ tx _ id',' rrn', 'arn' - dacă cardurile),
• fişier (e): CSV/XML/JSON + declaraţie lizibilă umană (PDF/HTML).

1. De la tranzacții la fișiere (tot ce am crezut că a fost în fișier?)

2. De la fișiere la tranzacții (totul în fișier este în magazinul nostru? se potrivesc statutele?)

8) Specificul șinelor de plată (în termeni generali)

Hărți: scenarii frecvente de întârziere a prezentării; întârziere „chargeback” sunt posibile (până la 120-540 de zile pentru caz); comisioanele interbancare și de sistem apar în fișiere, nu sunt deduse în ND.
SEPA/ACH: Loturile depind de ferestrele băncii; Anulările/returnările au propriile coduri Opțiunile din aceeași zi sunt tăiate separat.
Deschideți Banking/A2A: T + 0/1, dar fișierele pot merge post-factum; nevoia de RPP strict/ID unic pentru meciuri.
RTP/Instant: banii vin rapid, dar fișierul de raport este în grafic.
Crypto: decontare onchain instant, dar furnizorul face „ferestre de plată”; stochează 'fx _ at _ settle'.

9) Contabilitate (FI/Contabilitate)

9. 1. Metoda Accrual vs cache

Pentru raportarea managementului, accrual este adesea utilizat: recunoaștem veniturile/mișcarea la momentul 'settled _ at'.
Pentru trezorerie/DDS - metoda cache: recunoaștem faptul de a primi "finanțat _ at'.

9. 2. Cabluri tipice (simplificate)

• JT: Numerar în decontare cu PSP (AR: PSP)
• KT: Angajamentul jucătorului (Poșetă/Balanța jucătorului)

• Dt: Banca (casierie)
• Kt: Numerar în așezări cu PSP
• JT: Cheltuieli (taxe PSP), JT: Provizioane (dacă se modifică)

Stochezi un sheaf 'transaction _ id pentru urme.

10) Managementul riscurilor și alerte

Fișier ratat: Fără fișier de decontare înainte de X: YY - P1.
Întârziere de finanțare: T + N expirat, fără bani - P1.
Praguri Delta: varianta 'our _ gross' vs' file _ brut '> 0. 5% - P2; 'fees' în afara razei de acțiune - P2.
Reportare negativă: o serie de pachete nete negative - o investigație.
Impactul vacanței: prognoza automată ținând cont de calendar; în cazul în care faptul este <80% din prognoza - bilet.

11) Modelul de date (simplificat)

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) Exemple de șabloane SQL

12. 1. Înregistrare întreruptă

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. Reconcilierea tranzacțiilor cu fișierele

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. Prognoza veniturilor (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) Procese și SLO-uri

SLO 1: fișiere de decontare de import - T + 0, până la 08:00 Europa/Kiev.
SLO 2: reconcilierea inițială - până la ora 09:00, variante> 0. 5%.
SLO 3: Actualizarea prognozei fluxului de numerar - până la 10 a.m.
SLO 4: închiderea zilei - toate meciurile de finanțare sunt conduse la DWH.

14) Edge-case și cum să le gestioneze

Prezentare târzie: tranzacția a intrat în următorul lot - păstrați "faptul sursei" ("prezentat _ in _ batch _ id').
Captură parțială: captură multiplă pe autorizație - agregare corectă în lot.
Multi-MID: un singur furnizor, diferite MID-uri prin geo/brand - nu se amestecă într-un singur lot.
Reprocesare: atunci când un fișier este blocat - versioning 'batch _ revision' și revalidare completă.
Curse FX: cursuri - pe 'settled _ at'; finanțare într-o monedă diferită - start 'fx _ at _ funding' și delta.

15) Tablouri de bord și KPI-uri

Finanțarea ETA: data/ora preconizată a primirii vs efective.
Hit-rate SLA: procentul de fișiere care sosesc la timp.
Delta brut/net de către furnizor, metodă, MID.
Taxe% din volum, Sold de rezervă, Flux negativ de reportare.
Impactul de vacanță: prognoza vs efectiv de săptămână cu sărbători.

16) Cele mai bune practici (scurt)

1. Normalizați timpul până la UTC, dar păstrați cut-off provider_tz.
2. brut operațional separat și net de finanțare; nu confundați ND și finanțarea.
3. Implementați un calendar de finanțare cu sărbătorile bancare preintrate.
4. Automatizați importul și reconcilierea fișierelor de decontare + alerte la SLA/delta.
5. Implementați lot _ revision și reprocess deterministă.
6. Tip sursă unică de adevăr: „tranzacție ↔ lot ↔ finanțare” link-uri.
7. Salvați ARN/RRN și câmpurile de achiziționare a cardurilor - critice pentru litigii.
8. Fluxul de numerar prognozat luând în considerare weekendurile/vacanțele, rezervele și comisioanele.

17) Liste de verificare a implementării

Date și diagrame

• Таблицы 'payment _ transactions', 'settlement _ lotches', 'funding _ chitants',' recon _ links'.
• Câmpurile de fus orar sunt UTC + provider_tz.
• Поля FX: 'fx _ rate _ at _ settle', 'fx _ at _ funding'.

Import și validare

• Parsere CSV/XML/JSON + hash-uri de fișiere.
• Validarea sumelor/valutelor/datelor; meci по 'provider _ tx _ id/ARN'.
• Handlers „prezentare târzie”, „captură parțială”, „inversare”.

Operațiuni și alerte

• SLA monitor cut-off, fișiere ratate, întârzieri de finanțare.
• Alerte de prag Delta (brut, taxe, net).
• Impactul vacanței și raportul negativ de reportare.

18) ÎNTREBĂRI FRECVENTE

Î: De ce T + 2 a devenit T + 4?
R: Au fost weekenduri/sărbători la banca corespondentă sau la banca destinatară; см. calendar de finanțare.

Î: Există mai puțin în fișierul net decât calculul nostru net. Ce să mă uit?
R: Verificați taxele, reserve_delta, rambursarea întârziată/chargeback și corectitudinea cursurilor.

Î: Cum contabilizați cripta?
R: Prin fiat echivalent cu "settled _ at'; finanțarea poate veni la USDT/fiat - păstrați un „fx _ at _ funding” separat.

Î: Este posibil să aveți o singură întrerupere comună pentru toți furnizorii?
R: Nu, fiecare PSP are tz/oră. Faceți un afișaj agregator peste feliile lor.

Rezumat

• verifică cu exactitate furnizorii,
• lichiditatea prognozată și plățile acoperite
• să respecte SLA și să reducă riscurile operaționale
• vorbesc aceeași limbă ca finanțele și conformitatea.

Prin implementarea unui singur calendar de finanțare, un model riguros de date și o reconciliere automată, faceți fluxul de numerar previzibil și gestionabil.