Сеттлмент цикли і cut-off

1) Понятійна база

Settlement (сеттлмент) - розрахунок між PSP/Acquirer і мерчантом (оператором), при якому гроші за успішно захопленими транзакціями перераховуються на мерчантський рахунок.
Cut-off - щоденний «зріз» операцій, що потрапляють в конкретний розрахунковий цикл (зазвичай фіксований час в таймзоні провайдера).
T + N - типова нотація затримки рознесення коштів: T - дата cut-off, N - кількість робочих днів до фактичного зарахування.

• Картки (Visa/Mastercard): часто T + 2/T + 3 banking days, cut-off 23:00 UTC (приблизно).
• A2A / Open Banking: від 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, але можливі cut-off за звітами.
• Крипто: фактично T + 0 по мережі, але PSP може застосовувати власні funding вікна (T + 0/1).

2) Як працює cut-off і що в нього потрапляє

1. Провайдер фіксує вікно збору (наприклад, 00:00–23:00 UTC).
2. Всі settled/captured транзакції в цьому вікні потрапляють в пакет (batch).
3. До пакету агрегуються повернення, чарджбеки, корекції, щоб розрахувати gross і net funding.
4. Після настання cut-off формується settlement file і стартує таймер T + N до зарахування.

Важливо: авторизація без capture в пакет не потрапляє. Скасовані висновки - теж немає.

3) Типи розрахунків: gross vs net, резерви та комісії

Gross settlement - перераховується валова сума capture (мінус окреме списання комісій).
Net settlement - провайдер утримує fees, chargebacks, refunds, rolling reserve і перераховує net amount.
Rolling reserve - утримання% обороту на N днів (наприклад, 10% на 180 днів) для покриття ризику.
Negative carry-over - якщо «нетто» за день йде в мінус, дефіцит переноситься і погашається наступними циклами.

Рекомендація: зберігати розшифровку обох площин - operational gross (за транзакціями) і funding net (за файлами провайдера).

4) Таймзони, локальні вихідні та DST

Cut-off визначається таймзоною провайдера, яка може відрізнятися від вашої.
Враховуйте DST (перехід на літній час) - зрізи можуть зсуватися на ± 1 годину відносно локального часу.
Свята/вихідні в юрисдикції банку-одержувача впливають на N в T + N (наприклад, T + 2 banking days перетворюється в T + 4 навколо свят).
Практика: нормалізуйте всі технічні часи в UTC, паралельно зберігайте'provider _ tz _ cutoff _ at'і'local _ tz _ posted _ at'.

5) Settlement календар (funding calendar) і SLA

• cut-off час і tz для кожного методу/PSP,
• стандартний T + N і винятки (свята),
• очікувані суми (прогнози),
• SLA отримання: наприклад, "не пізніше 12:00 Europe/Kyiv в день T + 2".

Будь-які відхилення SLA → алерт і тікет в Ops/Finance.

6) Взаємозв'язок з Net Deposits і висновками

ND (чисті внесення) вважається по settled транзакціях (див. пов'язану статтю).
Висновки (withdrawals) не беруть участі в funding від PSP по депозитах, але впливають на касу мерчанта.
Планування ліквідності: inflow по сеттлменту мінус outflow по виплатах/податках/операційних витратах.

7) Звірка (reconciliation) та артефакти провайдерів

• 'batch _ id/ settlement_id', дата cut-off в tz провайдера,
• суми за типами: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• розшифровка за методами/мерчант-акаунтами («MID», «descriptor», «MCC»),
• референси транзакцій ('provider _ tx _ id','rrn','arn'- якщо карти),
• файл (и): CSV/XML/JSON + людиночитаний statement (PDF/HTML).

1. Від транзакцій до файлів (все, що ми вважали, потрапило в файл?)

2. Від файлів до транзакцій (все, що у файлі, є в нашій вітрині? статуси збігаються?)

8) Специфіка по рейках оплати (в загальних рисах)

Карти: часті сценарії presentment delay; можливі пізні'chargeback'( до 120-540 днів за кейсом); interchange & scheme fees з'являються у файлах, у ND не віднімаються.
SEPA/ACH: батчі залежать від банківських вікон; скасування/повернення мають власні коди; Same Day варіанти - окремі cut-off.
Open Banking / A2A: T + 0/1, але файли можуть йти post-factum; необхідність строгих RPP/Unique ID для матчів.
RTP/Instant: гроші приходять швидко, але звітний файл - за розкладом.
Крипто: ончейн-сетлмент миттєвий, але провайдер робить'payout windows'; зберігати'fx _ at _ settle'.

9) Облік, проводки та звітність (FI/Accounting)

9. 1. Аккруал vs кеш-метод

