Settlement va cut-off

1) Tushuncha bazasi

Settlement - PSP/Acquirer va merchant (operator) o’rtasidagi hisob-kitob bo’lib, bunda muvaffaqiyatli olingan tranzaksiyalar bo’yicha pul merchant hisob raqamiga o’tkaziladi.
Cut-off - muayyan hisob-kitob sikliga tushadigan operatsiyalarning kundalik «kesimi» (odatda provayder taymzonida belgilangan vaqt).
T + N - mablag’larni tarqatishni kechiktirishning namunaviy notatsiyasi: T - cut-off sanasi, N - amalda o’tkazilgunga qadar ish kunlari soni.

• Kartalar (Visa/Mastercard): ko’pincha T + 2/T + 3 banking days, cut-off 23:00 UTC (taxminan).
• A2A/Open Banking: T + 0 dan T + 1 gacha.
• 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, lekin hisobotlar bo’yicha cut-off bo’lishi mumkin.
• Kripto: aslida tarmoq orqali T + 0, lekin PSP oʻz funding oynalarini qoʻllashi mumkin (T + 0/1).

2) cut-off qanday ishlaydi va unga nima tushadi

1. Provayder yig’ish oynasini qayd etadi (masalan, 00: 00-23: 00 UTC).
2. Ushbu oynadagi barcha settled/captured tranzaksiyalar paketga (batch) kiradi.
3. Paketga qaytarmalar, charjbeklar, gross va net fundingni hisoblash uchun tuzatishlar kiritiladi.
4. Cut-off boshlanganda settlement file shakllantiriladi va T + N taymeri qabul qilingunga qadar boshlanadi.

Muhimi: capture’siz avtorizatsiya paketga kirmaydi. Bekor qilingan xulosalar ham yoʻq.

3) Hisob-kitoblar turlari: gross vs net, zaxiralar va komissiyalar

Gross settlement - capture yalpi summasi o’tkaziladi (minus vositachilik haqini alohida hisobdan chiqarish).
Net settlement - provayder fees, chargebacks, refunds, rolling reserve ushlab turadi va net amount sanab o’tadi.
Rolling reserve - tavakkalchilikni qoplash uchun aylanmaning foizini N kunga ushlab qolish (masalan, 180 kunga 10%).
Negative carry-over - agar «netto» kuniga minusga o’tib ketsa, taqchillik keyingi sikllarda ko’chiriladi va qoplanadi.

Tavsiya: operational gross (tranzaksiyalar bo’yicha) va funding net (provayder fayllari bo’yicha) ikkala tekislikning shifrini ochish.

4) Taymzonlar, mahalliy dam olish kunlari va DST

Cut-off siznikidan farq qilishi mumkin bo’lgan taymzon provayderi tomonidan belgilanadi.
DST (yozgi vaqtga oʻtish) ni hisobga oling - kesmalar mahalliy vaqtga nisbatan ± 1 soatga oʻtishi mumkin.
Oluvchi bank yurisdiksiyasidagi bayramlar/dam olish kunlari N + T + N ga ta’sir qiladi (masalan, T + 2 banking days bayramlar atrofida T + 4 ga aylanadi).
Amaliyot: UTCdagi barcha texnik vaqtlarni normallashtiring, parallel ravishda’provider _ tz _ cutoff _ at’va’local _ tz _ posted _ at’ni saqlang.

5) Settlement kalendar (funding calendar) va SLA

• har bir usul/PSP uchun cut-off vaqti va tz,
• standart T + N va istisnolar (bayramlar),
• kutilayotgan summalar (prognozlar),
• SLA olish: masalan, «T + 2 kuni soat 12:00 dan kechiktirmay Europe/Kyiv».

SLA → alert va Ops/Finance’dagi har qanday og’ishlar.

6) Net Deposits va xulosalar bilan o’zaro bog’liqlik

