ISO 20022 Datos mejorados – Direcciones estructuradas
El uso de datos mejorados es la siguiente fase de la migración a ISO 20022 en el ámbito de los pagos. Las mayores ventajas se obtendrán una vez que toda la cadena de extremo a extremo admita los datos mejorados que ofrecen los mensajes ISO 20022. Esto llevará tiempo, ya que los datos sólo serán tan ricos como dicte la entidad de la cadena de pagos con mayor restricción de datos. Es importante que las principales infraestructuras del mercado financiero (IMF) tomen la iniciativa adoptando los datos mejorados en sus propias reglas y normas, propagándose gradualmente por la red de pagos. Esta adopción ya ha comenzado, y Swift, CHAPS, SEPA y otras han establecido plazos y planes para pasar a los datos mejorados. Por ejemplo, las normas SEPA 2023 actualizan los mensajes ISO 20022 a la versión 2019, que incluye la versión más reciente y rica en datos del elemento de dirección estructurada (PostalAddress24). Utilizar esta versión (o una posterior) es el paso básico. Swift y otras FMI ya están en ello y, en el espacio corporativo, CGI-MP están planeando la actualización.
¿Qué son los datos mejorados?
Los datos mejorados son la sobrecarga de datos en un mensaje, posible gracias al uso del modelo de datos más estructurado que ofrece la norma ISO 20022, que permite un procesamiento de datos más preciso, ya sea para el CSC, el control normativo, la supervisión, la conciliación o los flujos de trabajo relacionados con la vinculación y la correspondencia, y que ofrece servicios de valor añadido mejor orientados.
Los aspectos clave de los datos mejorados son las direcciones estructuradas, los identificadores de entidad jurídica (LEI) y la información estructurada sobre remesas. Ya he tratado anteriormente la información estructurada sobre las remesas en el contexto de los casos de uso B2B; para más información , consulta este enlace. Hablaré de los IPJ en otro artículo, pero tanto los IPJ como las direcciones estructuradas ayudarán a identificar a las partes y agentes de la cadena, apoyando la incorporación automatizada, el procesamiento directo, el aumento de la transparencia, la velocidad y la reducción de costes. También habrá que tenerlas muy en cuenta para aplicarlas correcta y eficazmente.
Puede que hayas oído hablar de los datos mejorados, las direcciones estructuradas e incluso las direcciones híbridas. Este artículo pretende explicar los fundamentos, señalar algunos recursos clave y destacar algunos de los retos.
¿Qué son las direcciones estructuradas?
El modelo de datos ISO 20022 construye elementos de datos complejos a partir de sus partes componentes y estructuradas, lo que permite un desglose preciso y granular hasta el nivel más bajo del elemento de datos.
Una dirección totalmente estructurada es una dirección compuesta por las partes componentes (campos) definidas en la versión 2019 de los mensajes ISO 20022. Se trata del elemento complejo PostalAddress24 utilizado en esta versión. La versión de 2009 de los mensajes ISO 20022, ampliamente utilizada, utiliza una estructura de dirección anterior y menos detallada, PostalAddress6.
Las dos versiones se muestran a continuación: la versión de 2009 tiene 9 campos que comprenden la dirección (contando 7 iteraciones de Línea de dirección como un campo), mientras que la versión de 2019 los amplía a 15 campos.
Una dirección totalmente estructurada debe tener una separación estricta y coherente de las partes de la dirección en estos campos PostalAddress24 y, lo que es más importante, no se permite el uso de los campos repetidos Address Line (<AdrLine>). Por ejemplo, utilizar «The White House, 1600 Pennsylvania Avenue, Washington DC, USA»:
No estructurada:
<AdrLine>The White House, 1600 Pennsylvania Avenue</AdrLine> <AdrLine>Washington DC</AdrLine> <AdrLine>USA</AdrLine>
O No estructurado (o cualquier otra variación de AdrLine):
<AdrLine>The White House</AdrLine> <AdrLine>1600 Pennsylvania Avenue</AdrLine> <AdrLine>Washington DC, USA</AdrLine>
Estructurada:
<StrtNm>Pennsylvania Avenue</StrtNm> <BldgNb>1600</BldgNb> <BldgNm>The White House</BldgNm> <TwnNm>Washington, DC</TwnNm> <Ctry>US</Ctry>
Normalmente, los datos de los campos de línea de dirección repetidos (línea de dirección 1, 2, 3, etc.) son texto libre, incoherentes y suelen combinar varios elementos de dirección. Procesar estos campos de datos no estructurados es difícil, con una amplia lógica difusa y, a menudo, muchos falsos positivos. Como puedes ver en este sencillo ejemplo, el uso de un formato estructurado es menos ambiguo y permite un procesamiento más preciso, reduciendo la necesidad de transformar/parsear los datos, la lógica difusa y los falsos positivos.
Al considerar la migración de MT a MX, cabe señalar que el uso de una dirección «estructurada» está disponible en los formatos MT, pero no debe confundirse con una dirección estructurada MX / ISO 20022. El formato de dirección «estructurada» MT, como en el campo 59 opción F de un MT 103, debe considerarse no estructurado en el contexto de MX. Esto se demuestra en la tabla siguiente.
Dificultades de aplicación
La implantación de direcciones totalmente estructuradas plantea muchos retos importantes. Las FMI y las prácticas de mercado tienen que adoptar la versión 2019 de los mensajes ISO 20022, que utilizan PostalAddress24. Esto está ocurriendo; Swift CBPR+ ya la utiliza, el reglamento de la SEPA 2023 ordena el cambio y CGI-MP también ha definido y planificado la actualización a la versión de 2019, utilizando la pain.001.001.09 en lugar de la pain.001.001.03. Sin embargo, todas las demás partes interesadas en las cadenas de pago y gestión de efectivo deben seguir el ejemplo, incluidos los bancos, las empresas y sus proveedores de software. Las empresas de servicios, los sistemas ERP y TMS deben manejar los mensajes de la versión 2019 y el modelo de datos subyacente de forma nativa.
Los repositorios internos de datos de referencia tendrán que actualizarse para almacenar direcciones estructuradas nativas. Esto requerirá la migración de datos de los registros existentes, lo que, incluso para organizaciones de tamaño modesto, podría implicar muchos millones de registros de direcciones, una empresa nada trivial. Y lo que es más importante, muchos organismos gubernamentales y no gubernamentales necesitan actualizar sus fuentes de datos de referencia. En la actualidad, las listas de sanciones, los almanaques bancarios, los repositorios BIC, los registros de empresas de cada país, etc., almacenan datos de direcciones en formatos diferentes y no estructurados.
Los IPJ son un buen ejemplo de fuente de datos de referencia externa que utiliza formatos de dirección no estructurados. Esto resulta irónico, dado que el uso de los IPJ se está introduciendo como parte de las mejoras de los datos en las mismas normas del sistema que abogan por el uso de direcciones estructuradas. Esperemos que las ventajas del uso de los IPJ, para una identificación más clara de las partes, no se vean menoscabadas por la dificultad de conciliar su formato de dirección no estructurado con tu repositorio interno de direcciones estructuradas. Para ayudarte en tu propia investigación sobre este punto concreto, en los siguientes enlaces encontrarás los formatos de los IPJ, incluidos los formatos de dirección y ejemplos:
Esquema xml del IPJ:
https://www.gleif.org/en/lei-data/gleif-data-quality-management/xml-schema
Datos LEI xml, incluida la dirección, de Alphabet Inc:
https://search.gleif.org/#/record/5493006MHB84DD0ZWV18/show_xml
También he elaborado un resumen de la correspondencia entre la dirección del IPJ y la dirección postal ISO 2002224, disponible en una hoja de Google aquí:
https://docs.google.com/spreadsheets/d/13my6mwxqRmCXfAZd-5A5xUXCGGJgTQeUkaw8k9yXwKY/edit?usp=sharing
Está claro que la implantación generalizada de las direcciones estructuradas nativas será larga y difícil, por lo que será necesario un enfoque gradual de aquí a 2026. Ésta es también la razón por la que muchas FMI están adoptando un formato de dirección híbrido. La mayoría de los participantes y partes de la cadena de pagos necesitarán un plan a medio plazo para transformar los datos entre formatos estructurados y no estructurados, incluidos los formatos híbridos.
La introducción gradual de las direcciones estructuradas ha comenzado y en muchas FMI finalizará a finales de 2025, cuando ya no se permitan las direcciones no estructuradas e híbridas. El Consejo Europeo de Pagos (EPC), por ejemplo, ha publicado orientaciones sobre el uso de direcciones estructuradas a partir de noviembre de 2025 para los cuatro reglamentos del esquema de pagos SEPA(EPC 153-22). Entre noviembre de 2023 y noviembre de 2025, se permitirá un formato de dirección híbrido y escalonado.
Uso del formato de dirección híbrido
¿Qué es exactamente el formato híbrido?
Pensado como formato provisional en la migración de no estructurado a totalmente estructurado, algunas FMI han creado directrices de uso (UG) que permiten un formato de dirección híbrido que mezcla elementos estructurados y elementos no estructurados (es decir, líneas de dirección).
Un formato de dirección híbrido permite a los interesados utilizar los elementos de datos de PostalAddress24, pero no tan estrictamente definidos como en el formato estructurado. Podría ser manteniendo el número de edificio en el nombre de la calle o permitiendo cierto uso de las líneas de dirección además del nombre de la ciudad y el país. Observarás que la especificación base de PostalAddress24 tiene todos los elementos como opcionales, lo que permite una flexibilidad significativa, posibilitando este formato híbrido: las UG pueden exigir determinados elementos, como la ciudad y el país, al tiempo que permiten el uso opcional de líneas de dirección. Las UG, que dictan las normas específicas del formato híbrido, variarán según la autoridad editora. Remitiéndonos de nuevo a las orientaciones del EPC para la SEPA, se afirma,
«…se seguirá aceptando la introducción actual de direcciones con 2 apariciones del elemento de dirección no estructurado «Línea de dirección» asociado al elemento de dirección estructurado «País».»
Sin embargo, establece que a partir de noviembre de 2025:
«La provisión de direcciones estructuradas para pagos SEPA debe cumplir los siguientes requisitos: – No puede utilizarse el elemento de datos «Línea de dirección». – Deben utilizarse los elementos de datos «País» <Ctry> y «Nombre de ciudad» <TwnNm>. – Los otros 12 elementos de datos pueden utilizarse en función de los componentes de la dirección.»
Utilizando el ejemplo de la Casa Blanca, una dirección híbrida podría tener este aspecto:
Ejemplo híbrido 1:
<StrtNm>1600 Pennsylvania Avenue</StrtNm> <BldgNm>The White House</BldgNm> <TwnNm>Washington, DC</TwnNm> <Ctry>US</Ctry>
Este primer ejemplo, que algunos pueden considerar que no es una dirección híbrida[i], sería válido en una SR 2023 CBPR+ pacs.008.001.08 para las direcciones Deudor, Acreedor, Deudor último y Acreedor último.
Ejemplo híbrido 2:
<TwnNm>Washington, DC</TwnNm> <Ctry>US</Ctry> <AdrLine>1600 Pennsylvania Avenue</AdrLine> <AdrLine >The White House</AdrLine>
Este segundo ejemplo no sería válido para el Deudor, el Acreedor, el Deudor final o el Acreedor final, ya que el CBPR+ tiene una regla formal que impide esta opción híbrida (CBPR_Structured_vs_Unstructured_FormalRule). En las UG híbridas del EPC SEPA, 2 instancias de <AdrLine> en combinación con <Ctry> sería válido (pero no con <TwnNm>).
Grupo de Práctica del Mercado de Pagos y orientación Swift
El Grupo de Prácticas del Mercado de Pagos (PMPG) ha publicado una guía sobre direcciones estructuradas. Se trata de una lectura esencial e incluye amplios ejemplos de direcciones estructuradas para 32 países en un archivo Excel disponible aquí:
Una vez que hayas descargado el archivo excel PMPG, navega hasta la última hoja de cálculo, llamada Muestras. Esta hoja de cálculo contiene otro Excel incrustado que proporciona direcciones estructuradas de muestra para estos países y es extremadamente útil para entrenar tu Modelo de Grandes Lenguas (LLM) -supongo que probarás modelos de IA-.
Swift también ha publicado orientaciones sobre las direcciones estructuradas y su enfoque gradual para FINPlus y las Normas MX, incluso más allá de 2026.
Swift CBPR+: Estructura de las direcciones postales en los mensajes CBPRPlus (21 de agosto de 2023, en el momento de redactar este documento): https://www2.swift.com/knowledgecentre/kb_articles/5026188
Uso de la inteligencia artificial
No podemos terminar sin mencionar la IA. Dada la necesidad de transformación de formatos no estructurados a estructurados, esto es algo que probablemente se beneficie de un LLM adecuado que, cuando se alimente con suficientes instrucciones detalladas, parámetros y datos de muestra (tanto para el entrenamiento como para las pruebas), pueda reducir el esfuerzo. He experimentado con Claude 2, ChatGPT (sólo 3,5) y Bard con resultados desiguales. En este artículo se incluyen enlaces a un conjunto de instrucciones de muestra para un bot de chat de IA y a un archivo de Google Sheets de origen y destino. El archivo de origen contiene 10 direcciones LEI para que el modelo las convierta al formato/archivo de destino. El resto te lo dejo a ti. Dime en los comentarios cómo te va. ¡Que lo disfrutes!
[i] Sostengo que se trata de una dirección híbrida, ya que no cumple plenamente los elementos de datos estructurados y separados de nombre de calle y número de edificio.
