Documentation for a newer release is available. View Latest

Concepts

Los pagos/transacciones son procesados por IPF Processing Nodes. Los IPF Processing Nodes mantienen en memoria los datos de los pagos/transacciones que se están procesando. Los datos que se reciben/generan como parte de los diferentes eventos se almacenan de forma persistente como IPF Processing Events en el IPF Event Store (siguiendo el patrón Event Sourcing/CQRS). En caso de que un IPF Processing Node falle (p. ej., por problemas de infraestructura), otro IPF Processing Node del clúster reanudará el procesamiento de las transacciones en curso. Leyendo los processing events persistidos, este IPF Processing Node de failover puede regenerar el estado y los datos relevantes que se requieren para continuar el proceso en el punto en que estaba el IPF Processing Node original cuando falló.
Durante el procesamiento, los transaction processing events se consumen y procesan para mantener un Operational Data Store eventualmente consistente (normalmente dentro de unos pocos segundos) a través del componente Event Handler. IPF ODS viene con APIs mediante las cuales la IPF UI, así como otras aplicaciones (no IPF), pueden acceder (buscar y ver) los datos almacenados en el ODS.
Además de los datos a nivel de pago/transacción, IPF ODS también almacena datos de pagos a un nivel agregado para alimentar dashboards de monitorización de procesos (de negocio) como parte de IPF Operational GUI u otras aplicaciones externas.
Para el cumplimiento de retención de datos, es posible replicar datos desde el IPF Operational Data Store a un Archive. Este archivo puede aprovechar el precio de almacenamiento más eficiente (MongoDB Atlas, por ejemplo, ofrece 3 niveles basados en la frecuencia de acceso o los compromisos de latencia).
El componente Event Handler también puede publicar un stream de los mismos datos, o de datos procesados, a un sistema bancario downstream a través de un broker como Kafka, donde los datos pueden utilizarse para analítica, informes, monitorización y otros propósitos.

Complejidad de un modelo de datos de pagos basado en ISO 20022

Un modelo de datos de pagos basado en ISO 20022 es un modelo que puede soportar las estructuras de datos de los mensajes usados para el procesamiento de pagos, como pain.001, pain.002, pain.007, pain.008, pacs.008, pacs.002, pacs.004, pacs.003, pacs.007, pacs.028, camt.027, camt.055, camt.056, pero también mensajes de request to pay como pain.013 y pain.014. Además, la mayoría de los mensajes ISO 20022 contienen una jerarquía de objetos de datos, a veces múltiples jerarquías. Un ejemplo de mensaje con múltiples jerarquías es pain.001. El nivel más alto es un Instruction Group (GrpHdr) que puede contener una o más Credit Transfer Instructions (PmtInf) y cada Credit Transfer Instruction puede contener una o más Credit Transfer Transactions (CrdtTrfTxInf).

Múltiples Credit Transfer Transactions de diferentes Credit Transfer instructions (de distintos clientes originadores) pueden agruparse en un único mensaje pacs.008 que se envía a un CSM (a menudo un ACH). El CSM, a su vez, puede devolver un pacs.002 con actualizaciones de estado para las transferencias de crédito que ha recibido vía los mensajes pacs.008. Estas actualizaciones de estado pueden ser a nivel de grupo de un pacs.008 así como a nivel de transacción individual. También es posible que para una transferencia de crédito que ha sido procesada y liquidada se emita una solicitud de cancelación. Para monitorizar un pago (transferencia de crédito así como adeudo directo) a lo largo de su ciclo de vida de extremo a extremo, es importante que los datos que se intercambian a través de los diferentes mensajes basados en ISO 20022 (o los equivalentes no ISO 20022) puedan asociarse/vincularse entre sí. También debe ser posible ampliar la solución con mensajes adicionales, como para request to pay (pain.013 y pain.014), y vincularlos con la payment instruction (pain.001) que se ha generado durante el procesamiento de solicitudes de request to pay.

El siguiente diagrama muestra un subconjunto de los mensajes que son relevantes en el procesamiento de pagos, la jerarquía de elementos de datos dentro de estos mensajes y las asociaciones que tienen entre sí.

Como este ejemplo es solo un subconjunto de los mensajes ISO 20022 relacionados con pagos, no cubre las R-transactions (camt.056, pacs.004, etc.) u otros tipos de pago como adeudos directos. Incluso en este alcance limitado, un modelo de datos en el que cada nivel en un mensaje se almacena como una entidad de datos separada (tabla/colección) ya se convierte en un modelo complejo que es difícil de mantener y ampliar. Por lo tanto, es esencial utilizar un modelo de datos que sea genérico y ofrezca la posibilidad de añadir nuevos mensajes/objetos de datos y vincularlos con otros mensajes/objetos de datos con el mínimo impacto (cambios/extensiones) en el modelo de datos subyacente.

Modelo de datos lógico para ODS

Puntos de partida clave para definir el modelo de datos:

