Documentation for a newer release is available. View Latest

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.

ISO20022 MetaModel.drawio

Conceptos del Meta-Model

Term Description

Message Model

El Message Model se refiere a la parte del meta-model que trata de las Message Definitions

Business Model

El Business Model se refiere a la parte del meta-model que trata de los Business Processes

Business Area

Un Business Area es un dominio bajo el cual se agrupan Message Definitions y otros conceptos, p. ej., Payment Initiation

Message Definition

Una Message Definition es un único tipo de mensaje que puede intercambiarse, p. ej., pain.001.001.09 (Un Customer Credit Transfer Initiation message, parte del Business Area Payment Initiation). Está compuesta por Message Components y Message Elements. Observa que "pain" es la familia del mensaje (PAyment INitiation), el 001 que sigue identifica el tipo de mensaje (en este caso Customer Credit Transfer Initiation) y 001.09 se refiere a la variant y versión del mensaje.

Message Component

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., GroupHeader85, que se usa en pain.001.001.09. Observa que 85 se refiere a la versión del componente

Message Element

Un Message Element es un atributo de tipo simple de un Message Component, p. ej., GroupHeader85.msgId

Business Component

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 CashAccount40 o SecuritiesAccount19, que se relacionan con el Business Component a través de un Trace

Business Element

Un atributo de tipo simple de un Business Component, p. ej., Account.name

Trace

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

ISO20022 es un enfoque estándar único (metodología, proceso, repositorio) que deben usar todas las iniciativas de estándares financieros

ISO20022 Registration Authority (RA)

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.

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

Eclipse Modeling Framework (EMF)

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.

ISO20022 E-Repository (E-Repo)

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.

Message Definition Report (MDR)

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.

XML Schema Definition (XSD)

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>