Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

alert-icon-red-11.pngImage Added

 

ATTENTION:

This page has been migrated to the Tazama GitHub repository and is now located at:

https://github.com/frmscoe/docs/blob/main/Knowledge-Articles/01-Knowledge-Articles/17-ISO20022-And-Tazama.md

This page will no longer be maintained in Confluence.

Table of Contents

What is it?

ISO 20022 is a multi-part International Standard prepared by ISO Technical Committee TC68 Financial Services. It describes a common platform for the development of messages using:

...

ISO20022 is split into 3 main building blocks:

  1. The data model, which is referred to as the ISO20022 Business Model

    1. Business Model | ISO20022

  2. The data dictionary, known as the ISO20022 Repository

    1. The ISO 20022 Repository | ISO20022 :

  3. Messaging definition reports

    1. ISO 20022 Message Definitions | ISO20022

From the perspective of the 3 main building blocks of ISO20022, the impact on Actio can be broadly described as follows:

...

The business model covered a number of business domains:

Domain

Description

Actio

Common

The business components and their elements that are used to described the Business Concepts that are common to business domains.

MVP

Securities

The Securities domain provides the business components and their elements for cash movements related to transactions on equities, fixed income and other securities industry related financial instruments.

 

Payments and Cash Management

The Payments domain provides the business components and their elements for all payment activities that relate to transfer of funds between parties.

MVP

Trade Services

The Trade Services domain provides the business components and their elements related to all of the Trade Services operations that need to be reported in the statements.

 

Foreign Exchange

The Foreign Exchange domain provides the business components and their elements of all operations that are related to the foreign exchange market. Often abbreviated as FOREX.

 

Cards and Related Services

The Cards and Related Services domain provides the business components and their elements of all operations that are related to the following non-exhaustive list of financial instruments:

  • Debit card

  • Charge and credit card

  • Prepaid card

 

There are currently several thousand different business concepts identified in the business model.

...

The Payments and Cash Management domain includes a number of specific Business Areas for which messages have been classified. The following Business Areas are likely to be relevant to the Actio platform, its operator or its clients.

Business Area

Code

Description

Actio

Payments Initiation

pain

Messages that support the initiation of a payment from the ordering customer to a financial institution that services a cash account and reporting its status

MVP

Payments Clearing and Settlement

pacs

Messages that support the clearing and settlement processes for payment transactions between financial institutions

MVP

Cash Management

camt

Messages that support the reporting and advising of the cash side of any financial transactions, including cash movements, transactions and balances, plus any exceptions and investigations related to cash transactions.

 

Payments Remittance Advice

remt

Messages that support communication between creditors and debtors regarding remittance details associated with payments.

 

Account Management

acmt

Messages that support the management of account related activities, such as the opening and maintenance of an account.

 

Administration

admi

Generic messages, ie, system event notifications, generic rejections, etc…

 

Authorities Financial
Investigations

auth

Messages that support the provision of miscellaneous financial information to authorities, such as Regulators, Police,
Customs, Tax authorities, Enforcement authorities, Ministries, etc.

 

https://www.iso20022.org/sites/default/files/documents/D7/ISO20022_BusinessAreas.pdf

...

https://www.iso20022.org/business-area-message-set/366/881/download

Message ID

Description

cafr.001.001.01

A FraudReportingInitiation message is usually sent by a financial institution acting as an acquirer or as an issuer to an agent (processor, agent) to inform about a confirmed fraudulent transaction.

cafr.002.001.01

A FraudReportingResponse message is sent by an agent (processor, agent) to an issuer or acquirer in response to a FraudReportingInitiation message.

cafr.003.001.01

A FraudDispositionInitiation message is usually sent by an agent to a financial institution acting as an acquirer or as an issuer to report about the disposition of a confirmed fraudulent transaction.

cafr.004.001.01

A FraudDispositionResponse message is sent by an issuer or acquirer to an agent (processor, agent) in response to a FraudDispositionInitiation message.

Within each of the Business Areas, there are several messages defined to meet specific business model/process requirements. The messages available for pacs and pain are listed below. Note the structure of each message:

...

 

Message ID

Description

Actio

pacs.002.001.11

The FIToFIPaymentStatusReport message is sent by an instructed agent to the previous party in the payment chain. It is used to inform this party about the positive or negative status of an instruction (either single or file). It is also used to report on a pending instruction.

MVP

pacs.003.001.08