ND (sof to’lov) settled tranzaksiyalar bo’yicha hisoblanadi (bog’liq moddaga qarang).
Xulosalar (withdrawals) depozitlar bo’yicha PSP fundingida ishtirok etmaydi, lekin savdo kassasiga ta’sir qiladi.
Likvidlikni rejalashtirish: to’lovlar/soliqlar/operatsion xarajatlar bo’yicha inflow settlment minus outflow.

7) Provayderlarni solishtirish (reconciliation) va artefaktlar

• ’batch _ id/ settlement_id', cut-off sanasi tz provayderda,
• суммы по типам: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• (’MID’,’descriptor’,’MCC’),
• tranzaksiya referensiyalari (’provider _ tx _ id’,’rrn’,’arn’- agar xaritalar),
• fayl (lar): CSV/XML/JSON + inson o’qiydigan statement (PDF/HTML).

1. Bitimlardan fayllarga (biz oʻylagan hamma narsa faylga kiradimi?)

2. Fayllardan tranzaksiyalarga (fayldagi hamma narsa bizning oynamizda bormi? maqomi mos keladimi?)

8) To’lov relslari bo’yicha o’ziga xos xususiyatlar (umumiy chiziqlarda)

Xaritalar: tez-tez skriptlar presentment delay; kech «chargeback» bo’lishi mumkin (keys bo’yicha 120-540 kungacha); interchange & scheme fees fayllarda paydo boʻladi, ND chegirilmaydi.
SEPA/ACH: batchi bank oynalariga bog’liq; bekor qilish/qaytarish o’z kodlariga ega bo’lsa; Same Day variantlari - alohida cut-off.
Open Banking/A2A: T + 0/1, lekin fayllar post-factum; o’yinlar uchun qat’iy RPP/Unique ID zarurati.
RTP/Instant: Pul tezda keladi, lekin hisobot fayli - jadval bo’yicha.
Kripto: oncheyn-setlment bir zumda, lekin provayder’payout windows’qiladi; ’fx _ at _ settle’ ni saqlash.

9) Hisobga olish, o’tkazish va hisobot (FI/Accounting)

9. 1. Akkrual vs kesh usuli

Boshqaruv hisoboti uchun ko’pincha akkrual qo’llaniladi: «settled _ at» lahzasidagi tushum/harakatni tan olamiz.
G’aznachilik/QQS uchun - kesh usuli:’funded _ at’kelib tushganligi bo’yicha tan olamiz.

9. 2. Namunaviy simlar (soddalashtirilgan)

• Dt: PSP (AR: PSP) bilan hisob-kitoblardagi pul mablag’lari
• Kt: O’yinchi oldidagi majburiyatlar (o’yinchining hamyoni/balansi)

• Dt: Bank (savdo kassasi)
• Kt: PSP bilan hisob-kitoblardagi pul mablag’lari
• Dt: Xarajatlar (PSP fees), Dt/Kt: Zaxiralar (agar o’zgargan bo’lsa)

Izlash uchun’transaction _ id → batch_id → funding_id' bogʻlamini saqlang.

10) Tavakkalchilik-menejment va alertlar

Missed file: X: YY - P1 gacha settlement fayli yoʻq.
Funding delay: T + N muddati tugadi, pul yo’q - P1.
Delta thresholds: tafovut’our _ gross’vs’file _ gross’> 0. 5% - P2;’fees’oralig’idan tashqarida - P2.
Negative carry-over: salbiy netto-paketlar seriyasi - tergov.
Holiday impact: kalendarni hisobga olgan holda avtomatik prognoz; agar haqiqat <80% prognoz bo’lsa - chipta.

11) Ma’lumotlar modeli (soddalashtirilgan holda)

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) SQL namunalari

12. 1. Kesishni cut-off bo’yicha ro’yxatdan o’tkazish

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. «Bitimlardan faylga» qiyoslash

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. Tushumlar prognozi (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) Jarayonlar va SLO

SLO 1: import settlement-fayllar - T + 0, soat 08:00 gacha Europe/Kyiv.
SLO 2: boshlang’ich taqqoslash - 09:00 gacha, farqlar bo’yicha alertlar> 0. 5%.
SLO 3: cash-flow prognozini yangilash - soat 10:00 gacha.
SLO 4: kun yopilishi - barcha funding-o’yinlar DWHda boshlanadi.

