El uso de datos mejorados es la siguiente fase de la migraci\u00f3n a ISO 20022 en el \u00e1mbito de los pagos. Las mayores ventajas se obtendr\u00e1n una vez que toda la cadena de extremo a extremo admita los datos mejorados que ofrecen los mensajes ISO 20022. Esto llevar\u00e1 tiempo, ya que los datos s\u00f3lo ser\u00e1n tan ricos como dicte la entidad de la cadena de pagos con mayor restricci\u00f3n 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\u00e1ndose gradualmente por la red de pagos. Esta adopci\u00f3n 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\u00f3n 2019, que incluye la versi\u00f3n m\u00e1s reciente y rica en datos del elemento de direcci\u00f3n estructurada (PostalAddress24). Utilizar esta versi\u00f3n (o una posterior) es el paso b\u00e1sico. Swift y otras FMI ya est\u00e1n en ello y, en el espacio corporativo, CGI-MP est\u00e1n planeando la actualizaci\u00f3n.<\/p>\n
\u00bfQu\u00e9 son los datos mejorados?<\/h2>\n
Los datos mejorados son la sobrecarga de datos en un mensaje, posible gracias al uso del modelo de datos m\u00e1s estructurado que ofrece la norma ISO 20022, que permite un procesamiento de datos m\u00e1s preciso, ya sea para el CSC, el control normativo, la supervisi\u00f3n, la conciliaci\u00f3n o los flujos de trabajo relacionados con la vinculaci\u00f3n y la correspondencia, y que ofrece servicios de valor a\u00f1adido mejor orientados.<\/p>\n
Los aspectos clave de los datos mejorados son las direcciones estructuradas, los identificadores de entidad jur\u00eddica (LEI) y la informaci\u00f3n estructurada sobre remesas. Ya he tratado anteriormente la informaci\u00f3n estructurada sobre las remesas en el contexto de los casos de uso B2B; para m\u00e1s informaci\u00f3n , consulta este enlace<\/a>. Hablar\u00e9 de los IPJ en otro art\u00edculo, pero tanto los IPJ como las direcciones estructuradas ayudar\u00e1n a identificar a las partes y agentes de la cadena, apoyando la incorporaci\u00f3n automatizada, el procesamiento directo, el aumento de la transparencia, la velocidad y la reducci\u00f3n de costes. Tambi\u00e9n habr\u00e1 que tenerlas muy en cuenta para aplicarlas correcta y eficazmente.<\/p>\n Puede que hayas o\u00eddo hablar de los datos mejorados, las direcciones estructuradas e incluso las direcciones h\u00edbridas. Este art\u00edculo pretende explicar los fundamentos, se\u00f1alar algunos recursos clave y destacar algunos de los retos.<\/p>\n 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\u00e1s bajo del elemento de datos.<\/p>\n Una direcci\u00f3n totalmente estructurada es una direcci\u00f3n compuesta por las partes componentes (campos) definidas en la versi\u00f3n 2019 de los mensajes ISO 20022. Se trata del elemento complejo PostalAddress24 utilizado en esta versi\u00f3n. La versi\u00f3n de 2009 de los mensajes ISO 20022, ampliamente utilizada, utiliza una estructura de direcci\u00f3n anterior y menos detallada, PostalAddress6.<\/p>\n Las dos versiones se muestran a continuaci\u00f3n: la versi\u00f3n de 2009 tiene 9 campos que comprenden la direcci\u00f3n (contando 7 iteraciones de L\u00ednea de direcci\u00f3n como un campo), mientras que la versi\u00f3n de 2019 los ampl\u00eda a 15 campos.<\/p>\n Una direcci\u00f3n totalmente estructurada debe tener una separaci\u00f3n estricta y coherente de las partes de la direcci\u00f3n en estos campos PostalAddress24 y, lo que es m\u00e1s importante, no se permite el uso de los campos repetidos Address Line (<AdrLine>). Por ejemplo, utilizar \u00abThe White House, 1600 Pennsylvania Avenue, Washington DC, USA\u00bb:<\/p>\n Normalmente, los datos de los campos de l\u00ednea de direcci\u00f3n repetidos (l\u00ednea de direcci\u00f3n 1, 2, 3, etc.) son texto libre, incoherentes y suelen combinar varios elementos de direcci\u00f3n. Procesar estos campos de datos no estructurados es dif\u00edcil, con una amplia l\u00f3gica 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\u00e1s preciso, reduciendo la necesidad de transformar\/parsear los datos, la l\u00f3gica difusa y los falsos positivos.<\/p>\n Al considerar la migraci\u00f3n de MT a MX, cabe se\u00f1alar que el uso de una direcci\u00f3n \u00abestructurada\u00bb est\u00e1 disponible en los formatos MT, pero no debe confundirse con una direcci\u00f3n estructurada MX \/ ISO 20022. El formato de direcci\u00f3n \u00abestructurada\u00bb MT, como en el campo 59 opci\u00f3n F de un MT 103, debe considerarse no estructurado en el contexto de MX. Esto se demuestra en la tabla siguiente.<\/p>\n La implantaci\u00f3n de direcciones totalmente estructuradas plantea muchos retos importantes. Las FMI y las pr\u00e1cticas de mercado tienen que adoptar la versi\u00f3n 2019 de los mensajes ISO 20022, que utilizan PostalAddress24. Esto est\u00e1 ocurriendo; Swift CBPR+ ya la utiliza, el reglamento de la SEPA 2023 ordena el cambio y CGI-MP tambi\u00e9n ha definido y planificado la actualizaci\u00f3n a la versi\u00f3n de 2019, utilizando la pain.001.001.09 en lugar de la pain.001.001.03. Sin embargo, todas las dem\u00e1s partes interesadas en las cadenas de pago y gesti\u00f3n 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\u00f3n 2019 y el modelo de datos subyacente de forma nativa.<\/p>\n Los repositorios internos de datos de referencia tendr\u00e1n que actualizarse para almacenar direcciones estructuradas nativas. Esto requerir\u00e1 la migraci\u00f3n de datos de los registros existentes, lo que, incluso para organizaciones de tama\u00f1o modesto, podr\u00eda implicar muchos millones de registros de direcciones, una empresa nada trivial. Y lo que es m\u00e1s 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\u00eds, etc., almacenan datos de direcciones en formatos diferentes y no estructurados.<\/p>\n Los IPJ son un buen ejemplo de fuente de datos de referencia externa que utiliza formatos de direcci\u00f3n no estructurados. Esto resulta ir\u00f3nico, dado que el uso de los IPJ se est\u00e1 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\u00f3n m\u00e1s clara de las partes, no se vean menoscabadas por la dificultad de conciliar su formato de direcci\u00f3n no estructurado con tu repositorio interno de direcciones estructuradas. Para ayudarte en tu propia investigaci\u00f3n sobre este punto concreto, en los siguientes enlaces encontrar\u00e1s los formatos de los IPJ, incluidos los formatos de direcci\u00f3n y ejemplos:<\/p>\n Esquema xml del IPJ:<\/p>\n https:\/\/www.gleif.org\/en\/lei-data\/gleif-data-quality-management\/xml-schema<\/a><\/p>\n Datos LEI xml, incluida la direcci\u00f3n, de Alphabet Inc:<\/p>\n https:\/\/search.gleif.org\/#\/record\/5493006MHB84DD0ZWV18\/show_xml<\/a><\/p>\n Tambi\u00e9n he elaborado un resumen de la correspondencia entre la direcci\u00f3n del IPJ y la direcci\u00f3n postal ISO 2002224, disponible en una hoja de Google aqu\u00ed:<\/p>\n https:\/\/docs.google.com\/spreadsheets\/d\/13my6mwxqRmCXfAZd-5A5xUXCGGJgTQeUkaw8k9yXwKY\/edit?usp=sharing<\/a><\/p>\n Est\u00e1 claro que la implantaci\u00f3n generalizada de las direcciones estructuradas nativas ser\u00e1 larga y dif\u00edcil, por lo que ser\u00e1 necesario un enfoque gradual de aqu\u00ed a 2026. \u00c9sta es tambi\u00e9n la raz\u00f3n por la que muchas FMI est\u00e1n adoptando un formato de direcci\u00f3n h\u00edbrido. La mayor\u00eda de los participantes y partes de la cadena de pagos necesitar\u00e1n un plan a medio plazo para transformar los datos entre formatos estructurados y no estructurados, incluidos los formatos h\u00edbridos.<\/p>\n La introducci\u00f3n gradual de las direcciones estructuradas ha comenzado y en muchas FMI finalizar\u00e1 a finales de 2025, cuando ya no se permitan las direcciones no estructuradas e h\u00edbridas. 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<\/a>). Entre noviembre de 2023 y noviembre de 2025, se permitir\u00e1 un formato de direcci\u00f3n h\u00edbrido y escalonado.<\/p>\n \u00bfQu\u00e9 es exactamente el formato h\u00edbrido?<\/p>\n Pensado como formato provisional en la migraci\u00f3n de no estructurado a totalmente estructurado, algunas FMI han creado directrices de uso (UG) que permiten un formato de direcci\u00f3n h\u00edbrido que mezcla elementos estructurados y elementos no estructurados (es decir, l\u00edneas de direcci\u00f3n).<\/p>\n Un formato de direcci\u00f3n h\u00edbrido permite a los interesados utilizar los elementos de datos de PostalAddress24, pero no tan estrictamente definidos como en el formato estructurado. Podr\u00eda ser manteniendo el n\u00famero de edificio en el nombre de la calle o permitiendo cierto uso de las l\u00edneas de direcci\u00f3n adem\u00e1s del nombre de la ciudad y el pa\u00eds. Observar\u00e1s que la especificaci\u00f3n base de PostalAddress24 tiene todos los elementos como opcionales, lo que permite una flexibilidad significativa, posibilitando este formato h\u00edbrido: las UG pueden exigir determinados elementos, como la ciudad y el pa\u00eds, al tiempo que permiten el uso opcional de l\u00edneas de direcci\u00f3n. Las UG, que dictan las normas espec\u00edficas del formato h\u00edbrido, variar\u00e1n seg\u00fan la autoridad editora. Remiti\u00e9ndonos de nuevo a las orientaciones del EPC para la SEPA, se afirma,<\/p>\n \u00ab…se seguir\u00e1 aceptando la introducci\u00f3n actual de direcciones con 2 apariciones del elemento de direcci\u00f3n no estructurado \u00abL\u00ednea de direcci\u00f3n\u00bb asociado al elemento de direcci\u00f3n estructurado \u00abPa\u00eds\u00bb.\u00bb<\/em><\/p><\/blockquote>\n Sin embargo, establece que a partir de noviembre de 2025:<\/p>\n \u00abLa provisi\u00f3n de direcciones estructuradas para pagos SEPA debe cumplir los siguientes requisitos: – No puede utilizarse el elemento de datos \u00abL\u00ednea de direcci\u00f3n\u00bb. – Deben utilizarse los elementos de datos \u00abPa\u00eds\u00bb <Ctry> y \u00abNombre de ciudad\u00bb <TwnNm>. – Los otros 12 elementos de datos pueden utilizarse en funci\u00f3n de los componentes de la direcci\u00f3n.\u00bb <\/em><\/p><\/blockquote>\n Utilizando el ejemplo de la Casa Blanca, una direcci\u00f3n h\u00edbrida podr\u00eda tener este aspecto:<\/p>\n Este primer ejemplo, que algunos pueden considerar que no es una direcci\u00f3n h\u00edbrida[i], ser\u00eda v\u00e1lido en una SR 2023 CBPR+ pacs.008.001.08<\/a> para las direcciones Deudor, Acreedor, Deudor \u00faltimo y Acreedor \u00faltimo.<\/p>\n Este segundo ejemplo no ser\u00eda v\u00e1lido para el Deudor, el Acreedor, el Deudor final o el Acreedor final, ya que el CBPR+ tiene una regla formal que impide esta opci\u00f3n h\u00edbrida (CBPR_Structured_vs_Unstructured_FormalRule). En las UG h\u00edbridas del EPC SEPA, 2 instancias de <AdrLine> en combinaci\u00f3n con <Ctry> ser\u00eda v\u00e1lido (pero no con <TwnNm>).<\/p>\n El Grupo de Pr\u00e1cticas del Mercado de Pagos (PMPG) ha publicado una gu\u00eda sobre direcciones estructuradas. Se trata de una lectura esencial e incluye amplios ejemplos de direcciones estructuradas para 32 pa\u00edses en un archivo Excel disponible aqu\u00ed:<\/p>\n\u00bfQu\u00e9 son las direcciones estructuradas?<\/h2>\n
<\/div>\n<\/div>
No estructurada:<\/h3>\n
<AdrLine>The White House, 1600 Pennsylvania Avenue<\/AdrLine>\r\n\r\n<AdrLine>Washington DC<\/AdrLine>\r\n\r\n<AdrLine>USA<\/AdrLine><\/pre>\n
O No estructurado (o cualquier otra variaci\u00f3n de AdrLine):<\/h3>\n
<AdrLine>The White House<\/AdrLine>\r\n\r\n<AdrLine>1600 Pennsylvania Avenue<\/AdrLine>\r\n\r\n<AdrLine>Washington DC, USA<\/AdrLine><\/pre>\n
Estructurada:<\/h3>\n
<StrtNm>Pennsylvania Avenue<\/StrtNm>\r\n\r\n<BldgNb>1600<\/BldgNb>\r\n\r\n<BldgNm>The White House<\/BldgNm>\r\n\r\n<TwnNm>Washington, DC<\/TwnNm>\r\n\r\n<Ctry>US<\/Ctry><\/pre>\n
<\/div>\n<\/div>
Dificultades de aplicaci\u00f3n<\/h2>\n
Uso del formato de direcci\u00f3n h\u00edbrido<\/h2>\n
Ejemplo h\u00edbrido 1:<\/h3>\n
<StrtNm>1600 Pennsylvania Avenue<\/StrtNm>\r\n\r\n<BldgNm>The White House<\/BldgNm>\r\n\r\n<TwnNm>Washington, DC<\/TwnNm>\r\n\r\n<Ctry>US<\/Ctry><\/pre>\n
Ejemplo h\u00edbrido 2:<\/h3>\n
<TwnNm>Washington, DC<\/TwnNm>\r\n\r\n<Ctry>US<\/Ctry>\r\n\r\n<AdrLine>1600 Pennsylvania Avenue<\/AdrLine>\r\n\r\n<AdrLine >The White House<\/AdrLine><\/pre>\n
Grupo de Pr\u00e1ctica del Mercado de Pagos y orientaci\u00f3n Swift<\/h2>\n