API enabled transformation for treasurers

Sep 2021
 

Application Programming Interfaces (APIs)

APIs form an increasingly critical – and much talked about – glue for treasury systems. They help treasurers reduce manual interfacing and increase efficiency and control. Conceptually, APIs are a logical progression as systems become more integrated and holistic. 

Fifty years ago, data processing involved a lot of human effort such as operators working in pairs to input data twice, so that the mainframe could confirm that the two inputs were the same (thus reducing the risk of input errors). The progression can be visualized like this:

The first two are manual and subject to human error. Copy / paste can reduce errors, but is still subject to many risks, such as pasting into the wrong field or failing to select all the data when copying. 

Robotic Process Automation (RPA) can be seen as an intermediate step that is helpful when older systems do not expose APIs and / or the cost of implementing APIs is too high. At its simplest, RPA can be understood as software to automate human copy / paste processes. (Current generation RPA technology is more sophisticated and includes forms of artificial intelligence (AI) allowing for data validation and error handling.)

APIs provide the messaging and validation to allow two or more software applications to talk with each other. 

APIs are not new. In fact, they are foundational to computing. Without APIs, we would still be writing machine code for every task and specific to every hardware platform. Operating systems are APIs between hardware and application software. Microsoft Windows and other GUIs expose APIs that allow application software to generate windows, buttons, input fields, and so forth. APIs power the internet, enabling communication between browsers and servers, as well as between servers. APIs are behind what used to be called ‘mashups’ before this kind of integration became too commonplace to need a special name. (Early examples of mashups involved things like showing property for sale on Google maps.)
 

Kinds of APIs

There are many different kinds of APIs. As discussed above, operating systems expose APIs to enable application software to do useful work – this is local within a machine. APIs can also run between machines – for example the Windows APIs can be run across the internet to allow remote access to distant computers running Windows. With the advent of cloud computing, APIs allow work to be distributed across server farms around the world. 
The different dimensions of APIs can be simplified as:

1. Distance – local vs remote
2. Internal vs external
3. Bilateral vs multilateral
4. Data vs Service
5. Latency

Many large complex software systems use APIs internally. Twenty years ago, software was already being written in the three-tier model to separate the user interface (UI) or client from the business logic or server and from the data or database. Some large systems use APIs to connect internal modules. For example, SAP uses iDocs to communicate internally between its various modules. iDocs are XML data whose structure is based on the EDI standards ANSI ASC X12 and EDIFACT.
Although it is a helpful simplification to think about two pieces of software communicating with each other, the reality is increasingly multilateral or cloud like. Software is getting work done through multiple layers of networks – often collaborating independently from the initial requesting software. 

A third dimension is between data and services. A simple data API might provide a foreign exchange rate. A service API might provide a foreign exchange option price, taking spot rates, interest rates, and volatility from three different sources. Of course, services can also perform more complex work, reporting back with status messages and, where pertinent, data reports. 
APIs are normally near real time, in other words immediate. In practice, because of delays across the internet and limits on processing power, APIs provide status reports to the requesting process along the lines of:

• Acknowledgement (ACK/NACK) – “I received your request and I have understood what you want”
• In process – “I am working on your request”
• Completion – “I am finished” (Success or error, possibly with data)

As a specific example, AJAX  (which is used to make web pages interactive) uses the following “readyState” codes to inform the requesting process of the progress:

• 1: server connection established
• 2: request received 
• 3: processing request 
• 4: request finished, and response is ready

These are used in conjunction with “status” code 200 which means no errors. Thus the requesting process knows that when ready State == 4 and status == 200, the response is ready for processing. 

File transfer (such as SFT) is not considered to be an API, but to the extent that SFT is widely used to connect systems and operates in near real time, SFT can be considered analogous to APIs. SFT itself is an API for moving files between processes, and within the files there are normally specifically defined rules for data formatting and process control, as with APIs. 
Bank host-to-host connectivity is normally implemented with SFT and has API like functionality. For example, sending payment instructions, might look something like this:

• Client sends payment instructions in a file
• Bank acknowledges and confirms correct syntax with a return file
• (Later) Bank confirms execution with debit advice or statement with more files

The first two steps typically take less than 10 seconds. The third step depends on the bank’s internal processing speed. 
 

Typical API stack

This can be illustrated with some of the APIs in a typical treasury management system (TMS) ecosystem:

API & Cloud

There is strong circular relationship between API and cloud. The advent of cloud has greatly increased the exposure of APIs, especially between different software. Conversely, the cloud cannot not deliver its promise without APIs. Even the most limited uses of cloud, such as  hosting applications on the cloud, require UI and other low level APIs to function. The real promise of cloud is to deliver functionality by drawing on data and services from multiple different sources. Cloud service discovery promises to make such power transparent to users and eventually, to application creators as well. 

In many ways, this is analogous to the use of software libraries in traditional coding. Thirty years ago, software developers already had access to libraries that handled generic functionality, so they could focus on the business requirements of their own software. For example, TMS developers did not need to write their own charting software to display bar, line, and pie charts. They would link a charting library to their executable code and use function calls defined by the writers of the library to display charts for their users.

In a cloud environment, programmers do not need to link libraries to their code. They simply use the exposed services of a chart provider across the internet. With the advent of cloud service discovery and API standardization, charting providers will become interchangeable. 
Web services protocols are a subset of API used to enable this way of working. There are too many protocols for implementing such web services to cover them all. Some of the most commonly seen include:

