SWIFT y traducciones internacionales

1) Cuándo y por qué SWIFT en iGaming

• no hay raíl local (SEPA/FPS/ACH) o se requiere un pago B2B a otra jurisdicción;
• se necesitan pagos a socios/afiliados, pagos de impuestos, grandes rescates de liquidez (off-ramp → fiat);
• requiere una moneda que no se encuentra en los esquemas locales.
• Pros: cobertura global, alta previsibilidad con gpi. Contras: costo (fee + FX), plazos (T + 0-T + 3), fricción de cumplimiento.

2) Mecánica básica: bancos corresponsales y enrutamiento

El BIC del beneficiario → el banco receptor. Si no hay relación directa, el pago pasa por corresponsales (nostro/vostro).

• Serial (MT103/ISO pacs. 008 va sucesivamente bank→korr→bank).
• Cover (compartir pago y cobertura a través de MT202 COV/pacs. 009).
• Datos del itinerario: BIC del banco beneficiario, IBAN/cuenta, dirección/nombre, a veces banco intermedio (BIC).
• Comisiones: SHA/OUR/BEN - Elegir quién paga por los servicios de corresponsalía.

3) Mensajes y formatos: MT ⇄ ISO 20022 (MX)

MT103 (customer credit transfer), MT202 COV (cobertura), MT199/999 (formulario libre), MT192/195 (revocación/parada).
ISO 20022 (MX): pacs. 008 (credit transfer), pacs. 009 (FI-to-FI), pacs. 004 (return), camt. 052/053/054 (extractos/posting).
La transición a ISO está en marcha en muchos bancos; mantenga la compatibilidad doble (entrada/salida MT ↔ modelo canónico en su núcleo).

4) SWIFT gpi и UETR

gpi (Global Payments Innovation) agrega UETRS de extremo a extremo (UUID) y SLAs en el tiempo; da los estados received/credited/on-hold.
Utiliza un rastreador UETRR en el portal de banco/PSP o en la API, muestra al jugador/socio las razones comprensibles de ETA y los retrasos.
Vincule 'payment _ id ↔ UETR ↔ provider_ref' para dashboards y reconsificación.

5) Plazos, cut-off y calendarios

Cut-off en el remitente/corresponsal → golpeado hasta cut-off - una oportunidad en T + 0/T + 1, de lo contrario T + 1/T + 2.
Factores no STP: comprobaciones manuales, no coincidencia de nombre/dirección, BIC/IBAN inválido, desencadenante sancionador, moneda exótica.
Tenga en cuenta las vacaciones de ambos países y las monedas → mantenga un calendario (TARGET2/US/local).

6) Comisiones y FX: de qué se compone el coste

Model: `Cost per Approved (SWIFT) = bank_fee + correspondent_fee(s) + gpi_fee (если есть) + FX_margin + ops_cost (investigations/R-возвраты)`.

• SHA - Cada parte paga a su banco (default).
• OUR - usted cubre todas las comisiones, el beneficiario recibe exactamente el importe (más caro).
• BEN - El beneficiario paga todo (rara vez es adecuado para B2C).
• Margen FX: fuentes de cotización, spread, cut-time; fijar el curso/tiempo (quote id) para contabilizar y disputas.

7) Cumplimiento: sanciones, KYC/KYB, EDD

Sanciones/PEP/adverse: detección del remitente/beneficiario/bancos intermediarios; coincidencias por nombre/dirección/país → hold/EDD.
End-use/SoF/SoW: solicitudes de asignación de pago (invoice/contrato) y fuente de fondos en los desencadenantes (suma/geo/patrones).
Límites RBA/velocity: caps per-tx/per-day, nuevos datos → mayor validación.
Los datos de pago (remittance information) deben ser precisos: destino, número de contrato, factura.

8) Validación de datos y calidad STP

IBAN/Luhn/MOD97, validación BIC, dirección del destinatario (ciudad/país), códigos purpose (donde se requiere).
Name Check/Confirmation of Payee-análogo - si está disponible en el banco/PSP.
Whitelist datos de socios con TTL y reversificación.
Regla STP: cuanto más completos sean los campos, menos verificaciones y devoluciones manuales.

9) Rechazos, devoluciones e investigaciones (investigaciones)

• Reject antes del envío/aceptación (no se han aprobado validaciones).
• Retorno después de la recepción (comprobaciones tardías, cuenta cerrada, sanciones/EDD) - ISO pacs. 004 o MT Return.
• Recall/Stop & Recall: solicitud de retirada de pago (no garantizada).
• Investigaciones: correspondencia a través de MT199/999/MX camt/case, portal gpi.
• Práctica: almacenar códigos de causa/texto, SLA de procesamiento, plantillas de correo electrónico.

