ISO20022 Conceptos

ISO20022 fue creado para estandarizar el intercambio de información entre las diferentes partes involucradas en los servicios financieros. Mientras ISO20022 cubre muchas áreas dentro de los servicios financieros, por ejemplo, valores, financiamiento comercial, tarjetas y cambio de divisas, el apoyo de IPF se centra en el pagos área.

Si usted es nuevo en ISO20022 entonces le recomendamos leer el gratuito SWIFT libro electrónico ISO20022 para Dummies para familiarizarse.

Meta-Modelo

El ISO20022 el modelo comprende cuatro niveles, basados en los primeros cuatro niveles de la Marco de Arquitectura Empresarial Zachmann.

Nivel Propósito

Alcance

Lograr una comprensión exhaustiva de los objetivos del área de negocio, sus procesos relevantes y los roles que las partes involucradas desempeñan en ellos.

Conceptual

Formalizando la semántica y descubriendo los requisitos de comunicación e interacción de los procesos de negocio mediante la definición de las transacciones comerciales, actividades comerciales y coreografías de mensajes relacionadas con los procesos de negocio.

Lógico

Crear una descripción precisa de los mensajes y sistemas, sin tener en cuenta cómo se implementarán, centrándose en message definition s, bloques de construcción de mensajes y elementos de mensaje.

Físico

Crear una descripción precisa de los mensajes y sistemas en una tecnología que puede ser utilizada para la implementación.

Descripción general del modelo meta

El diagrama a continuación muestra algunos conceptos y relaciones primarias dentro del modelo. Tenga en cuenta que, además de estar divididos 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 de utilizar esos objetos dentro del contexto de diversos procesos empresariales / intercambios de mensajes.

ISO20022MetaModel.drawio

Conceptos del Meta-Modelo

Término Descripción

Modelo de Mensaje

El Modelo de Mensaje se refiere a la parte del meta-modelo que trata con Message Definition s

Modelo de Negocio

El Modelo de Negocio se refiere a la parte del meta-modelo que trata sobre los Procesos de Negocio.

Área de Negocios

Un Área de Negocio es un dominio bajo el cual Message Definition s y otros conceptos están agrupados, por ejemplo.https://www.iso20022.org/sites/default/files/documents/messages/mdr_part_1/ISO20022_MDRPart1_PaymentsInitiation_2018_2019_v1.docx[Iniciación de Pago]

Message Definition

A Message Definition es un único tipo de mensaje que puede ser intercambiado, por ejemplo.pain. 001. 001. 09(A Customer Credit Transfer Iniciación mensaje, parte del Área de Negocios de Iniciación de Pagos). Se compone de Componentes de Mensaje y Elementos de Mensaje. Tenga en cuenta que "pain" es la familia de mensajes, en este caso Iniciación de PAgo, el siguiente 001 identificó el message type, en este caso Customer Credit Transfer La iniciación y 001. 09 se refiere a la variante y versión del mensaje.

Componente de Mensaje

Un Componente de Mensaje es un tipo complejo que se utilizará en uno o más Message Definition s, puede hacer referencia a otros Componentes de Mensaje o Elementos de Mensaje, p. ej.https://www.iso20022.org/standardsrepository/type/GroupHeader85[GroupHeader85], que se utiliza en pain. 001. 001. 09. Tenga en cuenta que 85 se refiere a la versión del componente.

Elemento de Mensaje

Un Elemento de Mensaje es un atributo de tipo simple de un Componente de Mensaje, por ejemplo.GroupHeader85.msgId

Componente Empresarial

Un componente empresarial es una representación más general de un tipo estándar, como un Cuenta. En realidad, es un superconjunto/arquetipo de las diversas representaciones de Cuenta de los Componentes del Mensaje, como CashAccount40 or SecuritiesAccount19, que se relacionan con el Componente de Negocio a través de un Rastreo

Elemento Empresarial

Un atributo de tipo simple de un Componente de Negocio, p. ej. Account.name

Rastro

