WIXLIB

//8Guide to ISO 20022 migration, Part 2updated or redeveloped, and what impact this will have on participant banks.13 Currently, noenhancements are planned to maximise the benefits of the migration (although enhancements andadditional information may be added in the future, subject to proposal by the community following fullimplementation).14The system’s only substantial changes in functionality therefore result from the shift from thetraditional Y-copy topology to the new V-shape in line with T2. Users may also look forward to someimprovements. For example, it will be possible to warehouse payments for 10 calendar days, asopposed to five value days under the old system, or to cancel/recall not only warehoused payments,but also those that have successfully been processed within the last seven calendar days.151.3 US dollar areaThe migration to ISO 20022 in the US revolves around the US Federal Reserve’s Fedwire andClearing House Interbank Payments System (CHIPS) services, which are currently planned to makethe move in three phases. Preparation is currently underway with migration set to begin in November2020. In March 2019, the Federal Reserve updated its Fedwire Application Interface Manual fora final time, announcing version 4.0.2 as the “locked down” version that will be implemented inNovember 2020.16Along with other central banks, however, conscious of recent developments in the many-to-manyspace and keen to reflect market readiness, the Federal Reserve’s approach is currently beingreconsidered, with further updates likely to arrive in Q4 2019.1.4 Sterling areaIn the UK, migration is being driven predominantly by the Bank of England’s renewal of its RealTime Gross Settlement (RTGS) system (though other systems, such as BACS and Faster Payments,have subsequently been mandated to make the switch). As with the US Federal Reserve – and withthe same considerations in mind – the Bank of England is currently reviewing its approach and mayannounce any change of plan at Sibos in London in September 2019.Nevertheless, developments have taken place in the last few months. On 13 January 2019, theBank of England released a document outlining the new services offered under its renewed system,including the reconfiguration of data sent and received through the system to align with ISO20022 – leading to new liquidity and value-day reporting benefits, such as notification of successfulsettlement.The document also offers an update on the timeline, outlining four “transition states”:–– Foundation – a preparatory phase where relevant participants are engaged, early benefits aredelivered and system resilience is increased, where possible–– Participant Data Channels, where sent data is reconfigured based on ISO 20022, with furtherbenefits delivered–– Core RTGS Replacement, where the core RTGS systems are rebuilt and technical changes areconsolidated–– Fully Renewed Services (where all changes are finalised and non-critical elements are factored in.In its August 2019 Annual Report on RTGS and CHAPS,17 the Bank of England highlighted that thenext step in its renewal process is to continue working with external participants on the Foundationphase – developing the design of the new platform and preparing for implementation.

Guide to ISO 20022 migration, Part 22Overall impact for market participantsAs the 2021 deadline to move to ISO 20022 for FI to FI Payments & Reporting draws nearer, there arevarious developments which banks and corporates will need to be aware of and potentially act upon.This section explores some of the major ones.2.1 ISO 20022 Standards2.1.1 Variety of usage guidelinesDuring the past two years of 2017 2019 a variety of ISO 20022 usage guidelines have beendeveloped, including High Value Payments Plus, or HVPS , (in the one-to-many space), CBPR (inthe many-to-many space) and UDFS (in the local euro market). Each set of guidelines contains similarbut unique complexities that market participants will need to stay abreast of.The HVPS usage guidelines were built for the six core messages: pacs.008, pacs.009, pacs.004,pacs.002, camt.029 and camt.056. At the time of their creation, it was decided that the guidelineswere not going to be validated on the SWIFT network. This allowed each MI to comply with theHVPS , but also apply their own restrictions or “flavour”.A further set of guidelines, known as the CBPR usage guidelines (for use in correspondentbanking), are in development – with the guidelines for pacs.008, pacs.009, pacs.002 and pacs.004already available, and eight more set to be released by November 2019 (see Section 1.1: Theglobal view: SWIFT). In February 2019, it was agreed that these would be based upon the HVPS guidelines – acknowledging the fact that there might be some minor differences based on specificlocal requirements. And unlike the HVPS guidelines, CBPR includes a SWIFT network validation.Moreover, only one version of these guidelines will be implemented in the live environment across theSWIFT network.The slight differences between the two usage guidelines have a number of potential implications forall market participants. For example, a payment sent to an MI will use pacs.008 based on the HVPS usage guidelines (or UDFS for the Eurosystem), yet once it is passed on to a correspondent bank, itwill use the CBPR usage guidelines (see Figure 2 overleaf). Banks will therefore need to ensure thatthey understand both guidelines, and “speak” all the “dialects” of ISO 20022.//9

