“It took me 3 HOURS!” Integrating your backend with bank APIs is very easy

It can indeed only take 3 hours to create an API yourself, yet, here are five reasons why you should not do it by yourself.  

Open banking promised to be similar, or comparable, to the arrival of Internet banking and APIs are perhaps one of the most critical building blocks of the future of open banking. APIs have been holding the promise of an ecosystem where banks can interact with customers easily and Fintech providers and third parties can make financial data more accessible and harness the data for businesses to use it in various ways. 

My headline is of course provocative. I am a big believer in modernizing banking and the financial industry. For a developer-minded person like me navigating to an API sandbox, creating test credentials, and using our favorite development tools to make a simple API communication work is not a big deal. It’s as simple as shipping it in a couple of hours (of course, good API documentation is crucial. And many treasurers and finance professionals are very development-minded as well. Just look at the complex Excel sheets they create and manipulate every day. I am positive that they could create an API too.  

Connecting to an API is not more difficult than creating a Pivot table or a couple of VLOOKUPS. And this is the trap. A lot of companies have been running their homebrew cash forecasting solution in Excel. We used to say that Excel was our biggest competitor. And the reason to abandon Excel-based solutions? Well, the maintenance and scalability. The reasons why you should not do cash flow forecasting in Excel are similar to the reasons why you should reconsider your API strategy. And here are the five reasons why you should not develop APIs by yourself (just like you should not do cash flow forecasting in spreadsheets either): 

1. You are not always available to maintain it. Maybe this point suits me better as I consider myself a product person. I want to create solutions that are sustainable for the long-term and won’t need a lot of fixes. In other words, I should not be required to maintain or increment the code. It might be super easy to build one integration, but what happens when the bank or your ERP provider needs to change something? Or there’s a vulnerability that requires patching? As a treasurer, is it part of your role description to be pulled from the board meeting when one of your API integrations requires you to fix the code? I didn’t think so too.  
   
   
   
2. Scalability. Making software, or rather a pile of scripts that does the trick vs. making scalable, secure, and resilient cloud software are completely different things. Can your script hold on to current and future volumes? Can you trace and monitor it? How does it recover when something goes wrong (and to be honest, with every software something will eventually sometimes go wrong)? To build scalable and robust code, you need to have a testing and deployment strategy and embed concepts such as test automation in your development pipeline.
   
   
3. Security. I guess it cannot be stressed enough. You must demand the highest standards from your financial partners when it comes to security. Your ERP and system suppliers should hold valid third-party certifications (such as ISO 27K and ISAE / SOC). The homemade script doesn’t fit into this picture. How would a homemade script integrate your ERP system to make a € 100 million urgent payment to your bank fit into that picture? It simply doesn’t. Your overall architecture is as secure as your weakest link in that chain. For the sake of clarity, I’m not saying APIs are not safe. They are perhaps the most secure way to communicate between the banks and your financial systems. But you need to understand the big picture.
   
   
4. Complexity. You made it with one bank. Yes! Well, how about the next one which has slightly different APIs? And the third, and fourth. The API world is crying for standardization and my sincere hope is that for instance ISO 20022 can be re-used where it is applicable (this might become a news flash for some, but ISO 20022 is not bound to XML but can be as well presented for instance with JSON). How to spot hype? Someone claiming that integrating with APIs is super easy and happens with a snap of a finger. Yes, it might be the case. But rewind back to points 1-3, and take a holistic view, instead of rushing to cook your own API spaghetti.
    
5. Solutions will co-exist. If you expected APIs to wipe out SFTP, host-to-host, and EBICS connections then step in the line with me, my friend. Although the change and technological development here is inevitable, it takes time. And who to blame, as long as you are transferring files the good-old secure FILE transfer protocol (SFTP) is a secure and tested solution. If APIs would be here only to replace the existing banking channels and services, then the promise of a more real-time open ecosystem is seriously diluted. APIs can and should do, much more. 

Some might think my perception of APIs is pessimistic, but I consider myself an API realist. There’s still too some hype around the APIs while there start to be real applications live! My stand is that as long as the underlying processes and business models remain untouched, we’re mainly just talking about a different technology stack than before. And that alone is not a game-changer. And until premium APIs are priced premium, it is harder to bring those small innovations to the market that would help everyday life in finance and treasury. The future is built piece by piece, not over one night. APIs hold a promise to much wider potential than replacing existing bank connections for corporates. Stay tuned to understand how Nomentia will help you to navigate the change.