With this installment, we come to the end of our tour of major payments systems with a description of enterprise payments, which brings them all together. You can read the earlier installments here.
I hope it has been clear throughout these essays that all payment systems share a common structure, which I call the Five Actor Model, shown below. This makes it possible for a single software engine to process any kind of payment you can think of.
I first started writing about the concept of enterprise payments back in 2004, and it has since become a standard part of the payment industry in the form of payment hubs. As shown in Figure 2, a payment hub can be inserted between the front office, middle office, and back office of a bank.
The front office is the customer service channel, and now goes far beyond the branch into automated telephone interfaces, chat interfaces, online banking sites, mobile banking sites, and various ATMs and kiosks. Banks now need to support downloading statements and transactions into personal financial management software and mobile apps.
The middle office comprises the systems used by customer service personnel, including various customer management systems, sales and marketing systems, management information systems, branch administration systems, and payment initiation and management systems. These systems draw on back-office systems for reference data.
The back office is where all the actual processing goes on. While some banks have upgraded to unified “core banking” software that integrates all the deposit-taking, lending, and payment processing functions in a single application, many still rely on function-specific applications built decades ago. For example, most banks still separate card processing from other payment processing, so there is a separate system just for cards. Wire transfers also are separate in many banks, with a dedicated “wire room” that has special high security software and procedures.
If a bank has grown through acquisition, it will have all the systems of the banks it acquired. Conversions are extremely complicated, expensive, risky, and time-consuming, so many banks have put off doing them.
Payment hubs offer a way to allow older payment systems to function within a modern software architecture by providing rules for translating various messaging formats into a generic format. This way, the payment hub can emulate various hardware and software architectures, providing each system with the environment it needs to run. You see this approach in personal computers, where older software can run on modern hardware via the use of emulation.
Payment hubs also help by allowing banks to gradually absorbing functions into the hub, rather than trying to do it all at once. In this way, a bank can gradually build out its enterprise payments system, following the needs of the business, and eventually get to the point where it begins retiring old systems. Everything that was dependent on those systems wouldn’t notice any change because they were interacting with the hub. As additional features are introduced, they can be built into the hub, so there is only one set of interface changes.
ISO 20022 and Enterprise Payments Messaging
All these payment hubs had their own internal messaging standards at first, but global banking service provider SWIFT led an international effort to develop a common messaging standard for all payment types, called ISO 20022. All new payment systems have ISO 20022 built in, and older ones have been retrofitted to use it. Standards are difficult to displace, however, and ISO 20022 has suffered from the same one-size-fits-all problem that has bedeviled other “enterprise” projects. ISO 20022 is different from earlier standards, however, in that it makes use of an open standard called XML (eXtensible Markup Language), which allows customization in a machine-readable way. Therefore, it is possible to create industry-specific “dialects” of ISO 20022 while maintaining compatibility with the standard. Regrettably, I haven’t seen too much of this in action, but as newer payment systems built from the ground up to use ISO 20022 take over transaction volumes from older ones, its reach will expand.
Another parallel technology is open APIs (Application Programming Interfaces), which make integration between different software products easier by defining a series of function calls along with the data required to invoke them. Open APIs allow third parties to build their own interfaces, rather than waiting for the Open API owner to get around to them. For example, if you want to get a current balance from a deposit system with an open API, you simply send a message to the API and receive a message with the information in response. Payment hubs help with this by integrating directly with systems that don’t have open APIs and exposing their own common set of APIs. This makes is possible for banks to rapidly integrate with fintechs by doing most of the work in advance.
Today’s payments environment is much faster and more competitive due to enterprise payments hubs, and they can be found everywhere. As banks look toward incorporating novel forms of payments such as cryptocurrencies, they are much more concerned with regulations and risk than they are with the technical issues. When I started studying enterprise payments, it was common for technology integrations to take years and cost millions of dollars; by the time I was at Mercator Advisory Group, software developers were boasting about successful implementations that took three months. Agile development methodologies and prototyping have played an important part, but the essential insight that all payments have a common structure has enabled new payment products and new channels such as web and mobile. We can expect that technology over the next decades will continue to accelerate.