Conceptos

Los pagos/transacciones son procesados por los Nodos de Procesamiento IPF. Los Nodos de Procesamiento IPF mantienen los datos de los pagos/transacciones que están siendo procesados en memoria. Los datos que se reciben/generan como parte de los diferentes events se almacena de manera persistente como Procesamiento IPF Events en el IPF Event Almacene (siguiendo el Event Sourcing/CQRS pattern). En caso de que un Nodo de Procesamiento IPF falle (por ejemplo, debido a problemas relacionados con la infraestructura), otro Nodo de Procesamiento IPF en el clúster reanudará el procesamiento de las transacciones en curso. Al leer el procesamiento persistido events, este nodo de procesamiento IPF de conmutación por error es capaz de regenerar el state y los datos relevantes que se requieren para continuar el proceso en el punto en el que se encontraba el Nodo de Procesamiento IPF original cuando falló.
Durante el procesamiento, el procesamiento de transacciones events se consumen y procesan para mantener un eventually consistente (normalmente dentro de unos pocos segundos)Operational Data Store a través de la Event Componente de controlador. El IPF ODS viene con APIs a través de la cual la interfaz de usuario de IPF, 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, el IPF ODS también almacena datos de pago a un nivel agregado con el fin de alimentar los paneles de monitoreo de procesos (de negocio) (como parte de la GUI Operativa de IPF o aplicaciones externas).
Para el cumplimiento de la retención de datos, es posible replicar datos desde el IPF. Operational Data Store a un Archivo. Este archivo puede aprovechar los precios de almacenamiento más eficientes (MongoDB Atlas, por ejemplo, ofrece 3 niveles basados en la frecuencia de acceso o en los compromisos de latencia.
El Event El componente Handler también puede publicar un flujo de los mismos datos o de datos procesados a un sistema bancario descendente a través de un intermediario como Kafka donde los datos pueden ser utilizados para análisis, informes, monitoreo y otros propósitos.

Complejidad de un Modelo de Datos de Pago Basado en ISO 20022

Un modelo de datos de pago basado en ISO 20022 es un modelo de datos que puede soportar las estructuras de datos de los mensajes utilizados 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 solicite pagar mensajes 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 incluso múltiples. Un ejemplo de un mensaje de múltiples jerarquías es pain. 001. El nivel más alto es un Grupo de Instrucción (GrpHdr) que puede contener una o más Transferencias de Crédito Instructions(PmtInf) y cada Instrucción de Transferencia de Crédito puede contener una o más Transacciones de Transferencia de Crédito (CrdtTrfTxInf).

Múltiples transacciones de transferencia de crédito de diferentes transferencias de crédito instructions(de diferentes orígenes customers) puede ser agrupado en uno pacs. 008 mensaje 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 a través de la pacs. 008 mensajes. Estas actualizaciones de estado pueden ser en un pacs. 008 a nivel de grupo 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 presente una solicitud de cancelación. Para poder monitorear un pago (transferencia de crédito así como débito 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 mensajes equivalentes no basados en ISO 20022) puedan ser asociados/vinculados entre sí. También debe ser posible extender la solución con mensajes adicionales, como para la solicitud de pago (pain. 013 y pain. 014), y enlázalos con la instrucción de pago (pain. 001) que ha sido generado durante el procesamiento de solicitudes de pago.

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

Dado que este ejemplo es solo un subconjunto de los mensajes ISO 20022 relacionados con los pagos, no cubre las transacciones R-camt. 056, pacs. 004, etc.) o otros tipos de pago como los débitos directos. Incluso en este alcance limitado, un modelo de datos en el que cada nivel de un mensaje se almacena como una entidad de datos separada (tabla/colección) ya se ha convertido en un modelo complejo que es difícil de mantener y extender. Por lo tanto, es esencial utilizar un modelo de datos que sea genérico y ofrezca la posibilidad de agregar nuevos mensajes/objetos de datos y vincularlos con otros mensajes/objetos de datos con el impacto (cambios/extensiones) más limitado en el modelo de datos subyacente.

Modelo de Datos Lógico para ODS

Puntos clave de partida 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 mensaje, con el menor cambio/impacto posible en el modelo de datos existente (como nuevas tablas/colecciones).
Debe ser capaz de almacenar y acceder a los siguientes datos:
- mensajes (en ISO 20022 (XML/JSON) formato) recibido del partido/sistema de origen del pago (por ejemplo,customer canal o CSM puerta) y utilizada como entrada para el procesamiento
- datos generados durante el procesamiento, como IBAN o BIC enriquecidos, seleccionados CSM fecha de ejecución del agente o calculada
- mensajes (en ISO 20022 (XML/JSON) formato) generado durante el procesamiento y enviado a partes/sistemas externos
- acciones de procesamiento ejecutadas durante el procesamiento de un mensaje o una parte de un mensaje
- mensajes de entrada y salida en formato no ISO 20022 (cuando sea aplicable)
- estado de procesamiento de un mensaje o parte de un mensaje (instrucción, transacción, R-transacción, etc.) con un estado en proceso así como estado del ciclo de vida
- asociaciones/relaciones entre mensajes o partes de mensajes para una visión de extremo a extremo del ciclo de vida de un pago/transacción
Debe ser posible buscar datos en el ODS sobre la base de un conjunto predefinido de atributos de búsqueda
Debe ser posible, como parte de una implementación, agregar atributos de búsqueda adicionales (específicos de la implementación) y utilizarlos en el (estándar)APIs que vienen con el producto IPF
Debe ser posible configurar para cada procesamiento event cómo se almacena en el ODS(como un nuevo objeto de datos de mensaje o como un event que está vinculado a un objeto existente, etc.). Esta configuración es necesaria ya que los pasos de procesamiento (events) se puede añadir a process flow s, y debe ser posible definir cómo se deben manejar los datos de este event se almacena en el ODS.

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

El Objeto de Mensaje representa datos relacionados con el pago que se ingresan y/o se generan durante el procesamiento de pagos dentro de IPF. Un Objeto de Mensaje es parte de un mensaje ISO 20022 en base al cual se realiza el procesamiento (mediante un específico process flow) tiene lugar en IPF. El Objeto de Mensaje es una representación abstracta de una parte de un mensaje ISO 20022. Los datos relevantes en sí mismos están representados por la entidad de datos del Objeto de Mensaje del modelo. Cada Objeto de Mensaje tiene un atributo de Tipo de Objeto que consiste en el ISO 20022.message type(ej.pain. 001) y el nombre del elemento de datos en el mensaje ISO 20022 al que se refiere el objeto de mensaje correspondiente. La lista de tipos de objeto de mensaje se presenta a continuación.
El objeto de datos del mensaje representa los datos que se ingresan y generan por el process flow en IPF durante el procesamiento del objeto de mensaje correspondiente. Dado que estos datos se reciben a través de múltiples y separados procesos events que se manejan de forma individual y posteriormente se añaden a la ODS, los datos relevantes de cada procesamiento event se almacena en un registro de Objeto de Mensaje de Datos separado (de ahí la relación de uno a muchos con la entidad de datos de Objeto de Mensaje). De esta manera, los datos pueden ser almacenados en el ODS sobre la base de un principio de solo anexar sin actualizar los datos que ya están almacenados. Cuando los datos para un específico MDS El objeto es consultado (a través de la ODS APIs) la API devuelve un resultado que consiste en los datos combinados de todos MDS Registros de datos del objeto en cuestión MDS Objeto.
El objeto de relación de mensajes se utiliza para relacionar dos objetos de mensaje entre sí. Esta puede ser una relación de objetos del mismo mensaje (por ejemplo,pain001. CdtTrfTxInf objeto que es un hijo de un pain001. PmtInf objeto), pero también puede ser la relación entre dos objetos de diferentes mensajes (por ejemplo,pain001. CdtTrfTxInf objeto y un pacs008. CdtTrfTxInf Este conjunto permite relacionar cualquier Objeto de Mensaje con cualquier Objeto de Mensaje (y agregar nuevas relaciones) sin depender del modelo de datos ni la necesidad de cambiar el modelo de datos.
Procesamiento del Objeto de Mensaje Event se refiere a la events que son realizadas por IPF process flow s para el objeto de mensaje en cuestión.
La entidad de datos del estado del objeto de mensaje se refiere al estado de un objeto de mensaje. Es posible registrar múltiples tipos de estados para uno MDS Objeto así como múltiples estados del mismo tipo para uno MDS objeto. Por ejemplo, es posible hacer una distinción entre 'processStatus' y 'lifecycleStatus' como tipos de estado. El primero es el estado de un Objeto de Mensaje dentro de la ejecución de un proceso, el segundo es el estado a través de todos los procesos. El estado más reciente agregado es también el estado actual para ese Objeto de Mensaje.
El Mensaje de Intercambio se refiere a los mensajes entrantes y salientes que se intercambian con sistemas externos (no-IPF).customer canales,CSM puertas de enlace) y son entradas para o generadas por IPF process flow s. Un Mensaje de Intercambio tiene un indicador de dirección (entrante o saliente), el message type(pain. 001, pacs. 008,..), un indicador de versión y la aplicación desde la cual se recibe (entrante) o se envía (saliente).
El Objeto de Mensaje La Relación de Mensaje se refiere a la relación de un Objeto de Mensaje con los Mensajes de Intercambio. Un Objeto de Mensaje puede estar relacionado con múltiples mensajes entrantes y salientes, así como un mensaje puede relacionarse con múltiples Objetos de Mensaje.
El Índice del Objeto de Mensaje se refiere al índice/tablas/colección que se utilizan para buscar Objetos de Mensaje de un cierto tipo en base a criterios específicos. Cada tipo de objeto tiene criterios de búsqueda específicos, y cada tipo de Objeto de Mensaje también tiene su propio índice.