//10Guide to ISO 20022 migration, Part 2Figure 2: Complexity of message formats and usage rulesCustomerBankClearingBankCustomerPAIN 001PACS.008PACS 008CAMT 52/53/54Rules different bybank/country,CGI as facillitatorfor harmonisationHVPS subsetand rulesHVPS subsetand rulesRules may differby community/bank/country,CGI/CBPR /HVPS asfacilitator forharmonisationPACS.008PACS 008MT940/950/942MT101Rules differentby bankLocal StandardEurosystemUDFS subset andRTGSrules (very stricton structuredparty data)UDFS subset andrules (very stricton structuredparty data)Local StandardPACS.008 (and MT103 co-existence)CBPR Subset, usage rules and conversion rulesClient FormatISO20022 subsetNon-ISOSource: Deutsche Bank2.1.2 SWIFT gpiAs per SWIFT’s gpi roadmap, all products will be available in ISO 20022 messages. In November2018, SWIFT launched a “gpi ISO 20022 adoption initiative” to prepare for the general milestoneof November 2021 (see Figure 11 on page 19), which included the establishment of a “gpi expertsgroup”. CBPR works together with the “gpi expert group” to enable gpi services on ISO 20022. Thisupgrade is a critical element to maintain the newly achieved service standard for the customer andcontinue to build a more frictionless cross-border payments model.While gpi will be fully based on the CBPR usage guidelines, additional aspects, such as thecommunication with the gpi Tracker, if MT199 is used, must be considered in projects of this nature.Banks not yet live on gpi are strongly encouraged to use the ISO 20022 project to simultaneouslyimplement gpi for the benefit of their own customer.2.1.3 Annual ISO 20022 maintenance cycleIn previous years, there has been no harmonised maintenance and release cycle for ISO 20022 inpayments. As such, different ISO 20022 message versions are still in use simultaneously today.Following the move to ISO 20022, SWIFT will carry out a structured annual maintenance cycle, inalignment with major MIs and RTGS systems. As of November 2021, there will be one commonpractice of ISO 20022 pacs and camt messages for FI to FI payments and reporting available onthe SWIFT network at any one time. For example, at the end of 2021, the SWIFT community willimplement and subsequently work with the latest version of ISO 20022. This will be applicable toHVPS and CBPR only, not pain or camt messages used between banks and their clients or pacsmessages used in other schemes.