Un rastro es un vínculo físico de un nivel de abstracción del modelo a otro. Aparte de la E-Repo esta información se ve en el Message Definition Informes

Glosario

El término ISO20022 está sobrecargado y a menudo demasiado vago, especialmente al intentar abordar múltiples aspectos como la especificación, los datos, el meta-modelo y sus conceptos.

A continuación se presenta un conjunto de definiciones informales para varios conceptos primarios.

ISO20022

Término

Descripción

ISO20022

ISO20022 es un enfoque estandarizado único (metodología, proceso, repositorio) que debe ser utilizado por todas las iniciativas de estándares financieros.

ISO20022 Autoridad de Registro (RA)

El ISO20022 La Autoridad de Registro es un grupo que proporciona gobernanza para la representación técnica de lo publicado. ISO20022 artefactos del repositorio. Para nuestros propósitos, son los mantenedores de www.iso20022.org, que suministra XSDs, E-Repository y formato EMF*ISO20022 Meta-Modelo.

ISO20022 Meta-Modelo

El Meta-Modelo 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 comerciales y los roles de las diversas partes dentro de una actividad.

Formatos técnicos

Término Descripción

Eclipse Modeling Framework (EMF)

EMF es un formato de modelado de lenguaje (similar a MPS) para permitir la definición de Meta-Modelos. El Meta-Modelo ISO2002 se describe en este formato y es publicado por la RA. Un modelo EMF se representa en un formato de archivo *.ecore.

ISO20022 E-Repository (E-Repo)

El E-repo es un archivo binario de 100Mb que contiene todos los ISO20022 datos en el formato EMF Meta-Model. Se representa como un archivo *.iso20022.

Message Definition Informe (MDR)

Los MDR son documentos de referencia multipartes que son publicados por el ISO20022 RA que describe varias Coreografías de Mensajes y Message Definition s. Para cada Área de Negocio se representan como un conjunto de archivos *.docx, *.pdf, *.xls.

XML Definición de Esquema (XSD)

Los XSD son un formato estándar para expresar un esquema, se proporcionan XSD para cada Message Definition por el ISO20022 RA. Se representan en formato de archivo *.xsd.

Modelo de Negocio

El ISO20022 El modelo de negocio se refiere a parte de la ISO20022 Meta-Modelo relacionado con el Proceso de Negocio y el Negocio Componentes, un nivel conceptual más alto que el Modelo de Mensaje más utilizado. Se describe con mayor detalle. dentro de las páginas de documentación para el componente ISO2022-Meta.

El IPF ISO20022 El modelo proporciona un Java implementación pojo del Modelo de Negocio para referencia y comprensión, aunque el enfoque de nuestros esfuerzos actuales está dirigido hacia la implementación del Modelo de Mensaje.

Todos los Pojos de componentes empresariales se pueden encontrar dentro de 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>

Modelo de Mensaje

El ISO20022 El Modelo de Mensaje se refiere a parte de la ISO20022 Modelo Meta relacionado con Message Definition s y Mensaje Componentes. Las instancias de estos se describen comúnmente en XSDs proporcionados por ISO20022. Detalles completos de los varios los conceptos del Modelo de Mensaje se pueden encontrar dentro del Documentación Meta de ISO20022.

El rest de esta documentación se refiere a la Java implementación del subconjunto de Message Definition se utiliza por IPF, este la implementación incluye serialización y validación / restricciones como se describe en características sección.

Java Message Definition s

Todo Message Definition s se generan en el siguiente paquete:

com.iconsolutions.iso20022.mensaje.definiciones

--Pain. 001. 01. 09 Message Definition. En términos generales, es un Pojo con mejoras adicionales como como Lombok constructores, descripciones completas como comentarios de código, "Reglas de Mensaje" adicionales (además de las reglas XSD) aplicadas como beanvalidation.org/1. 0/spec/[JSR303] anotaciones.

package com.iconsolutions.iso20022.message.definitions.payments_initiation.pain001;

/*Generated by MPS */

