Warren Buffett is a smart role model for many people, including me. Although closely monitoring his insights and steps did not help me to create a fraction of wealth he has; I still cannot deny the fact that there are fantastic ideas and insights I learned from his shares. Once he said "After 25 years of buying and supervising a great variety of businesses, Charlie (Munger – his lifelong business partner) and I have not learned how to solve challenging business problems. What we have learned is to avoid them". Most probably it is not possible to solve problems that would come with APIs, but we can still find a way to avoid the most complicated ones.

I observed that there is so much information available about “How to use APIs”, but very limited ones are about “How not to use them”. Considering that most of us are in the early stages of Playing with the APIs era, I thought some lessons learned from the mistakes done in the banking industry while using APIs could be useful. I investigated some cases, then blended with some experience and prepared a short insight about it – with the hope that it might be useful.

SECURITY

First things first, Security. When I was a young boy (and still), I was a strong soccer fan and played for the school football team - as a goalkeeper. Among all other available 11 roles in the team - this was the hardest and the riskiest one. Even if you play a fantastic game for 89 minutes, a last-minute mistake could turn you from a hero to a moron that cause a defeat. When I started to work on cybersecurity area, I felt the very same feeling about the nature of the job - extremely difficult, critical, risky and one mistake or single point of failure causes defeat. I am also very surprised to see that how cybersecurity has been ignored by personal and professional levels. Same story for APIs, which should not be used without proper security in place.

APIs should be secured, they should be secured very well. I saw many APIs using HTTP, instead of HTTPS- that totally insecure the data traffic kills privacy and open the gates for fraud. Can you imagine proving an online banking service without encryption? You need to make it sure that both the APIs you produce and the ones you consume are secured and not the weakest link of your cybersecurity perimeter. There is no point locking all doors but leaving the windows open when you live on the ground floor - right?

“Does my API expose something that should not be exposed?” is the critical question that we must ask ourselves. If someone accesses to root file path on your server or over utilize exposed resources for a DDoS (denial of service) Attack – you may not enjoy the consequences for sure.

Security may not be necessarily the strongest asset of API Developers. If API developers lack security knowledge or culture, they might create huge risks. In the same way, putting too much trust on API consuming side is another danger.

Bank APIs are vulnerable for three types of attacks: Parameter Attacks (on API Data), Identity Attacks and Man in the Middle. OpenID Connect (knock-knock, who is it!) for authorization and OAuth 2.0 (Don't Touch the Cookie Monster's Cookies!) for authentication – are very important components of your API perimeter, that need to be managed very carefully & monitored closely.

POOR MESSAGES

When we first launched internet banking in 1997, the total team was three people. As a Junior IT System Analyst, in addition to many other things (from system design spec preparation to calling clients & asking how it is going) - I needed to take care of Error messages inside Internet banking too. In other words, I was responsible for leading the clients with the messages in a new, wild and unknown digital banking planet. In the beginning, the quality of my messages was so poor that rather than clarification, they were creating more confusion! You might imagine the chaos in place and the number of calls this confusion triggered. Who answered these calls?!? Yes, me again – the problem and the solution were provided by the same guy. Like every good composer, I suffered a lot at first then realized that unless I found a solution to this problem - I would be answering such calls all over my career. I concluded two solutions that might end my suffering: Self Explanatory Screen Designs (screens talk for themselves - oh I love that expression!) and Short/Clear error messages. It worked...

As of today, most of the APIs I saw have poor designs and messages. APIs mean developer community, that is composed of people from different demographics with different intelligence and experience levels. Think about the road signs, they were designed in a way that everyone can understand how it works. So, the second mistake we should avoid creating APIs that are very complex, hard to use and other than ourselves (sometimes even ourselves) don't understand the reason why a problem happened.

MANAGEMENT

And the third one is about the Management of APIs.

When you have an API, you should avoid the mistake of thinking that it's a Single Entity - like online or mobile banking. All APIs are part of large ecosystems and should be managed accordingly. APIs cannot be treated as single request/response interactions - they are more than that. There are many API designs with the use of wrong methods - a big NO, we cannot do that. We must stick some standards (Well, I do not mean Berlin Group or Open Banking type of API Standards, I mean quality standards!) so that the developer should know how to use GET, PUT, or POST actions at in appropriate times and ways. From Authorization to TPP Management (including support), there should be a service contract in place.

API usage should be monitored - not for the sake of monitoring, of course, monitoring for being ready for any corrective action needed. Plus, API calls made by both authenticated and unauthenticated users should be restricted. It is always wise to put a limit on anything that touches the Internet - this is valid both for the kid accessing the Internet at home and API at the bank!

The list could go up too many more items but because most of the readers are non-technical, rather than going into technical details - I just wanted to highlight the most critical three traps. Hope they would be valuable on your end.

As final words, API is a strange type of wild animal, if you want to pet one – you better be careful how to control it 😊