Conceptos de ISO20022
ISO20022 se creó para estandarizar el intercambio de información entre las distintas partes involucradas en los servicios financieros. Aunque ISO20022 abarca muchas áreas dentro de los servicios financieros (por ejemplo, valores, financiamiento del comercio, tarjetas y cambio de divisas), el soporte de IPF se centra en el área de pagos.
| Si eres nuevo en ISO20022, te recomendamos leer el ebook gratuito de SWIFT ISO20022 for Dummies para familiarizarte. |
Meta-Model
El modelo ISO20022 comprende cuatro niveles, basados en los cuatro primeros niveles del Zachmann Enterprise Architecture Framework.
| Level | Purpose |
|---|---|
Scope |
Lograr una comprensión exhaustiva de los objetivos del área de negocio, sus procesos relevantes y los roles que desempeñan las partes involucradas. |
Conceptual |
Formalizar la semántica y descubrir los requisitos de comunicación e interacción de los procesos de negocio definiendo las transacciones de negocio, actividades de negocio y coreografías de mensajes relacionadas con los procesos de negocio. |
Logical |
Crear una descripción precisa de los mensajes y sistemas, sin tener en cuenta cómo se implementarán, centrándose en las message definitions, message building blocks y message elements. |
Physical |
Crear una descripción precisa de los mensajes y sistemas en una tecnología que pueda usarse para la implementación. |
Visión general del Meta Model
El diagrama siguiente muestra algunos conceptos y relaciones principales dentro del modelo; observa que, además de dividirse por nivel, los conceptos también se dividen entre regiones "estáticas" y "dinámicas". Esto describe aún más el principio de tener un diccionario de datos estándar de objetos y usar esos objetos en el contexto de varios procesos de negocio/intercambios de mensajes.
Conceptos del Meta-Model
| Term | Description |
|---|---|
El Message Model se refiere a la parte del meta-model que trata de las Message Definitions |
|
El Business Model se refiere a la parte del meta-model que trata de los Business Processes |
|
Un Business Area es un dominio bajo el cual se agrupan Message Definitions y otros conceptos, p. ej., Payment Initiation |
|
Una Message Definition es un único tipo de mensaje que puede intercambiarse, p. ej., |
|
Un Message Component es un tipo complejo para usarse en una o más Message Definitions; puede referenciar otros Message Components o Message Elements, p. ej., |
|
Un Message Element es un atributo de tipo simple de un Message Component, p. ej., |
|
Un business component es una representación más general de un tipo estándar, como un Account. En realidad, es un superconjunto/arquetipo de las diversas representaciones de Account de los Message Components, como |
|
Un atributo de tipo simple de un Business Component, p. ej., Account.name |
|
Un trace es un vínculo físico de un nivel de abstracción del modelo a otro. Aparte del E-Repo, esta información se ve en los Message Definition Reports |
Glosario
El término ISO20022 está sobrecargado y a menudo es demasiado vago, especialmente al intentar abordar múltiples aspectos como la especificación, los datos, el meta-model y sus conceptos.
A continuación se presenta un conjunto de definiciones informales para varios conceptos principales
ISO20022
Term |
Description |
ISO20022 es un enfoque estándar único (metodología, proceso, repositorio) que deben usar todas las iniciativas de estándares financieros |
|
La ISO20022 Registration Authority es un grupo que proporciona gobernanza para la representación técnica de los artefactos del repositorio ISO20022 publicados. Para nuestros propósitos, son los mantenedores de www.iso20022.org, que suministra XSDs, E-Repository y EMF formato ISO20022 Meta-Model. |
|
El Meta-Model consiste en conceptos, reglas, tipos y relaciones que mapean formalmente la interacción para el intercambio de mensajes financieros. Hay alrededor de 100 conceptos en el modelo, que incluyen intercambios de mensajes, actividades de negocio y los roles de varias partes dentro de una actividad. |
Formatos técnicos
| Term | Description |
|---|---|
EMF es un formato de modelado de lenguajes (similar a MPS) que permite la definición de Meta-Models. El ISO2002 Meta-Model se describe en este formato y lo publica la RA. Un modelo EMF está representado en un formato de archivo .ecore. |
|
El E-repo es un archivo binario de 100Mb que contiene todos los datos ISO20022 en el formato EMF Meta-Model. Se representa como un formato de archivo .iso20022. |
|
Los MDR son documentos de referencia en varias partes que publica la ISO20022 RA y que describen varias Message Choreographies y Message Definitions. Para cada Business Area se representan como un conjunto de formatos de archivo .docx, _.pdf, _.xls. |
|
Los XSD son un formato estándar para expresar un esquema; la ISO20022 RA proporciona XSDs para cada Message Definition. Se representan como formato de archivo .xsd. |
Business Model
El ISO20022 Business Model se refiere a la parte del ISO20022 Meta-Model relacionada con Business Process y Business Components, un nivel más conceptual que las Message Model más utilizadas. Se describe con mayor detalle en las páginas de documentación del componente ISO2022-Meta.
El IPF ISO20022 Model proporciona una implementación Java pojo del Business Model para referencia y comprensión, aunque el foco de nuestros esfuerzos actuales se orienta hacia la implementación del Message Model.
Todos los business component Pojos se encuentran en los siguientes paquetes
com.iconsolutions.iso20022.business.components
dentro del siguiente artefacto
<dependency>
<groupId>com.iconsolutions.iso20022.model</groupId>
<artifactId>business-model</artifactId>
<version>${icon-iso20022-model.version}</version>
</dependency>
Message Model
El ISO20022 Message Model se refiere a la parte del ISO20022 Meta-Model relacionada con Message Definitions y Message Components. Las instancias de estos se describen comúnmente en XSDs proporcionados por ISO20022. Los detalles completos de los diversos conceptos del Message Model pueden encontrarse en la documentación ISO20022-Meta.
El resto de esta documentación se relaciona con la implementación Java del subconjunto de Message Definitions usado por IPF; esta implementación incluye serialisation y validation/constraints como se describe en la sección features.
Java Message Definitions
Todas las Message Definitions se generan en el paquete siguiente:
com.iconsolutions.iso20022.message.definitions
A continuación se muestra parte de una Message Definition Pain.001.01.09. En términos generales, es un Pojo con mejoras adicionales como Lombok builders, descripciones completas como comentarios de código, "Message Rules" adicionales (además de las reglas XSD) aplicadas como JSR303 annotations.
package com.iconsolutions.iso20022.message.definitions.payments_initiation.pain001;
/*Generated by MPS */
import com.iconsolutions.iso20022.meta.annotations.MessageDefinition;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlType;
import lombok.Builder;
import lombok.NoArgsConstructor;
import lombok.AllArgsConstructor;
import lombok.AccessLevel;
import lombok.Data;
import com.iconsolutions.ipf.payments.domain.annotation.Description;
import io.swagger.v3.oas.annotations.media.Schema;
import com.iconsolutions.iso20022.message.definitions.payments_initiation.pain001.jsr303.SupplementaryDataRule;
import com.iconsolutions.iso20022.message.meta.validation.level.MessageRule;
import java.io.Serializable;
import com.iconsolutions.iso20022.meta.annotations.MetaData;
import javax.xml.bind.annotation.XmlElement;
import jakarta.validation.constraints.NotNull;
import jakarta.validation.Valid;
import com.iconsolutions.iso20022.message.components.payment.group_header85.GroupHeader85;
import jakarta.validation.constraints.Size;
import java.util.List;
import com.iconsolutions.iso20022.message.components.payment_instruction.payment_instruction30.PaymentInstruction30;
import com.iconsolutions.iso20022.message.components.technical.supplementary_data1.SupplementaryData1;
import java.util.ArrayList;
/**
*
* Scope
* The CustomerCreditTransferInitiation message is sent by the initiating party to the forwarding agent or debtor agent. It is used to request movement of funds from the debtor account to a creditor.
* Usage
* The CustomerCreditTransferInitiation message can contain one or more customer credit transfer instructions.
* The CustomerCreditTransferInitiation message is used to exchange:
* - One or more instances of a credit transfer initiation;
* - Payment transactions that result in book transfers at the debtor agent or payments to another financial institution;
* - Payment transactions that result in an electronic cash transfer to the creditor account or in the emission of a cheque.
* The message can be used in a direct or a relay scenario:
* - In a direct scenario, the message is sent directly to the debtor agent. The debtor agent is the account servicer of the debtor.
* - In a relay scenario, the message is sent to a forwarding agent. The forwarding agent acts as a concentrating financial institution. It will forward the CustomerCreditTransferInitiation message to the debtor agent.
* The message can also be used by an initiating party that has authority to send the message on behalf of the debtor. This caters for example for the scenario of a payments factory initiating all payments on behalf of a large corporate.
* The CustomerCreditTransferInitiation message can be used in domestic and cross-border scenarios.
* The CustomerCreditTransferInitiation message must not be used by the debtor agent to execute the credit transfer instruction(s). The FIToFICustomerCreditTransfer message must be used instead.
*/
@MessageDefinition(value = "pain.001.001.09")
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "CustomerCreditTransferInitiationV09", propOrder = {"grpHdr", "pmtInf", "splmtryData"})
@Builder(toBuilder = true)
@NoArgsConstructor
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Data
@Description("Scope\r\nThe CustomerCreditTransferInitiation message is sent by the initiating party to the forwarding agent or debtor agent. It is used to request movement of funds from the debtor account to a creditor.\r\nUsage\r\nThe CustomerCreditTransferInitiation message can contain one or more customer credit transfer instructions.\r\nThe CustomerCreditTransferInitiation message is used to exchange:\r\n- One or more instances of a credit transfer initiation;\r\n- Payment transactions that result in book transfers at the debtor agent or payments to another financial institution;\r\n- Payment transactions that result in an electronic cash transfer to the creditor account or in the emission of a cheque.\r\nThe message can be used in a direct or a relay scenario:\r\n- In a direct scenario, the message is sent directly to the debtor agent. The debtor agent is the account servicer of the debtor.\r\n- In a relay scenario, the message is sent to a forwarding agent. The forwarding agent acts as a concentrating financial institution. It will forward the CustomerCreditTransferInitiation message to the debtor agent.\r\nThe message can also be used by an initiating party that has authority to send the message on behalf of the debtor. This caters for example for the scenario of a payments factory initiating all payments on behalf of a large corporate.\r\nThe CustomerCreditTransferInitiation message can be used in domestic and cross-border scenarios.\r\nThe CustomerCreditTransferInitiation message must not be used by the debtor agent to execute the credit transfer instruction(s). The FIToFICustomerCreditTransfer message must be used instead.")
@Schema(description = "Scope\r\nThe CustomerCreditTransferInitiation message is sent by the initiating party to the forwarding agent or debtor agent. It is used to request movement of funds from the debtor account to a creditor.\r\nUsage\r\nThe CustomerCreditTransferInitiation message can contain one or more customer credit transfer instructions.\r\nThe CustomerCreditTransferInitiation message is used to exchange:\r\n- One or more instances of a credit transfer initiation;\r\n- Payment transactions that result in book transfers at the debtor agent or payments to another financial institution;\r\n- Payment transactions that result in an electronic cash transfer to the creditor account or in the emission of a cheque.\r\nThe message can be used in a direct or a relay scenario:\r\n- In a direct scenario, the message is sent directly to the debtor agent. The debtor agent is the account servicer of the debtor.\r\n- In a relay scenario, the message is sent to a forwarding agent. The forwarding agent acts as a concentrating financial institution. It will forward the CustomerCreditTransferInitiation message to the debtor agent.\r\nThe message can also be used by an initiating party that has authority to send the message on behalf of the debtor. This caters for example for the scenario of a payments factory initiating all payments on behalf of a large corporate.\r\nThe CustomerCreditTransferInitiation message can be used in domestic and cross-border scenarios.\r\nThe CustomerCreditTransferInitiation message must not be used by the debtor agent to execute the credit transfer instruction(s). The FIToFICustomerCreditTransfer message must be used instead.")
@SupplementaryDataRule(groups = MessageRule.class)
public class CustomerCreditTransferInitiationV09 implements Serializable {
/**
* Set of characteristics shared by all individual transactions included in the message.
*/
@MetaData(fullName = "GroupHeader")
@XmlElement(name = "GrpHdr", required = true)
@NotNull
@Valid
protected GroupHeader85 grpHdr;
IPF Supported Message Definitions
En el momento de escribir esto, las "message definitions" actualmente soportadas por IPF incluyen:
| Message Definition Identifier | Message Definition |
|---|---|
acmt.023.001.04 |
IdentificationVerificationRequestV04 |
acmt.024.001.04 |
IdentificationVerificationReportV04 |
admi.002.001.01 |
MessageRejectV01 |
admi.004.001.02 |
SystemEventNotificationV02 |
admi.007.001.01 |
ReceiptAcknowledgementV01 |
admi.011.001.01 |
SystemEventAcknowledgementV01 |
camt.019.001.07 |
ReturnBusinessDayInformationV07 |
camt.025.001.06 |
ReceiptV06 |
camt.026.001.07 |
UnableToApplyV07 |
camt.027.001.07 |
ClaimNonReceiptV07 |
camt.028.001.09 |
AdditionalPaymentInformationV09 |
camt.029.001.09 |
ResolutionOfInvestigationV09 |
camt.052.001.08 |
BankToCustomerAccountReportV08 |
camt.054.001.10 |
BankToCustomerDebitCreditNotificationV10 |
camt.055.001.08 |
CustomerPaymentCancellationRequestV08 |
camt.056.001.08 |
FIToFIPaymentCancellationRequestV08 |
camt.087.001.06 |
RequestToModifyPaymentV06 |
head.001.001.02 |
BusinessApplicationHeaderV02 |
pacs.002.001.10 |
FIToFIPaymentStatusReportV10 |
pacs.003.001.08 |
FIToFICustomerDirectDebitV08 |
pacs.004.001.09 |
PaymentReturnV09 |
pacs.007.001.09 |
FIToFIPaymentReversalV09 |
pacs.008.001.08 |
FIToFICustomerCreditTransferV08 |
pacs.009.001.08 |
FinancialInstitutionCreditTransferV08 |
pacs.028.001.03 |
FIToFIPaymentStatusRequestV03 |
pain.001.001.09 |
CustomerCreditTransferInitiationV09 |
pain.002.001.10 |
CustomerPaymentStatusReportV10 |
pain.007.001.09 |
CustomerPaymentReversalV09 |
pain.008.001.08 |
CustomerDirectDebitInitiationV08 |
pain.013.001.07 |
CreditorPaymentActivationRequestV07 |
pain.014.001.07 |
CreditorPaymentActivationRequestStatusReportV07 |
Las Message Definitions se componen de Message Components.
Message Components
Todos los Message Components se generan en el paquete siguiente
com.iconsolutions.iso20022.message.components.<subpackage>
A continuación se muestra un extracto de un Message Component GroupHeader85. Como con las Message Definitions, los Message Components son Java beans con mejoras adicionales como Lombok builders, descripciones completas como comentarios de código, "Message Rules" adicionales (además de las reglas XSD) aplicadas como JSR303 annotations, y metadatos que relacionan los Message Components con Business Components.
package com.iconsolutions.iso20022.message.components.payment.group_header85;
/*Generated by MPS */
import com.iconsolutions.iso20022.meta.annotations.MessageComponent;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlType;
import lombok.Builder;
import lombok.AllArgsConstructor;
import lombok.AccessLevel;
import lombok.Data;
import com.iconsolutions.ipf.payments.domain.annotation.Description;
import io.swagger.v3.oas.annotations.media.Schema;
import java.io.Serializable;
import com.iconsolutions.iso20022.meta.annotations.MetaData;
import javax.xml.bind.annotation.XmlElement;
import jakarta.validation.constraints.NotNull;
import jakarta.validation.constraints.Size;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
import com.iconsolutions.ipf.payments.domain.jaxb.adapter.OffsetDateTimeFromIsoDateTimeXmlAdapter;
import javax.xml.bind.annotation.XmlSchemaType;
import java.time.OffsetDateTime;
import jakarta.validation.Valid;
import java.util.List;
import com.iconsolutions.iso20022.message.components.technical.authorisation1_choice.Authorisation1Choice;
import jakarta.validation.constraints.Pattern;
import jakarta.validation.constraints.Digits;
import java.math.BigDecimal;
import com.iconsolutions.iso20022.message.components.party_identification_information.party_identification135.PartyIdentification135;
import com.iconsolutions.iso20022.message.components.organisation.branch_and_financial_institution_identification6.BranchAndFinancialInstitutionIdentification6;
/**
* Set of characteristics shared by all individual transactions included in the message.
*/
@MessageComponent
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "GroupHeader85", propOrder = {"msgId", "creDtTm", "authstn", "nbOfTxs", "ctrlSum", "initgPty", "fwdgAgt"})
@Builder(toBuilder = true)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Data
@Description("Set of characteristics shared by all individual transactions included in the message.")
@Schema(description = "Set of characteristics shared by all individual transactions included in the message.")
public class GroupHeader85 implements Serializable {
public GroupHeader85() {
}
/**
* Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message.
Usage: The instructing party has to make sure that MessageIdentification is unique per instructed party for a pre-agreed period.
*/
@MetaData(fullName = "MessageIdentification", businessElement = "paymentIdentification.executionIdentification")
@XmlElement(name = "MsgId", required = true)
@NotNull
@Size(min = 1, max = 35)
protected String msgId;
Todas las Message Definitions y Message Components se encuentran en el artefacto siguiente
<dependency>
<groupId>com.iconsolutions.iso20022.model</groupId>
<artifactId>message-model</artifactId>
<version>${icon-iso20022-model.version}</version>
</dependency>