El modelo de datos debe ser lo más simple posible en su configuración y uso
El modelo de datos debe ser extensible en términos de mensajes y tipos de objetos de mensajes con el mínimo cambio/impacto en el modelo de datos existente (como nuevas tablas/colecciones)
Debe ser capaz de mantener y acceder a los siguientes datos:
- mensajes (en formato ISO 20022 (XML/JSON)) recibidos de la parte/sistema que origina el pago (p. ej., canal de cliente o gateway CSM) y usados como entrada para el procesamiento
- datos generados durante el procesamiento, como IBAN o BIC enriquecido, CSM agent seleccionado o execution date calculada
- mensajes (en formato ISO 20022 (XML/JSON)) generados durante el procesamiento y enviados a partes/sistemas externos
- acciones de procesamiento ejecutadas durante el procesamiento de un mensaje o parte de un mensaje
- mensajes de entrada y salida en formato no ISO 20022 (cuando aplique)
- estado de procesamiento de un mensaje o parte de un mensaje (instrucción, transacción, R-transaction, etc.) con un estado in-process así como un estado de ciclo de vida
- asociaciones/relaciones entre mensajes o partes de mensajes para una vista de extremo a extremo del ciclo de vida de un pago/transacción
Debe ser posible buscar datos en el ODS en base a un conjunto predefinido de atributos de búsqueda
Debe ser posible, como parte de una implementación, añadir atributos de búsqueda adicionales (específicos de la implementación) y usarlos en las APIs (estándar) que vienen con el producto IPF
Debe ser posible configurar, para cada evento de procesamiento, cómo se almacena en el ODS (como un nuevo objeto de datos de mensaje o como un evento que se vincula a un objeto existente, etc.). Esta configuración es necesaria ya que se pueden añadir pasos de procesamiento (eventos) a los process flows, y es necesario poder definir cómo se almacenan los datos de este evento en el ODS.

A continuación se ofrece una descripción de las diferentes entidades de datos y relaciones entre ellas en este modelo de datos lógico:

Message Object representa datos relacionados con pagos que son entrada para y/o generados durante el procesamiento de pagos dentro de IPF. Un Message Object es una parte de un mensaje ISO 20022 sobre la base del cual se realiza el procesamiento (mediante un process flow específico) en IPF. El Message Object es una representación abstracta de una parte de un mensaje ISO 20022. Los datos relevantes en sí se representan por la entidad de datos Message Object del modelo. Cada Message Object tiene un atributo Object Type que consiste en el tipo de mensaje ISO 20022 (p. ej., pain.001) y el nombre del elemento de datos en el mensaje ISO 20022 al que se refiere el Message Object en cuestión. La lista de tipos de Message Object figura más abajo.
Message Object Data representa los datos que son entrada para y generados por el process flow en IPF durante el procesamiento del Message Object en cuestión. Como estos datos se reciben a través de eventos de procesamiento múltiples y separados que se manejan individualmente y posteriormente se añaden al ODS, los datos relevantes de cada evento de procesamiento se almacenan en un registro Message Object Data separado (de ahí la relación 1-a-muchos con la entidad de datos Message Object). De esta manera, los datos pueden almacenarse en el ODS sobre la base de un principio de solo anexado, sin actualizar datos que ya están almacenados. Cuando se consultan los datos para un MDS Object específico (a través de las APIs del ODS), la API devuelve un resultado que consiste en los datos combinados de todos los registros de MDS Object Data del MDS Object en cuestión.
Message Object Relationship se utiliza para relacionar dos Message Objects entre sí. Esto puede ser una relación de objetos del mismo mensaje (p. ej., el objeto pain001.CdtTrfTxInf que es hijo de un objeto pain001.PmtInf), pero también puede ser la relación entre dos objetos de diferentes mensajes (p. ej., objeto pain001.CdtTrfTxInf y un objeto pacs008.CdtTrfTxInf). Esta configuración permite relacionar cualquier Message Object con cualquier Message Object (y añadir nuevas relaciones) sin dependencia del modelo de datos ni necesidad de cambiarlo.
Message Object Processing Event se refiere a los eventos que realizan los process flows de IPF para el Message Object en cuestión.
Message Object Status se refiere al estado de un Message Object. Es posible registrar múltiples tipos de estados para un MDS Object, así como múltiples estados del mismo tipo para un MDS Object. Por ejemplo, es posible distinguir entre 'processStatus' y 'lifecycleStatus' como tipos de estado. El primero es el estado de un Message Object dentro de la ejecución de un proceso; el segundo, el estado a través de todos los procesos. El último estado añadido es también el estado actual para ese Message Object.
Exchange Message se refiere a mensajes entrantes y salientes que se intercambian con sistemas externos (no IPF) (canales de clientes, gateways CSM) y son entrada para o generados por los process flows de IPF. Un Exchange Message tiene un indicador de dirección (inbound o outbound), el tipo de mensaje (pain.001, pacs.008, …), un indicador de versión y la aplicación de la que se recibe (inbound) o a la que se envía (outbound).
Message Object Message Relation se refiere a la relación de un Message Object con Exchange Messages. Un Message Object puede estar relacionado con múltiples mensajes entrantes y salientes, y un mensaje puede relacionarse con múltiples Message Objects.
Message Object Index se refiere al índice/tabla/colección que se utiliza para buscar Message Objects de un cierto tipo sobre la base de criterios específicos. Cada tipo de objeto tiene criterios de búsqueda específicos; cada tipo de Message Object tiene también su propio índice.

