Bucles de settlement y cut-off

1) Base conceptual

Settlement (settlement): un cálculo entre PSP/Acquirer y un merchant (operador) en el que el dinero de las transacciones captadas con éxito se transfiere a una cuenta merchant.
Cut-off es un «corte» diario de las operaciones que caen en un ciclo de cálculo específico (generalmente un tiempo fijo en la zona de tiempo del proveedor).
T + N - notación tipo de demora en la separación de fondos: T es la fecha de corte, N es el número de días hábiles antes de la inscripción real.

• Tarjetas (Visa/Mastercard): a menudo 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, pero es posible cortar-apagar los informes.
• Crypto: realmente T + 0 a través de la red, pero PSP puede aplicar sus propias ventanas fundidas (T + 0/1).

2) Cómo funciona el cut-off y lo que entra en él

1. El proveedor fija la ventana de recogida (por ejemplo, 00: 00-23: 00 UTC).
2. Todas las transacciones settled/captured de esta ventana entran en el paquete (batch).
3. Se agregan devoluciones, charjbacks, correcciones al paquete para calcular gross y funding net.
4. Al llegar el cut-off, se forma el archivo settlement y comienza el temporizador T + N antes de la inscripción.

Importante: la autorización sin capturar no entra en el paquete. Las conclusiones anuladas tampoco.

3) Tipos de cálculo: gross vs net, reservas y comisiones

Gross settlement - se enumera la cantidad bruta capture (menos el cargo por comisión).
Net settlement - el proveedor mantiene fees, chargebacks, refunds, rolling reserve y enumera net amount.
Reserva Rolling - retener el% de la facturación en N días (por ejemplo, 10% durante 180 días) para cubrir el riesgo.
Negative carry-over: si el «neto» de un día cae en negativo, el déficit se transfiere y se canjea en los siguientes ciclos.

Recomendación: Almacenar el descifrado de ambos planos: gross operativos (por transacciones) y net funding (por archivos del proveedor).

4) Temporizaciones, fines de semana locales y DST

Cut-off está definido por la zona de tiempo del proveedor, que puede ser diferente de la suya.
Tenga en cuenta el DST (horario de verano): los cortes pueden moverse ± 1 hora con respecto a la hora local.
Los días festivos/fines de semana en la jurisdicción del banco receptor afectan a N en T + N (por ejemplo, los días de banca T + 2 se convierten en T + 4 alrededor de los días festivos).
Práctica: normalizar todos los tiempos técnicos en UTC, en paralelo almacenar 'provider _ tz _ cutoff _ at' y 'local _ tz _ posted _ at'.

5) Calendario de Settlement (calendario fundido) y SLA

• cut-off tiempo y tz para cada método/PSP,
• T + N estándar y excepciones (vacaciones),
• las cantidades previstas (proyecciones),
• SLA de recepción: por ejemplo, «a más tardar 12:00 Europe/Kyiv por día T + 2».

Cualquier desviación de SLA → alerta y ticket en Ops/Finance.

6) Relación con los depósitos netos y las conclusiones

ND (depósitos netos) se considera por transacciones settled (ver artículo relacionado).
Los hallazgos (withdrawals) no participan en el funding de depósitos de PSP, sino que afectan al cajero de merchant.
Planificación de la liquidez: inflow por settlement menos outflow por pagos/impuestos/gastos operativos.

7) La conciliación (reconciliation) y los artefactos de los proveedores

• 'batch _ id/ settlement_id', fecha cut-off en el proveedor tz,
• суммы по типам: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• descifrar por métodos/cuentas merchant ('MID', 'descriptor', 'MCC'),
• referencias de transacciones ('provider _ tx _ id', 'rrn',' arn' - si las cartas),
• archivo (s): CSV/XML/JSON + estado humano (PDF/HTML).

1. De las transacciones a los archivos (¿todo lo que creíamos que había caído en el archivo?)

2. De archivos a transacciones (¿todo lo que hay en el archivo está en nuestro escaparate? ¿Los estados coinciden?)

8) Especificidad en los carriles de pago (en términos generales)

Mapas: scripts de presentación frecuentes delay; es posible un 'chargeback' tardío (hasta 120-540 días por caso); interchange & scheme fees aparecen en los archivos, en ND no se restan.
SEPA/ACH: los batches dependen de las ventanas bancarias; cancelaciones/devoluciones tienen sus propios códigos; Opciones de Same Day - cut-off individuales.
Open Banking/A2A: T + 0/1, pero los archivos pueden ir post-factum; la necesidad de un RPP/ID Unique riguroso para los partidos.
RTP/Instant: el dinero llega rápidamente, pero el archivo de informe está programado.
Crypto: la red de la cadena es instantánea, pero el proveedor hace 'payout windows'; almacenar 'fx _ at _ settle'.

9) Contabilidad, registros e informes (FI/Accounting)

9. 1. Accrual vs método de caché