The FIToFICustomerDirectDebit message is sent by the creditor agent to the debtor agent, directly or through other agents and/or a payment clearing and settlement system.
It is used to collect funds from a debtor account for a creditor.

 

pacs.004.001.10

The PaymentReturn message is sent by an agent to the previous agent in the payment chain to undo a payment previously settled.

 

pacs.007.001.10

The FIToFIPaymentReversal message is sent by an agent to the next party in the payment chain. It is used to reverse a payment previously executed.

 

pacs.008.001.09

The FIToFICustomerCreditTransfer message is sent by the debtor agent to the creditor agent, directly or through other agents and/or a payment clearing and settlement system. It is used to move funds from a debtor account to a creditor.

MVP

pacs.009.001.09

The FinancialInstitutionCreditTransfer message is sent by a debtor financial institution to a creditor financial institution, directly or through other agents and/or a payment clearing and settlement system.
It is used to move funds from a debtor account to a creditor, where both debtor and creditor are financial institutions.

 

pacs.010.001.04

The FinancialInstitutionDirectDebit message is sent by an exchange or clearing house, or a financial institution, directly or through another agent, to the DebtorAgent. It is used to instruct the DebtorAgent to move funds from one or more debtor(s) account(s) to one or more creditor(s), where both debtor and creditor are financial institutions.

 

pacs.028.001.04

The FIToFIPaymentStatusRequest message is sent by the debtor agent to the creditor agent, directly or through other agents and/or a payment clearing and settlement system. It is used to request a FIToFIPaymentStatusReport message containing information on the status of a previously sent instruction.

 

pain.001.001.11

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.

MVP

pain.002.001.11

The CustomerPaymentStatusReport message is sent by an instructed agent to the previous party in the payment chain. It is used to inform this party about the positive or negative status of an instruction (either single or file). It is also used to report on a pending instruction.

 

pain.007.001.10

The CustomerPaymentReversal message is sent by the initiating party to the next party in the payment chain. It is used to reverse a payment previously executed.

 

pain.008.001.09

The CustomerDirectDebitInitiation message is sent by the initiating party to the forwarding agent or creditor agent. It is used to request single or bulk collection(s) of funds from one or various debtor's account(s) for a creditor.

 

pain.009.001.05

The MandateInitiationRequest message is sent by the initiator of the request to his agent. The initiator can either be the debtor or the creditor.
The MandateInitiationRequest message is forwarded by the agent of the initiator to the agent of the counterparty.
The MandateInitiationRequest message is used to setup the instruction that allows the debtor agent to accept instructions from the creditor, through the creditor agent, to debit the account of the debtor.

 

pain.010.001.05

The MandateAmendmentRequest message is sent by the initiator of the request to his agent and/or counterparty. The initiator can both be the debtor or the creditor (or where appropriate the debtor agent).
The MandateAmendmentRequest message is forwarded by the agent of the initiator to the agent of the counterparty.
A MandateAmendmentRequest message is used to request the amendment of specific information in an existing mandate. The MandateAmendmentRequest message must reflect the new data of the element(s) to be amended and at a minimum a unique reference to the existing mandate. If accepted, this MandateAmendmentRequest message together with the MandateAcceptanceReport message confirming the acceptance will be considered as a valid amendment on an existing mandate, agreed upon by all parties. The amended mandate will from then on be considered the valid mandate.

 

pain.011.001.05

The MandateCancellationRequest message is sent by the initiator of the request to his agent. The initiator can either be the debtor or the creditor.
The MandateCancellationRequest message is forwarded by the agent of the initiator to the agent of the counterparty.
A MandateCancellationRequest message is used to request the cancellation of an existing mandate. If accepted, this MandateCancellationRequest message together with the MandateAcceptanceReport message confirming the acceptance will be considered a valid cancellation of an existing mandate, agreed upon by all parties.

 

pain.012.001.05

The MandateAcceptanceReport message is sent from the agent of the receiver (debtor or creditor) of the MandateRequest message (initiation, amendment or cancellation) to the agent of the initiator of the MandateRequest message (debtor or creditor).
A MandateAcceptanceReport message is used to confirm the acceptance or rejection of a MandateRequest message. Where acceptance is part of the full process flow, a MandateRequest message only becomes valid after a confirmation of acceptance is received through a MandateAcceptanceReport message from the agent of the receiver.

 

pain.013.001.08

The CreditorPaymentActivationRequest message is sent by the Creditor sending party to the Debtor receiving party, directly or through agents. It is used by a Creditor to request movement of funds from the debtor account to a creditor.

MVP