Tipos de Message Object

La siguiente tabla enumera un subconjunto de los tipos de Message Object que deben ser soportados en el ODS. La lista se basa en el esquema SCT Inst con el rulebook asociado y las message implementation guidelines (IGs).

ISO 20022 message Data element(s) in message Message Object Type in ODS Description

ISO 20022 message	Data element(s) in message	Message Object Type in ODS	Description
pain.001	`GrpHdr`	`pain001.GrpHdr`	El mensaje pain.001 es utilizado por los originadores del pago (el deudor o una parte en nombre del deudor) hacia el banco del deudor (directamente o mediante un forwarding agent). Un mensaje `pain001` contiene siempre un (y solo un) objeto `GrpHdr`. El objeto `GrpHdr` contiene datos relacionados con el mensaje como identificador (de mensaje) único, fecha de creación y remitente y receptor del mensaje.
pain.001	`PmtInf`	`pain001.PmtInf`	El objeto `PmtInf` representa una instrucción de pago de cliente individual. Un mensaje pain.001 (representado por el objeto `GrpHdr`) puede contener una o más instrucciones de pago (objetos `PmtInf`). Cada instrucción de pago representa el lado de débito de uno o más pagos.
pain.001	`CdtTrfTxInf`	`pain001.CdtTrfTxInf`	El objeto `CdtTrfTxInf` representa el lado de crédito de una instrucción de pago (`PmtInf`), también denominado credit transfer transaction. Una instrucción puede contener una o más credit transfer transactions.
pain.002	`GrpHdr.OrgnlGrpInfAndSts`	`pain002.GrpHdr`	El mensaje pain.002 es utilizado por el banco del deudor para informar al originador del pain.001 sobre el/los estado(s) de: el pain.001 completo, una o más instrucciones de pago del pain.001 o una o más credit transfer transactions de una o más instrucciones. Cada mensaje pain.002 contiene siempre un objeto GrpHdr que identifica el mensaje y el remitente y destinatario del mensaje. Como un mensaje pain.002 contiene un (y solo un) elemento de datos `OrgnlGrpInfAndSts`, este elemento también forma parte de este objeto de mensaje y no uno separado.
pain.002	`OrgnlPmtInfAndSts`	`pain002.OrgnlPmtInfAndSts`	El objeto `OrgnlPmtInfAndSts` representa la actualización de estado de una instrucción de pago individual. En el caso de un pago instantáneo, este objeto puede tener una o más ocurrencias en un pain.002. Esto último solo aplica si el pain.001 original tiene más de una instrucción de pago.
pain.002	`TxInfAndSts`	`pain002.TxInfAndSts`	El objeto `TxInfAndSts` representa la actualización de estado de una transacción individual en una instrucción. En el caso de un pago instantáneo, un `OrgnlPmtInfAndSts` puede tener ninguna o muchas ocurrencias de `TxInfAndSts`. Esto último solo aplica si el `PmtInf` original tiene más de un `CdtTrfTxInf`.
pacs.008	`GrpHdr`	`pacs008.GrpHdr`	El mensaje pacs.008 es utilizado por el banco del deudor para enviar una transferencia de crédito al banco del acreedor, directamente o a través de un CSM. Un pacs.008 tiene siempre un (y solo un) objeto `GrpHdr`. El objeto `GrpHdr` contiene datos relacionados con el mensaje, como identificador de mensaje único, fecha de creación, remitente y receptor del mensaje, datos de compensación y liquidación, etc.
pacs.008	`CdtTrfTxInf`	`pacs008.CdtTrfTxInf`	El objeto `CdtTrfTxInf` representa los datos de una transferencia de crédito individual. Incluye un identificador de transacción único del agente emisor (deudor). Este no es el identificador de la transacción según lo proporcionado por el originador del pago en el pain.001. Es un nuevo identificador generado por el agente deudor (esto es `PmtId/TxId` o `PmtId/EUTR`. En SCT Inst debe ser `PmtId/TxId`). El ODS necesita mantener la correlación entre el objeto `CdtTrfTxInf` en el pain.001 y el objeto `CdtTrfTxInf` asociado en el pacs.008 (solo aplicable para pacs.008 saliente). El identificador `End2End` que el originador del pago ha colocado en el `CdtTrfTxInf` en el pain.001 no puede usarse ya que no hay garantía de que sea único entre todas las transacciones. En SCT Inst, un único pacs.008 (o mejor dicho, el objeto `GrpHdr`) solo puede contener un `CdtTrfTxInf`. En la mayoría de los esquemas de pago no instantáneo, un pacs.008 puede contener más de un `CdtTrfTxInf`.
pacs.002	`GrpHdr`	`pacs002.GrpHdr`	El mensaje pacs.002 es utilizado por las instituciones financieras y los CSMs para informar a otras partes (como el agente deudor y el agente acreedor) sobre el estado de uno o más pacs.008 y/o una o más transacciones en un mensaje pacs.008 que se ha intercambiado entre las partes en cuestión. Cada mensaje pacs.002 tiene un (y solo un) objeto `GrpHdr`. Contiene datos como identificadores de mensaje así como parte remitente y parte receptora.
pacs.002	`OrgnlGrpInfAndSts`	`pacs002.OrgnlGrpInfAndSts`	El `OrgnlGrpInfAndSts` a nivel de mensaje pacs.008 (representado por el objeto `GrpGdr` del pacs.008). Un pacs.002 puede referirse a más de un mensaje pacs.008. Este objeto puede incluir la actualización de estado de un mensaje pacs.008 completo (y el `GrpHdr` asociado), por ejemplo cuando el mensaje pacs.008 completo ha sido rechazado debido a un identificador de mensaje duplicado. En el caso de SCT Instant, las Implementation Guidelines (IG) definen que un pacs.002 solo puede tener una ocurrencia de `OrgnlGrpInfAndSts`, lo que significa que un pacs.002 puede referirse solo a un pacs.008. El objeto `OrgnlGrpInfAndSts` contiene datos como una referencia al identificador de mensaje original (que es el message identifier del `GrpHdr` del pacs.008).
pacs.002	`TxInfAndSts`	`pacs002.TxInfAndSts`	El objeto `TxInfAndSts` representa la actualización de estado de una transacción individual (`CdtTrfTxInf`) de un pacs.008. Un pacs.002 (representado por el objeto `GrpHdr`) puede tener múltiples objetos `TxInfAndSts`. En el caso de SCT Instant, el número de ocurrencias de un objeto `TxInfAndSts` en un pacs.002 está restringido a una. El objeto `TxInfAndSts` contiene elementos de datos que hacen referencia al instruction ID (si se especifica) y al transaction id según lo especificado en el objeto `CdtTrfTxInf` del pacs.008.
camt.056	`Assgnmt` `Case` `CtrlData`	`camt056.GrpHdr`	El mensaje camt.056 es utilizado por el agente deudor para solicitar al agente acreedor la cancelación/recuperación de un pago, independientemente de si el pago ya se ha liquidado entre los bancos o no. `GrpHdr` no es un objeto en el propio mensaje, pero se utiliza para agrupar varios objetos de datos que aparecen en el mensaje camt.056 en el nivel más alto con ocurrencia de cero o (máximo) uno, siendo: `Assgnmt` `Case` `CtrlData` La razón para introducir este objeto `GrpHdr` para el camt.056 es ser lo más consistente posible en el ODS a través de los diferentes tipos de mensajes.
camt.056	`Undrlyg`	`camt056.Undrlyg`	El objeto Undrlyg (UnderlyingTransaction) contiene datos relacionados con la cancelación. Es posible cancelar un grupo completo (solo uno por mensaje) o una o más transacciones individuales. Un único mensaje camt.056 puede contener múltiples objetos Undrlyg, y cada Undrlyg puede a su vez contener múltiples elementos PaymentTransaction. Para SCT, la implementación actual solo admite la cancelación de una UnderlyingTransaction.
camt.056	`TxInf`	`camt056.TxInf`	El objeto TxInf representa una transacción individual a cancelar/recuperar. El objeto `TxInf` contiene elementos de datos que hacen referencia al identificador de mensaje original, instruction ID (si se especifica) y transaction id según lo especificado en el pacs.008 original. Un objeto `UndrLyg` puede contener múltiples objetos `TxInf`, también en el caso de SCT Inst.
pacs.004	`GrpHdr`	`pacs004.GrpHdr`	El mensaje pacs.004 es utilizado por el agente acreedor para informar al agente deudor que la solicitud de cancelación ha sido aceptada y que los fondos se devuelven al agente deudor. El objeto `GrpHdr` contiene elementos de datos como message ID, fecha de creación, información del remitente y receptor y settlement info. Un mensaje camt.056 tiene un y solo un objeto `GrpHdr`. El tipo de objeto también incluye el elemento de datos `OrgnlGrpInf`, ya que la ocurrencia en un pacs.004 es ninguna o una y, por lo tanto, no hay valor añadido en considerarlo como un objeto de mensaje separado.
pacs.004	`TxInf`	`pacs004.TxInf`	El objeto `TxInf` se refiere a la transferencia de crédito individual que se devuelve. Los elementos de datos que hacen referencia al GrpHdr original del mensaje pacs.008 pueden especificarse en el objeto `OrgnlGrpInf` así como en el objeto `TxInf` del mensaje pacs.004. El transaction id original debe especificarse en el objeto `TxInf`. Un mensaje pacs.004 puede contener uno o más objetos `TxInf`, también en el caso de SCT Inst.
`camt.029`	`Assgnmt` `RslvdCase` `Sts`	`camt029.GrpHdr`	En SCT Inst el camt.029 es utilizado por el agente acreedor para informar al agente deudor de que la solicitud de cancelación ha sido rechazada (y los fondos no se devuelven). El mensaje se utiliza como respuesta a un camt.056 (solicitud de cancelación) o a un pacs.028 (solicitud de actualización de estado) que envía el banco deudor para solicitar el estado de un camt.056 previamente enviado para el cual aún no se ha recibido respuesta (pacs.004 o camt.029). `GrpHdr` no es un objeto en el mensaje camt.029 en sí, pero se utiliza en el ODS para agrupar varios objetos de datos que aparecen en el mensaje camt.029 en el nivel más alto con ocurrencia de cero o (máximo) uno, siendo: `Assgnmt` `RslvdCase` `Sts` La razón para introducir este objeto `GrpHdr` para el camt.029 es ser lo más consistente posible en el ODS a través de los diferentes tipos de mensajes.
camt.029	`CxlDtls`	`camt029.CxlDtls`	El objeto `CxlDtls` contiene la actualización de estado de una solicitud de cancelación/recuperación que se ha recibido. Un camt.029 puede contener uno o más objetos `CxLDtls`, también en el caso de SCT Inst. Un objeto `CxlDtls` puede referirse a una o más transacciones. Si se ha enviado una solicitud de cancelación/recuperación para un mensaje pacs.008 completo (representado por el objeto `GrpHdr`), la información del grupo original forma parte de este objeto. En SCT Inst no es posible cancelar un grupo completo y, por lo tanto, esta situación no aplica para SCT Inst.
camt.029	`OrgnlPmtInfAndSts`	`camt029.OrgnlPmtInfAndSts`	El objeto `OrgnlPmtInfAndSts` se refiere a una transacción individual para la que se ha recibido una cancelación/recuperación. El objeto `OrgnlPmtInfAndSts` contiene referencias a la solicitud de cancelación/recuperación original, como message ID original, group ID, instruction ID y transaction ID. Además, contiene datos sobre el estado de la cancelación y los reason codes del rechazo de la solicitud de cancelación/recuperación.
pacs.028	`GrpHdr`	`pacs028.GrpHdr`	El mensaje pacs.028 es utilizado por el agente deudor en dos casos: a. para consultar al agente acreedor sobre el estado de una credit transfer transaction (un pacs.008) que se ha enviado al acreedor y para la cual no se ha recibido respuesta. b. para solicitar la respuesta a una solicitud de cancelación/recuperación (camt.056) enviada previamente cuando no se ha recibido respuesta del agente acreedor. En este caso, el mensaje de respuesta es un pacs.004 (cancelación/recuperación aceptada) o un camt.029 (cancelación/recuperación rechazada). Debido a que se trata de dos casos de uso diferentes, las implementaciones y el uso de los elementos de datos serán diferentes entre estos casos. El objeto `GrpHdr` contiene datos con respecto al mensaje (pacs.028), como message ID, creation datetime, remitente, receptor, etc. Un pacs.028 puede usarse para solicitar el estado de un mensaje pacs.008 completo (haciendo referencia al message ID tal como se especifica en el pacs.008 original o en el mensaje camt.056) o de una transacción individual. En el primer caso, el pacs.028 tiene uno o más objetos `OrgnlGrpInf` (en el caso de SCT Inst restringido a una ocurrencia); en el segundo caso, el pacs.028 tiene uno o más objetos `TxInf`.
pacs.028	`OrgnlGrpInf`	`pacs028.OrgnlGrpInf`	El objeto `OrgnlGrpInf` se refiere a un grupo original (en pacs.008) para el que se solicita la actualización de estado a través del message ID del `GrpHdr` del pacs.008 original. Como el camt.056 no incluye un objeto `GrpHdr`, el `OrgnlGrpInf` no contiene una referencia al message ID original, sino solo al Original Message Name Identifier (`OrgnlMsgNmId`).
pacs.028	`TxInf`	`pacs028.TxInf`	El objeto `TxInf` se refiere a una o más credit transfer instructions individuales (caso de uso 1) o a instrucciones de cancelación/recuperación (caso de uso 2). Para SCT Inst, un mensaje pacs.028 contiene uno (y solo uno) objeto `TxInf`. En el caso del caso de uso 1, el elemento de datos `TxInf/OrgnlInstrId` en el pacs.028 se refiere al elemento de datos `CdtTrfTxInf/PmtId/TxId` (transaction ID) en el pacs.008. En el caso del segundo, el elemento de datos `TxInf/OrgnlInstrId` en el pacs.028 se refiere al elemento de datos `Undrlyg/TxInf/CxlId` (cancellation ID) en el camt.056.
all	`SplmtryData`	`nnnnnnnn.SplmtryData`	El objeto `SplmtryData` puede aparecer en los mensajes enumerados anteriormente. Contiene datos que no son relevantes para el procesamiento de pagos, pero que deben incluirse cuando la transacción se reenvía a otras partes.

