SlideShare a Scribd company logo

swift_iso20022_payments_deep_dive_2020_slides_en02.pdf

A
AyoubKhanchali1

The document provides an overview of ISO 20022, including: - What ISO 20022 is and how it differs from previous standards like MT - The governance and maintenance process for ISO 20022 messages - Examples of ISO 20022 message types for payments, securities, cash management - Details on the migration from MT to ISO 20022 for financial institution to financial institution payments, which will begin in November 2022 - How ISO 20022 enables more structured data in payments through elements like names, addresses, remittance information and identifiers

Economy & Finance
1 of 63
Downloaded 15 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Most read
18
Most read
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Most read
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
ISO 20022 Programme Quality data, quality payments Awareness Webinar – Payments Deep Dive
2 What is ISO 20022? ISO 20022 Programme - Awareness Webinar – ISO Overview
3 What is ISO 20022? Proprietary MT ISO 7775 ISO 15022 ISO 20022 Payments Treasury & Trade 1973 Securities only 1984 Securities only 1999 2004 2000 • Paper-based • Proprietary syntax • Point-to-point • One size fits all • SWIFT only • Reference standard • Electronic • Open, neutral syntax • End-to-end transaction • Market practice • SWIFT + other organisations FIN MT: Computer-processable versions of telexes ISO 20022 Programme - Quality data, quality payments ISO 20022 Governance Responsibility • Approval of the international standard • Selection of the Registration Authority and set-up of the http://www.iso20022.org • Creation of Registration Management Group (RMG) • Creation of Standards Evaluation Groups (SEG) • Registration and publication of first ‘ISO 20022 messages’ • Approval of a new edition of the international standard in 2013
4 ISO 20022 message catalogue Published on www.iso20022.org MyStandards Maintenance process – built on strict business justifications and review process - leading to new ‘versions’ of the messages ‘PAIN’ = Payment Initiation = used in Corporate-to-bank ‘PACS’ = Payment Clearing and Settlement = used in Payments ‘SESE’ = Securities settlement = used in Securities ‘SEMT’ = Securities management = used in Securities ‘SEEV’ = Securities events = used in Securities ‘CAMT’ = Cash Management + used in Payment Reporting 23 Business Areas – examples : More than 20 submitting organisations, besides SWIFT More than 320 messages, covering payments, securities, trade services, FX, cards. ISO 20022 Programme - Quality data, quality payments What is ISO 20022?
A community agreement In 2018, the global financial community agreed to migrate from the MT (FIN) payment message standard to ISO 20022 The move to ISO 20022 will begin in November 2022 and coexistence with MT (FIN) will run until November 2025 All players need to start preparing for the migration now to be ready for November 2022 All FI to FI payments and cash reporting messages will move to ISO 20022 ISO 20022 Programme - Quality data, quality payments 5
Why is the Industry Adopting ISO 20022? Enabling a hyper-connected payment world Payments revolution Payments are rapidly transforming, with new players world-wide, transforming to meet the customer requirements and improving the customer experience. ISO payment and report formats are a key element of this transformation Domestic modernization Real time payments are quickly becoming the consumer payment method of choice and will quickly be an international payment option 24/7. ISO systems Global payments innovation SWIFT gpi is driving unprecedented change – delivering fast, transparent and trackable cross-border payments A hyper-connected payment world Through global harmonization of payment formats we are prepared for a future where complex and data rich payments move through any domestic and/or cross- border payment system, and are credited to beneficiaries – Instantly. Regulatory requirements Facilitates complying with ever changing and broader regulatory requirements. ! ISO 20022 Programme - Awareness Webinar – ISO Overview 6
7 The changing language of payments ISO 20022 Programme - Quality data, quality payments
What is changing? ISO 20022 Programme - Quality data, quality payments 8 Field names
ISO 20022 Programme - Quality data, quality payments 9 SWIFT MT versus ISO 20022: Key Concepts Element Field Message specification components Parties in a message DataType Format Min Max Presence CodeSet Qualifiers / Codes ISO 20022 MT Textual Rule Usage Rule CrossElementComplexRule Network Validated Rule Agent Bank Debtor Ordering Customer Creditor Beneficiary Customer Instructing Agent Message Sender Instructed Agent Message Receiver Legend:
New Parties :XX FIN MT format equivalent ISO 20022 Payment Originator Payments Clearing & Settlement (pacs) Payment Beneficiary Ultimate Debtor Forwarding Agent Debtor Initiating Party :50a Debtor Agent :52a 1 2 3 1 2 3 1 2 3 Ultimate Creditor Creditor Previous Instructing Agents Instructing Agent Instructed Agent Creditor Agent Reimbursement Agents Intermediary Agents :59a :57a :53a :54a :55a :56a :72:/INS/ :72:/INT/ Sender Receiver Legend: New parties introduced in ISO 20022 :70:/INST/ :50C/L :50C/L :70:/ULTB/ 10 ISO 20022 PROGRAMME - QUALITY DATA, QUALITY PAYMENTS
ISO 20022 Programme - Quality data, quality payments 11 MT 103 Customer Credit Transfer serial message flow MT 103 MT 103 MT 103 MT Party 11 Ordering Customer Ordering Institution Intermediary Institution Intermediary Institution Account with Institution Beneficiary A B C D The MT key concepts
pacs.008 pacs.008 pacs.008 pacs.008 Party ISO 20022 Programme - Quality data, quality payments 12 pacs.008 FI To FI Customer Credit Transfer serial message flow A B C D Debtor Debtor’s Agent Intermediary Agent 1 Intermediary Agent 2 Creditor’s Agent Creditor The ISO 20022 key concepts
What is changing? ISO 20022 Programme - Quality data, quality payments 13 Character sets
ISO 20022 Programme - Quality data, quality payments Special characters are additionally allowed in: • All party (agents and non-agents) Name and Address elements • The Related Remittance Information elements • The Remittance Information (structured & unstructured) elements List of special characters: !#&%*=^_’{|}~";@[] Additionally special characters $ and > < signs are enabled for the Email Address elements Currencies in the payments should be expressed in ISO Currency Codes only (3- Characters, e.g. EUR) Character Set Translation of any special character: !#&%*=^_’{|}~";@[]$ >< into MT messages will be represented by a . (Full Stop) All SWIFT ISO MX message elements (fields) which are defined (by data Type) as text are restricted to FIN X Characters: a-z A-Z 0-9 / - ? : ( ) . , ' + . $ < > ! # & % * = [ ] Note: While ISO 20022 base standards support non-Latin characters, CBPR+ will only support Latin characters in Phase 1 and Phase 2 U 14
What is changing? ISO 20022 Programme - Quality data, quality payments 15 Message Structure
16 ISO 20022 XML message identifier ISO 20022 Programme - Quality data, quality payments 4!a . 3!c . 3!n . 2!n Version Variant Message identifier/functionality Business area pacs.008.001.08 Version 8 Variant 1 FI To FI Customer Credit Transfer Payments Clearing and Settlement Example
17 How is an MT structure different from an MX structure? ISO 20022 Programme - Quality data, quality payments MT ISO 20022 (MX) <AppHdr> … </AppHdr> <Document> … </Document> ISO 20022 Business Application Header ISO 20022 Message Business Message
ISO 20022 Programme - Quality data, quality payments 18 Structured data becomes the new norm ISO 20022 Debtor data element example Customer data record example MT – free format option Debtor Name JOHN HECTOR JOSEPH SMITH - MASTERSONS :50K:/BE3000121637141 JOHN HECTOR JOSEPH SMITH – MASTERSONS HOOGSTRAAT 6 BRUSSELS 1000 BELGIUM ID:1111111111 Postal Address Department Sub Department Street Name HOOGSTRAAT Building Number 6 MT – structured option with risk of potential truncation & loss of info Post Code 1000 :50F:/BE3000121637141 1/JOHN HECTOR JOSEPH SMITH - 1/MASTERSONS 2/HOOGSTRAAT 6 3/BE/BRUSSELS 1000 Town Name BRUSSELS Country BE Identification Private Identification – Other Identification 1111111111 Debtor Account Identification IBAN BE3000121637141 Passport number is lost! Richness of ISO 20022 allows more granular data structure
What is changing? ISO 20022 Programme - Quality data, quality payments 19 Message types
ISO 20022 Programme - Quality data, quality payments 20 CBPR+ Phase 1 usage guidelines and planned translation rules Updated April 2020 U Existing FIN MTs ISO 20022 equivalent Usage guidelines Translation rules planned MT 103 / 102 pacs.008.001.0x Published on MyStandards Published on MyStandards MT 200 / 201 / 202 / 202 COV / 203 / 205 pacs.009.001.0x Published on MyStandards MT 103 RETURN / MT 202 RETURN pacs.004.001.0x Published on MyStandards MT 103 REJECT / MT 202 REJECT Negative pacs.002.001.0x MX to MT only SWIFT to Investigate Field 72 option or MT 199 No Equivalent Positive pacs.002.001.0x No translation planned MT 210 camt.057.001.0x Published on MyStandards MX to MT - Single MT 900 / 910 camt.054.001.0x Published on MyStandards MT 941 / 942 camt.052.001.0x No translation planned MT 940 / 950 camt.053.001.0x Not required – Guidance in UHB MT 920 camt.060.001.0x No translation planned head.001.001.0x – v2 Published with each request type N/A
ISO 20022 Programme - Quality data, quality payments 21 CBPR+ Phase 1 usage guidelines and planned translation rules Existing FIN MTs ISO 20022 equivalent Usage guidelines Translation rules planned MT 103 STP Pacs.008 STP Guideline Under development No translation planned MT 103 STP EU Pacs.008 EEA Guidelines To be planned No translation planned MT 204 Pacs.010 Under Development From MX to MT only MT 104 Pacs.003 Out of scope Out of scope head.001.001.0x – v2 Published with each request type N/A CBPR+ Phase 2 usage guidelines and planned translation rules Existing FIN MTs ISO 20022 equivalent Usage Guideline available on Mystandards & Readiness Portal Translation rules planned 192/292 (Cancellation Request) camt.056.001.0x - Cancellation Request In collaboration with gpi expert group To be confirmed Camt.026 – Unable to Apply Camt.027 – Claim Non Receipt Camt.087 – Request to Modify 296/199/299/112 (Query/Answer) camt.029.001.0x - Resolution of Investigation MT 101 Pain.001 Wait for CGI deliverable To be confirmed MT 110/MT 111/MT 112 New Cheques Messages Start development during June 2020 Workshop To be confirmed MT n90 / MT n91 New Fee Messages Start development during June 2020 Workshop To be confirmed
22 Overview of usage guidelines ISO 20022 Programme - Quality data, quality payments
ISO 20022 Programme - Quality data, quality payments Messages index pacs.008 - Financial Institution to Financial Institution Customer Credit Transfer pacs.009 (core) - Financial Institution Credit Transfer pacs.009 (cov) - Financial Institution ‘Cover’ Credit Transfer pacs.002 – FI To FI Payment Status Report pacs.004 – Payment Return Payment, Clearing and Settlement (pacs) messages U 23
pacs.008 ISO 20022 Programme - Quality data, quality payments 24 Financial Institution to Financial Institution Customer Credit Transfer
25 pacs.008 FI to FI Customer Credit Transfer pacs.008 Group Header Credit Transfer Transaction Information The pacs.008 has two core sets of nested element: Group Header which contain a set of characteristics that relate to all individual transactions Credit Transfer Transaction Information which contains elements providing information specific to the individual credit transfer transaction. A typical payment message in a many-to-many payment would be considered as a single transaction. The Industry CBPR+ committeee has decided that the pacs.008 will carry a single transaction as a best practice. It is however possible, where bilateral agreed, to include re-occurring Credit Transfer Transaction Information i.e. multiple payments, perhaps more associated with an early leg in the payment lifecycle, where upon these multiple transaction would typically be split into individual payment transactions. ISO 20022 Programme - Quality data, quality payments
26 MT 103 Customer Credit Transfer High Level Serial message flow MT 103 MT 103 MT 103 A B C D The MT way Originator Originating Bank Sending Bank Receiving Bank Beneficiary Bank Beneficiary Current serial MT 103 payment flow as the payment moves across the payment bank chain. MT 900s are generally used to confirm transaction execution to originating banks ISO 20022 Programme - Quality data, quality payments MT 900 MT 900 MT 900 Payment Initiation MT101 PAIN001 via FileAct Proprietary Payment Reporting MT9XX camt 5X via FileAct Proprietary
27 pacs.008 FI to FI Customer Credit Transfer High Level serial message flow The ISO 20022 way pacs.008 pacs.002 A B C D pacs.008 pacs.008 pacs.002 pacs.002 Debtor Debtor Agent Instructing Agent Instructed Agent Creditor Agent Creditor The new party names are shown in this ISO pacs 008 payment message flow, When the customer credit transfer migrates to the pacs 008, there is an option to provide payment status messages utilizing the pacs 002 message. The pacs 002 is a point to point status message and does not carry full comprehensive status information like the gpi tacker service The pacs 002 or the camt.054 can be used to confirm transaction execution to originating banks. ISO 20022 Programme - Quality data, quality payments Payment Initiation MT101 PAIN001 via FileAct Proprietary Proprietary Payment Reporting MT9XX camt 5X via FileAct camt.054 camt.054 camt.054
Agent D credits the account of the Creditor, and may optionally provide a notification e.g. notification of credit in addition to an account statement (camt.053) 28 pacs.008 FI to FI Customer Credit Transfer High Level Use Case settled over a Payment Market Infrastructure pacs.008 pacs.002 1 1 Debtor initiates a payment instruction to the Debtor Agent Debtor Agent (A) initiates a serial payment towards the Creditor Agent (D) using Agents B & C as intermediaries, who are direct participant of the Payment Market Infrastructure 3 Agent B processes the payment on Agent C, via the Payment Market Infrastructure. 4 Payment Market Infrastructure, settles the payment between Agent B and Agent C as direct participants of the Market Infrastructure, and provides a settlement confirmation to Agent B pacs.008 pacs.008 pacs.008 pacs.002 pacs.002 2 2 3 4 5 Settlement Complete 6 5 Agent C processes the payment on Agent D 6 A B C D ISO 20022 Programme - Quality data, quality payments The ISO 20022 way Each MI will determine their method of confirmation but the 002 is the standard ISO message.
pacs.009 (core) & pacs.009 (cov) ISO 20022 Programme - Quality data, quality payments 29 Financial Institution Credit Transfer
30 pacs.009 core versus cov pacs.009 (core) Group Header Credit Transfer Transaction Information pacs.009 (cov) Group Header Credit Transfer Transaction Information Underlying Customer Credit Transfer The pacs.009 has two main use cases: • as a core Financial Institution to Financial Institution Credit Transfer message, and • As a cov where it is used as cover of (to settle) a pacs.008. The pacs.009 therefore contain information of the underlying Customer Credit Transfer (pacs.008) for use in the cover scenario, which is the key attribute to differentiate between these two use cases. ISO 20022 Programme - Quality data, quality payments
31 MT 202 FI to FI Credit Transfer High Level message flow MT 202 A B C D The Financial Institution Credit Transfer 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. The MT way ISO 20022 Programme - Quality data, quality payments MT 202 MT 202 Originating FI Sending FI Receiving FI Beneficiary FI MT 900 MT 900 MT 900
32 pacs.009 FI to FI Credit Transfer High Level message flow pacs.009 pacs.009 pacs.009 pacs.002 pacs.002 pacs.002 A B C D The Financial Institution Credit Transfer 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. ISO 20022 Programme - Quality data, quality payments The ISO 20022 way Debtor FI Creditor FI Instructing FI Instructed FI camt.054 camt.054 camt.054
ISO 20022 Programme - Quality data, quality payments 33 MT 103 Customer Credit Transfer High Level message flow settled using the MT 202 cover method MT 103 MT 202 cov A B C D Note: For example purposes, this slide shows V-shape payment market infrastructure flows. Y-shape flows will be different. The MT way Payment Initiation MT101 PAIN001 via FileAct Proprietary Proprietary Payment Reporting MT9XX camt 5X via FileAct Originating Bank Originator Sending Bank Receiving Bank Beneficiary Sending Bank Receiving Bank Beneficiary Bank
34 pacs.009 cov FI to FI Credit Transfer High Level message flow demonstrating the change in party roles between messages pacs.009 cov pacs.009 cov The Financial Institution Credit Transfer cover 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 important to recognize that some roles change between these parallel messages. pacs.009 cov pacs.002 pacs.002 pacs.002 pacs.008 pacs.002 pacs.008 pacs.009 cov Party Debtor Debtor Creditor Creditor Creditor Agent Debtor Agent Underlying Debtor Underlying Creditor C D A B Payment Initiation MT101 PAIN001 via FileAct Proprietary Payment Reporting MT9XX camt 5X via FileAct Proprietary Debtor Creditor The correspondent banking cover payment method utilises both the pacs.008 and pacs.009 cov. The UETR element within these messages contain the same UETR which effectively interlink the messages. As an interlinked message it is important to understand the way certain parties change their role in the pacs.009 cov This is demonstrated in the example ISO 20022 Programme - Quality data, quality payments The ISO 20022 way
ISO 20022 Programme - Quality data, quality payments 35 MT 103 Customer Credit Transfer High Level message flow settled using the MT 202 cover method Via MI MT 103 MI COV MI COV A B C D Note: For example purposes, this slide shows V-shape payment market infrastructure flows. Y-shape flows will be different. The MT way Payment Initiation MT101 PAIN001 via FileAct Proprietary Proprietary Payment Reporting MT9XX camt 5X via FileAct MI Confirm Beneficiary Beneficiary Bank Originator Originating Bank Sending Bank Receiving Bank Receiving Bank Sending Bank
Agent C produces an end of day account statement report. An optional real time notifications e.g. advice of credit may have also been created at the time of the credit posting Agent C receives the payment and credits the account of Agent D Agent B processes the payment on Agent C, via the Payment Market Infrastructure. 36 pacs.008 FI to FI Customer Credit Transfer High Level Use Case settled using pacs.009 COV over a Payment Market Infrastructure pacs.008 pacs.002 pacs.009 cov 1 1 Debtor initiates a payment instruction to the Debtor Agent 2a Debtor Agent (A) initiates a payment using the cover method to the Creditor Agent (D) 2a 2b 2b In parallel the Debtor Agent (A) initiates a covering payment to credit the account of Agent (D) with their correspondent (Agent C) 3 5 6 6 4 3 7 pacs.009 cov Settlement Complete pacs.002 Agent D reconciles the covering funds and credits the account of the Creditor, and may optionally provide a notification e.g. notification of credit. 7 Payment Market Infrastructure, settles the payment between Agent B and Agent C as direct participants of the Market Infrastructure, and provides a settlement confirmation to Agent B 4 5 A D B C Payment Initiation MT101 PAIN001 via FileAct Proprietary Payment Reporting MT9XX camt 05X via FileAct Proprietary ISO 20022 Programme - Quality data, quality payments The ISO 20022 way Market Infrastructure will either conform to HVPS+ guidelines or establish their own usage guidelines based on the ISO 20022 standard.
pacs.002 ISO 20022 Programme - Quality data, quality payments 37 Status Information
ISO 20022 Programme - Quality data, quality payments pacs.002 Status Information pacs.002 Group Header Transaction Information And Status The Financial Institution To Financial Institution Payment Status Report 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 38
Agent B processes the payment on Agent C. Status Messages can follow ISO 20022 Programme - Quality data, quality payments 39 pacs.002 Payment Status Information High Level Use Case of multiple Payment Transaction Status updates pacs.008 pacs.002 1 1 Debtor initiates a payment instruction to the Debtor Agent 2 Debtor Agent (A) initiates a serial payment towards the Creditor Agent (D) using Agents B & C as intermediaries 5 4 3 Agent B provides a status update ACTC (accepted technical validations are successful) to Agent A, based upon a bilateral agreement. 4 3 pacs.008 pacs.008 2 5 pacs.002 Agent B provides a further status update ACSP (accepted settlement in progress) to Agent A, based upon a bilateral agreement. pacs 002 or camt.054 for final confirmation. An agent may provide multiple Payment Status Information updates (with different Transaction Status codes), where bilaterally agreed, throughout the payment processing lifecycle i.e. from receipt through to onward processing. B C A D The code list representing the Payment Transaction Status is part of the ISO 20022 external code list pacs.002 pacs.002 CBPR+ restricted the pacs.002 to a single transaction camt.054
ISO 20022 Programme - Quality data, quality payments 40 Payment Transaction Status Code definitions Code Name ISO Definition pacs High Level Use Case ACCC AcceptedSettlementCompleted Settlement on the creditor's account has been completed. Sent by Credit Agent to confirm the settlement on the creditor’s account ACCP AcceptedCustomerProfile Preceding check of technical validation was successful. Customer profile check was also successful. Sent by any Agent in the payment chain to confirm acceptance prior to technical validation. ACSC AcceptedSettlementCompleted Settlement on the debtor's account has been completed. Sent by the Debtor Agent to confirm settlement on the debtor account prior to payment execution. ACSP AcceptedSettlementInProcess All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. Sent by any Agent to the to confirm the payment is accepted following technical validations being successfully completed. ACTC AcceptedTechnicalValidation Authentication and syntactical and semantical validation are successful Sent by any Agent in the payment chain to the previous Agent to confirm the payment is accepted following technical validations being successfully completed. ACWC AcceptedWithChange Instruction is accepted but a change will be made, such as date or remittance not sent. Sent by any Agent in the payment chain to the previous Agent to confirm the payment is accepted following amendments being made. ACWP AcceptedWithoutPosting Payment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account. Sent by Credit Agent to the previous Agent to confirm the acceptance of payment without settlement on the creditor’s account, PDNG Pending Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed. Sent by any Agent in the payment chain to the previous Agent as an interim status whilst other validations are performed. RCVD Received Payment initiation has been received by the receiving agent. Sent by Any Agent to the previous Agent as confirmation that their Customer Credit Transfer initiation request has been received by the payment engine. RJCT Rejected Payment initiation or individual transaction included in the payment initiation has been rejected. Sent by Any Agent to inform the previous Agent that their Customer Credit Transfer has been rejected.
pacs.004 ISO 20022 Programme - Quality data, quality payments 41 Payment Return
ISO 20022 Programme - Quality data, quality payments pacs.004 Payment Return pacs.008 Group Header Credit Transfer Transaction Information pacs.009 cov Group Header Credit Transfer Transaction Information Underlying Customer Credit pacs.004 Group Header Transaction Information Original Group Information Original Transaction Reference In a similar structure to the pacs.009 (cov) underlying Customer Credit Transfer, the pacs.004 Return Payment message has amongst other elements Original Group Information which captures original information such as the Original UETR and Original Interbank Settlement Amount etc. and an Original Transaction Reference which contain the key elements of the original payment e.g. Debtor, Creditor etc. U 42
ISO 20022 Programme - Quality data, quality payments 43 pacs.002 Payment Reject and pacs.004 Return Flow High Level Use Case and key considerations. Within the pacs.004 Return Payment • the Original Group Information element is used to refers to original message for which the return relates to. e.g. based upon the above example pacs.008 as the original message would be included in the pacs.004 • the Transaction Information > Original UETR element would include UETR of the message received. i.e. the same UETR is used on the Return Payment. • the Original Transaction Reference element includes detail from the original message. e.g. the Debtor of the original pacs.008. • the Return Chain element includes the parties in return payment chain, noting the parties reverse (i.e. change role) from the original payment whereby the Debtor of the original payment becomes the Creditor in the Return Chain. • A reason code is added to the Return message to inform the agent of the reason for the return (e.g. AC04 Account closed) pacs.008 pacs.004 pacs.004 pacs.008 pacs.008 + Return Reason + Return Reason pacs.002 + Reject Reason B C A D The code list representing the Return Reason is part of the ISO 20022 external code list The Payment Return message is sent by an agent to the previous agent in the payment chain to undo a payment previously settled.
Creditor determines that they wish to return the payment e.g. they are unable to apply, and instructs their bank (Agent D) to return the payment together with the reason. Agent C processes the payment on Agent D Agent B processes the payment on Agent C Payment Return (pacs.004) of a complete Customer Credit Transfer (pacs.008) pacs.008 pacs.004 pacs.004 1 1 Debtor initiates a payment instruction to the Debtor Agent 2 Debtor Agent (A) initiates a serial payment towards the Creditor Agent (D) using Agents B & C as intermediaries 3 4 7 Agent C return funds to Agent B, together with the reason code for return. Agent B return funds to Agent A, together with the reason code for return. 8 8 pacs.008 pacs.008 + Return Reason + Return Reason 2 3 4 pacs.004 + Return Reason 5 6 Agent D credits the account of the Creditor, and may optionally provide a notification e.g. notification of credit in addition to an account statement (camt.054) 5 6 Agent D returns the payment to Agent C using a Payment Return message (pacs.004) also including the return reason code. . A B C D 7 Use Case p.4.1.2 ISO 20022 Programme - Quality data, quality payments The code list representing the Return Reason is part of the ISO 20022 external code list
ISO 20022 Programme - Quality data, quality payments 45 Payment Transaction Return Reason Code definitions examples (74 total) Code Name Definition AC01 IncorrectAccountNumber Format of the account number specified is not correct AC03 InvalidCreditorAccountNumber Wrong IBAN in SCT AC04 ClosedAccountNumber Account number specified has been closed on the bank of account's books AC06 BlockedAccount Account specified is blocked, prohibiting posting of transactions against it. AC13 InvalidDebtorAccountType Debtor account type is missing or invalid AC14 InvalidAgent An agent in the payment chain is invalid. AC15 AccountDetailsChanged Account details have changed. AC16 AccountInSequestration Account is in sequestration. AC17 AccountInLiquidation Account is in liquidation. AG01 TransactionForbidden Transaction forbidden on this type of account (formerly NoAgreement) AG02 InvalidBankOperationCode Bank Operation code specified in the message is not valid for receiver AM01 ZeroAmount Specified message amount is equal to zero Rejected by Network AM02 NotAllowedAmount Specific transaction/message amount is greater than allowed maximum AM03 NotAllowedCurrency Specified message amount is an non processable currency outside of existing agreement AM04 InsufficientFunds Amount of funds available to cover specified message amount is insufficient. AM05 Duplication Duplication
46 Cross Border Payments & Reporting (CBPR+) Working Group ISO 20022 Programme - Quality data, quality payments
ISO 20022 Programme - Quality data, quality payments 47 CBPR+ : A group of your peer banks advising SWIFT on how ISO 20022 should be used Objective Create global ISO 20022 Market Practice and Usage Guidelines for selected messages from the SWIFT MT Category 1, 2 & 9 set of messages, which will be validated on the SWIFT network in the many to many space. With the approach of  Benefiting from ISO 20022 features, and not alike for like adoption from SWIFT MT  Interoperable with high value payment system (HVPS+) guidelines*, while differences should be justified and documented  Incorporating gpi requirements, such as UETR  Incorporating securities requirements, for the cash-leg of a securities transactions  Including new messages & functionalities where required, e.g. Return & Status messages  Validated on the SWIFT network  Maintained on a yearly basis  Develop Translation Rules HVPS+: A working group of payment marketing infrastructure operators advising SWIFT on how ISO 20022 should be used for high value payment systems. HVPS+ has established usage guidelines for this purpose
MT 103/MX pacs 008 Customer Credit Transfer – Correspondent Bank High Level Serial message flow MT 103 A B C Translation Flow Originator (Debtor) Originating Bank (MT) (Debtor Agent) Sending Bank (MX) (Instructed Bank) Receiving Bank (MX) (Instructed Bank) Beneficiary (Creditor) In the early days of the ISO migration Coexistence Period there will be payment scenarios where translation will be required for a payment to be completed to the Beneficiary/Creditor When the originating Bank sends an MT format, the process will be very straight forward as there will be no excess data due to new fields or field length mismatches. Payment Initiation MT101 PAIN001 via FileAct Proprietary Proprietary Payment Reporting MT9XX camt 5X via FileAct ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted T MX pacs 008 48
MX pacs 008/MT 103 FI to FI Customer Credit Transfer-Correspondent Bank High Level serial message flow Embedded MT in MX Flow A B C MX pacs.008 pacs.008 Debtor Debtor Agent (MX) Instructing Agent(MX) Instructed Agent (MT) Creditor During the Coexistence Period when the Debtor Agent initiates an MX and a translation to MTs required there can be payment scenarios where additional fields, and, additional data in those fields, may result in an excess data condition. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Payment Initiation MT101 PAIN001 via FileAct Proprietary Payment Reporting MT9XX camt 5X via FileAct Proprietary T MT 103 pacs.002 SWIFT Cloud 49
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted <IntrmyAgt1> <FinInstnId> <BICFI>BDLIITGGXXX</BICFI> <ClrSysMmbId> <ClrSysId> <Cd>ITNCC</Cd> </ClrSysId> <MmbId>0123401600</MmbId> </ClrSysMmbId> <Nm>Banca dei Lavoratori Italiani</Nm> </FinInstnId> </IntrmyAgt1> <IntrmyAgt1Acct> <Id> <IBAN>IT27Z0123401600000000148292</IBAN> </Id> </IntrmyAgt1Acct> Example MX/MT Agent Field Tag (e.g. 56) Type A Format MX :56A:/IT27Z0123401600000000148292 BDLIITGGXXX MT 50
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Agent Field Tag (e.g.56) Type D Format <IntrmyAgt1> <FinInstnId> <ClrSysMmbId> <ClrSysId> <Cd>ITNCC</Cd> </ClrSysId> <MmbId>0123401600</MmbId> </ClrSysMmbId> <Nm>Banca dei Lavoratori Italiani</Nm> <PstlAdr> <StrtNm>Via dei Gigli</StrtNm> <BldgNb>1</BldgNb> <BldgNm>Palazzo Viola</BldgNm> <Flr>7 Piano</Flr> <PstCd>20100</PstCd> <TwnNm>Milano</TwnNm> <TwnLctnNm>Quartiere Isola</TwnLctnNm> <DstrctNm>Provincia di Milano</DstrctNm> <CtrySubDvsn>Lombardia</CtrySubDvsn> <Ctry>IT</Ctry> </PstlAdr> </FinInstnId> </IntrmyAgt1> MX :56D://IT0123401600 Banca dei Lavoratori Italiani Via dei Gigli,1,Palazzo Viola,7 Pi+ IT/Milano,20100,Quartiere Isola,Lom bardia,Provincia di Milano MT 51
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Debtor/Creditor (50,59) Unstructured Name and Address <Dbtr> <Nm>Hamburgische Hochwertige Landesbank eG</Nm> <PstlAdr> <AdrLine>Gebaude 5</AdrLine> <AdrLine>Hafenstrasse 7</AdrLine> <AdrLine>22767 Hamburg, DE</AdrLine> </PstlAdr> <CtryOfRes>DE</CtryOfRes> </Dbtr> <DbtrAcct> <Id> <Othr> <Id>123</Id> </Othr> </Id> </DbtrAcct> MX :50K:/123 Hamburgische Hochwertige Landesban+ Gebaude 5 Hafenstrasse 7 22767 Hamburg, DE MT 52
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Debtor/Creditor (50,59) Structured Name and Address <Dbtr> <Nm>Mueller Weltweit Handels GmbH</Nm> <PstlAdr> <StrtNm>Hafenstrasse</StrtNm> <BldgNb>7</BldgNb> <BldgNm>Willy-Brandt Gebaude</BldgNm> <Flr>3 OG</Flr> <PstBx>1203</PstBx> <Room>C3B</Room> <PstCd>22767</PstCd> <TwnNm>Hamburg</TwnNm> <TwnLctnNm>St. Pauli</TwnLctnNm> <Ctry>DE</Ctry> </PstlAdr> <Id> – <OrgId> – <LEI>TX1DBTRORGIDLEI67890</LEI> – </OrgId> </Id> <CtryOfRes>DE</CtryOfRes> </Dbtr> <DbtrAcct> <Id> <IBAN>DE25390200000004711001</IBAN> </Id> </DbtrAcct> MX :50F:/DE25390200000004711001 1/Mueller Weltweit Handels GmbH 2/Hafenstrasse,7,Willy-Brandt Geba+ 3/DE/Hamburg,22767,St. Pauli 6/DE/LEIC/TX1CDTRORGIDLEI67890 MT 53
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted The MT Remittance Information is translated applying prioritizing the information. Information is likely to be truncated and identified in most cases with the sign “+” at the end of the translated information. If a full element is not copied an Error Handling mechanism will be defined to report the missing information. In all cases, UltimateDebtor and UltimateCreditor will have the highest translation priority in the MT Field 70. Logic When the originating message is MX, the MT remittance information is translated with the following identifiers: • /ULTB/ - UltimateCreditor information prioritized as Name/Country [/TownName]. TownName is optional or (Name/OtherId) or Name alone or OtherId alone. • /ULTD/ - UltimateDebtor information prioritized as Name/Country/TownName. TownName is mandatory or (Name/OtherId) or Name alone or OtherId alone. • /PURP/ - purpose of the payment • /ROC/ - EndToEndIdentification when /ROC/ is not present in UnstructuredRemittanceInformation and value different from “NOTPROVIDED”. • /URI/ - the MX unstructured remittance information • /RELID/ - 1 or 2 identifications of the RelatedRemittanceInformation stored outside the message • /SRI/+ - means that structured remittance information is present in the original message but is not translated. Note: /URI/, /RELID/ and /SRI/+ are mutually exclusive meaning cannot be present together (even not by pair). Remittance Information Mapping - Definition 54
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Remittance Information (70) <CdtTrfTxInf> <PmtId> <InstrId>INSTRID-TMP001</InstrId> <EndToEndId>END2ENDID-TMP001</EndToEndId> <UETR>4f334519-092f-49fa-acf9-ce93c267ac8c</UETR> </PmtId> […] <UltmtDbtr> <Nm>Tower and Town Inc.</Nm> </UltmtDbtr> […] <UltmtCdtr> <Nm>Sivesh S</Nm> </UltmtCdtr> <RmtInf> <Ustrd>BELEG 1301 2019 RG.OPTIK/03/19-20 V.312589RG.OPTIK/ 02/19-20 V.200619</Ustrd> </RmtInf> </CdtTrfTxInf> MX :70:/ULTB/Sivesh S///ULTD/Tower and Tow n Inc.///ROC/END2ENDID-TMP001///URI /BELEG 1301 2019 RG.OPTIK/03/19-20 V.312589RG.OPTIK/ 02/19-20 V.200619 MT 55
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Bank to Bank Information Mapping - Definition Depending on the space available and the presence of the elements in the MX message, the following priorities and order are applied to field 72 Bank to Bank Information: • /INTA/ - IntermediaryAgent 2 & 3* • /SVCLVL/ - PaymentTypeInformation/ServiceLevel *(excluding 23E code – SDVA and G00n gpi codes) • /LOCINS/ - PaymentTypeInformation/LocalInstrument *(excluding 23B codes) • /CATPURP/ - PaymentTypeInformation/CategoryPurpose *(excluding 23E codes) • /ACC/ - InstructionForCreditorAgent (excluding 23E codes) • /REC/ - InstructionForNextAgent (excluding /FIN54/**) • /INS/ - PreviousInstructingAgent1,2,3 Logic Note: Possible missing (Error Handling mechanism will be defined to report the missing information) or truncated information can apply. *means new code words to be used in Field72 **/FIN54/ with BIC is used in a specific scenario in MT to indicate where the receiver will claim the money. This code word will be present only if a previous MT to MX translation already occurred. 56
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Bank to Bank Information (72) <PmtTpInf> <SvcLvl> <Prtry>Single Euro Payments Area</Prtry> </SvcLvl> <LclInstrm> <Prtry>Cash Concentration Intragroup</Prtry> </LclInstrm> </PmtTpInf> <IntrmyAgt2> <FinInstnId> <BICFI>BCITITMMXXX</BICFI> </FinInstnId> </IntrmyAgt2> <IntrmyAgt3> <FinInstnId> <BICFI>BARCIE22XXX</BICFI> </FinInstnId> </IntrmyAgt3> <InstrForNxtAgt> <InstrInf>Instruction number 1</InstrInf> </InstrForNxtAgt> <InstrForNxtAgt> <InstrInf>Instruction number 2</InstrInf> </InstrForNxtAgt> </CdtTrfTxInf> MX :72:/INTA/BCITITMMXXX /INTA/BARCIE22XXX /SVCLVL/Single Euro Payments Area /LOCINS/Cash Concentration Intragro //up /REC/Instruction number 1Instructi+ MT 57
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example of Regulatory Reporting Information <Cdtr> <Nm>ABC IMPORTS AND EXPORTS (INDIA) </Nm> <PstlAdr> […] </PstlAdr> <Id> <OrgId> <LEI>335800HMLW2U4UHRBW65</LEI> </OrgId> </Id> <CtryOfRes>DE</CtryOfRes> </Cdtr> […] <RgltryRptg> <DbtCdtRptgInd>CRED</DbtCdtRptgInd> <Authrty> <Nm>Reserve Bank of India</Nm> <Ctry>IN</Ctry> </Authrty> <Dtls> <Tp>Export Reporting</Tp> <Dt>2019-01-13</Dt> <Ctry>IN</Ctry> <Cd>P0102</Cd> <Amt Ccy="USD">123456891234567.50</Amt> <Inf>AAASDASAD</Inf> </Dtls> <RgltryRptg> MX :77B:AAASDASAD/BENEFRES/DE MT 58
ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example of Settlement Time <CdtTrfTxInf> … <SttlmTmIndctn> <DbtDtTm>2018-01-04T15:12:09+09:59</DbtDtTm> <CdtDtTm>2018-01-04T15:12:09+09:59</CdtDtTm> </SttlmTmIndctn> <SttlmTmReq> <CLSTm>09:30:47+05:00</CLSTm> <TillTm>09:30:47+05:00</TillTm> <FrTm>09:30:47+05:00</FrTm> <RjctTm>09:30:47+05:00</RjctTm> </SttlmTmReq> … </CdtTrfTxInf> MX :13C:/SNDTIME/1512+0959 :13C:/RNCTIME/1512+0959 :13C:/CLSTIME/0930+0500 :13C:/TILTIME/0930+0500 :13C:/FROTIME/0930+0500 :13C:/REJTIME/0930+0500 MT Illustration included multiple settlement times. It is unlikely all of the examples used would be included in a transaction at the same time. 59
Usage guidelines ISO 20022 Programme - Quality data, quality payments 60 Where can I find more information?
ISO 20022 Programme - Quality data, quality payments 61 MT/ISO 20022 Translation rules – Where to find out more https://www2.swift.com/mystandards/#/c/cbpr/landing Q1 2020 User Handbook iteration will include a full section describing the Translation mapping principals. MT/ISO 20022 Translation section of the CBPR+ landing page
ISO 20022 Programme - Quality data, quality payments 62 Further webinars & work sessions Join a webinar or work session near you to learn why ISO 20022 adoption is necessary, how to make the change and what support SWIFT will provide Where can I get more help? New resources are available for vendors SWIFTSmart The SWIFTSmart e-learning training platform includes an introduction to ISO 20022. A formal curriculum will be published by end of the year WWW ISO 20022 vendor landing page The ISO 20022 vendor landing page provides more information on the programme, timeline, transition period and resources MyStandards The CBPR+ MyStandards page hosts all usage guidelines, a readiness portal for testing your back office applications and coming soon a mapping sandbox to publish translation rules Partner Programme Join the Partner Programme to gain access to further support. The Programme also helps SWIFT customers to make well-informed purchasing and implementation decisions, and providers to differentiate their offerings in a crowded market place. Vendor support Partner Programme member support is available to help you through ISO 20022 migration, get trained, and support your implementation. Knowledge Centre The Knowledge Centre hosts detailed documentation on SWIFT products services, including the SWIFTNet messaging service that will be the basis for the new InterAct service to support CBPR+ compliant flows Documentation The Updated ISO 20022 for Dummies e-book is available to understand the basics of ISO 20022 and implications for financial messaging
www.swift.com

More Related Content

PDF
Payments 101 - Basics of Payments
Kapish Kaushal
 
PPTX
SWIFT - Clearing and Settlement
Aman Lalpuria
 
PPTX
Payment
Aman Lalpuria
 
PPTX
ISO 8583 Financial Message Format
Md. Hasan Basri (Angel)
 
PPT
SWIFT_L2.ppt with detailed version of swift
ShivamDubey304351
 
PPTX
Payment and Settlement Systems(SWIFT,NEFT and Securities Cycle)
Savita Marwal
 
PPT
Neft&rtgs
Aditi Mahapadi
 
PDF
National Automated Clearing House (NACH) an Overview by VSoft
VSoft Technologies
 
Payments 101 - Basics of Payments
Kapish Kaushal
 
SWIFT - Clearing and Settlement
Aman Lalpuria
 
Payment
Aman Lalpuria
 
ISO 8583 Financial Message Format
Md. Hasan Basri (Angel)
 
SWIFT_L2.ppt with detailed version of swift
ShivamDubey304351
 
Payment and Settlement Systems(SWIFT,NEFT and Securities Cycle)
Savita Marwal
 
Neft&rtgs
Aditi Mahapadi
 
National Automated Clearing House (NACH) an Overview by VSoft
VSoft Technologies
 

What's hot (20)

PDF
Your MiFID II Solutions & Services Guide
Conor Coughlan
 
PDF
What’s all the Fuss with ISO 20022?
Nasreen Quibria
 
PDF
N26 company slide deck
TechMeetups
 
PDF
Iso 20022-programme
Suresh Kumar Manoharan
 
PPT
Swift money transfer
Sandra Roberts
 
PPT
Remittances
arvind chaurasia
 
PDF
Swift standard messages
Peter Hansen
 
DOC
cv haitham
haitham said helal
 
PDF
IBM Notes Traveler Administration and Log Troubleshooting tips - Part 2
jayeshpar2006
 
PPTX
Bangladesh Bank Foreign Exchange Heist
AinulHasan4
 
PPT
FeliCa/NFCの概説とAndroidの対応状況
Isao Soma
 
PDF
HCL Notes and Nomad Troubleshooting for Dummies
panagenda
 
PDF
An Introduction to Open Banking (PSD2)
Paul Ark (Polapat Arkkrapridi)
 
PDF
Multi-bank Trade Finance for Corporates
André Casterman
 
PDF
Zazu crowdfunding deck
Alessandra Martini
 
PPTX
APIdays Zurich 2019 - The experience of BBVA API Market David Ramos Lehnhoff,...
apidays
 
PPTX
Openconfigを用いたネットワーク機器操作
Hirofumi Ichihara
 
PDF
The Philippine FinTech Landscape
TCI Network
 
PPTX
フロー技術によるネットワーク管理
Motonori Shindo
 
PDF
Hokkaido.cap#9 無線LANのスニッフィング
Panda Yamaki
 
Your MiFID II Solutions & Services Guide
Conor Coughlan
 
What’s all the Fuss with ISO 20022?
Nasreen Quibria
 
N26 company slide deck
TechMeetups
 
Iso 20022-programme
Suresh Kumar Manoharan
 
Swift money transfer
Sandra Roberts
 
Remittances
arvind chaurasia
 
Swift standard messages
Peter Hansen
 
cv haitham
haitham said helal
 
IBM Notes Traveler Administration and Log Troubleshooting tips - Part 2
jayeshpar2006
 
Bangladesh Bank Foreign Exchange Heist
AinulHasan4
 
FeliCa/NFCの概説とAndroidの対応状況
Isao Soma
 
HCL Notes and Nomad Troubleshooting for Dummies
panagenda
 
An Introduction to Open Banking (PSD2)
Paul Ark (Polapat Arkkrapridi)
 
Multi-bank Trade Finance for Corporates
André Casterman
 
Zazu crowdfunding deck
Alessandra Martini
 
APIdays Zurich 2019 - The experience of BBVA API Market David Ramos Lehnhoff,...
apidays
 
Openconfigを用いたネットワーク機器操作
Hirofumi Ichihara
 
The Philippine FinTech Landscape
TCI Network
 
フロー技術によるネットワーク管理
Motonori Shindo
 
Hokkaido.cap#9 無線LANのスニッフィング
Panda Yamaki
 
Ad

Similar to swift_iso20022_payments_deep_dive_2020_slides_en02.pdf (20)

PDF
ISO 20022: It’s Coming…Are You Ready?
GXS
 
PDF
swift_standards_masterclass_2019_presentation (1).pdf
PragashAdhimoolam1
 
PDF
A Payments Roadmap for Migrating to ISO 20022
Cognizant
 
PDF
Session2 swift 1-presentation-26-mar-2013
Sondhaya Sudhamasapa
 
PDF
SWIFT for ISO 20022 Brochure
Brett Lancaster
 
PPTX
Around the World in ISO 20022
Nasreen Quibria
 
PPTX
ISO20022
Prashant Gavankar
 
PDF
Payments ISO20022 Migration
Bartley O'Malley
 
PDF
Session2 swift 2-presentation-26-mar-2013
Sondhaya Sudhamasapa
 
PPTX
Webinar materials | PSD2: Ensuring a seamless payments journey - connecting A...
XMLdation Ltd
 
PDF
IFT_NEFT_ISO20022_CustomerCreditTransfer_pacs008.pdf
prachi715938
 
PDF
XMLdation seminar Milan 21st may 2014
XMLdation Ltd
 
PDF
Explore SWIFT - TFMASTERS - Demystifying SWIFT: The Backbone of Global Bankin...
tfmastersdm
 
PDF
The coming ISO 20022 revolution: are you ready yet?
Volante Technologies
 
PDF
CELENT - ISO20022 — THE PAYMENTS REVOLUTION
EBA-Day-IBM
 
PPS
Introduction To Iso 20022
Jk Mohanty
 
PDF
How Bayer Stopped Payments Pain with ISO20022
Nasreen Quibria
 
PPT
Windy_City_2013_The_New_Balance_and_Transaction_Reporting_Standard_BTRS.ppt
PragashAdhimoolam1
 
PDF
iso8583 presentation.pdf
ssuserfa55aa
 
PDF
Drive Value with the ISO 20022 Validator Tool
Nasreen Quibria
 
ISO 20022: It’s Coming…Are You Ready?
GXS
 
swift_standards_masterclass_2019_presentation (1).pdf
PragashAdhimoolam1
 
A Payments Roadmap for Migrating to ISO 20022
Cognizant
 
Session2 swift 1-presentation-26-mar-2013
Sondhaya Sudhamasapa
 
SWIFT for ISO 20022 Brochure
Brett Lancaster
 
Around the World in ISO 20022
Nasreen Quibria
 
ISO20022
Prashant Gavankar
 
Payments ISO20022 Migration
Bartley O'Malley
 
Session2 swift 2-presentation-26-mar-2013
Sondhaya Sudhamasapa
 
Webinar materials | PSD2: Ensuring a seamless payments journey - connecting A...
XMLdation Ltd
 
IFT_NEFT_ISO20022_CustomerCreditTransfer_pacs008.pdf
prachi715938
 
XMLdation seminar Milan 21st may 2014
XMLdation Ltd
 
Explore SWIFT - TFMASTERS - Demystifying SWIFT: The Backbone of Global Bankin...
tfmastersdm
 
The coming ISO 20022 revolution: are you ready yet?
Volante Technologies
 
CELENT - ISO20022 — THE PAYMENTS REVOLUTION
EBA-Day-IBM
 
Introduction To Iso 20022
Jk Mohanty
 
How Bayer Stopped Payments Pain with ISO20022
Nasreen Quibria
 
Windy_City_2013_The_New_Balance_and_Transaction_Reporting_Standard_BTRS.ppt
PragashAdhimoolam1
 
iso8583 presentation.pdf
ssuserfa55aa
 
Drive Value with the ISO 20022 Validator Tool
Nasreen Quibria
 
Ad

Recently uploaded (20)

PDF
Predicting Customer Bankruptcy Using Machine Learning Algorithm research pape...
Razan Shahwan
 
PPTX
Session 11-13. Working Capital Management and Cash Budget.pptx
2023mb21003
 
PPTX
social-studies-subject-for-high-school-globalization.pptx
villanuevajoealfred
 
PDF
Dialnet-DynamicHedgingOfPricesOfNaturalGasInMexico-8788871.pdf
davidromero210805
 
PPTX
Unilever_Financial_Analysis_Presentation.pptx
HarisKaimKhani
 
PDF
Mathematical Economics 23lec03slides.pdf
drmabdelnaby2060
 
PDF
Why Ignoring Passive Income for Retirees Could Cost You Big.pdf
Enterprise world
 
PDF
ssrn-3708.kefbkjbeakjfiuheioufh ioehoih134.pdf
sunnykrish2000
 
PDF
caregiving tools.pdf...........................
cyrilbotor
 
PDF
Spending, Allocation Choices, and Aging THROUGH Retirement. Are all of these ...
Better Financial Education
 
DOCX
marketing plan Elkhabiry............docx
ramadanantar44
 
PDF
financing insitute rbi nabard adb imf world bank insurance and credit gurantee
robertclive1690
 
PPTX
Session 14-16. Capital Structure Theories.pptx
2023mb21003
 
PDF
Lecture1.pdf buss1040 uses economics introduction
VidhiGupta718698
 
PDF
Dr Tran Quoc Bao the first Vietnamese speaker at GITEX DigiHealth Conference ...
Gorman Bain Capital
 
PPTX
The discussion on the Economic in transportation .pptx
awanganiqkmal191
 
PPT
E commerce busin and some important issues
AssadLeo1
 
PDF
final_dropping_the_baton_-_how_america_is_failing_to_use_russia_sanctions_and...
AnastosiyaGurin1
 
PDF
how_to_earn_50k_monthly_investment_guide.pdf
Grip Invest
 
PPTX
kyc aml guideline a detailed pt onthat.pptx
Sanjaysaini308877
 
Predicting Customer Bankruptcy Using Machine Learning Algorithm research pape...
Razan Shahwan
 
Session 11-13. Working Capital Management and Cash Budget.pptx
2023mb21003
 
social-studies-subject-for-high-school-globalization.pptx
villanuevajoealfred
 
Dialnet-DynamicHedgingOfPricesOfNaturalGasInMexico-8788871.pdf
davidromero210805
 
Unilever_Financial_Analysis_Presentation.pptx
HarisKaimKhani
 
Mathematical Economics 23lec03slides.pdf
drmabdelnaby2060
 
Why Ignoring Passive Income for Retirees Could Cost You Big.pdf
Enterprise world
 
ssrn-3708.kefbkjbeakjfiuheioufh ioehoih134.pdf
sunnykrish2000
 
caregiving tools.pdf...........................
cyrilbotor
 
Spending, Allocation Choices, and Aging THROUGH Retirement. Are all of these ...
Better Financial Education
 
marketing plan Elkhabiry............docx
ramadanantar44
 
financing insitute rbi nabard adb imf world bank insurance and credit gurantee
robertclive1690
 
Session 14-16. Capital Structure Theories.pptx
2023mb21003
 
Lecture1.pdf buss1040 uses economics introduction
VidhiGupta718698
 
Dr Tran Quoc Bao the first Vietnamese speaker at GITEX DigiHealth Conference ...
Gorman Bain Capital
 
The discussion on the Economic in transportation .pptx
awanganiqkmal191
 
E commerce busin and some important issues
AssadLeo1
 
final_dropping_the_baton_-_how_america_is_failing_to_use_russia_sanctions_and...
AnastosiyaGurin1
 
how_to_earn_50k_monthly_investment_guide.pdf
Grip Invest
 
kyc aml guideline a detailed pt onthat.pptx
Sanjaysaini308877
 

swift_iso20022_payments_deep_dive_2020_slides_en02.pdf

  • 1. ISO 20022 Programme Quality data, quality payments Awareness Webinar – Payments Deep Dive
  • 2. 2 What is ISO 20022? ISO 20022 Programme - Awareness Webinar – ISO Overview
  • 3. 3 What is ISO 20022? Proprietary MT ISO 7775 ISO 15022 ISO 20022 Payments Treasury & Trade 1973 Securities only 1984 Securities only 1999 2004 2000 • Paper-based • Proprietary syntax • Point-to-point • One size fits all • SWIFT only • Reference standard • Electronic • Open, neutral syntax • End-to-end transaction • Market practice • SWIFT + other organisations FIN MT: Computer-processable versions of telexes ISO 20022 Programme - Quality data, quality payments ISO 20022 Governance Responsibility • Approval of the international standard • Selection of the Registration Authority and set-up of the http://www.iso20022.org • Creation of Registration Management Group (RMG) • Creation of Standards Evaluation Groups (SEG) • Registration and publication of first ‘ISO 20022 messages’ • Approval of a new edition of the international standard in 2013
  • 4. 4 ISO 20022 message catalogue Published on www.iso20022.org MyStandards Maintenance process – built on strict business justifications and review process - leading to new ‘versions’ of the messages ‘PAIN’ = Payment Initiation = used in Corporate-to-bank ‘PACS’ = Payment Clearing and Settlement = used in Payments ‘SESE’ = Securities settlement = used in Securities ‘SEMT’ = Securities management = used in Securities ‘SEEV’ = Securities events = used in Securities ‘CAMT’ = Cash Management + used in Payment Reporting 23 Business Areas – examples : More than 20 submitting organisations, besides SWIFT More than 320 messages, covering payments, securities, trade services, FX, cards. ISO 20022 Programme - Quality data, quality payments What is ISO 20022?
  • 5. A community agreement In 2018, the global financial community agreed to migrate from the MT (FIN) payment message standard to ISO 20022 The move to ISO 20022 will begin in November 2022 and coexistence with MT (FIN) will run until November 2025 All players need to start preparing for the migration now to be ready for November 2022 All FI to FI payments and cash reporting messages will move to ISO 20022 ISO 20022 Programme - Quality data, quality payments 5
  • 6. Why is the Industry Adopting ISO 20022? Enabling a hyper-connected payment world Payments revolution Payments are rapidly transforming, with new players world-wide, transforming to meet the customer requirements and improving the customer experience. ISO payment and report formats are a key element of this transformation Domestic modernization Real time payments are quickly becoming the consumer payment method of choice and will quickly be an international payment option 24/7. ISO systems Global payments innovation SWIFT gpi is driving unprecedented change – delivering fast, transparent and trackable cross-border payments A hyper-connected payment world Through global harmonization of payment formats we are prepared for a future where complex and data rich payments move through any domestic and/or cross- border payment system, and are credited to beneficiaries – Instantly. Regulatory requirements Facilitates complying with ever changing and broader regulatory requirements. ! ISO 20022 Programme - Awareness Webinar – ISO Overview 6
  • 7. 7 The changing language of payments ISO 20022 Programme - Quality data, quality payments
  • 8. What is changing? ISO 20022 Programme - Quality data, quality payments 8 Field names
  • 9. ISO 20022 Programme - Quality data, quality payments 9 SWIFT MT versus ISO 20022: Key Concepts Element Field Message specification components Parties in a message DataType Format Min Max Presence CodeSet Qualifiers / Codes ISO 20022 MT Textual Rule Usage Rule CrossElementComplexRule Network Validated Rule Agent Bank Debtor Ordering Customer Creditor Beneficiary Customer Instructing Agent Message Sender Instructed Agent Message Receiver Legend:
  • 10. New Parties :XX FIN MT format equivalent ISO 20022 Payment Originator Payments Clearing & Settlement (pacs) Payment Beneficiary Ultimate Debtor Forwarding Agent Debtor Initiating Party :50a Debtor Agent :52a 1 2 3 1 2 3 1 2 3 Ultimate Creditor Creditor Previous Instructing Agents Instructing Agent Instructed Agent Creditor Agent Reimbursement Agents Intermediary Agents :59a :57a :53a :54a :55a :56a :72:/INS/ :72:/INT/ Sender Receiver Legend: New parties introduced in ISO 20022 :70:/INST/ :50C/L :50C/L :70:/ULTB/ 10 ISO 20022 PROGRAMME - QUALITY DATA, QUALITY PAYMENTS
  • 11. ISO 20022 Programme - Quality data, quality payments 11 MT 103 Customer Credit Transfer serial message flow MT 103 MT 103 MT 103 MT Party 11 Ordering Customer Ordering Institution Intermediary Institution Intermediary Institution Account with Institution Beneficiary A B C D The MT key concepts
  • 12. pacs.008 pacs.008 pacs.008 pacs.008 Party ISO 20022 Programme - Quality data, quality payments 12 pacs.008 FI To FI Customer Credit Transfer serial message flow A B C D Debtor Debtor’s Agent Intermediary Agent 1 Intermediary Agent 2 Creditor’s Agent Creditor The ISO 20022 key concepts
  • 13. What is changing? ISO 20022 Programme - Quality data, quality payments 13 Character sets
  • 14. ISO 20022 Programme - Quality data, quality payments Special characters are additionally allowed in: • All party (agents and non-agents) Name and Address elements • The Related Remittance Information elements • The Remittance Information (structured & unstructured) elements List of special characters: !#&%*=^_’{|}~";@[] Additionally special characters $ and > < signs are enabled for the Email Address elements Currencies in the payments should be expressed in ISO Currency Codes only (3- Characters, e.g. EUR) Character Set Translation of any special character: !#&%*=^_’{|}~";@[]$ >< into MT messages will be represented by a . (Full Stop) All SWIFT ISO MX message elements (fields) which are defined (by data Type) as text are restricted to FIN X Characters: a-z A-Z 0-9 / - ? : ( ) . , ' + . $ < > ! # & % * = [ ] Note: While ISO 20022 base standards support non-Latin characters, CBPR+ will only support Latin characters in Phase 1 and Phase 2 U 14
  • 15. What is changing? ISO 20022 Programme - Quality data, quality payments 15 Message Structure
  • 16. 16 ISO 20022 XML message identifier ISO 20022 Programme - Quality data, quality payments 4!a . 3!c . 3!n . 2!n Version Variant Message identifier/functionality Business area pacs.008.001.08 Version 8 Variant 1 FI To FI Customer Credit Transfer Payments Clearing and Settlement Example
  • 17. 17 How is an MT structure different from an MX structure? ISO 20022 Programme - Quality data, quality payments MT ISO 20022 (MX) <AppHdr> … </AppHdr> <Document> … </Document> ISO 20022 Business Application Header ISO 20022 Message Business Message
  • 18. ISO 20022 Programme - Quality data, quality payments 18 Structured data becomes the new norm ISO 20022 Debtor data element example Customer data record example MT – free format option Debtor Name JOHN HECTOR JOSEPH SMITH - MASTERSONS :50K:/BE3000121637141 JOHN HECTOR JOSEPH SMITH – MASTERSONS HOOGSTRAAT 6 BRUSSELS 1000 BELGIUM ID:1111111111 Postal Address Department Sub Department Street Name HOOGSTRAAT Building Number 6 MT – structured option with risk of potential truncation & loss of info Post Code 1000 :50F:/BE3000121637141 1/JOHN HECTOR JOSEPH SMITH - 1/MASTERSONS 2/HOOGSTRAAT 6 3/BE/BRUSSELS 1000 Town Name BRUSSELS Country BE Identification Private Identification – Other Identification 1111111111 Debtor Account Identification IBAN BE3000121637141 Passport number is lost! Richness of ISO 20022 allows more granular data structure
  • 19. What is changing? ISO 20022 Programme - Quality data, quality payments 19 Message types
  • 20. ISO 20022 Programme - Quality data, quality payments 20 CBPR+ Phase 1 usage guidelines and planned translation rules Updated April 2020 U Existing FIN MTs ISO 20022 equivalent Usage guidelines Translation rules planned MT 103 / 102 pacs.008.001.0x Published on MyStandards Published on MyStandards MT 200 / 201 / 202 / 202 COV / 203 / 205 pacs.009.001.0x Published on MyStandards MT 103 RETURN / MT 202 RETURN pacs.004.001.0x Published on MyStandards MT 103 REJECT / MT 202 REJECT Negative pacs.002.001.0x MX to MT only SWIFT to Investigate Field 72 option or MT 199 No Equivalent Positive pacs.002.001.0x No translation planned MT 210 camt.057.001.0x Published on MyStandards MX to MT - Single MT 900 / 910 camt.054.001.0x Published on MyStandards MT 941 / 942 camt.052.001.0x No translation planned MT 940 / 950 camt.053.001.0x Not required – Guidance in UHB MT 920 camt.060.001.0x No translation planned head.001.001.0x – v2 Published with each request type N/A
  • 21. ISO 20022 Programme - Quality data, quality payments 21 CBPR+ Phase 1 usage guidelines and planned translation rules Existing FIN MTs ISO 20022 equivalent Usage guidelines Translation rules planned MT 103 STP Pacs.008 STP Guideline Under development No translation planned MT 103 STP EU Pacs.008 EEA Guidelines To be planned No translation planned MT 204 Pacs.010 Under Development From MX to MT only MT 104 Pacs.003 Out of scope Out of scope head.001.001.0x – v2 Published with each request type N/A CBPR+ Phase 2 usage guidelines and planned translation rules Existing FIN MTs ISO 20022 equivalent Usage Guideline available on Mystandards & Readiness Portal Translation rules planned 192/292 (Cancellation Request) camt.056.001.0x - Cancellation Request In collaboration with gpi expert group To be confirmed Camt.026 – Unable to Apply Camt.027 – Claim Non Receipt Camt.087 – Request to Modify 296/199/299/112 (Query/Answer) camt.029.001.0x - Resolution of Investigation MT 101 Pain.001 Wait for CGI deliverable To be confirmed MT 110/MT 111/MT 112 New Cheques Messages Start development during June 2020 Workshop To be confirmed MT n90 / MT n91 New Fee Messages Start development during June 2020 Workshop To be confirmed
  • 22. 22 Overview of usage guidelines ISO 20022 Programme - Quality data, quality payments
  • 23. ISO 20022 Programme - Quality data, quality payments Messages index pacs.008 - Financial Institution to Financial Institution Customer Credit Transfer pacs.009 (core) - Financial Institution Credit Transfer pacs.009 (cov) - Financial Institution ‘Cover’ Credit Transfer pacs.002 – FI To FI Payment Status Report pacs.004 – Payment Return Payment, Clearing and Settlement (pacs) messages U 23
  • 24. pacs.008 ISO 20022 Programme - Quality data, quality payments 24 Financial Institution to Financial Institution Customer Credit Transfer
  • 25. 25 pacs.008 FI to FI Customer Credit Transfer pacs.008 Group Header Credit Transfer Transaction Information The pacs.008 has two core sets of nested element: Group Header which contain a set of characteristics that relate to all individual transactions Credit Transfer Transaction Information which contains elements providing information specific to the individual credit transfer transaction. A typical payment message in a many-to-many payment would be considered as a single transaction. The Industry CBPR+ committeee has decided that the pacs.008 will carry a single transaction as a best practice. It is however possible, where bilateral agreed, to include re-occurring Credit Transfer Transaction Information i.e. multiple payments, perhaps more associated with an early leg in the payment lifecycle, where upon these multiple transaction would typically be split into individual payment transactions. ISO 20022 Programme - Quality data, quality payments
  • 26. 26 MT 103 Customer Credit Transfer High Level Serial message flow MT 103 MT 103 MT 103 A B C D The MT way Originator Originating Bank Sending Bank Receiving Bank Beneficiary Bank Beneficiary Current serial MT 103 payment flow as the payment moves across the payment bank chain. MT 900s are generally used to confirm transaction execution to originating banks ISO 20022 Programme - Quality data, quality payments MT 900 MT 900 MT 900 Payment Initiation MT101 PAIN001 via FileAct Proprietary Payment Reporting MT9XX camt 5X via FileAct Proprietary
  • 27. 27 pacs.008 FI to FI Customer Credit Transfer High Level serial message flow The ISO 20022 way pacs.008 pacs.002 A B C D pacs.008 pacs.008 pacs.002 pacs.002 Debtor Debtor Agent Instructing Agent Instructed Agent Creditor Agent Creditor The new party names are shown in this ISO pacs 008 payment message flow, When the customer credit transfer migrates to the pacs 008, there is an option to provide payment status messages utilizing the pacs 002 message. The pacs 002 is a point to point status message and does not carry full comprehensive status information like the gpi tacker service The pacs 002 or the camt.054 can be used to confirm transaction execution to originating banks. ISO 20022 Programme - Quality data, quality payments Payment Initiation MT101 PAIN001 via FileAct Proprietary Proprietary Payment Reporting MT9XX camt 5X via FileAct camt.054 camt.054 camt.054
  • 28. Agent D credits the account of the Creditor, and may optionally provide a notification e.g. notification of credit in addition to an account statement (camt.053) 28 pacs.008 FI to FI Customer Credit Transfer High Level Use Case settled over a Payment Market Infrastructure pacs.008 pacs.002 1 1 Debtor initiates a payment instruction to the Debtor Agent Debtor Agent (A) initiates a serial payment towards the Creditor Agent (D) using Agents B & C as intermediaries, who are direct participant of the Payment Market Infrastructure 3 Agent B processes the payment on Agent C, via the Payment Market Infrastructure. 4 Payment Market Infrastructure, settles the payment between Agent B and Agent C as direct participants of the Market Infrastructure, and provides a settlement confirmation to Agent B pacs.008 pacs.008 pacs.008 pacs.002 pacs.002 2 2 3 4 5 Settlement Complete 6 5 Agent C processes the payment on Agent D 6 A B C D ISO 20022 Programme - Quality data, quality payments The ISO 20022 way Each MI will determine their method of confirmation but the 002 is the standard ISO message.
  • 29. pacs.009 (core) & pacs.009 (cov) ISO 20022 Programme - Quality data, quality payments 29 Financial Institution Credit Transfer
  • 30. 30 pacs.009 core versus cov pacs.009 (core) Group Header Credit Transfer Transaction Information pacs.009 (cov) Group Header Credit Transfer Transaction Information Underlying Customer Credit Transfer The pacs.009 has two main use cases: • as a core Financial Institution to Financial Institution Credit Transfer message, and • As a cov where it is used as cover of (to settle) a pacs.008. The pacs.009 therefore contain information of the underlying Customer Credit Transfer (pacs.008) for use in the cover scenario, which is the key attribute to differentiate between these two use cases. ISO 20022 Programme - Quality data, quality payments
  • 31. 31 MT 202 FI to FI Credit Transfer High Level message flow MT 202 A B C D The Financial Institution Credit Transfer 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. The MT way ISO 20022 Programme - Quality data, quality payments MT 202 MT 202 Originating FI Sending FI Receiving FI Beneficiary FI MT 900 MT 900 MT 900
  • 32. 32 pacs.009 FI to FI Credit Transfer High Level message flow pacs.009 pacs.009 pacs.009 pacs.002 pacs.002 pacs.002 A B C D The Financial Institution Credit Transfer 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. ISO 20022 Programme - Quality data, quality payments The ISO 20022 way Debtor FI Creditor FI Instructing FI Instructed FI camt.054 camt.054 camt.054
  • 33. ISO 20022 Programme - Quality data, quality payments 33 MT 103 Customer Credit Transfer High Level message flow settled using the MT 202 cover method MT 103 MT 202 cov A B C D Note: For example purposes, this slide shows V-shape payment market infrastructure flows. Y-shape flows will be different. The MT way Payment Initiation MT101 PAIN001 via FileAct Proprietary Proprietary Payment Reporting MT9XX camt 5X via FileAct Originating Bank Originator Sending Bank Receiving Bank Beneficiary Sending Bank Receiving Bank Beneficiary Bank
  • 34. 34 pacs.009 cov FI to FI Credit Transfer High Level message flow demonstrating the change in party roles between messages pacs.009 cov pacs.009 cov The Financial Institution Credit Transfer cover 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 important to recognize that some roles change between these parallel messages. pacs.009 cov pacs.002 pacs.002 pacs.002 pacs.008 pacs.002 pacs.008 pacs.009 cov Party Debtor Debtor Creditor Creditor Creditor Agent Debtor Agent Underlying Debtor Underlying Creditor C D A B Payment Initiation MT101 PAIN001 via FileAct Proprietary Payment Reporting MT9XX camt 5X via FileAct Proprietary Debtor Creditor The correspondent banking cover payment method utilises both the pacs.008 and pacs.009 cov. The UETR element within these messages contain the same UETR which effectively interlink the messages. As an interlinked message it is important to understand the way certain parties change their role in the pacs.009 cov This is demonstrated in the example ISO 20022 Programme - Quality data, quality payments The ISO 20022 way
  • 35. ISO 20022 Programme - Quality data, quality payments 35 MT 103 Customer Credit Transfer High Level message flow settled using the MT 202 cover method Via MI MT 103 MI COV MI COV A B C D Note: For example purposes, this slide shows V-shape payment market infrastructure flows. Y-shape flows will be different. The MT way Payment Initiation MT101 PAIN001 via FileAct Proprietary Proprietary Payment Reporting MT9XX camt 5X via FileAct MI Confirm Beneficiary Beneficiary Bank Originator Originating Bank Sending Bank Receiving Bank Receiving Bank Sending Bank
  • 36. Agent C produces an end of day account statement report. An optional real time notifications e.g. advice of credit may have also been created at the time of the credit posting Agent C receives the payment and credits the account of Agent D Agent B processes the payment on Agent C, via the Payment Market Infrastructure. 36 pacs.008 FI to FI Customer Credit Transfer High Level Use Case settled using pacs.009 COV over a Payment Market Infrastructure pacs.008 pacs.002 pacs.009 cov 1 1 Debtor initiates a payment instruction to the Debtor Agent 2a Debtor Agent (A) initiates a payment using the cover method to the Creditor Agent (D) 2a 2b 2b In parallel the Debtor Agent (A) initiates a covering payment to credit the account of Agent (D) with their correspondent (Agent C) 3 5 6 6 4 3 7 pacs.009 cov Settlement Complete pacs.002 Agent D reconciles the covering funds and credits the account of the Creditor, and may optionally provide a notification e.g. notification of credit. 7 Payment Market Infrastructure, settles the payment between Agent B and Agent C as direct participants of the Market Infrastructure, and provides a settlement confirmation to Agent B 4 5 A D B C Payment Initiation MT101 PAIN001 via FileAct Proprietary Payment Reporting MT9XX camt 05X via FileAct Proprietary ISO 20022 Programme - Quality data, quality payments The ISO 20022 way Market Infrastructure will either conform to HVPS+ guidelines or establish their own usage guidelines based on the ISO 20022 standard.
  • 37. pacs.002 ISO 20022 Programme - Quality data, quality payments 37 Status Information
  • 38. ISO 20022 Programme - Quality data, quality payments pacs.002 Status Information pacs.002 Group Header Transaction Information And Status The Financial Institution To Financial Institution Payment Status Report 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 38
  • 39. Agent B processes the payment on Agent C. Status Messages can follow ISO 20022 Programme - Quality data, quality payments 39 pacs.002 Payment Status Information High Level Use Case of multiple Payment Transaction Status updates pacs.008 pacs.002 1 1 Debtor initiates a payment instruction to the Debtor Agent 2 Debtor Agent (A) initiates a serial payment towards the Creditor Agent (D) using Agents B & C as intermediaries 5 4 3 Agent B provides a status update ACTC (accepted technical validations are successful) to Agent A, based upon a bilateral agreement. 4 3 pacs.008 pacs.008 2 5 pacs.002 Agent B provides a further status update ACSP (accepted settlement in progress) to Agent A, based upon a bilateral agreement. pacs 002 or camt.054 for final confirmation. An agent may provide multiple Payment Status Information updates (with different Transaction Status codes), where bilaterally agreed, throughout the payment processing lifecycle i.e. from receipt through to onward processing. B C A D The code list representing the Payment Transaction Status is part of the ISO 20022 external code list pacs.002 pacs.002 CBPR+ restricted the pacs.002 to a single transaction camt.054
  • 40. ISO 20022 Programme - Quality data, quality payments 40 Payment Transaction Status Code definitions Code Name ISO Definition pacs High Level Use Case ACCC AcceptedSettlementCompleted Settlement on the creditor's account has been completed. Sent by Credit Agent to confirm the settlement on the creditor’s account ACCP AcceptedCustomerProfile Preceding check of technical validation was successful. Customer profile check was also successful. Sent by any Agent in the payment chain to confirm acceptance prior to technical validation. ACSC AcceptedSettlementCompleted Settlement on the debtor's account has been completed. Sent by the Debtor Agent to confirm settlement on the debtor account prior to payment execution. ACSP AcceptedSettlementInProcess All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. Sent by any Agent to the to confirm the payment is accepted following technical validations being successfully completed. ACTC AcceptedTechnicalValidation Authentication and syntactical and semantical validation are successful Sent by any Agent in the payment chain to the previous Agent to confirm the payment is accepted following technical validations being successfully completed. ACWC AcceptedWithChange Instruction is accepted but a change will be made, such as date or remittance not sent. Sent by any Agent in the payment chain to the previous Agent to confirm the payment is accepted following amendments being made. ACWP AcceptedWithoutPosting Payment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account. Sent by Credit Agent to the previous Agent to confirm the acceptance of payment without settlement on the creditor’s account, PDNG Pending Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed. Sent by any Agent in the payment chain to the previous Agent as an interim status whilst other validations are performed. RCVD Received Payment initiation has been received by the receiving agent. Sent by Any Agent to the previous Agent as confirmation that their Customer Credit Transfer initiation request has been received by the payment engine. RJCT Rejected Payment initiation or individual transaction included in the payment initiation has been rejected. Sent by Any Agent to inform the previous Agent that their Customer Credit Transfer has been rejected.
  • 41. pacs.004 ISO 20022 Programme - Quality data, quality payments 41 Payment Return
  • 42. ISO 20022 Programme - Quality data, quality payments pacs.004 Payment Return pacs.008 Group Header Credit Transfer Transaction Information pacs.009 cov Group Header Credit Transfer Transaction Information Underlying Customer Credit pacs.004 Group Header Transaction Information Original Group Information Original Transaction Reference In a similar structure to the pacs.009 (cov) underlying Customer Credit Transfer, the pacs.004 Return Payment message has amongst other elements Original Group Information which captures original information such as the Original UETR and Original Interbank Settlement Amount etc. and an Original Transaction Reference which contain the key elements of the original payment e.g. Debtor, Creditor etc. U 42
  • 43. ISO 20022 Programme - Quality data, quality payments 43 pacs.002 Payment Reject and pacs.004 Return Flow High Level Use Case and key considerations. Within the pacs.004 Return Payment • the Original Group Information element is used to refers to original message for which the return relates to. e.g. based upon the above example pacs.008 as the original message would be included in the pacs.004 • the Transaction Information > Original UETR element would include UETR of the message received. i.e. the same UETR is used on the Return Payment. • the Original Transaction Reference element includes detail from the original message. e.g. the Debtor of the original pacs.008. • the Return Chain element includes the parties in return payment chain, noting the parties reverse (i.e. change role) from the original payment whereby the Debtor of the original payment becomes the Creditor in the Return Chain. • A reason code is added to the Return message to inform the agent of the reason for the return (e.g. AC04 Account closed) pacs.008 pacs.004 pacs.004 pacs.008 pacs.008 + Return Reason + Return Reason pacs.002 + Reject Reason B C A D The code list representing the Return Reason is part of the ISO 20022 external code list The Payment Return message is sent by an agent to the previous agent in the payment chain to undo a payment previously settled.
  • 44. Creditor determines that they wish to return the payment e.g. they are unable to apply, and instructs their bank (Agent D) to return the payment together with the reason. Agent C processes the payment on Agent D Agent B processes the payment on Agent C Payment Return (pacs.004) of a complete Customer Credit Transfer (pacs.008) pacs.008 pacs.004 pacs.004 1 1 Debtor initiates a payment instruction to the Debtor Agent 2 Debtor Agent (A) initiates a serial payment towards the Creditor Agent (D) using Agents B & C as intermediaries 3 4 7 Agent C return funds to Agent B, together with the reason code for return. Agent B return funds to Agent A, together with the reason code for return. 8 8 pacs.008 pacs.008 + Return Reason + Return Reason 2 3 4 pacs.004 + Return Reason 5 6 Agent D credits the account of the Creditor, and may optionally provide a notification e.g. notification of credit in addition to an account statement (camt.054) 5 6 Agent D returns the payment to Agent C using a Payment Return message (pacs.004) also including the return reason code. . A B C D 7 Use Case p.4.1.2 ISO 20022 Programme - Quality data, quality payments The code list representing the Return Reason is part of the ISO 20022 external code list
  • 45. ISO 20022 Programme - Quality data, quality payments 45 Payment Transaction Return Reason Code definitions examples (74 total) Code Name Definition AC01 IncorrectAccountNumber Format of the account number specified is not correct AC03 InvalidCreditorAccountNumber Wrong IBAN in SCT AC04 ClosedAccountNumber Account number specified has been closed on the bank of account's books AC06 BlockedAccount Account specified is blocked, prohibiting posting of transactions against it. AC13 InvalidDebtorAccountType Debtor account type is missing or invalid AC14 InvalidAgent An agent in the payment chain is invalid. AC15 AccountDetailsChanged Account details have changed. AC16 AccountInSequestration Account is in sequestration. AC17 AccountInLiquidation Account is in liquidation. AG01 TransactionForbidden Transaction forbidden on this type of account (formerly NoAgreement) AG02 InvalidBankOperationCode Bank Operation code specified in the message is not valid for receiver AM01 ZeroAmount Specified message amount is equal to zero Rejected by Network AM02 NotAllowedAmount Specific transaction/message amount is greater than allowed maximum AM03 NotAllowedCurrency Specified message amount is an non processable currency outside of existing agreement AM04 InsufficientFunds Amount of funds available to cover specified message amount is insufficient. AM05 Duplication Duplication
  • 46. 46 Cross Border Payments & Reporting (CBPR+) Working Group ISO 20022 Programme - Quality data, quality payments
  • 47. ISO 20022 Programme - Quality data, quality payments 47 CBPR+ : A group of your peer banks advising SWIFT on how ISO 20022 should be used Objective Create global ISO 20022 Market Practice and Usage Guidelines for selected messages from the SWIFT MT Category 1, 2 & 9 set of messages, which will be validated on the SWIFT network in the many to many space. With the approach of  Benefiting from ISO 20022 features, and not alike for like adoption from SWIFT MT  Interoperable with high value payment system (HVPS+) guidelines*, while differences should be justified and documented  Incorporating gpi requirements, such as UETR  Incorporating securities requirements, for the cash-leg of a securities transactions  Including new messages & functionalities where required, e.g. Return & Status messages  Validated on the SWIFT network  Maintained on a yearly basis  Develop Translation Rules HVPS+: A working group of payment marketing infrastructure operators advising SWIFT on how ISO 20022 should be used for high value payment systems. HVPS+ has established usage guidelines for this purpose
  • 48. MT 103/MX pacs 008 Customer Credit Transfer – Correspondent Bank High Level Serial message flow MT 103 A B C Translation Flow Originator (Debtor) Originating Bank (MT) (Debtor Agent) Sending Bank (MX) (Instructed Bank) Receiving Bank (MX) (Instructed Bank) Beneficiary (Creditor) In the early days of the ISO migration Coexistence Period there will be payment scenarios where translation will be required for a payment to be completed to the Beneficiary/Creditor When the originating Bank sends an MT format, the process will be very straight forward as there will be no excess data due to new fields or field length mismatches. Payment Initiation MT101 PAIN001 via FileAct Proprietary Proprietary Payment Reporting MT9XX camt 5X via FileAct ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted T MX pacs 008 48
  • 49. MX pacs 008/MT 103 FI to FI Customer Credit Transfer-Correspondent Bank High Level serial message flow Embedded MT in MX Flow A B C MX pacs.008 pacs.008 Debtor Debtor Agent (MX) Instructing Agent(MX) Instructed Agent (MT) Creditor During the Coexistence Period when the Debtor Agent initiates an MX and a translation to MTs required there can be payment scenarios where additional fields, and, additional data in those fields, may result in an excess data condition. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Payment Initiation MT101 PAIN001 via FileAct Proprietary Payment Reporting MT9XX camt 5X via FileAct Proprietary T MT 103 pacs.002 SWIFT Cloud 49
  • 50. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted <IntrmyAgt1> <FinInstnId> <BICFI>BDLIITGGXXX</BICFI> <ClrSysMmbId> <ClrSysId> <Cd>ITNCC</Cd> </ClrSysId> <MmbId>0123401600</MmbId> </ClrSysMmbId> <Nm>Banca dei Lavoratori Italiani</Nm> </FinInstnId> </IntrmyAgt1> <IntrmyAgt1Acct> <Id> <IBAN>IT27Z0123401600000000148292</IBAN> </Id> </IntrmyAgt1Acct> Example MX/MT Agent Field Tag (e.g. 56) Type A Format MX :56A:/IT27Z0123401600000000148292 BDLIITGGXXX MT 50
  • 51. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Agent Field Tag (e.g.56) Type D Format <IntrmyAgt1> <FinInstnId> <ClrSysMmbId> <ClrSysId> <Cd>ITNCC</Cd> </ClrSysId> <MmbId>0123401600</MmbId> </ClrSysMmbId> <Nm>Banca dei Lavoratori Italiani</Nm> <PstlAdr> <StrtNm>Via dei Gigli</StrtNm> <BldgNb>1</BldgNb> <BldgNm>Palazzo Viola</BldgNm> <Flr>7 Piano</Flr> <PstCd>20100</PstCd> <TwnNm>Milano</TwnNm> <TwnLctnNm>Quartiere Isola</TwnLctnNm> <DstrctNm>Provincia di Milano</DstrctNm> <CtrySubDvsn>Lombardia</CtrySubDvsn> <Ctry>IT</Ctry> </PstlAdr> </FinInstnId> </IntrmyAgt1> MX :56D://IT0123401600 Banca dei Lavoratori Italiani Via dei Gigli,1,Palazzo Viola,7 Pi+ IT/Milano,20100,Quartiere Isola,Lom bardia,Provincia di Milano MT 51
  • 52. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Debtor/Creditor (50,59) Unstructured Name and Address <Dbtr> <Nm>Hamburgische Hochwertige Landesbank eG</Nm> <PstlAdr> <AdrLine>Gebaude 5</AdrLine> <AdrLine>Hafenstrasse 7</AdrLine> <AdrLine>22767 Hamburg, DE</AdrLine> </PstlAdr> <CtryOfRes>DE</CtryOfRes> </Dbtr> <DbtrAcct> <Id> <Othr> <Id>123</Id> </Othr> </Id> </DbtrAcct> MX :50K:/123 Hamburgische Hochwertige Landesban+ Gebaude 5 Hafenstrasse 7 22767 Hamburg, DE MT 52
  • 53. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Debtor/Creditor (50,59) Structured Name and Address <Dbtr> <Nm>Mueller Weltweit Handels GmbH</Nm> <PstlAdr> <StrtNm>Hafenstrasse</StrtNm> <BldgNb>7</BldgNb> <BldgNm>Willy-Brandt Gebaude</BldgNm> <Flr>3 OG</Flr> <PstBx>1203</PstBx> <Room>C3B</Room> <PstCd>22767</PstCd> <TwnNm>Hamburg</TwnNm> <TwnLctnNm>St. Pauli</TwnLctnNm> <Ctry>DE</Ctry> </PstlAdr> <Id> – <OrgId> – <LEI>TX1DBTRORGIDLEI67890</LEI> – </OrgId> </Id> <CtryOfRes>DE</CtryOfRes> </Dbtr> <DbtrAcct> <Id> <IBAN>DE25390200000004711001</IBAN> </Id> </DbtrAcct> MX :50F:/DE25390200000004711001 1/Mueller Weltweit Handels GmbH 2/Hafenstrasse,7,Willy-Brandt Geba+ 3/DE/Hamburg,22767,St. Pauli 6/DE/LEIC/TX1CDTRORGIDLEI67890 MT 53
  • 54. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted The MT Remittance Information is translated applying prioritizing the information. Information is likely to be truncated and identified in most cases with the sign “+” at the end of the translated information. If a full element is not copied an Error Handling mechanism will be defined to report the missing information. In all cases, UltimateDebtor and UltimateCreditor will have the highest translation priority in the MT Field 70. Logic When the originating message is MX, the MT remittance information is translated with the following identifiers: • /ULTB/ - UltimateCreditor information prioritized as Name/Country [/TownName]. TownName is optional or (Name/OtherId) or Name alone or OtherId alone. • /ULTD/ - UltimateDebtor information prioritized as Name/Country/TownName. TownName is mandatory or (Name/OtherId) or Name alone or OtherId alone. • /PURP/ - purpose of the payment • /ROC/ - EndToEndIdentification when /ROC/ is not present in UnstructuredRemittanceInformation and value different from “NOTPROVIDED”. • /URI/ - the MX unstructured remittance information • /RELID/ - 1 or 2 identifications of the RelatedRemittanceInformation stored outside the message • /SRI/+ - means that structured remittance information is present in the original message but is not translated. Note: /URI/, /RELID/ and /SRI/+ are mutually exclusive meaning cannot be present together (even not by pair). Remittance Information Mapping - Definition 54
  • 55. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Remittance Information (70) <CdtTrfTxInf> <PmtId> <InstrId>INSTRID-TMP001</InstrId> <EndToEndId>END2ENDID-TMP001</EndToEndId> <UETR>4f334519-092f-49fa-acf9-ce93c267ac8c</UETR> </PmtId> […] <UltmtDbtr> <Nm>Tower and Town Inc.</Nm> </UltmtDbtr> […] <UltmtCdtr> <Nm>Sivesh S</Nm> </UltmtCdtr> <RmtInf> <Ustrd>BELEG 1301 2019 RG.OPTIK/03/19-20 V.312589RG.OPTIK/ 02/19-20 V.200619</Ustrd> </RmtInf> </CdtTrfTxInf> MX :70:/ULTB/Sivesh S///ULTD/Tower and Tow n Inc.///ROC/END2ENDID-TMP001///URI /BELEG 1301 2019 RG.OPTIK/03/19-20 V.312589RG.OPTIK/ 02/19-20 V.200619 MT 55
  • 56. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Bank to Bank Information Mapping - Definition Depending on the space available and the presence of the elements in the MX message, the following priorities and order are applied to field 72 Bank to Bank Information: • /INTA/ - IntermediaryAgent 2 & 3* • /SVCLVL/ - PaymentTypeInformation/ServiceLevel *(excluding 23E code – SDVA and G00n gpi codes) • /LOCINS/ - PaymentTypeInformation/LocalInstrument *(excluding 23B codes) • /CATPURP/ - PaymentTypeInformation/CategoryPurpose *(excluding 23E codes) • /ACC/ - InstructionForCreditorAgent (excluding 23E codes) • /REC/ - InstructionForNextAgent (excluding /FIN54/**) • /INS/ - PreviousInstructingAgent1,2,3 Logic Note: Possible missing (Error Handling mechanism will be defined to report the missing information) or truncated information can apply. *means new code words to be used in Field72 **/FIN54/ with BIC is used in a specific scenario in MT to indicate where the receiver will claim the money. This code word will be present only if a previous MT to MX translation already occurred. 56
  • 57. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example MX/MT Bank to Bank Information (72) <PmtTpInf> <SvcLvl> <Prtry>Single Euro Payments Area</Prtry> </SvcLvl> <LclInstrm> <Prtry>Cash Concentration Intragroup</Prtry> </LclInstrm> </PmtTpInf> <IntrmyAgt2> <FinInstnId> <BICFI>BCITITMMXXX</BICFI> </FinInstnId> </IntrmyAgt2> <IntrmyAgt3> <FinInstnId> <BICFI>BARCIE22XXX</BICFI> </FinInstnId> </IntrmyAgt3> <InstrForNxtAgt> <InstrInf>Instruction number 1</InstrInf> </InstrForNxtAgt> <InstrForNxtAgt> <InstrInf>Instruction number 2</InstrInf> </InstrForNxtAgt> </CdtTrfTxInf> MX :72:/INTA/BCITITMMXXX /INTA/BARCIE22XXX /SVCLVL/Single Euro Payments Area /LOCINS/Cash Concentration Intragro //up /REC/Instruction number 1Instructi+ MT 57
  • 58. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example of Regulatory Reporting Information <Cdtr> <Nm>ABC IMPORTS AND EXPORTS (INDIA) </Nm> <PstlAdr> […] </PstlAdr> <Id> <OrgId> <LEI>335800HMLW2U4UHRBW65</LEI> </OrgId> </Id> <CtryOfRes>DE</CtryOfRes> </Cdtr> […] <RgltryRptg> <DbtCdtRptgInd>CRED</DbtCdtRptgInd> <Authrty> <Nm>Reserve Bank of India</Nm> <Ctry>IN</Ctry> </Authrty> <Dtls> <Tp>Export Reporting</Tp> <Dt>2019-01-13</Dt> <Ctry>IN</Ctry> <Cd>P0102</Cd> <Amt Ccy="USD">123456891234567.50</Amt> <Inf>AAASDASAD</Inf> </Dtls> <RgltryRptg> MX :77B:AAASDASAD/BENEFRES/DE MT 58
  • 59. ISO 20022 Programme - Quality data, quality payments - BBH - March 2021 - Restricted Example of Settlement Time <CdtTrfTxInf> … <SttlmTmIndctn> <DbtDtTm>2018-01-04T15:12:09+09:59</DbtDtTm> <CdtDtTm>2018-01-04T15:12:09+09:59</CdtDtTm> </SttlmTmIndctn> <SttlmTmReq> <CLSTm>09:30:47+05:00</CLSTm> <TillTm>09:30:47+05:00</TillTm> <FrTm>09:30:47+05:00</FrTm> <RjctTm>09:30:47+05:00</RjctTm> </SttlmTmReq> … </CdtTrfTxInf> MX :13C:/SNDTIME/1512+0959 :13C:/RNCTIME/1512+0959 :13C:/CLSTIME/0930+0500 :13C:/TILTIME/0930+0500 :13C:/FROTIME/0930+0500 :13C:/REJTIME/0930+0500 MT Illustration included multiple settlement times. It is unlikely all of the examples used would be included in a transaction at the same time. 59
  • 60. Usage guidelines ISO 20022 Programme - Quality data, quality payments 60 Where can I find more information?
  • 61. ISO 20022 Programme - Quality data, quality payments 61 MT/ISO 20022 Translation rules – Where to find out more https://www2.swift.com/mystandards/#/c/cbpr/landing Q1 2020 User Handbook iteration will include a full section describing the Translation mapping principals. MT/ISO 20022 Translation section of the CBPR+ landing page
  • 62. ISO 20022 Programme - Quality data, quality payments 62 Further webinars & work sessions Join a webinar or work session near you to learn why ISO 20022 adoption is necessary, how to make the change and what support SWIFT will provide Where can I get more help? New resources are available for vendors SWIFTSmart The SWIFTSmart e-learning training platform includes an introduction to ISO 20022. A formal curriculum will be published by end of the year WWW ISO 20022 vendor landing page The ISO 20022 vendor landing page provides more information on the programme, timeline, transition period and resources MyStandards The CBPR+ MyStandards page hosts all usage guidelines, a readiness portal for testing your back office applications and coming soon a mapping sandbox to publish translation rules Partner Programme Join the Partner Programme to gain access to further support. The Programme also helps SWIFT customers to make well-informed purchasing and implementation decisions, and providers to differentiate their offerings in a crowded market place. Vendor support Partner Programme member support is available to help you through ISO 20022 migration, get trained, and support your implementation. Knowledge Centre The Knowledge Centre hosts detailed documentation on SWIFT products services, including the SWIFTNet messaging service that will be the basis for the new InterAct service to support CBPR+ compliant flows Documentation The Updated ISO 20022 for Dummies e-book is available to understand the basics of ISO 20022 and implications for financial messaging