import com.iconsolutions.iso20022.meta.annotations.MessageDefinition;
import jakarta.xml.bind.annotation.XmlAccessorType;
import jakarta.xml.bind.annotation.XmlAccessType;
import jakarta.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 jakarta.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 Soportado Message Definition s

En el momento de redactar, el actual "soportado" message definition s para IPF incluyen:

Message Definition Identificador Message Definition

acmt. 023. 001. 04

Identification Verification Request V04

acmt. 024. 001. 04

Informe De Verificación De Identificación V04

admi. 002. 001. 01

Message Reject V01

admi. 004. 001. 02

System Event Notification V02

admi. 007. 001. 01

Receipt Acknowledgement V01

admi. 011. 001. 01

System Event Acknowledgement V01

camt. 019. 001. 07

Return Business Day Information V07

camt. 025. 001. 06

Receipt V06

camt. 026. 001. 07

Unable To Apply V07

camt. 027. 001. 07

Claim Non Receipt V07

camt. 028. 001. 09

Información Adicional De Pago V09

camt. 029. 001. 09

Resolution De Investigación V09

camt. 052. 001. 08

Bank To Customer Account Report V08

camt. 054. 001. 10

Bank To Customer Debit Credit Notification V10

camt. 055. 001. 08

Solicitud De Cancelación De Pago Del Cliente V08

camt. 056. 001. 08

FITo FIPayment Cancellation Request V08

camt. 087. 001. 06

Request To Modify Payment V06

head. 001. 001. 02

Business Application Header V02

pacs. 002. 001. 10

FITo FIPayment Status Report V10

pacs. 003. 001. 08

FITo FICustomer Direct Debit V08

pacs. 004. 001. 09

Payment Return V09

pacs. 007. 001. 09

FITo FIPayment Reversal V09

pacs. 008. 001. 08

FITo FICustomer Credit Transfer V08

pacs. 009. 001. 08

Transferencia De Créditos De Instituciones Financieras V08

pacs. 028. 001. 03

FITo FIPayment Status Request V03

pain. 001. 001. 09

Customer Credit Transfer Initiation V09

pain. 002. 001. 10

Informe De Estado De Pago Del Cliente V10

pain. 007. 001. 09

Reversión De Pago Al Cliente V09

pain. 008. 001. 08

Customer Direct Debit Initiation V08

pain. 013. 001. 07

Solicitud De Activación De Pago Acreedor V07

pain. 014. 001. 07

Informe De Estado De Solicitud De Activación De Pago Acreedor V07

Message Definition s están compuestos por Componentes de Mensaje.

Componentes del Mensaje

Todos los componentes del mensaje se generan en el siguiente paquete.

com.iconsolutions.iso20022.message.components.<subpackage>

A continuación se presenta un extracto de un GroupHeader85 Componente de Mensaje. Al igual que Message Definition s, Los componentes del mensaje son Java beans con mejoras adicionales tales como Lombok constructores, descripciones completas como comentarios de código, reglas adicionales de "Mensaje" (además de las reglas XSD) aplicadas como beanvalidation.org/1. 0/spec/[JSR303] anotaciones y metadatos que relacionan los Componentes del Mensaje con los Componentes de Negocio.

package com.iconsolutions.iso20022.message.components.payment.group_header85;

/*Generated by MPS */

import com.iconsolutions.iso20022.meta.annotations.MessageComponent;
import jakarta.xml.bind.annotation.XmlAccessorType;
import jakarta.xml.bind.annotation.XmlAccessType;
import jakarta.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 jakarta.xml.bind.annotation.XmlElement;
import jakarta.validation.constraints.NotNull;
import jakarta.validation.constraints.Size;
import jakarta.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
import com.iconsolutions.ipf.payments.domain.jaxb.adapter.OffsetDateTimeFromIsoDateTimeXmlAdapter;
import jakarta.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;

Todo Message Definition Los componentes de s y mensaje se pueden encontrar en el siguiente artefacto.

<dependency>
    <groupId>com.iconsolutions.iso20022.model</groupId>
    <artifactId>message-model</artifactId>
    <version>${icon-iso20022-model.version}</version>
</dependency>