Si alguna vez te has preguntado cómo funcionan los protocolos establecidos para que nuestro dinero viaje de una parte a otra del mundo con la máxima fiabilidad, éste es el artículo donde encontrarás la respuesta.

Tras mi anterior charla en las jornadas 101 Panel Tech Days (puedes ver el vídeo aquí), me he puesto manos a la obra y, aporreando las teclas de mi ordenador, he conseguido sintetizar un tema complejo como es la mensajería SWIFT en unas cuantas palabras. Espero que os sirva de ayuda.

Para empezar, una breve introducción a la mensajería SWIFT.

¿Qué es SWIFT? Para muchos de vosotros, al oírlo, la imaginación os llevará a lo último en el desarrollo de aplicaciones para entornos Apple. Y la verdad, no os falta razón. Google a veces nos engaña. Si lanzamos una consulta con el termino SWIFT, los primeros enlaces que nos devuelve el famoso buscador hacen referencia al mencionado entorno de programación. Tendremos que bajar unas cuantas líneas hasta dar con el SWIFT que andamos buscando y objeto de esta entrada.

Hagamos un poco de retrospectiva. Tranquilos no nos iremos muy lejos, sólo unas cuantas décadas. En aquellos años, sólo había un puñado de bancos. La relación entre ellos solía ser bastante escasa y cuando algún cliente les era infiel, bastaba con cruzar una calle y llevar el dinero al banco vecino en la mano. Con el devenir de los años, el crecimiento, las nuevas tecnologías y el afloramiento de nuevos actores, propició que tanto el número de usuarios como entidades financieras creciese exponencialmente. La multiplicación de productos y servicios acentuó la complejidad y el número de transacciones que se venían realizando. Para dar solución a las dificultades inherentes aparecidas en este nuevo escenario, una serie de bancos y entidades financieras, decidieron reunirse y crear una nueva figura; un intermediario. Alguien que sumase y restase. Alguien en quién se pudiese confiar. Alguien que ayudase y aportase valor en todo este proceso. De todas estas necesidades surgieron las cámaras de compensación. No vamos a extendernos más en su presentación. Nos basta con saber que existen cámaras a nivel local, a nivel territorial y a nivel mundial.

SWIFT se puede considerar dentro de esta última categoría, aunque no es una cámara de compensación al uso. Es más bien un conjunto de protocolos y actuaciones que dan solución a la problemática suscitada en el complejo mundo de las comunicaciones interbancarias.

En este enlace podéis ver lo que SWIFT (Society for Worldwide Interbank Financial Telecommunication) dice sobre sí misma.

De la definición anterior, nos vamos a quedar con que SWIFT es una plataforma que provee a sus miembros de una serie de productos y servicios orientados a estandarizar un protocolo de comunicación fiable y seguro para sus operaciones financieras.

¿Existen otras alternativas? La respuesta es SÍ. Aunque excede al ámbito de este artículo. Comentar muy de pasada que existen otras entidades que tienen una operativa parecida a SWIFT. Si atendemos a la clasificación geográfica que hemos comentado con anterioridad; tendríamos a nivel local: IBERPAY; opera con entidades adscritas solo en España. A nivel territorial, tendríamos a EBA; una cámara de compensación que establece una serie de protocolos para entidades con visibilidad en Europa. Ambas, establecen protocolos de comunicación que garantizan la fiabilidad y seguridad de las operaciones realizadas a través de sus sistemas.

Pero volvamos con SWIFT y adentrémonos en los entresijos de sus protocolos y normas.

La Arquitectura de SWIFT

¿Cómo pensáis que SWIFT provee sus servicios de comunicación a sus miembros? A decir verdad es bastante sencillo y complejo a la vez. Parece una contradicción, pero no lo es. Han implementado un servicio de comunicación muy sencillo que les permite establecer unos protocolos de seguridad muy complejos, que garantizan la confidencialidad de la transacción. Sin entrar en mucho detalle (no es relevante), comentar que el método de transporte utilizado, en la mayoría de los casos, se basa en una estructura de mensajería estándar de comunicaciones, como puede ser MQ o JMS.