pain.001

GrpHdr

pain001.GrpHdr

El mensaje pain.001 es utilizado por los originadores del pago (el deudor o una parte en nombre del deudor) hacia el banco del deudor (directamente o mediante un forwarding agent). Un mensaje pain001 contiene siempre un (y solo un) objeto GrpHdr. El objeto GrpHdr contiene datos relacionados con el mensaje como identificador (de mensaje) único, fecha de creación y remitente y receptor del mensaje.

pain.001

PmtInf

pain001.PmtInf

El objeto PmtInf representa una instrucción de pago de cliente individual. Un mensaje pain.001 (representado por el objeto GrpHdr) puede contener una o más instrucciones de pago (objetos PmtInf). Cada instrucción de pago representa el lado de débito de uno o más pagos.

pain.001

CdtTrfTxInf

pain001.CdtTrfTxInf

El objeto CdtTrfTxInf representa el lado de crédito de una instrucción de pago (PmtInf), también denominado credit transfer transaction. Una instrucción puede contener una o más credit transfer transactions.

pain.002

GrpHdr.OrgnlGrpInfAndSts

pain002.GrpHdr

El mensaje pain.002 es utilizado por el banco del deudor para informar al originador del pain.001 sobre el/los estado(s) de: el pain.001 completo, una o más instrucciones de pago del pain.001 o una o más credit transfer transactions de una o más instrucciones.

