Setlment ciclos e cut-off

1) Base de entendimento

Senslement - Cálculo entre PSP/Aquirer e Merchant (operador), em que o dinheiro das transações captadas com sucesso é depositado em uma conta merchante.
Cut-off é o «corte» diário das operações que entram em um ciclo de cálculo específico (normalmente tempo fixo no time do provedor).
T + N é uma notação típica de atraso na distribuição de fundos: T - data de cut-off, N - número de dias úteis antes da inscrição real.

• Cartões (Visa/Mastercard): Muitas vezes T + 2/T + 3 banking days, cut-off 23:00 UTC (aproximadamente).
• A2A/Open Banking: de T + 0 a 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, mas pode ser cut-off por relatório.
• Cripto: de fato T + 0 na rede, mas PSP pode aplicar suas próprias janelas funding (T + 0/1).

2) Como funciona a cut-off e o que entra

1. O provedor registra a janela de coleta (por exemplo, 00-23: 00 UTC).
2. Todas as transações setled/captured nesta janela são incluídas no pacote (batch).
3. O pacote é adicionado a devoluções, charjbacks, correções para calcular gross e net funding.
4. Com a chegada do cut-off, o ficheiro é formado pelo senslement e começa o tempo T + N antes da inscrição.

O importante é que a autorização sem captação não entra no pacote. Também não há conclusões anuladas.

3) Tipos de cálculo: gross vs net, reservas e comissões

Gross senslement - É depositado o valor bruto capture (menos o débito separado das comissões).
Net Masslement - O provedor mantém fees, chargebacks, refunds, rolling reserve e lista net amount.
Rolling reserve - Retenção de% do negócio em N dias (por exemplo, 10% por 180 dias) para cobrir o risco.
Negative carry-over - Se o «neto» for para menos por dia, o déficit será transferido e reembolsado pelos ciclos seguintes.

Recomendação: armazenar ambos os planos - operational gross (transações) e funding net (arquivos do provedor).

4) Temporizões, fins de semana locais e DST

Cut-off é definido por um provedor de tempo que pode ser diferente do seu.
Leve em consideração o DST - os cortes podem ser alterados em £1 hora em relação ao horário local.
Feriados/fins de semana na jurisdição do banco destinatário afetam N em T + N (por exemplo, T + 2 banking days se transforma em T + 4 em torno das festas).
Prática: normalize todos os tempos técnicos em UTC, armazenando em paralelo 'provider _ tz _ cutoff _ at' e 'local _ tz _ posted _ at'.

5) Calendário de Senslement (funding calendar) e SLA

• cut-off tempo e tz para cada método/PSP,
• T + N padrão e exceções (feriados),
• os valores previstos (previsões),
• SLA receber: por exemplo, «no máximo 12h00 Europe/Kyiv no dia T + 2».

Qualquer desvio de SLA → alert e tíquete na Ops/Finance.

6) Relação com Net Deposits e conclusões

O ND (contribuições limpas) é considerado por transações sensled (consulte artigo vinculado).
As conclusões (withdrawals) não participam do funding do PSP sobre depósitos, mas afetam a caixa do Merchant.
Planejamento de liquidez: inflow por setlment menos outflow sobre pagamentos/impostos/despesas operacionais.

7) Confecção (reconciação) e artefatos de provedores

• 'batch _ id/masslement _ id', data de cut-off no tz do provedor,
• суммы по типам: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• decifrar os métodos/contas merchant ('MID', 'descriptor', 'MCC'),
• ('provider _ tx _ id', 'rrn', 'arn' - se cartões),
• (s): CSV/URL/JSON + status humano (PDF/HTML).

1. Transações para arquivos (tudo o que pensávamos ter entrado no arquivo?)

2. De arquivos para transações (tudo o que está no arquivo está na nossa vitrine? as estatais coincidem?)

8) Especificidade sobre roteiros de pagamento (em linhas gerais)

Cartões: cenários frequentes de presentment delay; Pode ser tardio 'chargeback' (até 120-540 dias por mala); interchange & scheme fes aparecem nos arquivos, ND não é deduzido.
SEPA/ACH: Batches dependem de janelas bancárias; cancelamentos/devoluções têm códigos próprios; As opções Same Day são cut-off individuais.
Open Banking/A2A: T + 0/1, mas os arquivos podem ir pós-factum; necessidade de RPP/ID único rigoroso para os jogos.
RTP/Point: O dinheiro vem rapidamente, mas o arquivo referenciado está programado.
Kripto: A rede onchain é instantânea, mas o provedor faz 'payout windows'; armazenar 'fx _ at _ setle'.

9) Contabilidade, cabos e relatórios (FI/Accounting)

9. 1. Acrual vs método em dinheiro

Os relatórios de gerenciamento são frequentemente aplicados ao acural, reconhecendo a receita/movimento no momento de 'sensled _ at'.
Para o Tesouro/DDS - método em dinheiro: reconhecemos a entrada de 'funded _ at'.