El mensaje financiero utiliza la potencia de dichas estructuras de mensajería: fiable, asíncrona e independiente, para viajar de un punto a otro. La responsabilidad del envío y recepción del mensaje financiero recae sobre dicha infraestructura de la comunicación. SWIFT se encargará exclusivamente de la gestión adecuada en la formación del contenido del mensaje.

Estructura del mensaje SWIFT.

Como ya hemos comentado, SWIFT provee de una serie de servicios para facilitar la comunicación entre entidades, es lo que se conoce como FIN SERVICE (Servicios financieros). Revisemos los posibles escenarios:

La comunicación más sencilla es entre un emisor ->SWIFT -> receptor. El emisor monta el mensaje y lo envía a SWIFT. Pasada la validación, el mensaje es enviado al receptor.

SWIFT – Comunicación FIN Service estándar

El segundo escenario es la comunicación del FIN Service tipo T. El modelo diferenciador radica en la intervención de un Service Administrator. El mensaje es formado en el emisor y enviado a SWIFT donde el administrador tiene la posibilidad de completar el mensaje, realizando notificaciones tanto al emisor como al receptor del mismo. Se debe tener en cuenta que el mensaje no es retenido por el administrador en su viaje.

SWIFT – Comunicación FIN Service tipo T

Por último, analizaremos el modelo tipo Y, donde FIN Service provee de un mensaje desde el emisor hasta el receptor, y en el que el administrador o bien sólo notifica a emisor o receptor, o bien puede notificar a ambos y a su vez retener el mensaje hasta que se envíe una notificación de autorización o de rechazo, bien por parte del emisor o bien por parte del receptor.

SWIFT – Comunicación FIN Service tipo Y

El detalle del mensaje SWIFT.

La estructura del mensaje, denominada FIN COPY (modelo del mensaje financiero) está formada por cinco bloques delimitados.

Nos centraremos en los mensajes denominados usuario-a-usuario. Es obligatorio que estos mensajes estén formados por los bloques 1, 2, 4 y 5, y la composición es muy sencilla: se monta un fichero de texto plano, que contendrá la estructura de bloques que se describe a continuación:

{1: CABECERA BÁSICO / HEADER BLOCK}

{2: CABECERA DE APLICACIÓN / APPLICATION HEADER BLOCK}

{3: CABECERA DE USUARIO / USER HEADER BLOCK}

{4: BLOQUE DE TEXTO / TEXT BLOCK}

{5: BLOQUE FINAL / TRAILER BLOCK}

• Los bloques 1, 2 y 3 contienen información general y esencial del mensaje.
• El bloque 4 contiene el texto particular para la implementación del mensaje financiero.
• El bloque 5 agrega información de control.
• Los bloques 3, 4 y 5 pueden a su vez contener sub-bloques, todos ellos separados entre llaves. También pueden estar formados por campos, nombrados por un número.
•  El único bloque que deberá aparecer en todos los mensajes de forma obligatoria será la cabecera (Header Block).
• Los bloques 2 a 5 serán opcionales. Dependiendo de la naturaleza del mensaje y de la aplicación SWIFT.

Para no extendernos más en el detalle técnico de la composición del mensaje, os he detallado toda la estructura de los distintos bloques en este documento que te puedes descargar desde aquí, si realmente estás interesado 🙂

En definitiva y para terminar, SWIFT es una red formada por más de 8,000 bancos, valores y corporaciones que se encuentran en más de 200 países, y que permite el intercambio de millones de mensajes financieros estandarizados entre instituciones financieras a través del mundo. Qué mejor colofón para concluir esta entrada del blog que los números publicados por SWIFT, cifrando la actividad cerrada del año 2016: