API Days: From Talk to Action

Since the first APIs started appearing in the bank-to-treasury space a few years ago, driven in part by the open banking revolution, there has been much talk of their transformational power. We consider the reality behind the claim, exploring the possibilities and the limitations.

The promise of system flexibility, agility, and scalability is a potent lure into the world of APIs. And with business models striving to offer a more online and immediate experience, and data- sharing now an essential part of this new economy, APIs do seem to be much in demand. Indeed, banks are willingly offering access to their new libraries – albeit with a regulatory push to get them going. But on the treasury front line, are they delivering?

APIs serve to facilitate communication between two systems, enabling the integration of third-party software and technology into new applications. “In layman’s terms, think of it as a communication channel that allows two computers to speak to one another. They are akin to the old-fashioned telephone operator who used to connect callers to the relevant parties,” explains Ken Bugayong, Financial Technology Instructor, University of Washington, and Senior Treasury Manager, Bloom Energy. In fact, the API request for communication is referred to as a ‘call.’

APIs in the treasury space may have a number of sources, typically coming from providers such as banks, TMS vendors and market data firms. In each case, the communication channels opened by APIs facilitate the sharing of information, much as a link provided by a search engine connects a user to a website to enable access to its underlying information.

The market data firm can use APIs to provide treasurers with real-time trading volumes and pricing. The TMS vendor could deploy APIs to aggregate multi-bank balances and other transactional metrics. An individual bank might use APIs to deliver client balance and transaction data, payment instructions or user authentications. “The idea is that the client can leverage that data and take advantage of real-time accessibility,” explains Meg Garand, Managing Director, Bank of America (BofA).

Without APIs, the sharing of bank data, for example, is typically carried out through web portal data extracts or host-to-host connections through standard file formats. “Unfortunately, individual data extracts can be tedious and time consuming in practice while host-to-host transmission can sometimes be unsuccessful or data can be corrupted, and such issues must be resolved manually with the data provider, for which treasurers today simply do not have the time,” comments Bugayong. From a banking perspective, Garand notes that with clients increasinglyexpecting their banks to provide consistent data across all channels, APIs offer “a connected experience, opening up the whole breadth of a platform”.

It’s true that APIs can bring a new seamless, faster, and more efficient way of sharing data, admits Bugayong. “This means that once the API communication channel is set up, it eliminates the need to execute recurring manual processes – and most updates can be tackled with a simple refresh, which can even be set up to perform automatically in the background, at a predefined schedule. Certain instructions could also be automated and passed on via API, based on predefined triggers, eliminating the need for intermediate manual steps.”

Barriers to adoption

APIs are still a nascent technology in the treasury space and this may foster reservations about their adoption: they are far from ubiquitous. If corporates have existing connectivity that is working well with their banking partners, then there may not be sufficient near-term benefits in changing out the plumbing and migrating to APIs, comments Ed Barrie, former Senior Director, Treasury, Salesforce, and now Co-Founder and Chief Product Officer at cloud-based data analytics vendor Treasury4.

Another concern Barrie notes is that connectivity and integration with banking partners, even via APIs, is often viewed as an IT project requiring deep technical resources. These are frequently limited in most organisations. “Support of APIs is growing but not yet consistently available across the banking community,” he comments. “In order to connect with all of their banking partners, and to be able to exchange all of the data, files, and messages that their organisation and business processes need, it may require the treasurer to opt for a hybrid solution of APIs, host-to-host and/or SWIFT.”

Bugayong, in his role as a financial technology instructor, often finds himself addressing concerns about API security. As a treasurer, he understands the need to protect the business. But he knows too that conversations around API adoption often quickly move beyond the finance function into the realms of IT. For this reason, he suggests that individual treasurers should strive to develop a better understanding of API automation and cyber-security issues to have more productive conversations with IT colleagues on the API topic.

At the very least, treasurers should be aware of the possibility of increased cybercrime arising from API adoption, warns Bugayong. Indeed, opening up new digital channels requires certain precautions and for APIs, consideration must, for example, be given to the safe storage of the digital keys used to trigger data transmission, and to the security of the channel itself. A capable – and sympathetic – IT function with cyber- security expertise can easily resolve such issues, he says.

But even treasurers who understand the risks and rewards presented by APIs may still need to tap engineering expertise to translate the accompanying “elaborate documentation” into a successful deployment. Release documentation details elements such as connectivity endpoints, the different calls available, the pass parameters for set-up, and identity management processes. Typically the level of expertise required to use this detail is not found in the treasury department.

This may present another barrier to API adoption, notes Bugayong. “Where the treasurer builds on their understanding of APIs and can knowledgeably converse with IT about their adoption, then help with initial set-up and ongoing maintenance may be more forthcoming.” What’s more, he continues, “the combination of specialist treasury knowledge and a willing IT partner will assist in the communication of the efficiencies of using APIs to other affected stakeholders and decision- makers, improving transparency on the business case for implementation”.