Cada mensaje pain.002 contiene siempre un objeto GrpHdr que identifica el mensaje y el remitente y destinatario del mensaje.

Como un mensaje pain.002 contiene un (y solo un) elemento de datos OrgnlGrpInfAndSts, este elemento también forma parte de este objeto de mensaje y no uno separado.

pain.002

OrgnlPmtInfAndSts

pain002.OrgnlPmtInfAndSts

El objeto OrgnlPmtInfAndSts representa la actualización de estado de una instrucción de pago individual. En el caso de un pago instantáneo, este objeto puede tener una o más ocurrencias en un pain.002. Esto último solo aplica si el pain.001 original tiene más de una instrucción de pago.

pain.002

TxInfAndSts

pain002.TxInfAndSts

El objeto TxInfAndSts representa la actualización de estado de una transacción individual en una instrucción. En el caso de un pago instantáneo, un OrgnlPmtInfAndSts puede tener ninguna o muchas ocurrencias de TxInfAndSts. Esto último solo aplica si el PmtInf original tiene más de un CdtTrfTxInf.

pacs.008

GrpHdr

pacs008.GrpHdr

El mensaje pacs.008 es utilizado por el banco del deudor para enviar una transferencia de crédito al banco del acreedor, directamente o a través de un CSM. Un pacs.008 tiene siempre un (y solo un) objeto GrpHdr. El objeto GrpHdr contiene datos relacionados con el mensaje, como identificador de mensaje único, fecha de creación, remitente y receptor del mensaje, datos de compensación y liquidación, etc.