10) Flujos en el producto (referencia)

10. 1 Inbound (recepción de fondos)

1. Emite los datos: BIC/IBAN/beneficiary name/address, a veces BIC intermedio.
2. El cliente/socio envía el MT103/pacs. 008 → su banco.
3. Webhook/extracto (camt. 053/MT940) → la inscripción en el balance, mapping por 'EndToEndId/UETRR/Remit'.
4. CUV/CUS/Sanciones - post-control y, de ser necesario, recall/return.

10. 2 Outbound (pagos)

1. Solicitud → verificación de RBA/sanciones, validación de datos, selección de SHA/OUR/BEN y moneda/FX.
2. Envío a través de API/banco cliente → recepción de UETRR.
3. Seguimiento de gpi, estados, comunicación de ETA, tramitación de return/investigación.
4. Reconsificación de T + 0/T + 1 por extracto.

11) Lager, altas y reconsilación

Identificadores: 'payment _ id ↔ UETER ↔ bank_ref ↔ EndToEndId/RemittanceInfo'.
Extractos: camt ISO. 052/053/054 o MT MT940/942; parcing comisiones/moneda/fecha de la divisa.
T + 0/T + 1-conciliación: sumas, FX, comisiones, «colgantes» (líneas sin colgar) → el turno de las investigaciones.
Informes/auditorías: registros inmutables, fuente del curso FX, versiones de datos de contraparte.

12) Orquesta, Failover y SLA

Multi-banco/multi-PSP para monedas clave; corresponsales de respaldo.
Reglas de enrutamiento: por moneda, país, tamaño, banco SLA, valor (fee + FX).
Cut-off-aware planificador (teniendo en cuenta las vacaciones).
Puntos de referencia SLA: casos automáticos - ≤ T + 1, EDD manual - ≤ T + 2-T + 3; actualizaciones de estado gpi - near-real-time.

13) UX y comunicaciones

Una ETA transparente y una explicación de los factores (banco/país/moneda, cut-off, OUR/SHA).
Muestre el enlace UETRR/estado en el gabinete del socio/VIP.
Campos claros para introducir datos, sugerencias de formato de dirección/IBAN/BIC, advertencias de OUR‐komissiyakh.
Plantillas de respuesta por return/recall/investigation.

14) Métricas y OKR

Success/Approval Rate SWIFT, доля STP.
Time-to-Funds/Time-to-Payout p50/p95.
gpi visibility% (porcentaje de pagos con seguimiento actualizado).
Retorno/Recall/Tasa de investigación, tiempo medio de investigación.
Costo per Approved (fee + FX + ops), spread FX en b.p.
False-positive de cumplimiento, una fracción de casos manuales.

15) Anti-patrones

Un banco/corresponsal por divisa → SPOF.
Datos incompletos (dirección/nombre/destino) → comprobaciones manuales y retorno.
Ignora cut-off/vacaciones, no hay planificador.
No se fija el tipo de cambio/tiempo de cotización → disputas sobre FX.
Los registros MIX de PII y pagos sin tokenización/RBAC.
No hay mapping 'payment _ id ↔ UETER' → pistas «perdidas» y caos en el sapport.

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

• Cuentas y líneas de corresponsalía por moneda objetivo; 2 + bancos asociados.
• Modelo canónico MT/ISO 20022 en el núcleo; parsers camt. 052/053/054 y MT940/942.
• Integración de gpi/UETR, estados de dashboard, notificaciones.
• Validación IBAN/BIC, direcciones; whitelist de los datos; selección SHA/OUR/BEN.
• FX Pólizas: fuente de cotización, fijación, spread limites, registro.
• Sanciones/KYC/KYB/RBA/EDD; plantillas de documentos y gestión de casos.
• Orquesta por corte-off y días festivos; enrutamiento por costo/SLA.
• Lager y T + 0/T + 1-reconsilación; Cola sin colas; informes.
• Playbucks return/recall/investigation; señalizados webhooks, idempotencia.
• Formación sapport: estados gpi, códigos de causa, comunicaciones FX/comisiones.

17) Resumen

SWIFT es la «artillería pesada» para los pagos internacionales de iGaming. Construya un circuito multi-banco con gpi/UETRR, mantenga un registro FX y de comisiones estricto, cumpla con las sanciones/EDD, automatice la T + 1-reconsificación y muestre a los clientes ETA y estados transparentes. Entonces, incluso los complejos pagos cruzados serán predecibles, conformes a los requisitos y económicamente manejables.