Garand acknowledges that overcoming barriers requires effort. “Before adoption, there must first be an appreciation of the benefits of APIs, to create a common understanding of the business problem we are looking to solve, so that a robust business case can be formed,” she says. Treasurers expecting integration into their applications and ecosystems must first understand what’s available from their core system (especially ERP and TMS) providers. “It’s then vital to explore current treasury processes in order to define expectations of API connectivity. This should raise questions about how additional API-delivered data will be consumed and leveraged, and what the organisational appetite is for moving to real-time processing.”

Meeting needs

In theory, APIs should function in any application environment. However, connecting legacy applications that are built on batch processing and physical file data integration architectures may be challenging, warns Barrie. “It’s fantastic that some bank APIs can provide near real- time balance and transaction reporting, but if the end-application can import a physical bank statement file only once per hour, then the treasury is not able to realise the full benefits of API capabilities.”

Garand raises a similar point. “As a bank, understanding what the client’s applications are able to do is key, so whether it’s an ERP, TMS or home-grown system, we need to know if it has the API connectivity to offer the services and be able to consume the data that the client wants, and more importantly, whether or not it is able to comply with the necessary security requirements.”

While it’s apparent that many core system providers do meet API connectivity requirements, she says it’s still incumbent upon banks to consider the wide scope of businesses represented by their clients, from SME business banking customers through to commercial banking and multinational clients. “Within that spectrum, we need to think in a detailed way about all the different internal applications that they use, or providers that they count on to deliver data, because all are at different stages in their API connectivity abilities, and they may require different API-based solutions.”

The standardisation issue

The wide spread of use cases and providers has led to a lack of API standardisation. APIs are beginning to hit the mainstream of treasury consciousness, but the fact that many financial institutions are currently using disparate formats for information dissemination in their APIs remains an issue.

The larger banks have the resources to throw at API development, and smaller institutions have been partnering with third parties to develop their own solutions. But because API adoption in corporate finance and treasury is at an early stage, a standardised industry approach may take some time in coming, notes Bugayong. “In the interim, this can be more challenging for internal developers not only to integrate the APIs but also to maintain them and provide continuous support,” he notes. “If a corporate has 10 banks, each with its own set of structures, fields, and naming conventions, those developers must understand these nuances prior to consolidating the information internally.”
Customising each and every API connection for a global multi-banking corporate treasury is an unwelcome prospect. API development is advancing beyond the banking space but the challenge of standardisation remains, for now.

With the major providers all wanting to be the pioneer in this space, this is unhelpful. But as the banking and treasury world opens up to API possibilities, and the provider space is filling up, so signs of the will to co-operate and standardise are emerging. For example, the US-based National Automated Clearing House Association (NACHA) has created an API Standardization Industry Group initiative, which has published an inclusive API Playbook. The Afinis membership- based standards organisation, also in the US, is focusing on APIs in corporate banking services.

Further afield, the industry is making efforts in driving standardisation in how banks and vendors develop and deploy APIs. Barrie cites Financial Data Exchange, SWIFT and the ISO 20022 organisation (under ISO TC68 Financial Services) as all progressing on standardised use and data definitions in APIs.

“API standardisation should revolve around leveraging the business data definitions from ISO 20022 XML in order to drive uptake and reduce the level of effort to integrate into an end-application,” he believes. “The industry has invested substantial time and resources into the ISO 20022 XML standards over 15-plus years, and many applications and banks support the related XML message sets. The industry should be leveraging these same business definitions in how the data is presented via APIs.”

At a technical level, APIs are a transport mechanism with the predominant data payload being the JSON (JavaScript Object Notation) format. Some banks can provide BAI2, CAMT, CSV and even MT940/942 formats via their APIs, notes Barrie. “Creating new or altered business data definitions within APIs will slow adoption since it will take longer to understand the nature of the data and in turn normalise and map it into an end-application.”

Build or buy?

As discussed, integrating and maintaining bank or other provider APIs requires a unique engineering skill set, not to mention the wherewithal to observe best cyber-security practices. Treasury teams can certainly design APIs to make data available to other teams in their organisation. However, because APIs are not yet standardised globally, it can be a costly, resource-intensive, and cumbersome process for any treasurer looking to take on the task of developing their own APIs.

Bugayong notes that with a number of third-party solution providers (notably in the TMS and ERP community) having already integrated their platforms with published bank APIs, they are now offering their services as ‘one-stop shop’ real-time data solutions. “Treasurers without the in- house resources to handle integrating and maintaining APIs should seriously consider this approach first because their vendors have done the work of integrating with each of the banks, standardising internally, and warehousing the consolidated data,” he explains.

