ISO 20022 in focus with HSBC

HSBC processes 4.4 billion payments every year – or 139 every second. The bank has offered ISO 20022 XML based products and solutions since 2003, and has seen a continuous growth in customer demand and transaction volume. Recently, HSBC partnered with SWIFT to define a common industry standard for APIs in Hong Kong, based on ISO 20022.

For HSBC, the adoption of ISO 20022 with rich, structured and flexible data fields will lay the foundation for better client experiences through enhanced product propositions and digital delivery.

The growing adoption of ISO 20022 means we are getting closer to a world of borderless payments with interoperability between various payments infrastructures. This will enable clients to be more efficient in their treasury operations, while the richer data included in payments using the standard will provide fresh insights to help treasurers intelligently run and grow their businesses.

With ISO 20022, high value and real-time payment systems are converging on a common, rich, structured financial language. This consistent and uniform language for payments will allow banks to send more remittance information and identify all parties as part of the payment. This will enable more automated processing, reducing costs and risks while improving matching and reconciliation for corporate treasurers. 

Payment systems in different countries use a variety of financial messaging standards today. These disparate standards, each with their own data models and structure, means data for cross-border payment processing is translated multiple times across the payments chain, susceptible to misinterpretation, manual intervention and delayed processing.

What improvements does ISO 20022 bring over MT?

• Element hierarchy: Nested elements for logical grouping of data.For example: Creditor comprises
• Dedicated elements For example:Dedicated End-to-end Identification customer reference from Debtor to Creditor
• Settlement Account is a dedicated element rather than relying on cross-field validation, and includes granular sub-elements including Currency of account
• Service Level Code or Proprietary description repeated 3 times to capture specific service explanations
• Charge information includes sub-elements to capture the Agent that takes charges or is due charges
• Mandatory Debtor Agent and Creditor Agent are static roles which clearly identify who services the customer
• Enhanced data modelExtensible financial language that accommodates local practices and their variants. For example:Accounts identified by sub-elements such as IBAN or Other
• Codes identified as Proprietary or as an ISO recognised Code which may be defined externally to the message
• Agents and party identification includes LEI and more granular Postal Address
• New elementsEnabling On Behalf Of (OBO) payments for example using Initiating Party field to capture details of party initiating credit transfer on behalf of Debtor
• Structured Remittance Information can include rich invoice information to support reconciliation for the Creditor
• Dedicated instruction elements allow instructions for specific parties, such as Instruction for Creditor Agent and Instruction for Next Agent