Tipos de Objetos de Mensaje

La tabla a continuación enumera un subconjunto de los tipos de objetos de mensaje que deben ser compatibles en el ODS. La lista a continuación se basa en el esquema SCT Inst con el libro de reglas asociado y las directrices de implementación de mensajes (IGs).

Mensaje ISO 20022 Elemento(s) de datos en el mensaje Tipo de Objeto de Mensaje en ODS Descripción

Mensaje ISO 20022	Elemento(s) de datos en el mensaje	Tipo de Objeto de Mensaje en ODS	Descripción
pain. 001	`GrpHdr`	`pain001. GrpHdr`	El pain. 001 El mensaje es utilizado por los originadores de pagos (el deudor o una parte en nombre del deudor) hacia el banco deudor (directamente o a través de un agente de reenvío). Un `pain001` el mensaje contiene siempre uno (y solo uno)`GrpHdr` objeto. El `GrpHdr` El objeto contiene datos relacionados con el mensaje, como el identificador único (mensaje), la fecha de creación y el remitente y destinatario del mensaje.
pain. 001	`PmtInf`	`pain001. PmtInf`	El `PmtInf` el objeto representa un individuo customer instrucción de pago. Uno pain. 001 mensaje (representado por el `GrpHdr` el objeto) puede contener uno o más pagos instructions(`PmtInf` instrucciones de pago). Cada instrucción de pago representa el lado de débito de uno o más pagos.
pain. 001	`CdtTrfTxInf`	`pain001. CdtTrfTxInf`	El `CdtTrfTxInf` el objeto representa el lado del crédito de una instrucción de pago (`PmtInf`), también denominado transacción de transferencia de crédito. Una instrucción puede contener una o más transacciones de transferencia de crédito.
pain. 002	`GrpHdr. OrgnlGrpInfAndSts`	`pain002. GrpHdr`	El pain. 002 el mensaje es utilizado por el banco deudor para informar al originador de la pain. 001 sobre el estado (actualizaciones) de la completa pain. 001, uno o más pagos instructions en el pain. 001 o una o más transacciones de transferencia de crédito de una o más instructions. Cada pain. 002 El mensaje contiene siempre un objeto GrpHdr que identifica el mensaje y el remitente y destinatario del mensaje. Como un pain. 002 el mensaje contiene uno (y solo uno)`OrgnlGrpInfAndSts` el elemento de datos, este elemento también forma parte de este objeto de mensaje y no es uno separado.
pain. 002	`OrgnlPmtInfAndSts`	`pain002. OrgnlPmtInfAndSts`	El `OrgnlPmtInfAndSts` el objeto representa la actualización de estado de una instrucción de pago individual. En caso de un instant el pago de este objeto puede tener una ocurrencia de uno o más en uno pain. 002. Este último solo es aplicable si también el original pain. 001 tiene más de una instrucción de pago.
pain. 002	`TxInfAndSts`	`pain002. TxInfAndSts`	El `TxInfAndSts` el objeto representa la actualización de estado de una transacción individual en una instrucción. En el caso de un instant pago uno `OrgnlPmtInfAndSts` puede tener ninguna o muchas ocurrencias de `TxInfAndSts`. Este último solo es aplicable si también el original `PmtInf` tiene más de uno `CdtTrfTxInf`.
pacs. 008	`GrpHdr`	`pacs008. GrpHdr`	El pacs. 008 mensaje es utilizado por el banco deudor para enviar una transferencia de crédito al banco acreedor, directamente o a través de un CSM. A pacs. 008 siempre tiene uno (y solo uno)`GrpHdr` objeto. El `GrpHdr` El objeto contiene datos relacionados con el mensaje, como el identificador único (mensaje), la fecha de creación, el remitente y el destinatario del mensaje, datos relacionados con la compensación y liquidación, etc.
pacs. 008	`CdtTrfTxInf`	`pacs008. CdtTrfTxInf`	El `CdtTrfTxInf` El objeto representa los datos de una transferencia de crédito individual. Incluye un identificador de transacción único del agente remitente (deudor). Este no es el identificador de los datos de la transacción tal como lo proporciona el originador del pago en el pain. 001. Es un nuevo identificador que ha sido generado por el agente deudor (esto es `PmtId/TxId` or `PmtId/EUTR`. En SCT Inst esto debe ser `PmtId/TxId`). El ODS necesita mantener la correlación entre el `CdtTrfTxInf` objeto en el pain. 001 y el asociado `CdtTrfTxInf` objeto en el pacs. 008(solo aplicable para Salida pacs. 008). El `End2End` identificador que el originador del pago ha colocado en el `CdtTrfTxInf` en el pain. 001 no se puede utilizar ya que no hay garantía de que sea único en todas las transacciones. En SCT Inst, uno pacs. 008(o mejor dicho el `GrpHdr` el objeto) solo puede contener uno `CdtTrfTxInf`. En la mayoría de los no-instant esquemas de pago, uno pacs. 008 puede contener más de uno `CdtTrfTxInf`.
pacs. 002	`GrpHdr`	`pacs002. GrpHdr`	El pacs. 002 El mensaje es utilizado por las Instituciones Financieras y los CSM para informar a otras partes (como el agente deudor así como el agente acreedor) sobre el estado de uno o más pacs. 008 y/o una o más transacciones en un pacs. 008 mensaje que ha sido intercambiado entre las partes concernidas. Cada pacs. 002 el mensaje tiene uno (y solo uno)`GrpHdr` objeto. Contiene datos como identificadores de mensajes, así como la parte que envía y la parte que recibe.
pacs. 002	`OrgnlGrpInfAndSts`	`pacs002. OrgnlGrpInfAndSts`	El `OrgnlGrpInfAndSts` objeto en pacs. 008 nivel de mensaje (representado por el `GrpGdr` objeto del pacs. 008). Uno pacs. 002 puede referirse a más de uno pacs. 008 mensaje. Este objeto puede incluir la actualización de estado de un completo pacs. 008 mensaje (y asociado `GrpHdr`), por ejemplo, cuando el completo pacs. 008 El mensaje ha sido rechazado debido a un identificador de mensaje duplicado. En caso de SCT Instant las Directrices de Implementación (IG) definen que un pacs. 002 solo puede tener uno `OrgnlGrpInfAndSts` ocurrencia, lo que significa que uno pacs. 002 puede referirse a solo uno pacs. 008. El `OrgnlGrpInfAndSts` el objeto contiene datos como una referencia a la identificación del mensaje original (que es el identificador del mensaje de la `GrpHdr` de la pacs. 008).
pacs. 002	`TxInfAndSts`	`pacs002. TxInfAndSts`	El `TxInfAndSts` el objeto representa la actualización de estado de una transacción individual (`CdtTrfTxInf`) de un pacs. 008. Uno pacs. 002--`GrpHdr` el objeto) puede tener múltiples `TxInfAndSts` objetos. En el caso de SCT Instant, el número de ocurrencias de un `TxInfAndSts` objeto en un pacs. 002 is restricted a uno. El `TxInfAndSts` el objeto contiene elementos de datos que se refieren al ID de instrucción (si se especifica) y al ID de transacción según se especifica en el `CdtTrfTxInf` objeto del pacs. 008.
camt. 056	`Assgnmt` `Case` `CtrlData`	`camt056. GrpHdr`	El camt. 056 El mensaje es utilizado por el agente deudor para solicitar al agente acreedor la cancelación/revocación de un pago, independientemente de si el pago ya ha sido liquidado entre los bancos o no.`GrpHdr` no es un objeto en el mensaje en sí, sino que se utiliza para agrupar varios objetos de datos que aparecen en el camt. 056 mensaje en el nivel más alto con una ocurrencia de cero o (máximo) uno, siendo: `Assgnmt` `Case` `CtrlData` La razón para introducir esto `GrpHdr` objeto para el camt. 056 es ser lo más consistente posible en el ODS a través de los diferentes message type s.
camt. 056	`Undrlyg`	`camt056. Undrlyg`	El objeto Undrlyg (UnderlyingTransaction) contiene datos relacionados con la cancelación. Es posible cancelar ya sea un grupo completo (solo uno por mensaje) o una o más transacciones individuales. Una sola camt. 056 El mensaje 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 que debe ser cancelada/reclamada. La `TxInf` El objeto contiene elementos de datos que se refieren al ID del mensaje original, al ID de la instrucción (si se especifica) y al ID de la transacción según lo especificado en el original.pacs. 008. Uno `UndrLyg` el objeto puede contener múltiples `TxInf` objetos, también en caso de SCT Inst.
pacs. 004	`GrpHdr`	`pacs004. GrpHdr`	El pacs. 004 El mensaje es utilizado por el agente acreedor para informar al agente deudor que la solicitud de cancelación de pago ha sido aceptada y que los fondos son devueltos al agente deudor. El `GrpHdr` El objeto contiene elementos de datos como el ID del mensaje, la fecha de creación, la información del remitente y del destinatario, así como la información de liquidación. A camt. 056 el mensaje tiene uno y solo uno `GrpHdr` objeto. El tipo de objeto también contiene el `OrgnlGrpInf` elemento de datos como la ocurrencia en un pacs. 004 no es ninguno o uno y, por lo tanto, no hay valor añadido en considerarlo como un objeto de mensaje separado.
pacs. 004	`TxInf`	`pacs004. TxInf`	El `TxInf` el objeto se refiere a la transacción individual de transferencia de crédito que se devuelve. Los elementos de datos que se refieren al GrpHdr original de la pacs. 008 el mensaje puede ser especificado en el `OrgnlGrpInf` objeto así como en el `TxInf` objeto del pacs. 004 mensaje. Se debe especificar el id de la transacción original en el `TxInf` objeto. Uno pacs. 004 el mensaje puede contener uno o más `TxInf` objetos, 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 que la solicitud de cancelación de pago ha sido rechazada (y los fondos no son devueltos). El mensaje se utiliza como respuesta a un camt. 056(solicitud de cancelación) o un pacs. 028( solicitud de actualización de estado) que es enviada por el banco deudor para solicitar el estado de un ** previamente enviado.camt. 056 por la cual no hay respuesta (pacs. 004 or camt. 029) ha sido recibido aún. `GrpHdr`no es un objeto en el camt. 029 mensaje en sí, pero se utiliza en el ODS para agrupar varios objetos de datos que aparecen en el camt. 029 mensaje en el nivel más alto con una ocurrencia de cero o (máximo) uno, siendo: `Assgnmt` `RslvdCase` `Sts` La razón para introducir esto `GrpHdr` objeto para el camt. 029 es ser lo más consistente posible en el ODS a través de los diferentes message type s.
camt. 029	`CxlDtls`	`camt029. CxlDtls`	El `CxlDtls` El objeto contiene la actualización de estado de una solicitud de cancelación/retiro que ha sido recibida. Uno camt. 029 puede contener uno o más `CxLDtls` objetos, también en caso de SCT Inst. Uno `CxlDtls` El objeto puede referirse a una o más transacciones. Si se ha enviado una solicitud de cancelación/retiro para un completo pacs. 008 mensaje (representado por el `GrpHdr` El objeto) la información del grupo original es parte de este objeto. En SCT Inst no es posible cancelar un grupo completo, y por lo tanto esta situación no es aplicable para SCT Inst.
camt. 029	`OrgnlPmtInfAndSts`	`camt029. OrgnlPmtInfAndSts`	El `OrgnlPmtInfAndSts` El objeto se refiere a una transacción individual para la cual se ha recibido una cancelación/revocación. La `OrgnlPmtInfAndSts` el objeto contiene referencias a la solicitud de cancelación/retiro original, como el ID del mensaje original, el ID del grupo, el ID de la instrucción y el ID de la transacción. Además, contiene datos sobre el estado de la cancelación y reason codes por rechazar la solicitud de cancelación/retiro.
pacs. 028	`GrpHdr`	`pacs028. GrpHdr`	The pacs. 028 el mensaje es utilizado por el agente deudor en los siguientes casos: a. consultar al agente acreedor sobre el estado de una transacción de transferencia de crédito (a pacs. 008) que ha sido enviado al acreedor y para el cual no se ha recibido respuesta. b. para solicitar la respuesta a una solicitud de cancelación/revocación enviada previamente (camt. 056) cuando no se ha recibido una respuesta del agente acreedor. En este caso, el mensaje de respuesta es ya sea un pacs. 004(cancelación/revocación aceptada) o un camt. 029(cancelación/retiro rechazado). 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 `GrpHdr` el objeto contiene datos con respecto a la (pacs. 028) mensaje como ID de mensaje, fecha y hora de creación, remitente, destinatario, etc. A pacs. 028 puede ser utilizado para solicitar el estado de un completo pacs. 008 mensaje (haciendo referencia al ID del mensaje según se especifica en el original pacs. 008 or camt. 056 mensaje) o una transacción individual. En el primer caso, el pacs. 028 tiene uno o más `OrgnlGrpInf` objetos (en caso de SCT Inst restricted a una ocurrencia), en el segundo caso la pacs. 028 tiene uno o más `TxInf` objetos.
pacs. 028	`OrgnlGrpInf`	`pacs028. OrgnlGrpInf`	El `OrgnlGrpInf` el contexto de un grupo original (en pacs. 008) para el cual se solicita la actualización de estado a través del ID de mensaje `GrpHdr` objeto del original pacs. 008. A medida que el camt. 056 no incluye un `GrpHdr` objeto el `OrgnlGrpInf` no contiene una referencia al ID del mensaje original, sino solo al Identificador del Nombre del Mensaje Original `OrgnlMsgNmId`).
pacs. 028	`TxInf`	`pacs028. TxInf`	El `TxInf` el objeto se refiere a una o más transferencias de crédito individuales instructions(caso de uso 1) o una cancelación/revocación instructions(use case 2). Para SCT Inst, un pacs. 028 el mensaje contiene uno (y contiene uno)`TxInf` objeto. En caso de uso del caso 1, el elemento de datos `TxInf/OrgnlInstrId` en el pacs. 028 se refiere al elemento de datos `CdtTrfTxInf/PmtId/TxId`(ID de transacción) en el pacs. 008. En caso de lo último, el elemento de datos `TxInf/OrgnlInstrId` en el pacs. 028 se refiere al elemento de datos `Undrlyg/TxInf/CxlId`(ID de cancelación) en el camt. 056.
todo	`SplmtryData`	`nnnnnnnn. SplmtryData`	El `SplmtryData` El objeto puede aparecer en el mensaje mencionado anteriormente. Contiene datos que no son relevantes para el procesamiento de pagos, pero que deben incluirse cuando la transacción se envíe a otras partes.

