WIXLIB

3. Message development approachAll messages have been developed in conjunction with the ISO 20022 Message DevelopmentGroup from late 2019 through early 2021. This group was formed in 2018 and there are 22organizations participating in the group. It consists of Payments Canada Members, including theBank of Canada, as well as government and corporate stakeholder representatives. It is across-system group and each firm may send different experts to the meetings depending onwhether we are creating messages for high-value payments (Lynx), real-time payments (RTR) orbatch payments.Meetings were held in November and December 2019 to finalize the pacs.008, pacs.009 (core andcov) and head.001 (BAH) over the course of five full-day sessions. Pacs.004 was finalized duringsessions held in the fourth quarter of 2020. Minor updates to all messages related to CBPR changes were reviewed and finalized in early 2021. All Lynx Participants were invited toparticipate. See Appendix 2 for more information related to the ISO 20022 Message DevelopmentGroup, including the terms of reference and list of participating organizations.An important aspect of the work to create the Lynx ISO 20022 messages has been the alignmentof the Lynx messages with both the CBPR and HVPS message usage guidelines (seedefinitions of these important groups in Appendix 1). CBPR ’s work focuses on high-value crossborder payments and HVPS ’s work focuses on domestic, centrally cleared high-value payments.The two groups have aligned their respective usage guidelines very closely and the Lynx ISO20022 messages are similarly aligned. The main differences between the Lynx ISO 20022messages and the CBPR ISO 20022 messages are that the Lynx messages are designed to befit-for-purpose for Canadian high-value payments that are centrally cleared and settled throughLynx on the books of the Bank of Canada.3 We frequently refer to CBPR and HVPS in both thiscompanion document and in the Lynx ISO 20022 Message Specifications because alignment andharmonization with these important initiatives are of critical importance for data integrity andinteroperability. It is important to note that alignment with the CBPR usage guidelines has takenprecedence over alignment with HVPS because the CBPR usage guidelines will beimplemented on the SWIFT network when they begin their migration to ISO 20022 in November of2022. Therefore, Canadian financial institutions will begin to receive these messages fromcross-border SWIFT correspondents and if they plan to transmit those messages within Canada,3See Appendix 3 for a summary of the differences between CBPR guidelines and the Lynx ISO 20022messages.8

they will need to have the capability to formulate ISO 20022 Lynx messages that allow for all thesame elements and components that are part of the CBPR usage guidelines implemented onSWIFT. This will ensure that all data elements can be transmitted in full and avoid truncationbetween Canadian financial institutions. See illustration of this flow in Diagram 1 below:DIAGRAM 1 – Cross-border correspondent payment flow for Lynx.Over the past few years Payments Canada has been working closely with other high-valuepayment system operators around the globe to harmonize our respective ISO 20022 messages,promote common approaches to message usage and further ensure global interoperability.In 2015 SWIFT launched an ISO 20022 Harmonization Charter to promote common approachesto implementation among Financial Market Infrastructures (FMIs) around the world (ISO 20022Harmonization Charter on swift.com). Some 30 FMIs (including Payments Canada and the Bankof Canada) have signed the Harmonization Charter. The key principles of the Charter include: Sharing of information - FMIs share information about their ISO 20022 implementationplans with the other endorsing and supporting FMIs.Adherence to market practice – FMIs adhere to global ISO 20022 Market Practices andbase their own usage guidelines on these market practices.Adherence to the message version and release management – FMIs update to the latestISO 20022 message version that is in line with the ISO 20022 release cycle.9

With this in mind, SWIFT and other global payment system operators have agreed to begin themigration to ISO 20022 starting with the version of the messages published in 2019 (referred toas Standards Release 2019 or SR2019). Payments Canada will also use this version for the Lynxrelease two implementation in November of 2022.4. Lynx ISO 20022 message portfolioBelow is the portfolio of ISO 20022 messages that are envisioned for the Lynx target end-stateimplementation:ISO 20022Message nameISO 20022MessageidentifierLynx MessagefunctionLynx releaseMessagestatus forLynxBusinessApplicationHeader (BAH)head.001.001.02BusinessApplication Headerfor all MessagesTo beimplemented inrelease two,November2022Final(publishedJune 2021)FI to FICustomer CreditTransferpacs.008.001.08Single customercredit transferTo beimplemented inrelease two,November2022Final(publishedJune 2021)FinancialInstitution CreditTransferpacs.009.001.08(core)Single financialinstitution credittransfer (core)To beimplemented inrelease two,November2022Final(publishedJune 2021)FinancialInstitution CreditTransferpacs.009.001.08Single financialinstitution credittransfer (cover)To beimplemented inrelease two,November2022Final(publishedJune 2021)Core Messages10

