SEPA Credit Transfer/Instant

1) Qué es SCT y SCT Inst - y por qué es importante iGaming

SCT (SEPA Credit Transfer) es una transferencia de crédito en euros entre bancos de la zona SEPA con un cálculo normalmente T + 0/T + 1 (depende del cut-off).
SCT Inst (SEPA Instant) es una transferencia instantánea 24/7/365 con un crédito objetivo en segundos (límite en la cantidad y participación del banco - con un banco/proveedor específico).

Las ventajas para iGaming son: bajo costo, sin charjbacks clásicos, alta autoridad de los reguladores, predecible settlement y pagos en masa convenientes.

2) Opciones de uso

2. 1 Depósitos (inbound)

IBAN de bala (referencias virtuales) o IBAN virtuales por cliente/factura.
Para SCT Inst, el «quasi-instantáneo» más rápido posible de los fondos de onboarding.
Asignación de pago (remittance information) → mapping a 'payment _ id'.

2. 2 Conclusiones/pagos (outbound)

Pagos masivos a través de SCT (batches) o cachouts instantáneos a través de SCT Inst.
Playback: Si el banco del destinatario no soporta el Inst - auto-folback en SCT normal.

3) Arquitectura de integración (referencia)

• Banking/PSP Layer: cuenta (a) en la UE, soporte SCT/SCT Inst, webhooks/archivos de extractos.
• Payments Core: orquestación de depósitos/pagos, estados, límites.
• Risk & Compliance: cribado sancionador de pagadores/destinatarios, RBA/EDD.
• Accounting & Recon: etiqueta, mapping 'payment _ id ↔ bank_ref/EndToEndId', reporting.
• Monitorización: ETA, tolerancia a fallas, alertas en códigos R/devoluciones.

• IBAN/wirth. el enlace se emite → el cliente inicia el pago en su banco → SCT/SCT Inst → webhook/extracto → acreditación en el saldo del jugador → reconsificación.

• Solicitud de retirada → verificación (RBA/sanciones/validación IBAN) → SCT Inst (si está disponible) o SCT → estados/referencias → notificación al jugador → reconsificación.

4) Plazos, cut-off y ETA

SCT: la llegada de T + 0/T + 1, depende de la hora de envío y corte-fuera del banco; es posible «horas/días bancarios».
SCT Inst: objetivo real-time, 24/7; si el banco del destinatario no está en la red Inst o se excede el límite - la transferencia puede ser rechazada/transferida a la SCT normal (según las reglas del proveedor/banco específico).

Práctica UX: muestre una ETA dinámica y explique que Inst no está disponible en todos los bancos/sumas.

5) Verificación de los datos

IBAN: comprobación de longitud/formato/suma de comprobación (MOD97).
BIC (donde se necesita) y directorios bancarios para el enrutamiento.
Name Check/Confirmation of Payee análogo (si está disponible en su banco/PSP): la comparación del nombre del destinatario con IBAN reduce los errores y los códigos R.
Bloqueo beneficiario: whitelist de datos previamente verificados con TTL y límites.

6) Devoluciones y códigos R (diagnóstico)

• IBAN/No se encontró una cuenta incorrecta - Reject antes del depósito.
• Límites/Restricciones de Entrada - Desviación de SCT Inst o Folback.
• Los bloqueos de cumplimiento en el banco receptor son Return/Recall después de la prueba previa.
• El banco del destinatario no está disponible - Técnico Reject.

Operaciones: lógica el código R, el texto de la causa y la hora; ejecutar auto-workflow (volver a comprobar IBAN/nombre, pedir aclaraciones al cliente, escalar en cumplimiento).

7) Cumplimiento y control de riesgos

KYC/KYB: niveles para jugadores/socios de RBA; duchas, PoA/SoF para grandes sumas o anomalías.
Examen sancionador del remitente/destinatario (nombre, dirección, país; para los jurlitz - nombre/reg. datos).
Límites RBA: caps per-tx/per-day, velocity por IBAN/destinatario/dispositivo.
Flags rojos: rapid in-out (cobro rápido), cambio IBAN, aplastamiento, coincidencias por medios avanzados.
Intercambio de documentos: almacenamiento de datos/consentimientos justificativos dentro de los requisitos de la jurisdicción.