Для управлінської звітності часто застосовується аккруал: визнаємо виручку/рух в момент'settled _ at'.
Для казначейства/ДДС - кеш-метод: визнаємо за фактом надходження'funded _ at'.

9. 2. Типові проводки (спрощено)

• Дт: Грошові кошти в розрахунках з PSP (AR: PSP)
• Кт: Зобов'язання перед гравцем (гаманець/баланс гравця)

• Дт: Банк (каса мерчанта)
• Кт: Грошові кошти в розрахунках з PSP
• Дт: Витрати (PSP fees), Дт/Кт: Резерви (якщо змінилися)

Зберігайте зв'язку'transaction _ id для трасування.

10) Ризик-менеджмент і алерти

Missed file: немає settlement-файлу до X:YY — P1.
Funding delay: T + N закінчився, грошей немає - P1.
Delta thresholds: розбіжність'our _ gross'vs'file _ gross'> 0. 5% - P2;'fees'поза діапазоном - P2.
Negative carry-over: серія негативних нетто-пакетів - розслідування.
Holiday impact: автоматичний прогноз з урахуванням календаря; якщо факт <80% прогнозу - тікет.

11) Модель даних (спрощено)

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-шаблонів

12. 1. Реєстрація «зрізу» за 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. Звірка «від транзакцій до файлу»

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. Прогноз надходжень (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) Процеси і SLO

SLO 1: імпорт settlement-файлів - T + 0, до 08:00 Europe/Kyiv.
SLO 2: первинна звірка - до 09:00, алерти за розбіжностями> 0. 5%.
SLO 3: оновлення cash-flow прогнозу - до 10:00.
SLO 4: закриття дня - всі funding-матчі заведені в DWH.

14) Edge-cases і як їх обробляти

Late presentment: транзакція потрапила в наступний batch - зберігайте «факт джерела» ('presented _ in _ batch _ id').
Partial capture: кілька capture на одну авторизацію - коректно агрегуйте в batch.
Multi-MID: один провайдер, різні MIDs за гео/брендами - не змішувати в одній партії.
Reprocessing: при косяку файлу - версіонування'batch _ revision'і повна пере-звірка.
FX-скачки: курси - на'settled _ at'; funding в іншій валюті - заведіть'fx _ at _ funding'і дельту.

15) Дашборди і KPI

Funding ETA: очікувана дата/час надходження vs факт.
Hit-rate SLA: частка файлів, що прийшли вчасно.
Delta gross/net по провайдерам, методам, MIDs.
Fees % of volume, Reserve balance, Negative carry-over streak.
Holiday impact: прогноз vs факт по тижнях зі святами.

16) Best practices (коротко)

1. Нормалізуйте час в UTC, але зберігайте provider_tz cut-off.
2. Розділяйте operational gross і funding net; не плутайте ND і funding.
3. Впроваджуйте funding calendar із заздалегідь внесеними святами по банках.
4. Автоматизуйте імпорт і звірку settlement-файлів + алерти на SLA/дельти.
5. Реалізуйте версіонування партій ('batch _ revision') і детермінований reprocess.
6. Введіть single source of truth: зв'язку'transaction ↔ batch ↔ funding'.
7. Зберігайте ARN/RRN і еквайрингові поля для карт - критично для диспутів.
8. Прогнозуйте cash-flow з урахуванням вихідних/свят, резервів і комісій.

17) Чек-листи впровадження

Дані та схеми

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

Імпорт і валідації

• Парсери CSV/XML/JSON + хеші файлів.
• Валідація сум/валют/дат; match по `provider_tx_id/ARN`.
• Хендлери «late presentment», «partial capture», «reversal».

Операції та алерти

• SLA-монітор cut-off, missed files, funding delays.
• Delta-порогові алерти (gross, fees, net).
• Звіт по holiday impact і negative carry-over.

18) FAQ

Q: Чому T + 2 перетворилося на T + 4?
A: Були вихідні/свята в банку-кореспонденті або у банку-одержувача; см. funding calendar.

Q: У файлі net менше, ніж наш розрахунок net. Що дивитися?
A: Перевірте fees, reserve_delta, пізні refund/chargeback, і коректність курсів.

Q: Як враховувати крипту?
A: За фіатним еквівалентом на'settled _ at'; funding може прийти в USDT/фіат - зберігайте окремий'fx _ at _ funding'.

Q: Чи можна один загальний cut-off для всіх провайдерів?
A: Ні, у кожного PSP свій tz/год. Робіть агрегуючу вітрину поверх їх зрізів.

Резюме

• точно звіряти провайдерів,
• прогнозувати ліквідність і покривати виплати,
• дотриматися SLA і скоротити операційні ризики,
• говорити однією мовою з фінансами і комплаєнсом.

Впровадивши єдиний funding calendar, сувору модель даних і автоматизовану звірку, ви зробите грошовий потік передбачуваним і керованим.