Guide to ISO 20022 migration, Part 2//11Operating similarly to the current SWIFT FIN maintenance process, banks/communities will have theopportunity to raise change requests to meet regulatory requirements or improve system efficiencies.The importance of this change request is then decided by the SWIFT global community, whichapproves or rejects the change via the country voting (see Figure 3). Participants will also be able toprovide feedback to the release cycle, ensuring key issues are identified and addressed by the globalcommunity.It is expected that one of the first maintenance cycles following the move to ISO 20022 will see theoptional unstructured address lines removed completely, as MIs already confirmed that they will nolonger be supported once the coexistence phase with FIN ends in 2025.Figure 3: SWIFT ISO 20022 Market Practice (MP) Change Request (CR) submissionsSWIFT ISO 20022 Market Practice (MP)Change Request (CR) SubmissionsDeadline MP CRSubmission1 Apr Y0Optional MP meeting to review the CRsMay Y0Jun Y0Sep Y0MP CRRejectedSubmitterinformedAlignment with HVPS MP CRAccepted Impact on baseCR to ISOmessageBoardinformedAll MP CR, with or without ISO20022 base message impactFeed into ISOHVPS informedMP CR Rejected1 Jun Y0Review ISO CRsMessage ChangeRequest DocumentationMP meeting toreview all CRsend AugY0MP CR RejectedBoard RatificationDec Y0SubmitterinformedYesNoPublicationDraft MP v 1Feb Y 1Nov Y 1Deadline CR forISO 20022messagesCountry Vote on MP CRs4 weeksmid OctY0Jan Y 1No impact onbase messageISO 20022 Message ChangeRequest SubmissionsCBPR Use Case GuidelinesPublicationFinal MP v 1Publication of new version ofbase ISO 20022 message V 1MP Market Practice, CR Change Request, YO Current Year, Y 1 Following YearLive: MP v 1Live: ISO 20022 message V 1Feb Y 1Nov Y 1Source: SWIFT2.1.4 Adapting the framework for new actorsIn order to account for evolving payment practices among businesses around the world, theupcoming version of ISO 20022 incorporates new terminology and data fields. First of all, it isimportant to understand the terminology delineating different types of actors in a payment chain.ISO 20022 wording distinguishes between “agents” – banks moving money along the chain – and“parties”, bank clients making, initiating and receiving payments (see box-out overleaf).

//12Guide to ISO 20022 migration, Part 2Definition of payment actors under ISO 20022Actor:Any participant in the payment chainAgent:A participant in the payment chain that executes the movement of fundsbetween – either the bank of the payer or payee or an intermediarycorrespondent bankParty:A bank client, making initiating or receiving a payment within the chainCreditor:The party whose account is credited with a paymentDebtor:The party whose account is debited with the paymentUltimatecreditor:The party which is the ultimate beneficiary of the payment. For example, thepayment is credited to an account of a financing company, but the ultimatebeneficiary is the customer of the financing company.Ultimatedebtor:The party that originally ordered goods or services and to whom the seller hassent the invoice. Ultimate debtor is used when the receiver of the invoice isdifferent from the payerInitiatingparty:The party on the initiative of which the payment data is established. This mightbe the payer itself, an agent, or the company service centreAccordingly, the incoming version of ISO 20022 introduces three new parties in the paymentschain: the ultimate creditor, the ultimate debtor and the initiating party (see Figure 4). These are notcurrently accommodated by FIN messages, a situation that often proves a pain point for banks andcorporates.In a payment factory scenario, for example, while a payment may be credited to a company’saccount (creditor), the ultimate beneficiary of the payment may be the customer or the subsidiaryof the company (ultimate creditor) instead. Without a dedicated payment field, crucial informationpertaining to the ultimate creditor is sent outside of the payment message entirely. This makes itdifficult to ensure that all relevant information is passed down the payment chain – often delayingpayments processing and complicating reconciliation.The ISO 20022 standard introduces specific fields for the information pertaining to these paymentactors – making the payment message clearer and more structured. This circumvents the issuesunder FIN equivalent payments and helps improve Anti-Financial Crime controls and reconciliationprocesses.The move to ISO 20022 messages does bring some challenges, too. A direct equivalent of F72(Sender to Receiver Information) is not included in ISO 20022 messages, though it does includeadditional fields where this information could be mapped – such as “Instruction for Next Agent” or“Instruction for Creditor Agent” (see Figure 5).

Guide to ISO 20022 migration, Part 2//13Figure 4: Future end-to-end payment chainActors (agents & parties) and message types in the future end-to-end payment flowPayment Initiation (pain)UltimateDebtorDebtorPayments Clearing & Settlement (pacs)ForwardingAgentInitiatingPartyPrevious tructingAgentCash Mgt ditorCreditorAgentCreditorNew parties introduced in ISO 20022Source: Deutsche BankFigure 5: Payment flow- pacs.008 vs MT103:72:/INS/ForwardingAgent:53aPrevious termediaryAgentsUltimateCreditorAgents & ructingAgentInstructedAgentCreditorAgent:52a or SenderSender or :72:/INS/*Receiver or :56a:57aRemittance InformationFurther Information:XXDebtorAgentInstruction for Creditor AgentInstruction for Next Agent:72End-to-End IdentificationFIN MT format equivalent*depending on the message flowSource: Deutsche Bank:70:72Instruction for Next Agent:70:72Creditor:59a