ISO 20022Message nameISO 20022MessageidentifierLynx MessagefunctionLynx releaseMessagestatus forLynxPayment Returnpacs.004.001.09Return of a single(customer orfinancial institution)credit transferTo beimplemented inrelease two,November2022Final(publishedJune 2021)Statement(includes balancesand transactions)To be optionallyavailable inrelease two,November2022Initial draft(reviewedDecember2019) - to bepublishedReport of paymentstatusBeingconsidered forfutureimplementationInitial draftRequest for areport of paymentstatusBeingconsidered forfutureimplementationInitial draftRequest for areturn of a singlecustomer credittransferBeingconsidered forfutureimplementationInitial draftRefusal of arequest for a singlecustomer credittransferBeingconsidered forfutureimplementationInitial draftReporting MessagesBank toCustomerStatementcamt.053.001.08Supporting MessagesPayment StatusReportFI to FI PaymentStatus RequestRequest forCancellationResolution )(notreviewed)(notreviewed)11

ISO 20022Message nameISO 20022MessageidentifierLynx MessagefunctionLynx releaseMessagestatus forLynxReceiptcamt.025.001.05Message receiptacknowledgementBeingconsidered forfutureimplementationInitial draft(notreviewed)This document and the Lynx ISO 20022 Message Specification documents only cover the first fivemessages (the Core Messages) in the list above, the pacs.008, pacs.009 (core and cov), pacs.004and head.001. Payments Canada will also make the camt.053 optionally available for Participantswithin the Lynx application for release two. The specifications for the camt.053 will be provided aspart of the Lynx application enhancements. The rest of the message portfolio will be finalizedonce the scope of the next release is agreed. For Lynx release two, Lynx participants must be ableto receive only the pacs.008 ( BAH), pacs.009 (core and cov BAH) and pacs.004 ( BAH)messages through the new Lynx SWIFTNet Partial Y-Copy Closed User Group (CUG also referredto as the MX CUG). This new MX CUG will coexist and run in parallel with the existing SWIFT MTCUG (for MT 103 and MT 205). This coexistence period will remain in place until a date is set forthe discontinuation of the SWIFT Lynx MT CUG, after which Lynx will begin to process only theISO 20022 messages.4 Details related to the new MX CUG and the partial Y-copy details can befound in the Lynx SWIFTNet Partial Y-Copy Companion Document and the Lynx Rules (underdevelopment as of the publication of this document).4.1 Message flowsThe pacs.008, pacs.009 and pacs.004 messages and Y-copy flows are illustrated in Diagrams 2, 3and 4 below:4The plan and dates for decommissioning the MT CUG will be discussed and agreed to with Participants asthere will be a number of factors that need to be taken into consideration (e.g. SWIFT migration windowuntil 2025) prior to any changes being made.12

DIAGRAM 2 – pacs.008 SWIFTNet Message and Y-Copy Flow.DIAGRAM 3 – pacs.009 SWIFTNet Message and Y-Copy Flow.13

DIAGRAM 4 – pacs.004 SWIFTNet Message and Y-Copy Flow.The Business Application Header (head.001) will be part of the business message and sit atop thepacs.008, pacs.009 (core and cov) and pacs.004 when they are sent from instructing agents toinstructed agents. Messages transmitted over SWIFTNet InterAct contain additional technicalheaders that are used for routing and other network and security purposes. See Diagram 5 belowillustrating this in the context of a SWIFT message.14

DIAGRAM 5 – SWIFTNet InterAct Message Blocks.4.2 Implementation of ISO 20022 for LynxThe following sections provide some highlights on the message specification details that areapplicable across the portfolio.4.2.1 Single payments only in LynxThe master ISO 20022 messages (pacs.008, pacs.009 and pacs.004) allow for multiple paymentsto be included in the messages. For Lynx, only a single payment will be allowed in each respectiveISO 20022 message. This restriction is already part of the Lynx ISO 20022 Message Specificationwhere the number of transactions is limited to only ‘1’.15

4.2.2 Character SetLynx ISO 20022 messages will support the following Character Set. All message elements which are defined (by Data Type) as text are limited to the SWIFTFIN-X Character Set (this is the Character Set that is currently in place for the SWIFT MTmessages): A-Z a-z 0-9 / - ? : ( ) . , ‘ CR LF and SPACE.Special characters are additionally allowed in 1) all party (agents and non-agents) NameAnd Postal Address components/elements, 2) the Related Remittance Informationcomponent, 3) the Remittance Information (Structured and Unstructured) component and4) the Email Address where included as part of a Proxy element. The list of specialcharacters is as follows: ! # % & * { } " ; @ [ \ ] .This is aligned with the Character Set that will also be implemented by SWIFT (CBPR ) for theircross-border ISO 20022 messages. It should be noted that while ISO 20022 base standardssupport non-Latin characters, CBPR (and Lynx) will only support Latin characters in the initialservice implementation.4.2.3 Use of Local InstrumentLynx will make use of the Payment Type/Local Instrument/Proprietary element to indicate thesettlement mechanism and settlement priority for all Lynx transactions. For this reason, thesecomponents and elements have been made mandatory (where possible) and contain thefollowing specific market practice/textual rule and proprietary code list for the population of thiselement:Lynx LocalInstrument:Local Instrument is to be used to indicate the settlement mechanism and settlementpriority information as defined by Lynx. This is an alphanumeric element (numbers orletters). The first character represents the settlement mechanism and the next 2characters, if present, represent the settlement priority for the Liquidity SavingsMechanism (LSM). Acceptable values are: 1 (definition Urgent Payment Mechanism - UPM, default priority)2 (definition LSM, default priority)201 (definition LSM, priority 1)16

