Is the Right Technology Chosen to Support Real-Time Retail Payments?

Legacy electronic payments systems, including ATM, card, ACH and RTGS, use a variety of technical approaches and standards. These are not appropriate—or sufficient—to support high volume, real-time retail payments.  As a result, new technologies and protocols are being used in RTRP systems worldwide

The Level One Project believes that new payments systems should be architected to include the capabilities listed below. These capabilities are in addition to the core L1P Design Principles (for example, real-time clearing, push payment, and near real-time settlement). Together, these capabilities drive and enable low cost payments.

  1. “API native” protocols to enable DFSPs and other financial services providers to easily connect to and transact with the system. This is an alternative to message-based protocols. Access can be enabled for both bank and non-bank DFSPs, depending on the regulatory environment in a given country or region.
  2. Robust asynchronous interaction patterns to make communication resilient in situations where DFSPs network connectivity is unreliable.
  3. Guarantees DFSPs identity in exchanges by using digital signatures on all financial communications between parties.
  4. The use of a validation exchange prior to the transmittal of a payment order: the validation gives the receiving DFSP the opportunity to say “yes, this account is valid, and is ready to receive the amount of funds proposed”.
  5. The ability to exchange other data between the sending and receiving DFSP prior to transmittal of the payment order: this may include fee information and/or counterparty name or other identity information.
  6. The ability for a receiving institution to accept or reject a transmitted payment order.
  7. A flexible addressing protocol, which allows a scheme to adopt multiple types of payee identifiers, including mobile phone numbers, bank account numbers, merchant ID’s, QR codes, and aliases. This supports the requirements of different use cases, while preserving the integrity of the relationship between a given identifier and the transaction account which is receiving funds.
  8. The ability of the end-user to move their identifier between DFSP, similar to mobile phone number portability.
  9. The use of “request to pay” communications to allow a recipient of funds to request payment without needing to effect a “pull” payment order.
  10. The use of low-risk, automated settlement mechanisms.
  11. The ability to support the automation of costly manual processes, particularly with respect to exception management and dispute resolution.
  12. The ability to interconnect with other RTRP schemes and hubs; the ability to exchange transactions cross-currency if the scheme supports this.

Next Topic in this Section: What Regulatory Support is Critical for a Thriving Digital Ecosystem?