APIs vs Message Queuing

Technically, there are various ways to connect the different actors in the Nexus ecosystem. The primary choice is between a synchronous protocol (such as webservices and (REST)APIs) and an asynchronous protocol (such as message queuing). Both solutions work well in the Nexus design, although there are several aspects to take into consideration, such as performance, resilience and security, as well as ease of implementation.
The main use case of Nexus is the instant exchange of funds, in a cross-border setting. Most likely, this payment is initiated through a ‘rich’ graphical user interface (eg a mobile app or internet banking). This results in the main requirement for the interaction to be low latency, to avoid keeping the Sender waiting. However, Typically, we plan for the use of a synchronous protocol for the ‘setup’ phase of the payment, as the interaction between the user, its interface (eg mobile app) and Nexus, favours speed over certainty. The client-server setup works well during this phase, as the client (the mobile app) is able to handle failure scenarios. For example:
  • If the server fails, the client must take responsibility to handle the error
  • When the server is working again, the client is responsible for resending the request
  • If the server gives a response to the call and the client fails, the operation is lost
  • If the server overloads, the request is lost and the client is able to handle this (for example by resending the request)
However, IPS systems (as well as ACHs, central banks and the SWIFT network) tend to use an asynchronous protocol. Nexus will be able to support this as well. The responsibilities shift somewhat as a result of the different protocol:
  • If the server fails, the message persists in the message queue
  • When the server is working again, the server is able to retrieve the pending message
  • If the server responds to the call and the client fails, or fails to acknowledge, the message persists in the queue
  • The server is able to pick up message from the queue according to its capacity; messages are able to be buffered in the queue
Thus, with an asynchronous protocol, certainty of delivery and processing is achieved at the potential cost of latency. This works well in a payment processing environment, which is why IPSs tend to favour message queuing. However, when the user is interacting using a rich interface, the delay may lead to an unwanted user experience. Nexus thus supports both models and is able to tailor the use of the protocol to specific requirements.
Please also note that for the interaction towards the Destination Bank, Nexus acts as the client. If this interaction is to be done via a synchronous protocol, the destination bank is expected to expose APIs to Nexus, which may complicate implementation. Implementing an asynchronous protocol may be easier for the Destination Bank.