//14Guide to ISO 20022 migration, Part 22.2 SWIFTNet services2.2.1 Translation testingAs the ISO 20022 adoption approaches, market participants must be able to validate theirinterpretation of the CBPR usage guidelines. SWIFT has begun developing a translation portal totranslate SWIFT FIN messages to ISO 20022 messages and vice versa.In June 2019, SWIFT released the first beta version of its translation portal, with mapping viewerfunctionality. At the time of writing, a second beta version is set to be released in December 2019,which will include a “Google translate-like” feature, provisionally known as the translation sandbox.Once an MT103 message is inputted into the feature a user can click “convert”, which translates themessage into the pacs.008 format.The first version of this translation portal to be generally available is scheduled for release inDecember 2019. While the service currently applies only to the translation of MT103 messagesto pacs.008 and conversely of pacs.008 messages to MT103, future updates are expected toincorporate a wider variety of formats – though these are yet to be defined.Community testingAlongside these tools, SWIFT will also facilitate community testing. SWIFT will provide pilotmessaging and translation services as of September 2020, ahead of a go live in November 2021.This will allow banks to send and receive ISO 20022 messages with their counterparties to confirmreadiness.2.2.2 SWIFT central translation serviceFollowing the move to ISO 20022, market participants that take receipt of payments will have toconsider – in cases where their infrastructure is not ready for consumption of ISO 20022 front-toback – how they translate incoming payment messages from the new format to the old FIN formatfor further processing. In anticipation, SWIFT has developed a translation service for the coexistenceperiod for incoming messages, with three primary delivery models: central translation in flight, centraltranslation via API, and local translation.Central translation in flightUnder the in-flight method, an MX/ISO 20022 message is caught “in flight” between the orderingbank to the receiving bank and a translated MT/FIN formatted copy will be attached to the message.Both the MX and MT versions of the message are delivered to the receiving bank as a multi-formatenvelope via the store-and-forward messaging service.The more structured and granular data provided by the MX message means that mapping from MXto MT will naturally lead to a potential loss of data, known as truncation. While the translated messagewill allow the receiver to carry out the processing/accounting of the payment, it may still need toreview the original MX. Reasons for this include, but are not limited to:–– Anti-Financial Crime due diligence responsibilities;–– Additional information that may be needed for reconciliation; and–– A client requesting to see the content of the MX (to the extent it is relevant to them).This method focuses on CBPR translation only and is not applicable for ISO 20022 use with MIs(see Figure 6).

Guide to ISO 20022 migration, Part 2//15Figure 6: Central translation in flight1In flight with multi-format MX X to MT onlySource: SWIFTCentral translation via APIThe second central translation method uses an API to facilitate the payment message translation. Inthis case, an MX message is sent from the ordering bank to the receiving bank with no intermediarytranslation step. Once received, an API call from the receiving bank’s back office is then used toinitiate a request to SWIFT to translate the message centrally and provide the corresponding SWIFTMT in addition. This method has a two-way translation functionality – capable of translating MXmessages to MT, and MT messages to MX. At first, the solution will be only focused on CBPR translations, but this is set to be extended to other usage guidelines (see Figure 7).This particular translation method is focused on participants which might only play a specific role inthe payment chain – meaning they may need to work in both MT and MX messages concurrently.After the move to

Guide to ISO 20022 migration Part 2 Our "Guide to ISO 20022 migration: Part 1" was published in May 2019 and this, Part 2 in our series of ISO 20022 guides, follows only four months later. Yet the migration to this new global standard for payments messaging has made significant progress even in such a relatively brief period of time.