pain. 001

GrpHdr

pain001. GrpHdr

El pain. 001 El mensaje es utilizado por los originadores de pagos (el deudor o una parte en nombre del deudor) hacia el banco deudor (directamente o a través de un agente de reenvío). Un pain001 el mensaje contiene siempre uno (y solo uno)GrpHdr objeto. El GrpHdr El objeto contiene datos relacionados con el mensaje, como el identificador único (mensaje), la fecha de creación y el remitente y destinatario del mensaje.

pain. 001

PmtInf

pain001. PmtInf

El PmtInf el objeto representa un individuo customer instrucción de pago. Uno pain. 001 mensaje (representado por el GrpHdr el objeto) puede contener uno o más pagos instructions(PmtInf instrucciones de pago). Cada instrucción de pago representa el lado de débito de uno o más pagos.

pain. 001

CdtTrfTxInf

pain001. CdtTrfTxInf

El CdtTrfTxInf el objeto representa el lado del crédito de una instrucción de pago (PmtInf), también denominado transacción de transferencia de crédito. Una instrucción puede contener una o más transacciones de transferencia de crédito.

pain. 002

GrpHdr. OrgnlGrpInfAndSts

pain002. GrpHdr

El pain. 002 el mensaje es utilizado por el banco deudor para informar al originador de la pain. 001 sobre el estado (actualizaciones) de la completa pain. 001, uno o más pagos instructions en el pain. 001 o una o más transacciones de transferencia de crédito de una o más instructions.

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

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