There is little doubt that treasury is becoming an increasingly technology- fuelled role. Where it is reaching into the data analytics, data science and data integration space, Barrie suggests that best- in-class treasuries are evolving into centres of excellence for analytics. This, he notes, will drive the need for timely and efficient access to data, with APIs becoming the de facto delivery channel.

While it seems to make sense for treasurers to partner where possible to leverage the expertise and experience of others, if a suitable partner is not available, and the will to push the learning curve is strong, self-build is not an unrealistic proposition. Indeed, Garand notes that banks such as BofA are already supporting the integration of corporate-client-developed APIs, and they continue to partner with more providers.

Creative uses

APIs have the potential to be a game- changer, believes Garand, especially in terms of real-time accessibility of more data and services. The ability to leverage data and services faster is compelling. “If a client wants to send a real-time payment to another country, an API will be much quicker than updating content in a file to originate that payment. That payment can also be pre-validated via API connection to a standardised national database of accounts. Then, in transit, APIs are capable of delivering real-time tracking data directly to the payer or payee’s ecosystem.”

These are valuable use cases. However, one misperception in the marketplace is that APIs will offer vastly enriched data for use by corporates that will unlock all sorts of new insights. “This is not yet the reality,” explains Barrie. “We have seen the case of several global banks’ API-based transaction data being significantly less than what the banks provide in their CAMT.xml [ISO 20022 XML] statements,” he warns.

Indeed, he notes that “some global banks” have their country branches transmit balance and transaction data into a centralised reporting warehouse, often in legacy MT940/942 or proprietary formats, which is then exposed via API for customer consumption. He feels that there is “little to no difference in the quality and quantity of data” in these cases versus legacy formats and is certain that this is not an API limitation but “rather a constraint informed by legacy processes, systems and truncated data formats that are still in existence”. In other words, it’s not the ‘fault’ of APIs but the environment in which they are deployed.

Nonetheless, matters are beginning to evolve, and Barrie is seeing greater API development effort focusing on “ideal API territory” such as core process enhancement. Account balance and transaction reporting, payments initiation and payments status reporting, for example, create high data-volume flows. API adoption here means latency between transaction booking by the bank and reporting to the customer is at last being reduced.

What’s more, some Tier 1 banks are beginning to push further out on use cases, with APIs being deployed for reporting on account signatories including signing limits, account interest conditions and account entitlements. “Historically, these data flows have always been manually collected, generally via email. It would be great to see banks support AR [i.e. Lockbox] details including images via APIs,” Barrie says, adding that investment holdings and transactions are also candidates for API support. “In the years ahead, APIs will change the bank-corporate relationship to be connected, continuous and collaborative.”

As APIs become more standardised and mainstream, it is likely that they will underpin increasingly creative use cases, says Bugayong. Today, APIs can streamline many processes such as acquiring account history, issuing payment instructions, executing certain trades and investments, performing transaction status inquiries, making credit decisions, and retrieving bank contact information. “In the future, with the advent of IoT [internet of things] and AI, it is certainly within the realm of possibility to retrieve bank information and issue instructions via voice assistants, for example,” he suggests. “It will also be possible to establish a fully autonomous treasury that uses algorithms to execute treasury transactions based on predefined triggers.”

This may sound like science fiction, or even an end-of-days scenario for some treasurers, but it’s not, insists Bugayong. Process automation using APIs can be achieved in many areas including investment rebalancing, global pooling, and sweeping of cash. In the execution of hedges, for example, APIs could be aligned with AI to automate end-to-end hedging activities.

Here, a smart treasury could automatically gather and calculate its hedgeable exposures from its TMS or ERP data and explore the market for forward points on specific currencies. The system could then seek offers from accredited counterparties and, where pre-set treasury, risk, and compliance policy parameters are met, use APIs to execute, confirm and settle appropriate trades. Once the hedge period ends, acceptance or delivery to the counterparty can also be automated via API.

But in the same way that few would be comfortable travelling in a pilotless plane, so full automation of a key business function such as treasury is unlikely, for now. Indeed, says Bugayong, the intersection of APIs, RPA and AI/ML does not signal the end of treasury because there will always be a need for human expertise to set policy, oversee activity, calibrate business parameters, and generally provide confidence in financial processes.

Important questions

Of course, banks such as BofA have invested heavily in resources to educate and encourage appropriate API adoption and best practices. Nonetheless, treasurers who understand the opportunities that APIs could bring to the function first need to consider how that data can be best harnessed, says Garand.

It’s a fundamental discussion, so to help decide how to move forward with APIs, consider the following:

The use of APIs will continue to grow. As Barrie states: “It’s not a fad or short-term ‘proof-of-concept.’ This is where financial messaging and business processes are moving to.” While the conversation for many may still be at an early stage, talk is rapidly evolving into action. Banks are keen to leverage their investment and will willingly facilitate discussions, says Garand. For treasurers awakening to the practical value of APIs, it is now time to make that call.