Сеттлмент циклы и 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 → batch_id → funding_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, строгую модель данных и автоматизированную сверку, вы сделаете денежный поток предсказуемым и управляемым.