pain. 002

OrgnlPmtInfAndSts

pain002. OrgnlPmtInfAndSts

El OrgnlPmtInfAndSts el objeto representa la actualización de estado de una instrucción de pago individual. En caso de un instant el pago de este objeto puede tener una ocurrencia de uno o más en uno pain. 002. Este último solo es aplicable si también el original pain. 001 tiene más de una instrucción de pago.

pain. 002

TxInfAndSts

pain002. TxInfAndSts

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

pacs. 008

GrpHdr

pacs008. GrpHdr

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

pacs. 008

CdtTrfTxInf

pacs008. CdtTrfTxInf

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

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

pacs. 002

GrpHdr

pacs002. GrpHdr

El pacs. 002 El mensaje es utilizado por las Instituciones Financieras y los CSM para informar a otras partes (como el agente deudor así como el agente acreedor) sobre el estado de uno o más pacs. 008 y/o una o más transacciones en un pacs. 008 mensaje que ha sido intercambiado entre las partes concernidas. Cada pacs. 002 el mensaje tiene uno (y solo uno)GrpHdr objeto. Contiene datos como identificadores de mensajes, así como la parte que envía y la parte que recibe.

pacs. 002

OrgnlGrpInfAndSts

pacs002. OrgnlGrpInfAndSts

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