pain.014.001.08

The CreditorPaymentActivationRequestStatusReport message is sent by a party to the next party in the creditor payment activation request chain. It is used to inform the latter about the positive or negative status of a creditor payment activation request (either single or file).

 

pain.017.001.01

The MandateCopyRequest message is sent by the initiator of the request to his agent. The initiator can either be the debtor or the creditor.
The MandateCopyRequest message is forwarded by the agent of the initiator to the agent of the counterparty.
A MandateCopyRequest message is used to request a copy of an existing mandate. If accepted, the mandate copy can be sent using the MandateAcceptanceReport message.

 

pain.018.001.01

The MandateSuspensionRequest message is sent by the initiator of the request to its agent. The initiator can either be the debtor, debtor agent, creditor or creditor agent.
A MandateSuspensionRequest message is used to request the suspension of an existing mandate until the suspension is lifted.

 

PACS MDR: https://www.iso20022.org/message/mdr/20766/download

...

Drawio
zoom1
simple0
inComment0
custContentId6324264
pageId6389792custContentId6324264
lbox1
diagramDisplayNameUntitled Diagram.drawio
contentVer1
revision1
baseUrlhttps://frmscoe.atlassian.net/wiki
diagramNameUntitled Diagram.drawio
pCenter0
width1192.5
links
tbstyle
height701.5

...

Our approach for mapping the data requirements for Actio, and specifically in relation to incoming Mojaloop data, is to:

  1. Identify the Mojaloop data fields that are available to Actio as part of the QUOTE and TRANSFER messages

  2. Group the Mojaloop data fields by ISO20022 business components, as defined in the ISO20022 data dictionary

  3. Identify a suitable data element to represent the data in the Actio platform as an ISO20022 compliant element

  4. Specify the transformation requirements for the Mojaloop field to the ISO20022 element

  5. Identify additional minimum data fields required in the ISO20022 message that are not available in the Mojaloop messages and source suitable values for these fields.

Further work will be required to design a fully compliant ISO20022 data model for Actio that includes the data that we are intending to use for the Transaction Monitoring Service.

...

View file
nameMojaloop to ISO20022 mapping - v.0.4 20210630.xlsx

Tab

Contents

Mojaloop Messages

This tab details the fields available in each of the four Mojaloop messages:

  • POST /quotes

  • PUT /quotes

  • POST /transfers

  • PUT /transfers

Each field is defined according to the Mojaloop specification:

https://github.com/mojaloop/mojaloop-specification/blob/master/fspiop-api/documents/API-Definition_v1.1.md

and Swagger definition:

https://docs.mojaloop.io/api-snippets/?urls.primaryName=v1.1

pain.001.001.11

This tab contains the mapping of the Mojaloop POST /quotes message to ISO 20022 pain.001.001.11.

A: pain.001 field XPath

B (hidden): Reconciliation with the initial Actio implementation of pain.001 to close any gaps

C: The Mojaloop equivalent for the ISO field, or a substitute/default alternative if a Mojaloop field is not available

D: The origin of the field, i.e.

  • Created: The ISO field is created/populated by the Payment Platform Adapter

  • Inferred: The ISO field is defaulted based on our understanding of the Mojaloop message

  • Calculated: The ISO field is derived based on other, related information in the Mojaloop message

  • Copied: The ISO field is directly copied from the indicated Mojaloop field.

E: The standard ISO type (field description) for the field

F: The ISO field description for the field

G: Any pertinent notes on the transformation of the field

pain.013.001.09

This tab contains the mapping of the Mojaloop PUT /quotes message to ISO 20022 pain.013.001.09.

The structure in this sheet is similar to that of pain.001.001.11.

pacs.008.001.10

This tab contains the mapping of the Mojaloop POST /transfers message to ISO 20022 pacs.008.001.10.

The structure in this sheet is similar to that of pain.001.001.11.

pacs.002.001.12

This tab contains the mapping of the Mojaloop PUT /transfers message to ISO 20022 pacs.002.001.12.

The structure in this sheet is similar to that of pain.001.001.11.

Rules Coverage

This sheet details the current identified rules and maps the rule data requirements to the pain.001.001.11 message.

POST quotes

PUT quotes

POST transfers

PUT transfers

For reference only, the original Mojaloop mapping of the messages as provided by Michael Richards of ModusBox.

Etc

The remaining tabs contain lists of values for some of the fields in the Mojaloop messages. The tab name is the field name that relates to the list of values for that field.

Mojaloop message enrichment

...