We published an article on platform design in treasury contexts some years ago in one of our monthly treasury newsletters. It examined how the benefits of hybrid and heterogeneous "best-of-breed" system architectures stood up to comparison with traditional monolithic system landscapes, highlighting the implications for the choice of systems and providers and tracing the individual steps towards implementation. Back then we concluded that, given a clear vision for the treasury platform, even heterogeneous system landscapes with internal and external interfaces can be implemented as stable and efficient solutions.
Be that as it may, the fact is that the vast majority of treasurers today work with digital ecosystems whose core is still essentially a monolithic treasury management system that is hooked up to this or that satellite tool – a trading platform, say, or an electronic banking system – be it in the cloud or not. In this kind of environment, connectivity and integration are more or less synonyms for interfaces, some of which are fraught with glaring security loopholes and inefficiencies. Since the vision of a modular treasury system we portrayed back then has made only modest progress towards reality in the meantime, you might be thinking that an admission of guilt is in order? Well, sorry, but no. Because this is where things really start happening…
It is no wonder that CIOs and corporate IT architects have so far advocated keeping the number of systems and tools as small as possible and thereby keeping a tight rein on diversity. Maximum integration via a minimum number of interfaces has been the watchword, born of the belief that linking up two IT systems and then guaranteeing that everything will work smoothly and without errors in practice is always going to be a tricky balancing act. That's certainly true if you are using outdated methods. Or if you have to use such methods, because your systems won't support anything else. Think for a moment about the tools your treasury system uses: Think of all the points at which information is exported, stored in files, reallocated and then imported again somewhere else. Even if these processes are automated and secure to a reasonable extent, they are still performed using interface technology from the past millennium.
So why should everything suddenly get better if we all switch to what are known as APIs? Why do more than a few experts refer to their increasing use as a "game changer" in treasury departments, as an "enabler of transformation"? And that with a concept that, in principle, has been around for several decades?
From a purely technical perspective, APIs, or application programming interfaces, are nothing more than a collection of routines and standards which applications or individual modules use to communicate and share information with each other. As is so often the case, standardisation is the key to their success. At the end of the day, the way in which systems and modules interact, exactly how they access functions, data, interfaces and other elements, is of no interest to the common-or-garden user. Nor should it have to be, because everything works automatically in the background and there is no need for all the hassle of engineering interfaces. The benefits are obvious: APIs allow individual systems, system landscapes and, ultimately, entire platforms to be modularised into individual components. Remember that vision of the modular system from which users can pick and choose the best tools and services?
One possible use for APIs – one that could yield the greatest potential benefits for treasurers – was actually created by the regulator in the form of the Payment Service Directive, or PSD2. Obliging banks to make APIs available for account information and payment transactions has opened up completely new ways to integrate real-time information in treasury processes. Not only that, it has also spawned a new market of providers who are selling value-added services on this basis. Traditional house banks, TMS providers and fintechs are all getting a piece of the action. The important thing, though, is the fact that you can integrate all their services on offer in your processes and systems. And you can do that thanks to APIs!
Essentially, PSD2 is just one of many examples of how APIs can be used in treasuries. Only when market-ready solutions based on cloud technologies become available as software as a service does it make lasting sense to use APIs in treasury contexts. Why? Because only then can a series of fundamental difficulties – such as the myriad manual steps involved in converging data and different systems, and the long implementation cycles hitherto inherent in the introduction of IT tools – be properly addressed. Speed, simplicity and cost-efficiency: That is what tapping the potential of APIs is all about. There are no shortage of sensible applications: They start with basic automation steps in the treasury system and move up through more complex risk management issues, financing questions and the various links in the payment transaction process chain, to name but a few examples.
When talking about APIs and the cloud, one intuitively thinks of the growing number of fintechs and the innovative tools and services they offer. For treasurers, however, the API wave will also revolutionise the provider market from the ground up. Banks, (market) data providers and TMS producers will all be affected. Astonishingly, banks themselves are assuming a pioneering role, deploying APIs in the context of "open banking". The Global Payments Innovation (GPI) program and the associated payment tracking service, for example, were initiated by SWIFT on the basis of API technology supplied by the banks. Nor will providers of treasury management systems be able to hide from this development. There is nothing to be afraid of, though: The treasury platform of tomorrow will not be a dizzying mosaic of individual cloud solutions that control their processes automatically via esoteric communication channels. At its core, every treasury department will still need a TMS as the pivotal element in bundling the risks it needs to control. That said, there is no stopping the trend towards the modularisation and openness of these systems. Providing open APIs, in other words, is becoming the industry standard. So there is no point wasting your time with vendors who still try to sell you obsolete interface technologies such as file transfer and the like – vendors who have no API strategy worthy of the name.
By now, it should be clear that the treasury platform of tomorrow will be API-based. Centred around an open core (the TMS), it will be able to seamlessly integrate add-on services using the software as a service model. Incidentally, the same goes for the pricing model. Why pay for something of which you only use a part? In closing, our advice to treasurers can therefore only be: Play a part in shaping your own universe of systems and services. Pursue your own active API strategy. The first step is to assess at what points which services and which technologies can genuinely add value. One thing we will promise you: You won't believe the possibilities you discover!
Source: KPMG Corporate Treasury News, Edition 83, August 2018
Author: Michael Baum, Senior Manager, Finance Advisory, firstname.lastname@example.org
© 2020 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative (“KPMG International”), einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.