En caso de SCT Instant las Directrices de Implementación (IG) definen que un pacs. 002 solo puede tener uno OrgnlGrpInfAndSts ocurrencia, lo que significa que uno pacs. 002 puede referirse a solo uno pacs. 008. El OrgnlGrpInfAndSts el objeto contiene datos como una referencia a la identificación del mensaje original (que es el identificador del mensaje de la GrpHdr de la pacs. 008).

pacs. 002

TxInfAndSts

pacs002. TxInfAndSts

El TxInfAndSts el objeto representa la actualización de estado de una transacción individual (CdtTrfTxInf) de un pacs. 008. Uno pacs. 002--GrpHdr el objeto) puede tener múltiples TxInfAndSts objetos. En el caso de SCT Instant, el número de ocurrencias de un TxInfAndSts objeto en un pacs. 002 is restricted a uno. El TxInfAndSts el objeto contiene elementos de datos que se refieren al ID de instrucción (si se especifica) y al ID de transacción según se especifica en el CdtTrfTxInf objeto del pacs. 008.

camt. 056

Assgnmt

Case

CtrlData

camt056. GrpHdr

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

Assgnmt
Case
CtrlData

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

camt. 056

Undrlyg

camt056. Undrlyg

El objeto Undrlyg (UnderlyingTransaction) contiene datos relacionados con la cancelación. Es posible cancelar ya sea un grupo completo (solo uno por mensaje) o una o más transacciones individuales. Una sola camt. 056 El mensaje 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 que debe ser cancelada/reclamada. La TxInf El objeto contiene elementos de datos que se refieren al ID del mensaje original, al ID de la instrucción (si se especifica) y al ID de la transacción según lo especificado en el original.pacs. 008. Uno UndrLyg el objeto puede contener múltiples TxInf objetos, también en caso de SCT Inst.