203 (definition LSM, priority 3)205 (definition LSM, priority 5)R (definition Reserved Collateral Mechanism - RCM, default priority)4.2.4 Agents and partiesThere are 16 Agents and 14 Parties in a pacs.008 message (and double this number in apacs.009 COV and a pacs.004). Agents are defined in the context of ISO 20022 as FinancialInstitutions (FIs) and Parties are defined as non FIs.Below is a table containing some definitions of the main Agents and Parties in the pacs.008,pacs.009 and pacs.004 messages. This is not an exhaustive list and is provided here with somealternative terms to familiarize the audience with some of the new ISO 20022 terminology forAgents and Parties in payments.Agent/PartyISO 20022 definitionUltimate DebtorUltimate party that owes anamount of money to the(ultimate) creditor.DebtorParty that owes an amount ofmoney to the (ultimate)creditor.Ultimate CreditorUltimate party to which anamount of money is due.CreditorParty to which an amount ofmoney is due.Initiating PartyParty that initiates thepayment. This can be eitherthe debtor or a party thatinitiates the credit transfer onbehalf of the debtor.Alternative termsOriginator, OriginatingCustomer, Originating Party,Payor.Beneficiary, BeneficiaryCustomer, Receiving Party,Payee.17

Agent/PartyISO 20022 definitionAlternative termsDebtor AgentFinancial institution servicingan account for the debtor.OriginatingParticipant/MemberCreditor AgentFinancial institution servicingan account for the creditor.BeneficiaryParticipant/MemberInstructing AgentAgent that instructs the nextparty in the chain to carry outthe (set of) instruction(s).Sender (normally, in the oldMT terminology)Instructed AgentAgent that is instructed by theprevious party in the chain tocarry out the (set of)instruction(s).Receiver (normally, in the oldMT terminology)Previous Instructing AgentAgent immediately prior to theInstructing Agent.Intermediary AgentAgent between the DebtorAgent and the Creditor Agent.18

Diagram 6 below illustrates where these Agents and Parties fall in a simple credit transfer(pacs.008) flow.DIAGRAM 6 – Lynx ISO 20022 Message flow – pacs.008 (black colour indicates mandatory Agents/Parties, blue means optional)The following is a summary of the rules and restrictions for Agents and Parties in the Lynx ISO20022 messages. Details of the rules and all detailed content of the Lynx ISO 20022 messageelements can be found in the Lynx ISO 20022 Message Specifications. These rules andrestrictions are closely aligned with both CBPR and HVPS . Formal rules and restrictions arevalidated in the message and will cause a message to be non-compliant (i.e. the message wouldnot pass schema validation and would be NAK’d by SWIFT) if they are not followed. Marketpractice rules are textual and the messages will pass validation without a message being rejected(or NAK’d). However, market practice rules should still be followed when formulating any ISO20022 message for Lynx. The word ‘Textual’ has been included in the name of these marketpractice rules to differentiate them from the formal rules (which have the word ‘Rule’ at the end ofthe rule name).19

Lynx agentsFormal rules / restrictionsApplicable to all agents (except where noted).Branch ID is removed (except for Creditor Agent where it is left optional for when the CreditorAgent is located in Japan).Financial Institution Identification/other is removed.If Clearing System Member ID is used, Clearing System Identification is mandatory - code only,proprietary is removed.Postal address/address type is removed.Lynx StructureVsUnstructuredPostalAddressRule:If Portal Address is used and if Address Line is present, then all other optional elements inPostal Address must be absent.This rule is inherited verbatim from CBPR .Lynx TownNameandCountryRule:If Postal Address is used, and if Address Line is absent, then Country and Town Name must bepresent.This rule is inherited verbatim from CBPR .Postal Address/Address Line is restricted to three lines of 35 characters.Lynx AgentNamePostalAddressRule:Name and Postal Address must always be present together.This rule is inherited verbatim from CBPR .Applicable only to From/To in the BAH (FI ID) and Instructing/Instructed Agents.BICFI is mandatory, Clearing System Member ID and LEI are optional. Name and PostalAddress are removed.20

