When it comes to the clearing and settlement of financial transactions between banks and other financial institutions, SWIFT rules the roost. The SWIFT payment network is what lets individuals and businesses accept electronic or card payments even if the counterparty uses a different bank.
SWIFT (which stands for Society for Worldwide Interbank Financial Telecommunications) is the world’s leading provider of secure financial messaging services – a vast network banks use to exchange information like money transfer instructions. Founded in 1973, it’s a global cooperative owned by over 11,000 members that facilitates the exchange of tens of millions of messages a day, and it’s growing fast.
As part of its effort to stay ahead of a rapidly evolving market, SWIFT is making compliance with a standard called ISO 20022 – which improves message routing as part of many cross-border payments and reporting (CBPR+) interactions – mandatory in November of this year.
ISO 20022, which has been around since 2004, represents a dramatic upgrade, with a new message format that’s expected to boost operational efficiency, enhance customer experience and enable innovative new services. Yet for those that rely on SWIFT (namely those that conduct cross-border financial transactions), there is now uncertainty and unresolved questions on the best path forward to meet this new standard.
You can read up on the specifics of the implementation and compliance timeline here, but the key for November 2022 is to upgrade your messaging interface, including review of your configuration to test the receipt of multi-format MX messages (ISO 20022 + MT).
From August 2022, on opt-in basis, or November 2022, for general availability, you’ll have the option to send payments and reporting messages via MT over FIN, as you do today, or ISO 20022 over the FINplus service. Payments-related messages will be received as ISO 20022 messages, or as multi-format messages when delivered via the In-flow Translation service, with both the ISO 20022 and the embedded translated MT. Reporting messages can be received as MTs over FIN, or as ISO 20022 messages over FINplus.
SWIFT won’t completely retire the existing message formats (MT and MX) or FIN (financial information) number system until 2025, but the new ISO 20022-based CBPR+ system becomes an option for early adopters in August and generally available in November, so all banks are on the clock to make sure their message interface at least supports the receipt of ISO 20022-compliant messages.
The amount of work that alone entails will vary by institution. In some markets, most banks have relied so heavily on SWIFT that the rest of their systems for real-time gross transfer are rudimentary and rigid. Other markets like India and Singapore have been on the road to real-time processing of inter-bank transfers for years, so setting themselves up for ISO 20022 will be pretty straightforward.
For example, within the last few years the Monetary Authority of Singapore has been building out their own rich, real-time system for cross-border digital payments, so banks that are tight with MAS should find complying with ISO 20022 a relatively simple matter of tweaking their message interfaces.
Still, every bank has a different journey ahead of it based on their existing infrastructure, technical debt, and strategy. Some are more advanced than others, some have built their own platforms, and others rely on commercial payments platform they’ve integrated into their customer system.
Event-driven architecture (EDA) is a design pattern that has been adopted by digital leaders across industries reliant on real-time data dissemination, such as capital markets, retail, and aviation. The core of EDA is the business “event”, that being something that occurs, which drives the immediate distribution of information about that event so systems and people across the enterprise can react to it.
The fundamental building block of EDA is the event broker – an intermediary that routes information between systems that publish information and those that subscribe to information of that kind. An event mesh is a network of event brokers that uses dynamic message routing (DMR) to distribute information about events from one application to any other application, and any number of applications, no matter where they’re deployed – no cloud, private cloud, public cloud, or any combination.
Not every bank or use case benefits from an event mesh, so how can you figure out if you need one? There are several key indicators you can look for and consider:
With EDA, new channels, payment types and systems can just be added as by connecting them to they connect to the event mesh so they can listen to the topics they care about and do there own thing. No complex integrations, even when you want to consume these events in a cloud or at another site – the event mesh takes care of making the right payment event stream available wherever you want.Enabling Payments Modernization with an Event MeshLearn how big players in the payments ecosystem are modernizing their infrastructure to support high volumes and real-time transactions while integrating with legacy systems and new technology.
Banks that need to make serious upgrades to their infrastructure to support ISO 20022 are at a critical inflection point. This is yet another factor driving institutions to modernize their entire system by moving on from MQ-based payment processing (which isn’t cloud-friendly), embracing event-driven architecture (EDA), and building an event mesh.
If you’re facing the need to tear down walls just to support ISO 20022, doesn’t it make sense to seize the opportunity to modernize and build a tech stack that gives you so many other benefits? Why wouldn’t you want the ability to act on payment information (even for ancillary non-payment purposes) in real-time?
When it comes to payment processing, there are several advantages that EDA brings. During a recent EDA Summit presentation, Eknath Vasishtha, Lead Architect at one of Australia’s Big 4 Banks, ANZ, explained how EDA has helped ANZ simplify their payments landscape in a way that improved customer experience including:
You can watch his presentation here:
In another EDA Summit 2022 presentation, Standard Chartered Bank integration experts Sugata Sarkar and Srinath Sripada-Rao explained how EDA, an event mesh, APIs, and the cloud are reshaping the future of banking. They explain the architectural shift underway, along with the foundational principles they’ve committed to in order to reach their north star of becoming a digital-first, cloud-first, and connected bank:
Sripiada-Rao explained the evolution of message-oriented middleware from message queues and point-to-point delivery where each consumer needs to know the end point of each provider; to service-oriented architecture and enterprise service bus which introduced publish/subscribe message exchange pattern; to today’s EDA and event mesh model which enables dynamic routing based on taxonomy, so consumers can trust the event mesh to get information where it needs to be.
He broke down how EDA entails three components: an event mesh, a sophisticated taxonomy or event model that’s aligned with business object relationships, and an event catalog that lets people across the bank discover, reuse and govern events.
In March of 2021, Standard Chartered Bank Korea used Solace PubSub+ Platform to maximize the agility and efficiency of their Straight2Bank online banking platform which lets businesses make payments and transactions on the go.
Solace has been working with Standard Chartered Bank since 2010 to provide low-latency data distribution for its foreign exchange trading platform across key financial hubs in Singapore, London, Tokyo, and New York. An event mesh they’ve built with Solace technology routes pricing, trades, and orders between each location, enabling them to offer the best market price to each of its customers. As the adoption of digital banking accelerates in Korea, they needed a robust framework that would enable them to develop new digital channels and services that cater to their customers.
At the time, Jason Ki, senior vice president, technology & innovations, SCB Korea, said:
“Solace’s advanced technology provides the ideal platform for the bank to build scalable and future-proof services. We are working with Solace to ensure IT provides modern and agile support to the business while ensuring positive ROI and maximum reliability.”
A Solace powered event mesh built with a network of PubSub+ event brokers dynamically routes events across the payment ecosystem deployed on-premises, private cloud, and public cloud for faster and more efficient transaction completions.
Technical benefits including giving yourself the ability to:
Business benefits include:
Because PubSub+ uses “smart topics” with hierarchy definitions and wildcard filtering to give you the flexibility in application design that you need from a modern event-driven solution. To learn more about how Solace’s rich topics enable fine-grained filtering, read my colleague Aaron’s blog post Solace Topics vs. Kafka Topics or watch this excellent 5-minute video.
Another important feature poised to help banks more easily modernize their payment processing is partition queues, which can partition event streams based on topics and even wildcards.
When a single application/service is processing all payments, things are simple. Whenever a payment is initiated, or cancelled, those requests go to the same component. But when you scale you’ll have many instances of that application, probably microservices, processing requests, and that can get tricky. If a payment and cancel go to different instances, with no recognition that that’s happened, the cancellation might hit the core banking system first, not doing anything, and then the payment is successfully processed.
With support for partition queues, coming later this year, you will be able to partition those events streams. We can do this today with topic sharding, that’s how the banks have been doing it, we are simplifying it, and our ability to partition queues is particularly powerful when paired with our support for wildcard topics.
One requirement banks face in the realm of payment processing is that of end-to-end observability, i.e. giving each participant in a transaction that’s failed the power to prove that they aren’t the problem. I like to call this reducing your mean time to innocence.What is distributed tracing and how does OpenTelemetry work for event-driven integration?How distributed tracing solves issues in the synchronous API world and why it fits even better into event-driven systems.
Our distributed tracing functionality emits trace events in OpenTelemetry format so you can collect, visualize & analyze them in any OpenTelemetry compatible tool such as Jaeger, DataDog, Dynatrace and many others. That means banks will be able to tell not just if a given message was published but exactly when and by whom, where exactly it went, down to individual hops, who received it and when… or why not.
While considering how you’ll support ISO 20022, don’t overlook the opportunity to modernize your system more generally to improve agility and performance, support cloud goals, and improve customer experience. To learn more, check out this whitepaper, How to Modernize Your Payment Processing System for Agility and Performance.