In the last decade, the nature of payments has changed irrevocably. The need for real-time payment models, digital-first customer experiences, and standard payment services have created a variety of FinTechs, a growth in cryptocurrency adoption, and disrupted traditional payment processes and institutions.
To thrive in this new payments landscape, financial institutions need to offer more capabilities with their technology ecosystem, use diverse integration patterns, and establish a governance model that spans multiple protocols and environments. This blog will explore how evented APIs can help financial institutions design modern payments systems to address the challenges surfacing in the industry.
The challenge with payments
In banking, the majority of data movement is done over some type of messaging transport, as most banking transactions are asynchronous.
Most banking transactions are asynchronous because they are often complex, involve multiple parties, and take some time to execute — payments is an example of this. Payments will often be submitted over a Synchronous mechanism like a RESTful call (web/mobile), however, the execution of that payment may require the choreography of multiple participants each one taking a varied amount of time to complete.
Even though current payments models work relatively well, there are some key challenges:
- The payment processing logic is bound to the messaging transport that enables the asynchronous paradigm. There are often diverse messaging transports, and there is no way to define business contracts agnostic to the transports, which makes the logic difficult if not impossible to reuse.
- There is no end-to-end visibility and governance for the payment process, leading to blind spots when errors do occur.
As described in a previous post, evented APIs can alleviate these problems by:
- Using the Async API standard, business logic and the knowledge of the transports can be separated. Business logic is coded against the Async API contract and not against the particularities of the various messaging transports.
- With MuleSoft, evented APIs are first-class citizens alongside RESTful ones, as such one can trace a payment process flow end-to-end.
The evented API approach
For the purpose of this exercise, we will explore a hypothetical funds transfer in a domestic inter-bank example — from an account with Wells Fargo to one with Bank of America. A user would submit a transfer from a mobile phone over a RESTful interface. The REST API would translate that payment transaction object into an internal domain-specific “canonical” model and then call to the Payment Initiation API. From there the Payment Initiation API would do some preprocessing and further publish downstream to the Payment Processing API.
The Payment Processing API will do the following things:
- Send an event to the Debit API. This is typically to the institution where the originator account lives.
- Send an event to the Credit API. This would typically be with another external bank.
- Send an event to the Settlement API to initiate clearing and settlement with the Central Bank
- Send an event to the Notification API to let the user know that the payment is in process.
Once the central bank has done its clearing and settling of the payment, it will send an event to both the debtor bank and creditor bank to update their respective accounts. Typically the event is simply an acknowledgement that the transfer is completed, and no changes are required. Updates to the accounts, such as reversals, occur only if there was an error with the transfer. The Reconciliation API will receive the event from the central bank and perform the appropriate updates if there are any. It will also send out a notification to the user that the transfer has been completed.
The sequence diagram below illustrates the general flow of events:
Some typically messaging transports that could be used in this example, could be:
● AMQP is used in a variety of ways, but it is primarily a queuing protocol that guarantees sequencing of events.
● MQTT is a lightweight pub/sub protocol typically used to interact between the enterprise and external devices, or any web app for that matter; as such it is often used for lightweight notifications or in IoT scenarios.
● Kafka is an enterprise-wide messaging transport designed to support both streaming and pub/sub.
● JMS/MQ is an older IBM specific messaging transport over which most of the financial networks still operate (i.e. SWIFT)
In this instance, an evented API could act as a bridge, for instance retrieving an event from Kafka and publishing it out on MQTT. The evented API paradigm could connect disparate messaging transports into a cohesive “event mesh.” The diagram below illustrates this:
The key API here is the Payment Processor API, which acts as a choreographer of multiple events. It also bridges all messaging protocols (AMQP, KAFKA, JMS, and MQTT)
The “leafs” of the evented API graph, Creditor API, Debtor API, and Notification API are subscribers to their events and undertake interaction with other downstream APIs to update databases/ledgers/notifications channels.
Examples of the Async API specifications identified above can be found in the following Github repository.
Summary
Evented APIs are transforming the way we perform business processes by adding a new layer of governance and visibility where once there was none. Many more banking processes will be transformed by this new paradigm. This transformation will eventually lead to a better overall customer experience through a higher degree of security and governance and a much faster time to recovery and operational consistency through a higher degree of visibility.
This transformation will eventually lead to a better overall customer experience through a higher degree of security and governance, a much faster mean time to recovery, and operational consistency through a higher degree of visibility.
To learn more about how to manage the full lifecycle of your APIs, download our eBook.