Lynx agentsLynx From To InstructingAgent InstructedAgent BICPI Rule1:BAH/From/BICFI must match Instructing Agent/BICFI, except where BAH Copy Duplicate COPY or CODU ANDBAH/To/BICFI must match Instructed Agent/BICFI, except where BAH Copy Duplicate COPYor CODU.This rule is inherited verbatim from CBPR .Lynx From To InstructingAgent InstructedAgent/BICFI Rule2:BAH/From/BICFI must match Instructing Agent/BICFI if Copy Duplicate is absent ANDBAH/To/BICFI must match Instructed Agent/BICFI if Copy Duplicate is absent.This rule is inherited verbatim from CBPR .Applicable only to Return Chain and Original Transaction Reference, Debtor/Creditor as Agent inpacs.004:Lynx ReturnChainDebtorAgentRule:If Original Message Name Identification is a pacs.009.001.xx, MT205 or MT202, then the Debtormust be identified as an Agent in Return Chain.This rule is inherited verbatim from CBPR .Lynx ReturnChainDebtorCreditorPartyRule:If Original Message Name Identification is a pacs.008.001.xx or MT103, then in the ReturnChain:- If Debtor/Agent is present, Creditor/Agent must be absent, and- If Creditor/Agent is present, Debtor/Agent must be absent.And both Agents can be absent.This rule is inherited verbatim from CBPR .Lynx OriginalTransactionReferenceDebtorAgentRule:If Original Message Name Identification is a pacs.009.001.xx or MT 205 or MT202, and ifOriginal Transaction Reference is present, Debtor if present must be identified as an Agent.This rule is inherited verbatim from CBPR .Lynx e:If Original Message Name Identification is a pacs.008.001.xx or MT103, then in OriginalTransaction Reference:- If Debtor/Agent is present, Creditor/Agent must be absent, and- If Creditor/Agent is present, Debtor/Agent must be absent.21

This rule is inherited verbatim from CBPR .Market Practice RulesApplicable to All Agents (except Instructing/Instructed Agents).Lynx Textual Agent NationalOnly:Whenever Debtor Agent, Creditor Agent and all Agents in between are located within the samecountry, the Clearing System Member Identification only may be used.This rule is inherited verbatim from CBPR .22

Lynx agentsLynx Textual Agent Option1:BICFI, complemented optionally with LEI (preferred option).This rule is inherited verbatim from CBPR .Lynx Textual Agent Option2:(Clearing System Member Identification OR LEI) AND (Name AND (Unstructured Postal AddressOR [Structured Postal Address with minimum Town Name AND Country]). It is recommended toalso add the Post Code when available.This rule is inherited verbatim from CBPR .Lynx Textual Agent Option3:Name AND (Unstructured OR [Structured Postal Address with minimum Town Name ANDCountry]). It is recommended to also add the Post Code when available.This rule is inherited verbatim from CBPR .Lynx Textured Co-existence PostalAddress:Address Line (Unstructured Address) remains available only for cases when the payment isinitiated in FIN, or by an MI, during coexistence only. The Structured Postal Address remains thepreferred option. Therefore:- If a payment is initiated on FIN, or by an MI, and the Postal Address is unstructured, theoutgoing ISO 20022 message will transport unstructured postal address, up to the CreditorAgent.- If a payment is initiated in ISO 20022, Postal Address must be structured.This rule is inherited verbatim from CBPR .Textual Rules Added at Message Level of all Agents:If BICFI is present, then (Name AND Postal Address) are NOT allowed (Clearing SystemMember Identification and LEI may complement) – However, in case of conflicting information,the BIC will always take precedence.If BICFI is absent, (Name AND Postal Address) OR Clearing System Member Identification mustbe present and both are allowed together.These rules are inherited verbatim from CBPR .23

Lynx partiesFormal rules / restrictionsApplicable to all parties (except where noted).Contact details is removedIdentification/Org ID/Other and Identification/Private ID/Other are both limited to 2 repetitions.Postal Address/Address Type is removed.Structured and Unstructured Postal Address are mutually exclusive (see formal rule forDebtor/Creditor, for all other Parties, only Structured Address is allowed - AddressLine isremoved).Town Name and Country are mandatory for Structured Postal Address (except for UltimateCreditor where only Country is mandatory) (see formal rule below).Postal Address/Address Line is restricted to 3 lines of 35 characters.Lynx PartyNamePostalAddressRule:If Postal Address is present, then Name is mandatory (except Parties in Structured RemittanceInformation component).This rule i

1The full Message Identifier Name for these ISO 20022messages is pacs.008.001.08, pacs.009.001.08 (core or cov) and pacs.004.001.09. For the sake ofbrevity and simplicity, we are shortening this notationin this document and will refer to the messages by theshorter notation pacs.008, pacs.009 (core or cov)and pacs.004. 5