pacs.008

CdtTrfTxInf

pacs008.CdtTrfTxInf

El objeto CdtTrfTxInf representa los datos de una transferencia de crédito individual. Incluye un identificador de transacción único del agente emisor (deudor). Este no es el identificador de la transacción según lo proporcionado por el originador del pago en el pain.001. Es un nuevo identificador generado por el agente deudor (esto es PmtId/TxId o PmtId/EUTR. En SCT Inst debe ser PmtId/TxId). El ODS necesita mantener la correlación entre el objeto CdtTrfTxInf en el pain.001 y el objeto CdtTrfTxInf asociado en el pacs.008 (solo aplicable para pacs.008 saliente). El identificador End2End que el originador del pago ha colocado en el CdtTrfTxInf en el pain.001 no puede usarse ya que no hay garantía de que sea único entre todas las transacciones.

En SCT Inst, un único pacs.008 (o mejor dicho, el objeto GrpHdr) solo puede contener un CdtTrfTxInf. En la mayoría de los esquemas de pago no instantáneo, un pacs.008 puede contener más de un CdtTrfTxInf.

pacs.002

GrpHdr

pacs002.GrpHdr

El mensaje pacs.002 es utilizado por las instituciones financieras y los CSMs para informar a otras partes (como el agente deudor y el agente acreedor) sobre el estado de uno o más pacs.008 y/o una o más transacciones en un mensaje pacs.008 que se ha intercambiado entre las partes en cuestión. Cada mensaje pacs.002 tiene un (y solo un) objeto GrpHdr. Contiene datos como identificadores de mensaje así como parte remitente y parte receptora.

pacs.002

OrgnlGrpInfAndSts

pacs002.OrgnlGrpInfAndSts

El OrgnlGrpInfAndSts a nivel de mensaje pacs.008 (representado por el objeto GrpGdr del pacs.008). Un pacs.002 puede referirse a más de un mensaje pacs.008. Este objeto puede incluir la actualización de estado de un mensaje pacs.008 completo (y el GrpHdr asociado), por ejemplo cuando el mensaje pacs.008 completo ha sido rechazado debido a un identificador de mensaje duplicado.

En el caso de SCT Instant, las Implementation Guidelines (IG) definen que un pacs.002 solo puede tener una ocurrencia de OrgnlGrpInfAndSts, lo que significa que un pacs.002 puede referirse solo a un pacs.008. El objeto OrgnlGrpInfAndSts contiene datos como una referencia al identificador de mensaje original (que es el message identifier del GrpHdr del pacs.008).

pacs.002

TxInfAndSts

pacs002.TxInfAndSts

El objeto TxInfAndSts representa la actualización de estado de una transacción individual (CdtTrfTxInf) de un pacs.008. Un pacs.002 (representado por el objeto GrpHdr) puede tener múltiples objetos TxInfAndSts. En el caso de SCT Instant, el número de ocurrencias de un objeto TxInfAndSts en un pacs.002 está restringido a una. El objeto TxInfAndSts contiene elementos de datos que hacen referencia al instruction ID (si se especifica) y al transaction id según lo especificado en el objeto CdtTrfTxInf del pacs.008.