pacs. 004

GrpHdr

pacs004. GrpHdr

El pacs. 004 El mensaje es utilizado por el agente acreedor para informar al agente deudor que la solicitud de cancelación de pago ha sido aceptada y que los fondos son devueltos al agente deudor. El GrpHdr El objeto contiene elementos de datos como el ID del mensaje, la fecha de creación, la información del remitente y del destinatario, así como la información de liquidación. A camt. 056 el mensaje tiene uno y solo uno GrpHdr objeto.

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

pacs. 004

TxInf

pacs004. TxInf

El TxInf el objeto se refiere a la transacción individual de transferencia de crédito que se devuelve. Los elementos de datos que se refieren al GrpHdr original de la pacs. 008 el mensaje puede ser especificado en el OrgnlGrpInf objeto así como en el TxInf objeto del pacs. 004 mensaje. Se debe especificar el id de la transacción original en el TxInf objeto. Uno pacs. 004 el mensaje puede contener uno o más TxInf objetos, 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 que la solicitud de cancelación de pago ha sido rechazada (y los fondos no son devueltos). El mensaje se utiliza como respuesta a un camt. 056(solicitud de cancelación) o un pacs. 028( solicitud de actualización de estado) que es enviada por el banco deudor para solicitar el estado de un ** previamente enviado.camt. 056 por la cual no hay respuesta (pacs. 004 or camt. 029) ha sido recibido aún.

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

Assgnmt
RslvdCase
Sts

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

camt. 029

CxlDtls

camt029. CxlDtls

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

camt. 029

OrgnlPmtInfAndSts

camt029. OrgnlPmtInfAndSts