• SOAP (Simple Object Access Protocol) which can use both HTTP and SMTP and handles data in XML
• AJAX (Asynchronous JavaScript and XML) which enables asynchronous exchange over HTTP and handles data in XML and JSON
• REST (Representational state transfer) which is more of a architecture than a protocol; most web service APIs are RESTful

A simple (and freely accessible) web service example is ECB’s foreign exchange rate service, which is easily accessible from any browser and generates a file of foreign exchange rates:
This will place an XML file with the SGDEUR spot rates for June 2021.Typically the requesting process would consume the data by parsing the XML directly in memory rather than as a file. 

Another example is Google who offer hundreds of APIs to access many of their services including Gmail and Sheets (but not search). In the banking context, DBS has the largest suite of APIs which are referenced at https://www.dbs.com/dbsdevelopers/discover/index.html. 
 

APIs for treasury

As explained above, all treasuries rely on APIs. There are some areas where APIs are generating particular interest from treasurers. These include:

• Real time banking
• Real time collections
• ERP connectivity
• Artificial Intelligence
• Business Intelligence
• Dynamic hedging

Examples from DBS’s suite of APIs include:

• Direct debits 
• Instant payments 
• FX enquiry 
   

Real time banking

Real time cash management is probably the most discussed API use case for treasury. The premise is that APIs will allow treasurers to see real time balance and flow data from their banks. This is very useful for some industries – especially B2C, where instant payments and real time confirmation of their receipt may provide a release from high merchant fees on cards described subsequently in more detail. 

For B2B, the use case is less compelling because B2B companies are less likely to work with near real time processes – most B2B is done on open account, which reduces the need for real time cash management. Current arrangements where banks provide, for example, hourly intra MT942 statements normally suffice for open account businesses. (Now that banks are promoting their APIs, they will have no excuse to claim they cannot send hourly MT942s.)

Another benefit touted for APIs is richer data than offered in MT940 statements. In fact, leading banks are already offering MX ISO20022 camt statements in XML that handle megabytes of detail. ISO20022 camt messages can handle any banking details and have been standardized country by country by SWIFT’s Common Global Implementation (CGI) groups, which include banks and corporates. Therefore, ISO20022 camt statements can handle any information, while being extensible. DBS is a leader in CGI and already offers CAMT052 and CAMT053 APIs. 

(Sensible banks are offering API data in ISO20022 XML because there is no value added in re-inventing wheels. Most bank APIs use SOAP which, as described above, encodes data in XML.)
A big driver for API banking has been the EU’s PSD2, which mandates that banks offer open APIs. This mandate is intended to enable third parties to build value added services for bank client. The Stripe banking-as-a-service API is an example of this. 

Unfortunately, the EU did not mandate standardization of banking APIs. SWIFT has been working on this, but progress is slow. As a result, corporates who wish to use banking APIs will probably have to build bilateral interfaces with each bank, thereby losing all the benefits of standardization across banks that have evolved with SWIFT MT and ISO20022 messaging. 

SWIFT GPI – launched in 2017 – fixes many problems in the old correspondent cross border payment process, primarily by introducing an SLA for speed, transparency, and fees. GPI also introduced tracking technology that uses ISO 20022 APIs to allow payments to be tracked across the world.
 

Real Time Collections

For businesses with B2C operations, with APIs, treasurers can avoid complex collection process, involving the manual handling of cash, cheques and cards. Additionally, APIs have solved the issues associated with cheque and card payments of long turnaround time affecting cashflow and high MDR rates for card payments, affecting margins. 

The use of a QR collection method enables customers to conveniently scan and pay using their mobile phones avoiding manual payments and bypassing expensive gateways. An Inward Credit Notification (ICN) API triggers a message instantly, in real time to the company’s ERP as soon as payment hits the bank account. DBS is one such bank at the forefront of providing such APIs to business ranging from healthcare and financial services to shipping.   
 

ERP APIs

As described above, ERP to bank and TMS interfacing has normally been through file transfer. Newer ERPs like Xero tend to use APIs more – DBS’s partnership with Xero  is a good example. 
Generally, ERP integration through APIs offers a broader user experience that goes beyond payments and statements. For example, Xero users can open accounts with DBS directly from within Xero.  
 

Artificial Intelligence (AI)

Some treasurers are taking advantage of AI web services offered by all the major cloud service providers to benefit from AI in their treasury operations. Google offers TensorFlow and its new service Vertex, as well as a slew of more specific AI services. AWS offers Amazon Forecast, which they describe as a “zero-setup service for using your existing time series data and turning it into accurate forecasts for the future”. Microsoft also offers AI services on its Azure platform. 
Chatbots (as services) can help make treasury data more accessible to non-treasury colleagues. In one example, treasury used chatbot web services connected to their banking data to enable sales people can use the chatbot to inquire whether their customer has paid yet. 
 

Business Intelligence (BI)

Treasurers are using APIs to deliver treasury data to management dashboards. APIs can provide more real time updates to dashboards as compared to file uploads (which tend to be daily or sometimes monthly) and are more secure than direct database access. 
 

Dynamic hedging 

APIs can also enable dynamic hedging to support international e-commerce. APIs can connect e-commerce with hedging services – either internal or external – to provide up to date foreign currency prices during the bid or price list risk period, and then hedge sales when confirmed. 
In some cases, treasurers use data from their e-commerce to dynamically hedge their price list or bid risk, and to fix offer prices for short periods of time to give their customers more certainty in the procurement process. 
 

DBS offers the largest suite of banking API solutions to help treasurers on their transformation journey. Click below to know more.