Banking & Web Services: The File is Dead, Long Live the API

Today most, if not all, financial transactions flowing between Banks, Financial Institutions, Corporates, Government agencies, Insurance companies and Securities counterparties are based on files. In…

Jerome Tillier profile picture
Jerome Tillier

July 30, 20126 minute read

Descriptive text explaining the contents of the image.

Today most, if not all, financial transactions flowing between Banks, Financial Institutions, Corporates, Government agencies, Insurance companies and Securities counterparties are based on files. In the UK, a typical payroll department submits a BACS batch on specific days for salaries or expenses. In France, pensions and benefits are released via large files from French government agencies to their Banks. A typical Consumer Packaged Goods company issues a vast quantity of payment files on a weekly basis to their suppliers. File-based financial transactions are the actual life blood that pumps through the global economy.

Today most financial flows are optimised around bulk transactions, cut-off times, and traceability from a file level, to batch, then single level instructions. Treasury departments and Banks have their business processes and systems arranged around files. You could argue that a SWIFT MT101s is a single instruction, but it is still contained within a file, exchanged over a network, for a file repository’s consumption at the receiver end.

Services-Oriented architecture (SOA), also called Web Services, is a technology that enables businesses to exchange electronic transactions between major IT and business systems, without the need for file-based exchange of data. Software applications communicate to each other directly, passing data between each other without the need for a middleware or integration layer. These applications are designed to fit each other like Lego blocks, with an interoperable set of interfaces called APIs, which are usually documented to make it easy to fit the “interlocking Lego block”. Web Services are sometimes confused with “web user interface”, which is not the same thing at all.

Two significant areas of Payments and Cash Management (PCM) are currently driving the adoption of SOA: mobile-based Financial services (which I mentioned in my recent blog) and Corporate-to-Bank ERP integration. Other areas such as Trade and Securities also transform the way data is exchanged, but let’s focus on PCM first in this blog. SOA (or web services) can be considered as another host-to-host communication protocol, enabling clients or counterparts to exchange data with the bank.

Web services for mobile-based FS: One way to roll out a mobile-based service, for instance mobile banking, mobile payments or mobile e-Invoicing, is to build the front-end application this would be typically be an app in the Apple Store or Android Market) and the bank-side “mobile application server” separately. The front-end application can then communicate with the Bank’s systems using web services: sending and receiving data through the API, over the internet and the mobile network. A Bank can decide to “lock down” access to their API to their own developed applications. Access can also be provided to clients or third parties, either on a subscription basis (accessing current accounts and moving money) or open to the public (such as news stories, offers, public statistics). Files would still exist within the Bank’s environment, hidden behind the web services API. For example a mobile payment initiated by a user could probably become a UK Faster Payment transaction, a SWIFT MT101, or even be embedded within an SEPA XML file over the inter-bank space. In this case, web services are an enabler that can allow a bank to bridge their “file” world with a myriad of custom-made applications, without causing too much chaos onto the existing architecture.

Web Services for ERP integration: Let’s remove the elephant from the room right at the start of this. A lot of noise is currently being made around SAP’s Banking Services Network, which announced that their ultimate goal is “to seamlessly integrate banks with their corporate customers”. The real novelty here is to enable SAP’s own clients to seamlessly select in their ERP the bank API they want to connect to. This is a step towards the exchange of financial transactions without the use of files and all other associated elements (middleware, protocol mediation, translation and conversion, communication protocols, SWIFT). In my opinion, this needs to be a wake-up call to banks. Corporate Treasurers now have the ability to decouple themselves completely from their bank’s channels and formats at a click of the mouse, with SAP acting as a broker in the banking relationship. This represents both a market opportunity for banks who are early adopters and participants of the SAP Banking Services Network, but also presents a level of risk as they all appear in a common marketplace with a fair amount of disintermediation.

Now, thinking about how GXS brings value to banks in this area; we already service a number of clients and integrate in various ways with such technology. Here are two examples of how I think we can take Banks to the next level:

  • Managed Integration Services over Web Services as a standard integration point between applications from Financial Institutions, ERP and TMS integration, 3rd party mobile technology vendors
  • GXS acting as the “web service” layer for any organisation that currently has a file-based external capability (online banking and/or host-to-host protocols). GXS can be a white-labelled Cloud Integration service and help you publish your web service APIs to the wider world.

To conclude, web services have now reached a level of technical maturity, combined with solid commercial applications and volumes within the Banking sector. The lessons learned from Mobile-based Financial Services demonstrates that web services enable Banks be more creative in terms of client product offerings across all segments (consumer, SMBs, mid-market, large corporates) and all sectors (Payments and Cash Management, Trade Finance, Securities) without significantly changing the internal infrastructure of the bank. Medium and Large corporates have yet to benefit from an ERP integration standpoint, their technology vendors are leading with web services capabilities, even offering to broker the relationship with banks. I am sure we will hear the same idea this year from Treasury Systems vendors as well. If Corporate Treasurers are ready to look at web Services, are banks ready to take their API to market? Maybe SAP’s BSN is a first step in entering the world of Bank web services for ERP integration. The next step could be a real game changer: Banks publishing their APIs directly over the internet.

Share this post

Share this post to x. Share to linkedin. Mail to
Jerome Tillier avatar image

Jerome Tillier

Jerome is a Senior Solutions Consultant in Financial Services, based in the UK.

See all posts

More from the author

How will 3D printers help improve banking KYC?

How will 3D printers help improve banking KYC?

Yes, you just read this title correctly. 3D printers are widely known to offer the potential to be a game changer in the physical supply…

5 minute read

5 Ways to Enable Differentiation in Transaction Banking

5 Ways to Enable Differentiation in Transaction Banking

Differentiate or die. This is a key business and marketing principle. This provocative phrase reminds us that the Natural Laws also have very real implications,…

5 minute read

NACHA Global Payments Forum 2013 – a GXS Waltz in Vienna

NACHA Global Payments Forum 2013 – a GXS Waltz in Vienna

In a recent announcement GXS highlighted the reasons behind our new membership to the National Automated Clearing House Association’s Global Payment Forum. Last week, I…

4 minute read

Stay in the loop!

Get our most popular content delivered monthly to your inbox.