9. 2. Fios típicos (simplificado)

• DT: Dinheiro em contas com PSP (AR: PSP)
• T: Obrigação com o jogador (carteira/saldo do jogador)

• DT: Banco (caixa merçante)
• TC: Dinheiro em contas com PSP
• DT: Gastos (PSP fees), DT/TAC: Reservas (se mudado)

Guarde o laço 'direction _ id → batch _ id → funding _ id' para traçar.

10) Gerenciamento de risco e alertas

Missed arquive: Nenhum ficheiro senslement até X: YY - P1.
Funding delay: T + N expirou, sem dinheiro - P1.
Delta thresholds: discrepância 'our _ gross' vs 'arquivo _ gross'> 0. 5% - P2; 'fees' fora do intervalo - P2.
Negative carry-over: série de pacotes netos negativos - investigação.
Impacto Holiday: previsão automática com base no calendário; se o dado <80% da previsão for tíquete.

11) Modelo de dados (simplificado)

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) Exemplos de modelos SQL

12. 1. Inscrição de corte por 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. Confecção de transações para arquivo

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. Previsão de receita (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) Processos e SLO

SLO 1: importação de arquivos setlement - T + 0, até às 08h00 Europe/Kyiv.
SLO 2: cruzamento primário até às 09:00, alertas de discrepância> 0. 5%.
SLO 3: Atualização da previsão cash-flow até às 10h.
SLO 4: encerramento do dia - Todos os jogos funding estão em DWH.

14) Edge-cases e como processá-los

Late presentment: a transação entrou no seguinte batch: guarde o «fato de origem» ('presented _ in _ batch _ id').
Partial capture: várias capturas por autorização - Agregue corretamente no batch.
Multi-MID: um provedor, MIDs diferentes por geo/marca - não misturar em um único lote.
Reprocessing: Quando o arquivo é encaixado, é versionizado 'batch _ revision' e está completo.
Corridas FX: cursos - em 'massled _ at'; funding em outra moeda - use 'fx _ at _ funding' e delta.

15) Dashboards e KPI

Funding ETA: data prevista/hora de entrada vs fato.
Hit-rate SLA: proporção de arquivos que chegaram na hora.
Delta gross/net sobre provedores, métodos, MIDs.
Fees % of volume, Reserve balance, Negative carry-over streak.
Holiday impact: previsão vs fato de semanas com feriados.

16) Best pratices (curta)

1. Normalize o tempo no UTC, mas mantenha o provider _ tz cut-off.
2. Divida operational gross e funding net; não confunde ND e funding.
3. Implemente o funding calendar com feriados pré-definidos por banco.
4. Automatize a importação e o cruzamento de arquivos setlement + alertas para SLA/delta.
5. Realize a versionização dos lotes ('batch _ revision') e reprocess determinado.
6. Digite o single fonte of truth: laços de 'transmissão ↔ batch ↔ funding'.
7. Mantenha o ARN/RRN e os campos de cartão equiringo - crucial para displicências.
8. Preveja cash-flow com base em fins de semana/feriado, reservas e comissões.

17) Folhas de cheque de implementação

Dados e esquemas

• Таблицы `payment_transactions`, `settlement_batches`, `funding_receipts`, `recon_links`.
• Campos de temporização: UTC + provider _ tz.
• Поля FX: `fx_rate_at_settle`, `fx_at_funding`.

Importar e validar

• Parsers CSV/URL/JSON + hashi arquivos.
• Validação de somas/moedas/datas; match по `provider_tx_id/ARN`.
• Hendler «late presentment», «partial capture», «reversal».

Operações e alertas

• Monitor SLA cut-off, missed files, funding delays.
• Alertas de limiar Delta (gross, fees, net).
• Relatório sobre o impacto holiday e o carry-over negativo.

18) FAQ

Q: Por que o T + 2 se transformou em T + 4?
A: Houve um fim de semana/feriado no banco correspondente ou no banco destinatário; см. funding calendar.

Q: O arquivo net é menor do que o nosso cálculo net. O que ver?
A: Verifique fees, reserve _ delta, refund tardio/chargeback, e correção de cursos.

Como levar em conta a cripta?
A: Pelo equivalente a fiato em 'massled _ at'; o funding pode chegar ao USDT/fiat - guarde um «fx _ at _ funding» separado.

Q: Pode um cut-off compartilhado para todos os provedores?
A: Não, cada PSP tem um tz/hora. Façam uma vitrine agregada sobre os seus pedaços.

Currículo

• verificar exatamente os provedores,
• prever a liquidez e cobrir os pagamentos,
• cumpra a SLA e reduza os riscos operacionais,
• falar o mesmo idioma com finanças e complicações.

Ao implementar um funding calendar unificado, um modelo rigoroso de dados e um processamento automatizado, você tornará o fluxo de dinheiro previsível e controlado.