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:

1. 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.
2. 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:

1. 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.
2. 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.
3. 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.