camt.056

Assgnmt

Case

CtrlData

camt056.GrpHdr

El mensaje camt.056 es utilizado por el agente deudor para solicitar al agente acreedor la cancelación/recuperación de un pago, independientemente de si el pago ya se ha liquidado entre los bancos o no. GrpHdr no es un objeto en el propio mensaje, pero se utiliza para agrupar varios objetos de datos que aparecen en el mensaje camt.056 en el nivel más alto con ocurrencia de cero o (máximo) uno, siendo:

Assgnmt
Case
CtrlData

La razón para introducir este objeto GrpHdr para el camt.056 es ser lo más consistente posible en el ODS a través de los diferentes tipos de mensajes.

camt.056

Undrlyg

camt056.Undrlyg

El objeto Undrlyg (UnderlyingTransaction) contiene datos relacionados con la cancelación. Es posible cancelar un grupo completo (solo uno por mensaje) o una o más transacciones individuales. Un único mensaje camt.056 puede contener múltiples objetos Undrlyg, y cada Undrlyg puede a su vez contener múltiples elementos PaymentTransaction. Para SCT, la implementación actual solo admite la cancelación de una UnderlyingTransaction.

camt.056

TxInf

camt056.TxInf

El objeto TxInf representa una transacción individual a cancelar/recuperar. El objeto TxInf contiene elementos de datos que hacen referencia al identificador de mensaje original, instruction ID (si se especifica) y transaction id según lo especificado en el pacs.008 original. Un objeto UndrLyg puede contener múltiples objetos TxInf, también en el caso de SCT Inst.

pacs.004

GrpHdr

pacs004.GrpHdr

El mensaje pacs.004 es utilizado por el agente acreedor para informar al agente deudor que la solicitud de cancelación ha sido aceptada y que los fondos se devuelven al agente deudor. El objeto GrpHdr contiene elementos de datos como message ID, fecha de creación, información del remitente y receptor y settlement info. Un mensaje camt.056 tiene un y solo un objeto GrpHdr.

El tipo de objeto también incluye el elemento de datos OrgnlGrpInf, ya que la ocurrencia en un pacs.004 es ninguna o una y, por lo tanto, no hay valor añadido en considerarlo como un objeto de mensaje separado.

pacs.004

TxInf

pacs004.TxInf

El objeto TxInf se refiere a la transferencia de crédito individual que se devuelve. Los elementos de datos que hacen referencia al GrpHdr original del mensaje pacs.008 pueden especificarse en el objeto OrgnlGrpInf así como en el objeto TxInf del mensaje pacs.004. El transaction id original debe especificarse en el objeto TxInf. Un mensaje pacs.004 puede contener uno o más objetos TxInf, también en el caso de SCT Inst.

camt.029

Assgnmt

RslvdCase

Sts

camt029.GrpHdr

En SCT Inst el camt.029 es utilizado por el agente acreedor para informar al agente deudor de que la solicitud de cancelación ha sido rechazada (y los fondos no se devuelven). El mensaje se utiliza como respuesta a un camt.056 (solicitud de cancelación) o a un pacs.028 (solicitud de actualización de estado) que envía el banco deudor para solicitar el estado de un camt.056 previamente enviado para el cual aún no se ha recibido respuesta (pacs.004 o camt.029).

GrpHdr no es un objeto en el mensaje camt.029 en sí, pero se utiliza en el ODS para agrupar varios objetos de datos que aparecen en el mensaje camt.029 en el nivel más alto con ocurrencia de cero o (máximo) uno, siendo:

Assgnmt
RslvdCase
Sts

La razón para introducir este objeto GrpHdr para el camt.029 es ser lo más consistente posible en el ODS a través de los diferentes tipos de mensajes.

camt.029

CxlDtls

camt029.CxlDtls

El objeto CxlDtls contiene la actualización de estado de una solicitud de cancelación/recuperación que se ha recibido. Un camt.029 puede contener uno o más objetos CxLDtls, también en el caso de SCT Inst. Un objeto CxlDtls puede referirse a una o más transacciones. Si se ha enviado una solicitud de cancelación/recuperación para un mensaje pacs.008 completo (representado por el objeto GrpHdr), la información del grupo original forma parte de este objeto. En SCT Inst no es posible cancelar un grupo completo y, por lo tanto, esta situación no aplica para SCT Inst.

camt.029

OrgnlPmtInfAndSts

camt029.OrgnlPmtInfAndSts

El objeto OrgnlPmtInfAndSts se refiere a una transacción individual para la que se ha recibido una cancelación/recuperación. El objeto OrgnlPmtInfAndSts contiene referencias a la solicitud de cancelación/recuperación original, como message ID original, group ID, instruction ID y transaction ID. Además, contiene datos sobre el estado de la cancelación y los reason codes del rechazo de la solicitud de cancelación/recuperación.

pacs.028

GrpHdr

pacs028.GrpHdr

El mensaje pacs.028 es utilizado por el agente deudor en dos casos:

