Long reads

How APIs can unlock huge value for banks and their treasury customers

Scott Hamilton

Scott Hamilton

Contributing Editor, Finextra Research

When corporate and banking institution systems communicate, it’s all about easier, faster, and more. Data is the product, and Application Programmer Interfaces (APIs) are becoming the ‘golden key’ to sharing it for accounts, transactions, and reporting on both.

At the NW Summit of the Association for Financial Professionals, experts from both worlds provided insights on the state of financial services API advancements. “How Can Banking API’s Unlock Value within Treasury and Across the Organisation” explained how simplified connectivity rules between financial institutions and their customers are expanding the volume and value of available data for corporate, middle market, and even small business finance, operations, and client service teams to manage their daily activities.

Ed Barrie, Chief Product Officer for Treasury4, a data analytics and solutions fintech, led the session. He was joined by Christina Easton of Easton Consulting Group and a former treasury pro at Microsoft, Cisco Systems, and Avalara, as well as Bank of America. Tim Smallow, a veteran of cash management leadership roles at Amazon, PayPal, and several financial providers rounded out the panel.

Barrie co-founded Treasury4 about three years ago after successful senior finance and assistant treasury roles at Salesforce, Tableau, Microsoft, and Spokane, Washington-based Itron – a provider of software and intelligent infrastructure services to utilities and communities. He explained the session’s key goals: to explain what is and is not currently available across a wide spectrum of financial institutions - and why and how exploring and taking advantage of APIs that work is worth every business treasury and finance team’s time and commitment.

APIs: Where old news becomes today’s hot topic

Misconceptions abound regarding APIs among financial institutions and their customers, said Barrie. They really aren’t novel or groundbreaking, at least in a technical sense, he explained, as frameworks and structures to report account balance and banking activities and transactions in common ‘languages’ have existed for decades. In fact, the precursors to today’s much heralded API “explosion” go back at least 55 years, maybe more.

“APIs are simply systems talking to another - that's not new. A lot of this technology originally was used in financial services in high volume, low data payload areas - specifically in credit card processing.” Now, Barrie explained, dramatically more connectivity is on the table, with more and more data types being supported through APIs across thousands of banks and financial technology partners across the world.

With more vendor solutions being developed in the ERP (enterprise resource planning) and TMS (treasury management system) arenas, banks aren’t the only ones interested in improving FI-to-customer data communications. However, the speed, simplicity, and effectiveness – and value - of reporting integrations has been substantially improved across all sectors in recent years.

Noting that larger banks and industry leaders like SWIFT have been creating increasingly powerful reporting tools and methods since the 1970s, the industry has evolved to the point where, Barrie says, “a lot of institutions will say that they're really software companies inside a financial institution,” given how much financial importance, IT budget, and dedicated staffing they’ve assigned to account balance and activity reporting tools for their customers.

Data usage and sharing regulations, primarily around consumer financial applications in Europe, started some of today’s dominant trends leading to industry standards now spreading more widely throughout the corporate finance world. ISO20022 may seem like a new thing, but early forms of this emerging (and simplified) reporting structure and syntax existed more than a decade ago, said Barrie.

Older iterations of financial reporting won’t go away either but will continue to be used if they work well. “Host to Host, like BAI2 (communication protocols/financial reporting standards) and SWIFT, are not dying yet. This is a hybrid world […] We're gonna have hybrid connectivity solutions” for a while yet, he asserted.

Data rules bring responsibilities and risks, along with varying ‘standards’, for treasurers

Given that rights to data are such a hot topic these days, it’s no surprise that the NW AFP panel discussion focused a lot on assessing and managing the risk of handling it safely.

APIs, by making it easier for parties on all sides of financial transactions to use and transfer account and transaction information, help extend this data’s value for many different and emerging applications. But with that comes the risk of it being compromised, and the responsibility to meet all the globally-variable regulations attached to sharing it internally and with partners.