8) Economía y Comisiones

• Tarifa bancaria/PSP para SCT/SCT Inst (transacción/paquete/descuento volumétrico);
• fee posibles por extractos/webhooks/archivos;
• operativo: procesamiento de códigos R/casos manuales/sapport;
• FX - sólo en las conversiones cruzadas fuera del euro (para SEPA generalmente EUR→EUR).

Métrica: considera todos los fondos y el tiempo (antes de que aparezca dinero en tu cuenta/cliente), no solo el «precio de transferencia».

9) Lager y Reconsilación

Identificadores únicos: utilice 'EndToEndId '/' RemittanceInfo' para mapear 'payment _ id ↔ bank_ref'.
Las tablas insignia son: 'payments', 'payouts',' bank _ statements', 'recon _ lines'.
Reconsificación automática T + 0/T + 1: sumas, comisiones, estados, líneas no asignadas («colgantes») - en una cola separada.
Informes: descargas por jurisdicción, registro de ajustes, registros inmutables.

10) Orquestación de rutas y Feolover

Reglas de selección: si el banco del destinatario/la cantidad es compatible con Inst → SCT Inst; de lo contrario, SCT.
Lógica de Folback: No está disponible Inst/High Falls - Auto-Switch; informar a ETA en IU.
Idempotencia/anti-toma: clave 'payment _ id/withdrawal _ id'; retraídas con backoff + jitter.
Doble proveedor/cuenta en diferentes bancos en mercados clave → tolerancia a fallas.

11) Patrones UX (conversión y confianza)

Muestre claramente el método (SCT/SCT Inst), ETA y las comisiones antes de la confirmación.
Compruebe el IBAN/nombre antes de enviar (y las sugerencias de formato).
Estados de tiempo real: «creado → enviado al banco → acreditado/denegado/devuelto».
Para depósitos: IBAN/referencias virtuales, QR/copia, instrucciones para el destino del pago.

12) Métricas y OKR

Approval/Success Rate по SCT/SCT Inst.
Time-to-Funds (in) / Time-to-Payout (out) p50/p95.
La participación de Inst en los flujos y su impacto en la conversión.
R-codes rate (por tipos y bancos), tiempo de resolución de casos.
Costo de aprobación (todo en uno), costo del caso manual.
Uptime por proveedor/banco, retrasos en webhooks/extractos.

13) Anti-patrones

Un banco/un proveedor sin reserva (SPOF).
No hay validación del IBAN/nombre del destinatario.
Los opacos de ETA y comisiones son un estallido de tickets/cancelaciones.
No hay idempotencia - toma de cargos/pagos.
Ignorar los códigos R y las líneas de extractos «colgantes» son brechas en la contabilidad.
Mezcla de PII y registros de pago sin tokenización/accesos.

14) Lista de verificación de implementación (corta)

• Cuenta (a) en EC/PSP con soporte SCT + SCT Inst, webhooks firmados y archivos de extractos.
• IBAN virtuales/referencias de facturación/cliente; mapping 'payment _ id ↔ EndToEndId'.
• Validación IBAN/BIC y (donde existe) Name Check; whitelist datos con TTL.
• Límites RBA, sanciones/PEP/adverse, reglas EDD/SoF.
• Enrutamiento de Inst→SCT y folback, idempotencia, retraídas.
• Lager/reconsificación T + 0/T + 1, procesamiento de «colgantes», informes.
• Dos socios bancarios/canal, un playbook de degradación e incidentes.
• UX: ETA/Comisiones/Estados en tiempo real, instrucciones para el destino del pago.
• Métricas/dashboards: AR, Time-to-Funds, R-codes, costo.
• Entrenamiento de sapport: causa de códigos R, patrones de respuesta, plazos.

15) Resumen

SCT/SCT Inst es un «caballo de trabajo» para los pagos en euros en iGaming: barato, predecible y amigable con el cumplimiento. Construya un circuito dual (Inst + estándar SCT), agregue validaciones de IBAN/nombre y un sello claro, automatice la reconsificación y procesamiento de códigos R, y en UX muestre ETA y comisiones de forma transparente. De esta manera obtendrá una alta conversión, pagos rápidos y un rendimiento operativo sostenido en los mercados de la UE.