El OrgnlPmtInfAndSts El objeto se refiere a una transacción individual para la cual se ha recibido una cancelación/revocación. La OrgnlPmtInfAndSts el objeto contiene referencias a la solicitud de cancelación/retiro original, como el ID del mensaje original, el ID del grupo, el ID de la instrucción y el ID de la transacción. Además, contiene datos sobre el estado de la cancelación y reason codes por rechazar la solicitud de cancelación/retiro.

pacs. 028

GrpHdr

pacs028. GrpHdr

The pacs. 028 el mensaje es utilizado por el agente deudor en los siguientes casos:

a. consultar al agente acreedor sobre el estado de una transacción de transferencia de crédito (a pacs. 008) que ha sido enviado al acreedor y para el cual no se ha recibido respuesta.

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

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 GrpHdr el objeto contiene datos con respecto a la (pacs. 028) mensaje como ID de mensaje, fecha y hora de creación, remitente, destinatario, etc.

A pacs. 028 puede ser utilizado para solicitar el estado de un completo pacs. 008 mensaje (haciendo referencia al ID del mensaje según se especifica en el original pacs. 008 or camt. 056 mensaje) o una transacción individual. En el primer caso, el pacs. 028 tiene uno o más OrgnlGrpInf objetos (en caso de SCT Inst restricted a una ocurrencia), en el segundo caso la pacs. 028 tiene uno o más TxInf objetos.

pacs. 028

OrgnlGrpInf

pacs028. OrgnlGrpInf

El OrgnlGrpInf el contexto de un grupo original (en pacs. 008) para el cual se solicita la actualización de estado a través del ID de mensaje GrpHdr objeto del original pacs. 008. A medida que el camt. 056 no incluye un GrpHdr objeto el OrgnlGrpInf no contiene una referencia al ID del mensaje original, sino solo al Identificador del Nombre del Mensaje Original OrgnlMsgNmId).

pacs. 028

TxInf

pacs028. TxInf

El TxInf el objeto se refiere a una o más transferencias de crédito individuales instructions(caso de uso 1) o una cancelación/revocación instructions(use case 2). Para SCT Inst, un pacs. 028 el mensaje contiene uno (y contiene uno)TxInf objeto.

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

En caso de lo último, el elemento de datos TxInf/OrgnlInstrId en el pacs. 028 se refiere al elemento de datos Undrlyg/TxInf/CxlId(ID de cancelación) en el camt. 056.

todo

SplmtryData

nnnnnnnn. SplmtryData

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

Todos los mensajes pueden ser recibidos de sistemas/partes externas para ser procesados por IPF (denominados como entrantes), así como generados por IPF y enviados a sistemas/partes externas. Pain. 001 en la mayoría de los casos es solo entrante, pero en caso de que el banco actúe como agente de forwarding o el IPF se utilice únicamente para la gestión de instrucciones, el pain. 001 también puede ser saliente. Lo mismo puede decirse de pain. 002 con la diferencia de que en la mayoría de los casos es únicamente saliente.

El diagrama a continuación es un ejemplo de cómo los objetos de mensaje de pain. 001 Los mensajes pueden ser mapeados a los objetos de mensaje de salida.pacs. 008 mensajes que se envían a los CSMs y pain. 002 que se envían al originador del pago. Este ejemplo demuestra que las transferencias de crédito de uno y el mismo pain. 001 o incluso la misma instrucción de pago (PmtInf) pueden ser dirigidos (y liquidados con) diferentes CSMs (agentes). También, las transferencias de crédito de diferentes métodos de pago instructions o incluso pain. 001 Los mensajes pueden agruparse para ser enviados a un específico CSM agente (solo aplicable cuando se refiere a un lote basado CSM type).

El diagrama también demuestra que puede haber todo tipo de relaciones/enlaces entre el pain. 001, el pain. 002 y los objetos de mensaje subyacentes de esos mensajes. Es posible generar un pain. 002 con la actualización de estado del pain. 001 en mensaje (GrpHdr) nivel, 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 múltiples pain. 002 los mensajes se crean para los diferentes instructions/transacciones de uno pain. 001 mensaje. También es posible que para una instrucción de pago o transacción se generen múltiples actualizaciones de estado durante su ciclo 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 registrada en la cuenta del acreedor). Esto demuestra la importancia de un modelo flexible para vincular cualquier objeto de mensaje con cualquier objeto de mensaje, de modo que un pago pueda ser rastreado y trazado a lo largo de su ciclo de vida completo.

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