14) Edge-cases va ularni qanday qayta ishlash

Late presentment: tranzaksiya keyingi batchga tushdi - «manba faktini» saqlang (’presented _ in _ batch _ id’).
Partial capture: bitta avtorizatsiya uchun bir nechta capture - batch’ga toʻgʻri biriktiring.
Multi-MID: bitta provayder, geo/brendlar bo’yicha turli MIDlarni bir partiyada aralashtirib bo’lmaydi.
Reprocessing: faylni buklashda - «batch _ revision» versiyasi va toʻliq qayta solishtirish.
FX-poygalar: kurslar -’settled _ at’; boshqa valyutadagi funding -’fx _ at _ funding’va deltani oching.

15) Dashbordlar va KPI

Funding ETA: kutilayotgan qabul qilish sanasi/vaqti vs fakt.
Hit-rate SLA: oʻz vaqtida kelgan fayllar ulushi.
Delta gross/net provayderlar, usullar, MIDs bo’yicha.
Fees % of volume, Reserve balance, Negative carry-over streak.
Holiday impact: prognoz vs bayram haftalari bo’yicha haqiqat.

16) Best practices (qisqacha)

1. UTC’dagi vaqtni normallashtiring, lekin provider_tz yoping.
2. operational gross va funding netni ajrating; ND va fundingni chalkashtirib yubormang.
3. Funding calendarni oldindan belgilangan bayramlar bilan joriy qiling.
4. Settlement fayllarini + SLA/deltadagi alertlarni import qilish va solishtirishni avtomatlashtiring.
5. Partiyalar versiyasini (’batch _ revision’) va determinizatsiya qilingan reprocessni amalga oshiring.
6. Single source of truth: linklarni kiriting’transaction, batch, funding’.
7. ARN/RRN va xarita ekvayring maydonlarini saqlang - munozaralar uchun juda muhim.
8. Dam olish/dam olish kunlari, zaxiralar va komissiyalarni hisobga olgan holda cash-flow-ni bashorat qiling.

17) Joriy etish chek-varaqalari

Ma’lumotlar va sxemalar

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

Import va validatsiyalar

• CSV/XML/JSON + xesh fayllari.
• Summalar/valyutalar/sanalar validatsiyasi; match по `provider_tx_id/ARN`.
• Hendlerlar «late presentment», «partial capture», «reversal».

Operatsiyalar va alertlar

• SLA-monitor cut-off, missed files, funding delays.
• Delta-chegara alertlari (gross, fees, net).
• Holiday impact va negative carry-over bo’yicha hisobot.

18) FAQ

Q: Nima uchun T + 2 T + 4 ga aylandi?
A: Bank-korrespondentda yoki bank-oluvchida dam olish/bayram kunlari bo’lgan; см. funding calendar.

Q: Net faylida bizning net hisob-kitobimizdan kam. Nimani tomosha qilish kerak?
A: fees, reserve_delta, kech refund/chargeback va kurslarning to’g’riligini tekshiring.

Q: Kriptoni qanday hisobga olish kerak?
A: Fiat ekvivalenti bo’yicha’settled _ at’; funding USDT/fiatga kelishi mumkin - alohida’fx _ at _ funding’ni saqlang.

Q: Barcha provayderlar uchun bitta umumiy cut-off qilish mumkinmi?
A: Yo’q, har bir PSPning o’z tz/soati bor. Ularning bo’laklari ustiga yig’ma vitrin qiling.

Xulosa

• provayderlarni aniq solishtirish,
• likvidlikni prognoz qilish va to’lovlarni qoplash,
• SLAga rioya qilish va operatsion xavflarni kamaytirish,
• moliya va komplayens bilan bir tilda gaplashish.

Yagona funding calendar, qat’iy ma’lumotlar modeli va avtomatlashtirilgan taqqoslash orqali siz pul oqimini oldindan aytib bo’lmaydigan va boshqariladigan qilib qo’yasiz.