Arquitectura de la red de pagos de la Society for Worldwide Interbank Financial Telecommunication (SWIFT)

SWIFT (Society for Worldwide Interbank Financial Telecommunication) es un sistema de mensajería que usan los bancos de todo el mundo para realizar transacciones financieras con bancos ubicados en otros países. Tiene su sede en Bélgica, y utiliza identificadores de 8 a 11 caracteres llamados códigos SWIFT para identificar al banco emisor y al banco receptor.

El código SWIFT fue desarrollado alrededor de 1975 con un formato propio, pero en 1994 se definió el estándar internacional ISO 9362. Después fue revisado dos veces más, y la versión actualmente en uso es la de 2014. El formato concreto puede verse en la siguiente página proporcionada por Wise, una empresa fintech de Estonia (antes Transferwise):

https://wise.com/gb/swift-codes/bic-swift-code-checker

Los primeros 4 caracteres corresponden al banco. Los siguientes 2, al país. Los 2 siguientes, a la región. Y por último, un código opcional de 3 caracteres para la sucursal. Por ejemplo, si el código SWIFT es SMCOGB2LXXX, se refiere a la sucursal XXX del banco SMCO en la región 2L del Reino Unido (GB). Aunque en principio se asigna a bancos, como la mayor demanda proviene de transferencias, muchas grandes multinacionales que suelen mover dinero entre países también obtienen y usan códigos SWIFT. Dicho al revés: si te expulsan de la red de pagos SWIFT, tus transacciones financieras reciben un golpe fuerte. En el caso de Irán y Corea del Norte, naturalmente, no tienen acceso a SWIFT.

Este texto explica la estructura técnica del sistema SWIFT según Alex Xu, autor de System Design Interview (publicado en coreano como Conceptos básicos del diseño de sistemas a gran escala aprendidos a través de casos de entrevistas simuladas).

1. Existen los Bank, que son las partes que envían y reciben dinero; los Regional Processor (RP), que procesan las solicitudes recibidas desde los Bank; y los Slice Processor (SP), que reciben las solicitudes desde los RP y almacenan los registros relacionados con las transferencias. Para simplificar, supongamos que existen Bank/RP/SP del lado A y Bank/RP/SP del lado B.
2. Bank(A) envía a RP(A) una solicitud de transferencia hacia Bank(B). RP(A) valida la solicitud y luego la transmite a SP(A). SP(A) guarda la solicitud y, después, envía a RP(A) una respuesta indicando que la solicitud fue procesada, y a RP(B) la solicitud de transferencia.
3. Tras recibir la respuesta, RP(A) envía a Bank A una respuesta indicando que la solicitud de transferencia fue aceptada (ACK) o rechazada (NAK). RP(B), al recibir la solicitud desde SP(A), almacena temporalmente el mensaje y luego emite un número único (MON) para ese mensaje antes de enviarlo a SP(B).
4. SP(B) valida el MON, realiza el proceso de autorización y después envía a RP(B) un mensaje de "envía el dinero a Bank B".
5. RP(B) entrega el mensaje a Bank B. Bank B lo recibe y lo guarda, luego efectúa el pago real y comunica el resultado exitoso o fallido (UAK/UNK) a RP(B).
6. RP(B) genera un reporte con el resultado de la transferencia y lo envía a SP(B). SP(B) lo almacena y luego envía una copia a SP(A). SP(A) vuelve a almacenarlo.

Aunque es un sistema creado alrededor de 1975, contiene todos los elementos de un microservicio moderno orientado a eventos. SP almacena en forma de mensajes tanto las solicitudes de transferencia como los reportes del resultado, y RP usa SP para ofrecer servicio a las solicitudes de los Bank. RP solo se encarga de recibir solicitudes de transferencia de los Bank o de reenviar a los Bank de su zona las solicitudes de transferencia que llegan a su área. Como resultado, todas las solicitudes relacionadas con transferencias terminan con una copia de la petición y otra del resultado del procesamiento almacenadas tanto en el SP del lado emisor como en el SP del lado receptor. Desde la perspectiva del Bank, SP no es visible en absoluto.