Para los informes de gestión, a menudo se aplica el accrual: reconocemos los ingresos/movimientos en el momento de 'settled _ at'.
Para el Tesoro/DDS es un método de caché: reconocemos el hecho de recibir 'funded _ at'.

9. 2. Tipos de cableado (simplificado)

• DT: Efectivo en liquidación con PSP (AR: PSP)
• KT: Compromisos con el jugador (cartera/saldo del jugador)

• Dt: Banco (cajero)
• QT: Efectivo en liquidación con PSP
• Dt: Gastos (PSP fees), Dt/Kt: Reservas (si cambian)

Almacene el ligamento 'transaction _ id → batch_id → funding_id' para el rastreo.

10) Gestión de riesgos y alertas

Archivo perdido: no hay archivo settlement hasta X: YY - P1.
Funding delay: T + N ha caducado, no hay dinero - P1.
Delta thresholds: discrepancia 'our _ gross' vs 'file _ gross'> 0. 5% - P2; 'fees' fuera de rango - P2.
Negative carry-over: serie de paquetes netos negativos - investigación.
Impacto de vacaciones: predicción automática teniendo en cuenta el calendario; si el hecho <80% del pronóstico es un ticket.

11) Modelo de datos (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) Ejemplos de plantillas SQL

12. 1. Registro 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. Conciliación «de transacciones a archivos»

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. Previsión de ingresos (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) Procesos y SLO

SLO 1: importación de archivos settlement - T + 0, hasta 08:00 Europe/Kyiv.
SLO 2: la conciliación primaria es hasta las 09:00, alertas por discrepancias> 0. 5%.
SLO 3: Actualización de pronóstico cash-flow - hasta las 10:00.
SLO 4: cierre de la jornada - todos los partidos de funding están establecidos en la DWH.

14) Edge-cases y cómo procesarlos

Presentación tardía: la transacción llegó al siguiente batch - almacena el «hecho de origen» ('presented _ in _ batch _ id').
Capture parcial: múltiples capturas por autorización - agregue correctamente en el batch.
Multi-MID: un proveedor, diferentes MID por geo/marcas - no mezclar en un lote.
Reprocessing: cuando el fichero está desactivado - versionando 'batch _ revision' y pluma completa de conciliación.
FX-salto: cursos - en 'settled _ at'; funding en otra moneda - establecer 'fx _ at _ funding' y delta.

15) Dashboards y KPI

Funding ETA: esperada fecha/hora de recepción vs hecho.
Hit-rate SLA: una fracción de los archivos que llegaron a tiempo.
Delta gross/net por proveedores, métodos, MIDs.
Fees % of volume, Reserve balance, Negative carry-over streak.
Holiday impact: predicción vs hecho por semana con vacaciones.

16) Mejores prácticas (corto)

1. Normalice el tiempo en UTC, pero almacene provider_tz cut-off.
2. Comparta el gross operativo y el net funding; no confunda ND y funding.
3. Implemente el calendar fundido con las vacaciones de antemano en los bancos.
4. Automatice la importación y conciliación de archivos settlement + alertas en SLA/delta.
5. Implemente la versificación de lotes ('batch _ revision') y la reprocess determinista.
6. Escriba el origen único de la verdad: las relaciones 'transaction ↔ batch ↔ funding'.
7. Guarde el ARN/RRN y los campos de acoplamiento para las cartas - crítico para las pantallas.
8. Pronostique el flujo de efectivo teniendo en cuenta los fines de semana/vacaciones, reservas y comisiones.

17) Hojas de verificación de implementación

Datos y esquemas

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

Importar y validar

• Parsers CSV/XML/JSON + hashes de archivos.
• Validación de sumas/monedas/fechas; match по `provider_tx_id/ARN`.
• Hendlers «late presentment», «partial capture», «reversal».

Operaciones y alertas

• Monitor SLA cut-off, archivos perdidos, delays fundidos.
• Alertas de umbral Delta (gross, fees, net).
• Informe sobre el impacto holiday y el carry-over negative.

18) FAQ

P: ¿Por qué T + 2 se convirtió en T + 4?
R: Hubo fines de semana/vacaciones en el banco corresponsal o en el banco receptor; см. funding calendar.

P: El archivo net es más pequeño que nuestro cálculo net. ¿Qué ver?
R: Compruebe fees, reserve_delta, refund/chargeback tardío, y la corrección de los cursos.

P: ¿Cómo considerar la cripta?
A: Por el equivalente fiat en 'settled _ at'; funding puede venir en USDT/fiat - almacenar separado 'fx _ at _ funding'.

P: ¿Es posible un cut-off común para todos los proveedores?
R: No, cada PSP tiene su tz/hora. Haga un escaparate de agregación encima de sus cortes.

Resumen

• comprobar con precisión los proveedores,
• prever la liquidez y cubrir los pagos,
• cumplir con el SLA y reducir los riesgos operativos,
• hablar el mismo idioma que las finanzas y el cumplimiento.

Al implementar un único calendar fundido, un modelo de datos riguroso y una conciliación automatizada, hará que el flujo de efectivo sea predecible y manejable.