a. para consultar al agente acreedor sobre el estado de una credit transfer transaction (un pacs.008) que se ha enviado al acreedor y para la cual no se ha recibido respuesta.

b. para solicitar la respuesta a una solicitud de cancelación/recuperación (camt.056) enviada previamente cuando no se ha recibido respuesta del agente acreedor. En este caso, el mensaje de respuesta es un pacs.004 (cancelación/recuperación aceptada) o un camt.029 (cancelación/recuperación rechazada).

Debido a que se trata de dos casos de uso diferentes, las implementaciones y el uso de los elementos de datos serán diferentes entre estos casos.

El objeto GrpHdr contiene datos con respecto al mensaje (pacs.028), como message ID, creation datetime, remitente, receptor, etc.

Un pacs.028 puede usarse para solicitar el estado de un mensaje pacs.008 completo (haciendo referencia al message ID tal como se especifica en el pacs.008 original o en el mensaje camt.056) o de una transacción individual. En el primer caso, el pacs.028 tiene uno o más objetos OrgnlGrpInf (en el caso de SCT Inst restringido a una ocurrencia); en el segundo caso, el pacs.028 tiene uno o más objetos TxInf.

pacs.028

OrgnlGrpInf

pacs028.OrgnlGrpInf

El objeto OrgnlGrpInf se refiere a un grupo original (en pacs.008) para el que se solicita la actualización de estado a través del message ID del GrpHdr del pacs.008 original. Como el camt.056 no incluye un objeto GrpHdr, el OrgnlGrpInf no contiene una referencia al message ID original, sino solo al Original Message Name Identifier (OrgnlMsgNmId).

pacs.028

TxInf

pacs028.TxInf

El objeto TxInf se refiere a una o más credit transfer instructions individuales (caso de uso 1) o a instrucciones de cancelación/recuperación (caso de uso 2). Para SCT Inst, un mensaje pacs.028 contiene uno (y solo uno) objeto TxInf.

En el caso del caso de uso 1, el elemento de datos TxInf/OrgnlInstrId en el pacs.028 se refiere al elemento de datos CdtTrfTxInf/PmtId/TxId (transaction ID) en el pacs.008.

En el caso del segundo, el elemento de datos TxInf/OrgnlInstrId en el pacs.028 se refiere al elemento de datos Undrlyg/TxInf/CxlId (cancellation ID) en el camt.056.

all

SplmtryData

nnnnnnnn.SplmtryData

El objeto SplmtryData puede aparecer en los mensajes enumerados anteriormente. Contiene datos que no son relevantes para el procesamiento de pagos, pero que deben incluirse cuando la transacción se reenvía a otras partes.

Todos los mensajes pueden recibirse de sistemas/partes externas para ser procesados por IPF (denominados inbound), así como ser generados por IPF y enviados a sistemas/partes externas. Pain.001 es en la mayoría de los casos solo inbound, pero si el banco actúa como forwarding agent o IPF se utiliza solo para la gestión de instrucciones, el pain.001 también puede ser outbound. Lo mismo puede decirse de pain.002 con la diferencia de que en la mayoría de los casos es solo outbound.

El siguiente diagrama es un ejemplo de cómo los message objects de los mensajes pain.001 pueden mapearse a los message objects de los mensajes pacs.008 salientes que se envían a CSMs y pain.002 que se envían al originador del pago. Este ejemplo demuestra que las credit transfers de un mismo pain.001 o incluso de la misma payment instruction (PmtInf) pueden enrutar (y liquidarse con) diferentes CSMs (agentes). Además, las credit transfers de distintas payment instructions o incluso de distintos mensajes pain.001 pueden agruparse para enviarse a un CSM agent específico (solo aplicable cuando se trata de un tipo de CSM basado en lotes).

El diagrama también demuestra que puede haber todo tipo de relaciones/vínculos entre el pain.001, el pain.002 y los message objects subyacentes de esos mensajes. Es posible generar un pain.002 con actualización de estado del pain.001 a nivel de mensaje (GrpHdr), pero también es posible devolver actualizaciones de estado a nivel de instrucción de pago o de transacción. También es posible que se creen múltiples mensajes pain.002 para las diferentes instrucciones/transacciones de un mensaje pain.001. También es posible que para una payment instruction o transacción se generen múltiples actualizaciones de estado durante su ciclo de vida de procesamiento (por ejemplo, una para informar que una transacción ha sido aceptada para su procesamiento tras la validación inicial y otra para informar que la transacción ha sido contabilizada en la cuenta del acreedor). Esto demuestra la importancia de un modelo flexible para vincular cualquier message object con cualquier message object de modo que un pago pueda seguirse y rastrearse a lo largo de todo su ciclo de vida.

Ten en cuenta que este ejemplo solo cubre un subconjunto de los mensajes y message objects subyacentes que están en el alcance del ODS e incluso de SCT Inst. Si se incluyera el alcance completo de mensajes en el ejemplo (con solicitudes y respuestas de cancelación y solicitudes y respuestas de actualización de estado), terminaría con un diagrama muy complejo con muchos mensajes y message objects y las relaciones entre todos esos objetos.