One of the fallacies of APIs is that they are in fact “standard.” As proof, Barrie shared a very complex, yet current chart with the audience showing scores of financial services providers with all sorts of reporting formats and capabilities mixed among them.

Yet the number of discrete applications and general ease of connecting banks with consumers, treasury/finance departments of businesses, investment teams, and other client types are expanding steadily. Specifications that used to be closely guarded are now openly shared by financial institutions with their customers and partners, even if it’s still not at all certain that what and how reporting works between one bank and its clients will be the same for every other bank-customer relationship connection. Regardless, the setup and implementation timeframes have definitely been shrinking, Barrie said, noting that now it is becoming common to “get these things stood up in weeks and days - and not months and quarters,” as was often the case in the past with complex, bank-to-customer data integration projects.

Easton explained how in the merchant processing arena, for example, “the level of data and the categorisation of data is going to be different”, in the evolving marketplace compared to the past. She noted that in the card space right now, “you might get some rich data, but it may not be coming to you as efficiently as an API with a bank from a cash management perspective.”

Even within the same bank, she asserted, “you might see differences in the payload, but also in the breadth and ability to advocate for additional features or datasets.”

It’s particularly important for treasury and finance teams to advocate internally and to their financial providers for their specific reporting and connectivity needs, which means they must be “aware of the differences and knowing exactly what you want, and why you want it, to fully take advantage.” That, Easton said, will require finding the right people within the organisation and at the bank and telling them, “We really need XYZ - and we're not getting it.”

Departmental use cases are creating value for APIs across the organisation

Smallow, a veteran manager of many bank-corporate global data and payment integration projects, agreed with Easton that there are distinct API and reporting use cases and capabilities, that must be considered when comparing ecommerce, card applications, treasury, or other departmental needs. Wherever the data is being used, value can be measured, sometimes by significant strides made from cost, reconciliation, and client experience standpoints.

“There's definitely the desire to be as efficient and expedient with the payload of the information that we need, but making sure that we get all of it that we need intact, consistently […] the other thing is the data must be machine readable, that we can feed it into our systems to automate all those processes. That's exactly what we want.”

However, Smallow said, there are other parts of the treasury manager’s world where this will not or can’t yet apply. “There are still very archaic processes, either paper-based or email-based, to probably think about [like] how could we store that information and exchange it not only with the bank, but how would we ingest and use it in our systems - and act upon on it - in a timely manner?”

Efficiency, accessibility, and eliminating stubborn bottlenecks are API expansion goals

APIs and the information they make more easily accessible can help make many corporate treasury, finance, and accounting teams and procedures more efficient, and much more valuable to a given company’s overall operations.

Still, challenges abound, some posed by industry innovations and emerging practices like instant payments and 24/7 operations - especially in the case of companies operating internationally. These new wrinkles and their requirements can complicate the API evaluation and adoption process for a bank and its customers.

Not to mention actual operating models and their heightened expectations, said Barrie. “Being able to transact real time is an ultimate wish, but then how you actually respond to that with the human capacity required)is the other challenge, right? You're gonna have people staffed 24/7 to respond to all this - and you're going to be responsible for everything that happens 24/7.”

In-house banking, bank signatory/account management, KYC (know your customer), audit responses, and fraud management applications are just some of the other areas within treasury where API’s - and especially more standardised regulations and practices among all financial institutions - could really help companies operate more efficiently, the trio of panellists agreed.

“Getting all of that information would enable us to be able to react very quickly and easily to any question that we might have from the tax department, regulators, etc.” said Smallow, referring to one consistent need among corporate treasury teams.

Describing the ‘clunky’ process of getting info from a banking partner to business treasury and finance groups, Smallow shared one of the greatest impacts and value enhancement opportunities he and other practitioners hope for from APIs going forward:

“Today, if you do have to go out to the bank to request that (bank account/signatory and related) information, (the process is often) ‘What do you have on your system? Please send it back to us.’ Truly having the access to that in real time - and being able to (quickly and easily) pull that down - will be extremely beneficial."

Comments: (0)