ISO 20022
Implantar un nuevo lenguaje de pagos no es sencillo:
Aunque se introdujeron hace casi 20 años, las normas ISO 20022 no han iniciado su camino hacia la adopción generalizada hasta los últimos años. Diseñada para producir una norma global para la comunicación electrónica y la interpretación de los datos de las transacciones financieras, su objetivo es permitir pagos sin fisuras dentro y fuera de las fronteras, animando a las Fintech y a los operadores tradicionales por igual a aprovechar las ventajas que ofrece para innovar en torno a los servicios ofrecidos a los clientes. ISO 20022 ofrece grandes oportunidades, como modelos de datos más ricos, flexibilidad, interoperabilidad y formato XML. Se espera que la adopción de la ISO 20022 aporte ventajas como una mayor eficacia en el procesamiento de los pagos, una mejor calidad de los datos, una reducción de los errores y un mejor cumplimiento de los requisitos normativos. Muchas instituciones y sistemas financieros de todo el mundo están en proceso de transición a esta norma, y las fechas clave para su implantación varían según la región y la aplicación. Las organizaciones que obtendrán mayores beneficios son las que reconozcan la naturaleza transformadora de los servicios que pueden ofrecerse e inviertan en aplicaciones nativas ISO 20022. Sin embargo, implantar la ISO 20022 no es en absoluto un camino fácil. Sin la planificación y el trabajo previo adecuados, puede ser una misión costosa y compleja, que agote los recursos. Nuestra experiencia de trabajo en estas implantaciones con clientes puede resumirse en estas 5 recomendaciones clave: Estrategia/Adopción de datos: Es esencial comprender el nuevo lenguaje de la ISO 20022, que ofrece un formato estructurado y un nuevo modelo de datos. Se recomienda dar prioridad al cumplimiento de la industria y a la comercialización de las nuevas funciones. Es importante apoyar los requisitos de datos estructurados, teniendo en cuenta el impacto en el almacenamiento y aprovechando la información deterceros con un inventario de datos. Estrategia de fases: La evaluación temprana de las relaciones existentes con corresponsales y FMI es fundamental, junto con la definición de una estrategia clara de implantación. Los bancos deben enfrentarse a nuevos retos de cumplimiento y decidir sobre enfoques como la sustitución de los sistemas de pago básicos o los sistemas heredados con envolturas ISO. Gobernanza: La planificación eficaz a nivel de organización, las estrategias de comunicación claras y el patrocinio a nivel ejecutivo son cruciales. Debe haber resultados claros del programa y criterios acordados para las distintas fases de la migración. Pruebas y validación: Se recomienda encarecidamente un enfoque de pruebas exhaustivo que incluya la validación E2E, la comunicación interna y externa con las partes interesadas y las pruebas con clientes utilizando Swift MyStandards. Las pruebas deben abarcar casos reales de uso en producción, implicar a otros bancos e incluir flujos tanto «felices» como «infelices». Después de la implementación: La migración suele constar de tres fases: el inicio de la coexistencia, la migración a MX a través de las categorías de mensajes MT 1, 2 y 9, y la adopción de datos mejorados y estructurados. Es crucial comprometerse pronto con los clientes corporativos para la adopción de datos mejorados. La aplicación de la norma ISO 20022 es un avance significativo en el sistema de pagos, que ofrece ventajas en términos de información y datos estructurados que conducen a una posible automatización de los procesos. El camino es largo y difícil, y requiere actualizaciones y recursos continuos.
May Business Consulting tiene una gran experiencia y combina expertos en la materia con gestores de programas que han vivido el viaje de la migración. Pueden ayudarte a planificar y ejecutar eficazmente un proyecto de migración a la ISO 20022, abordando los retos relacionados con la gobernanza, la estrategia de datos, el escalonamiento empresarial, las pruebas y la evolución posterior a la implantación. Ponte en contacto para obtener más información utilizando el siguiente enlace para hablar con nuestro Socio principal.
Mapeo ISO 20022 LEI y BIC
Correspondencia entre el código de identificación de la persona jurídica y el código de identificación de la empresa
Apunta
Este artículo explica por qué el archivo csv de asignación de relaciones IPJ/CIB publicado por la GLEIF no siempre puede utilizarse fácilmente para obtener el IPJ correcto relacionado con un determinado BIC. Muestra cómo enriquecer el archivo csv con campos de IPJ adicionales, para diferenciar y seleccionar mejor el IPJ correcto cuando hay más de uno relacionado con un mismo BIC.
Antecedentes
En las diversas adopciones de la ISO 20022 en el ámbito de los pagos, concretamente la introducción prevista de datos mejorados, el uso obligatorio de Identificadores de Personas Jurídicas (IPJ) debería formar parte de cualquier proyecto de implantación para bancos y PSP.
En este artículo veremos el caso de uso en el que, para la organización dada (ya sea un agente o una parte), se dispone del Código Identificador Empresarial (BIC) y, a partir de él, necesitamos obtener el IPJ pertinente para rellenar el mensaje ISO 20022.
Mapeo LEI / BIC
Swift y la GLEIF han creado un archivo de relación csv de código abierto que relaciona el BIC asignado a una organización con su IPJ. Se actualiza cada mes y puede descargarse del sitio web de la GLEIF.
Por tanto, este archivo podría importarse cada mes a un almacén de datos de referencia y utilizarse para buscar el IPJ correcto para un BIC determinado.
Relaciones entre muchos
Si fuera tan sencillo, este artículo sería redundante, así que aquí está la (pequeña) complicación… un único BIC puede estar relacionado con varios IPJ; del mismo modo, un único IPJ puede estar relacionado con varios BIC.
En el momento de redactar este documento, el archivo csv de mapeo de noviembre de 2023 tiene 22447 elementos mapeados. De ellos, el 98,4% (22084) son BIC que sólo corresponden a un único IPJ. Sin embargo, hay una minoría de BIC que corresponden a varios IPJ. Por ejemplo, el BIC «INGCITM1XXX» corresponde a 6 IPJ, como se muestra en la siguiente imagen. Con sólo el propio campo del IPJ, no es fácil diferenciarlos y asegurarse de que se selecciona la organización correcta.
Enriquecimiento con datos adicionales del IPJ
Para solucionarlo, podemos enriquecer el archivo csv con campos de IPJ adicionales, con lo que la selección correcta debería ser más fácil. A continuación se muestra el archivo enriquecido con 6 campos adicionales.
Cómo enriquecer
Las API de la GLEIF proporcionan todo lo necesario para obtener los campos de datos adicionales de la organización, concretamente utilizando la información de nivel 1 lei-records > (LEI Records) > GET LEI Record By ID (LEI).
Utilizando este punto final de la API con el parámetro de página[size] y el filtro[lei], donde este último es una cadena separada por comas de los IPJ a enriquecer. A continuación se muestra un fragmento de este código Python.
# URL of the GLEIF API endpoint
url = f"https://api.gleif.org/api/v1/lei-records?page[size]={batch_size}&filter[lei]={lei_csv_param}"
# Make the API call to GLEIF
response = requests.get(url)
# Check if the API call was successful
if response.status_code == 200:
# Parse the JSON response
data = response.json()
# Extract the data from the response
if not data['data'][0]:
return 'No LEI data found'
else:
for item in data['data']:
# Get the LEI
if 'attributes' in item:
lei = item['attributes'].get('lei')
legal_name = item['attributes']['entity']['legalName']['name']
legal_adr_city = item['attributes']['entity']['legalAddress']['city']
legal_adr_ctry = item['attributes']['entity']['legalAddress']['country']
legal_adr_postalcode = item['attributes']['entity']['legalAddress']['postalCode']
status = item['attributes']['entity']['status']
lei_enriched_data.append([lei, legal_name, legal_adr_city, legal_adr_ctry,
legal_adr_postalcode, status])
return lei_enriched_data
Repositorio GitHub
El código Python completo puede clonarse de mi repositorio de GitHub aquí:
Soy un codificador aficionado, que acaba de aprender Python, por lo que tienes mis disculpas por el lamentable estado de este código, sin embargo, funciona y no supera los límites de velocidad de la API de la GLEI. También incluye otros métodos que llaman a los puntos finales de la API de la GLEIF y un método para validar el formato y la suma de comprobación de un IPJ.
Espero que te sean útiles. ¡Que los disfrutes!
Advertencia sanitaria API de la GLEIF
Una advertencia sanitaria sobre las API de la GLEI: lee los términos y condiciones (más abajo). Tienen tarifas limitadas y superarlas probablemente dará lugar a códigos de estado 429 (demasiadas solicitudes).
Condiciones generales
El uso de los datos del IPJ de la GLEIF es gratuito.
La GLEIF no establece relaciones contractuales individuales con usuarios concretos de los datos del IPJ.
La limitación de velocidad está fijada actualmente en 60 peticiones, por minuto, por usuario, para todos los usuarios.
Por favor, consulta en su lugar las Condiciones de Uso de los Datos del IPJ disponibles aquí: https://www.gleif.org/en/meta/lei-data-terms-of-use/
¿Con Excel?
En caso de que utilices Excel para abrir o ver los archivos csv original y enriquecido, ten en cuenta que debido a los caracteres acentuados y no latinos que admiten los campos del IPJ, como los que se encuentran en el nombre legal, el código python utiliza la codificación UTF-16 al escribir los datos en el archivo csv enriquecido. Si intentas abrirlo con Excel (haciendo doble clic en el archivo csv), puede que no funcione. En su lugar, sigue estos pasos para importar el archivo csv a Excel:
- Abre Excel y, a continuación, abre un libro en blanco.
- En la cinta de opciones, selecciona Archivo y luego Abrir.
- Busca la ubicación del archivo csv, selecciónalo y elige Abrir.
- En el Asistente para importar texto, asegúrate de seleccionar Unicode (UTF-8) como origen del archivo. Esto es muy importante – mira la imagen de abajo.
- Si se te pide que conviertas los datos, selecciona No convertir.
Por último, si tienes que utilizar Excel, te aconsejo que utilices una importación de Power Query. Para archivos csv grandes es más eficaz. Por supuesto, no intentes importar el archivo de asignación ISIN / LEI a menos que utilices un modelo de datos en Power Query. El ISIN / LEI csv tiene más de 2 millones de registros y es >240Mb.
Después de empezar a estudiar los aspectos prácticos de la obtención del IPJ correcto a partir de un BIC determinado, para rellenar un mensaje ISO 20022 y cumplir los requisitos pendientes del IPJ (CHAPS, CBPR+, SEPA, etc.), he pensado en compartir algunas ideas iniciales y herramientas que pueden ayudar a otros. Si necesitas más información, ponte en contacto conmigo.
ISO 20022: Consideraciones sobre la actualización de 2009 a 2019
ISO 20022: Consideraciones sobre la actualización de 2009 a 2019
Introducción
Este es el escenario: tu empresa está aceptando instrucciones de pago de clientes a través del canal que elijas. Puede ser transferencia de archivos, API, Swift FileAct, etc. El factor clave es que, no hace mucho, actualizaste el formato de instrucción de pago del cliente a ISO 20022, basado en un pain.001.001.03 ( iniciación depago). Esa versión, de 2009, existe desde hace muchos años, es compatible con la mayoría de los sistemas ERP/TMS y es compatible con CGI-MP. El formato de tu interfaz está actualizado, con capacidad para mensajes ISO 20022 flexibles y ricos en datos, y todos tus clientes se han integrado. Todo va bien.
Ahora llega la versión de 2019, la pain.001.001.09. Si envías mensajes de pago a determinados esquemas, como la Transferencia de Crédito SEPA, según el reglamento de 2023, necesitarás (en algún momento) actualizarte a la pain.001.001.09. La mensajería interbancaria está alineada en torno a 2019 (por ejemplo, pacs.008.001.08) y, para una interoperabilidad de datos sin fisuras, otros grupos y prácticas se alinearán ahora: CGI-MP está pasando a esta versión y ha publicado sus UG (ver CGI-MP en MyStandards).
Como el interbancario está migrando a ISO 20022 para apoyar los pagos transfronterizos y los negocios de gestión de efectivo a partir de marzo de 2023, también se actualizan las versiones y directrices de los mensajes CGI-MP [to 2019] para alinearlas con el uso interbancario.
- Manual del usuario CGI-MP WG1 – Actualización Feb 2023
Aunque puede que las normas de tu régimen o práctica dicten este cambio, ¿tienen tus clientes necesidades que se satisfarán con la actualización? Cambiar el formato de la interfaz de un cliente y los datos que puede tener que proporcionar suele ser perturbador, no es algo que quieras hacer a menudo o sin un calendario de actualización detallado, pruebas y un plan de comunicación con el cliente. En el caso de la actualización a 2019, en muchos casos de uso el beneficio para el cliente puede no ser inmediato u obvio, sino que se trata de una actualización de base, con el potencial de beneficios futuros, como la remesa electrónica o las capacidades de alias. Entonces, ¿necesitas actualizar el formato de pago de tus clientes a 2019, cuáles son las consideraciones clave y cuáles son algunos de los retos e impactos?
Enfoque de actualización
A diferencia de algunas de las versiones anteriores de mensajes ISO 20022, 2009 a 2019 es en gran medida compatible con versiones anteriores, ciertamente para el pain.001. Si contemplas tu propia actualización, una opción práctica sería seguir el enfoque de coexistencia probada, mediante un plan de actualización en 2 fases:
- Traducción provisional: Mantén un formato de cara al cliente basado en pain.001.001.03 y asigna los pagos internamente a 2019 (pain.001.001.09 o pacs.008.001.08 etc) antes de enviarlos.
- Nativo a largo plazo: En paralelo y a lo largo del tiempo, construye el formato de cara al cliente pain.001.001.09 y migra a los clientes cuando estén listos.
La versión 2019 está diseñada para admitir datos mejorados. Es el origen y el uso de estos datos lo que requiere una planificación cuidadosa para garantizar que puedan incluirse en el flujo lo antes posible. Una migración por fases se basa en comprender las diferencias de los datos mejorados y si tú o tus clientes os beneficiaréis de estos datos, dónde se originarán los datos y cómo incorporarlos a tu plan de actualización y a tu hoja de ruta de productos. Generalmente:
- Si los datos mejorados son originados por tu cliente, como un departamento de cuentas a pagar de una empresa o un proveedor de servicios de pago intermediario, el enfoque de traducción provisional seguirá limitando la aceptación de estos datos, por ejemplo, no hay campo de IPJ en un pain.001.001.03, por lo que si son originados por tu cliente, no se pueden recibir. Se necesitarán otros medios para aceptar los datos.
- Alternativamente, si se pueden derivar datos mejorados, como buscar el IPJ o la dirección estructurada a partir de los datos de referencia del cliente, funcionará el enfoque de traducción intermedia. Puedes derivar los datos mejorados e insertarlos en el pain.001.001.09 posterior, suponiendo, por supuesto, que tus datos de referencia maestros ya se hayan actualizado para admitirlo. Implícitamente, la actualización de los datos de referencia es probablemente un requisito previo de cualquier plan de actualización y puede que sea el flujo de trabajo más complejo y que más tiempo consuma.
Diferencias clave
La versión 2019 introduce cambios en varios elementos de datos existentes y, lo que es más importante, varios elementos nuevos. Las siguientes imágenes, con pain.001.001.03 a la izquierda y pain.001.001.09 a la derecha, ilustran las principales diferencias de alto nivel en la especificación base.
Datos complementarios
Se ha añadido un elemento de datos suplementario al nivel de Iniciación de la Transferencia de Crédito del Cliente y a cada pago (nivel de Información de la Transacción de Transferencia de Crédito). Las directrices de uso (UG) son reglas diseñadas para restringir el uso a partir de la especificación base. Especifican un subconjunto de los datos base disponibles y, en determinados casos, las reglas empresariales (reglas de campos cruzados) que deben respetarse. Por el contrario, los datos suplementarios están diseñados para ampliar el mensaje más allá de la especificación base. Los datos suplementarios no se utilizan mucho en el ámbito de los pagos y están fuera del alcance de este artículo. Es poco probable que afecten a tu actualización y pueden ignorarse. Para obtener más información sobre los datos suplementarios y ver uno de los pocos usos, ve a la UG SCRIPS para camt.050.
Cabecera de grupo
Los únicos cambios significativos en la Cabecera de grupo son los relacionados con la dirección postal, la identificación de la organización y los datos de contacto de las partes o agentes. Estos 3 elementos tienen nuevos campos para admitir datos mejorados y se tratarán más adelante en este artículo, ya que son elementos reutilizables y se aplican a todas las partes y agentes del mensaje.
Información sobre el pago
En el lado del deudor, elemento de información de pago, hay una serie de cambios sutiles, algunos de los cuales son:
- Nivel de servicio. El nivel de servicio ahora puede tener múltiples ocurrencias en lugar de la única ocurrencia permitida en el pain.001.001.03. Esto permite a un cliente especificar cuál de las reglas disponibles debe aplicarse al pago, concretamente puede utilizarse para seleccionar una gama más amplia de opciones de productos de pago, pero es más una mejora futura, una vez que esas ofertas de productos estén disponibles, que algo que repercuta en cualquier migración.
- Fecha de ejecución solicitada. Esto cambia de ser sólo una ISODate a una ISODate o una ISODateTime. Esta característica se alinea con las crecientes capacidades de pagos y liquidez en tiempo real en todo el mundo, donde una fecha de ejecución futura puede ser ahora una hora exacta. Para la mayoría de los casos de uso, no habrá impacto en el cliente y puede permanecer sin cambios como una ISODate en la fase provisional. Internamente, para la solución provisional, será necesaria una reasignación a ../ReqdExctnDt/Dt.
- Apoderado. El elemento actualizado CashAccount38 tiene un elemento Proxy, para dar cabida a un identificador alias/proxy como nombre supuesto alternativo para la cuenta. Se trata de un componente reutilizable, por lo que aparece en todas las instancias de una cuenta, no sólo en la deudora. El uso de alias para enviar pagos está creciendo rápidamente, sobre todo en las transacciones entre iguales. El UPI de India y el PIX de Brasil son ejemplos de actualidad, y la SEPA está planeando su propia capacidad de alias. Si el proxy es algo necesario como parte de la fase de actualización provisional, deberías considerar la posibilidad de actualizar tu fuente de datos de referencia para derivar nombres de alias y sortear la ausencia de esto en el pain.001.001.03.
Información sobre la Transferencia de Crédito
Los cambios clave en el elemento de pago incluyen:
- UETR. La Referencia Única de Transacción de Fin a Fin es una nueva incorporación. Esto refleja la inclusión de la UETR en la versión de las normas Swift MT de 2021 (es decir, MT 103 Bloque 3 Campo 121). El UETR es un identificador importante en la cadena de pago y muchas infraestructuras de mercado y servicios de mensajería exigen su uso (Swift CBPR+, SCRIPS). Tanto para una solución provisional como a largo plazo, puede generarse y rellenarse en el pain.001.001.09 si es necesario. Su generación por parte del deudor o deudor final, como una empresa, aún no es una práctica habitual, dado que el EndToEndId suele satisfacer sus necesidades (consulta un artículo anterior sobre EndToEndId para obtener más detalles al respecto) y el seguimiento Swift gpi, si se utiliza, puede presentarse desde el punto en que el agente deudor procesa el pago. Si una empresa Swift requiere un seguimiento gpi completo, generará el UETR y necesitará que exista la solución a largo plazo para poder pasar en el pain.001.001.09.
- Dirección postal. Uno de los cambios más significativos es la mejora de la dirección postal. Esto se aplica a todas las apariciones, ya sean de una parte (como el Deudor final en la imagen de abajo) o de un agente. El elemento complejo PostalAddress24 tiene 6 campos adicionales, lo que permite una dirección estructurada más granular, para anular en última instancia el uso de campos de Línea de dirección no estructurados. Algunas UG de esquema ya restringen o prohíben el uso de los campos no estructurados Address Line. En la fase intermedia, es importante iniciar el camino hacia direcciones totalmente estructuradas: lo mínimo debería ser configurar el uso por parte de tus clientes del dolor.001.001.03, asegurarte de que se rellenan el nombre de la ciudad y el país, y evitar el uso de líneas de dirección. Consulta este artículoanterior sobredirecciones estructuradas para obtener más información.
- Identificador de Personas Jurídicas (LEI) y BIC. La versión de 2019 añade el IPJ al modelo de datos. El IPJ es un identificador único para una organización. No se aplica a los particulares, por lo que se encuentra en el elemento complejo OrganisationIdentification29. Puedes encontrar más información sobre los IPJ en las preguntas y respuestas de la Fundación Global del IPJ (GLEIF). La GLEIF también dispone de un conjunto de puntos finales de API que admiten funciones como la búsqueda y consulta de IPJ. Por último, cabe destacar el sutil cambio del BICOrBEI al AnyBIC. Consulta las expresiones regulares que aparecen a continuación para conocer las diferencias que deben incorporarse a cualquier lógica de validación.
2019 Formato AnyBIC:
<xs:pattern value="[A-Z0-9]{4,4}[A-Z]{2,2}[A-Z0-9]{2,2}([A-Z0-9]{3,3}){0,1}"/>
2009 Formato BICOrBEI:
<xs:pattern value="[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}"/>
- Información estructurada sobre remesas. La repetición del elemento complejo Información estructurada sobre remesas no es nueva. Ofrece la promesa de una mejora significativa, sobre todo en los casos de uso B2B, y ya lo he tratado en un artículo anterior. La versión anterior ofrecía un rico conjunto de datos y, aunque es importante, en igual medida, no ha sido admitida por los esquemas interbancarios. La nueva versión (StructuredRemittanceInformation16) incluye varios campos de datos nuevos, el más importante de los cuales es el elemento complejo repetido Detalles de línea (DocumentLineInformation1). Esto permite una granularidad completa de cada pago, como se muestra en la imagen de jerarquía de datos de 3 niveles que aparece a continuación: pago -> documento relacionado (por ejemplo, factura) -> detalles de línea. Para tu actualización, a menos que tus casos de uso requieran detalles de línea, es probable que los campos de datos existentes satisfagan las necesidades de tus clientes y la atención debe seguir centrada en la expansión de los esquemas interbancarios que admiten información estructurada sobre remesas.
Directrices de uso y prácticas de mercado
Este artículo se ha centrado en los cambios de la especificación base más que en los cambios de las reglas de negocio (directrices de uso) para los grupos de prácticas de mercado o esquemas. Son éstos los que requerirán un análisis detallado y recursos de actualización, por ejemplo, CGI-MP establece el uso empresarial detallado de los datos de información reglamentaria, como el indicador de información reglamentaria aplicado a la parte DEBT o CRDT, el uso de códigos de finalidad de pago (ver conjuntos de códigos externos) en RgltryRptg no Purp, el uso del NIF (TXID) de la parte en Othr/Id, etc.
En cuanto a la Información Estructurada sobre Remesas, el avance más importante no es la adición de los campos mencionados anteriormente, sino el creciente apoyo a la aceptación de estos datos por parte de los sistemas interbancarios. Este soporte, sin embargo, sigue siendo variado. Swift CBPR+ admite hasta 9.000 caracteres (excluidas las etiquetas), Lynx de Payments Canada sigue este planteamiento, mientras que el esquema AFT admite hasta 100.000 ocurrencias de StructuredRemittanceInformation16, Nordic Payments Council admite 999 ocurrencias. Mientras tanto, la SEPA también admite hasta 999 ocurrencias, pero sólo a través de un Servicio Opcional Adicional (AOS) que tiene una participación limitada. La ampliación continuada del apoyo a la información estructurada sobre remesas (y hacerla obligatoria para los participantes) sigue siendo una gran prioridad.
Resumen
La actualización de 2009 a 2019 es una preparación para el uso de datos mejorados y para aprovechar las ventajas que ello aportará. La compatibilidad retrospectiva y un enfoque de coexistencia (2 fases) permiten que la actualización minimice el impacto en las interfaces de los clientes, pero las principales ventajas sólo se conseguirán una vez que los elementos de datos mejorados nativos de 2019 estén implantados y se utilicen (y estén respaldados por las FMI y las reglas del sistema).
Notas:
- Este artículo se refiere a las especificaciones del mensaje base, no a ninguna directriz de uso (UG) específica adoptada por un esquema o grupo concreto.
- Se centra sólo en el pain.001, agnóstico del uso del relé, e ignora otros mensajes, como pain.002.001.10. Esto es intencionadamente simplista; ponte en contacto conmigo si necesitas asesoramiento sobre el estado u otros mensajes/flujos.
- ISO 20022 es agnóstica en cuanto a sintaxis. Puede que haga referencia a xml y xsd, pero sólo a modo de ejemplo y para ilustrar el modelo de datos. Otras sintaxis, como JSON, son igualmente válidas.
Direcciones estructuradas ISO 20022
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.