My local bank branch just put up a sign telling its customers that it is moving to a cashless model by the end of the (northern hemisphere) Summer 2017. 10 years ago there were no ATMs in that branch but there were certainly a lot of staff there, all of them dealing almost exclusively with cash (and cheques!) so times are definitely changing.
What I find interesting is that I stopped using cash in 2011. Since then I rarely set foot inside a bank, relying instead on online banking services. So, does the fact that it’s only now that my local bank is adopting a cashless model mean that the bank is 6 years behind in terms of their technology? I think it’s more likely that the processes in place within banking are forcing banks to move at the pace of the slowest technology adopters. I can completely understand the importance of prudence and governance in the industry and I feel far more comfortable with a bank being “too” cautious with my hard-earned cash!
From an API implementation standpoint, I think that legacy delivery processes may be causing a slower technology adoption rate in many banking and financial institutions. If this is indeed the case then this will pose a serious challenge for them when it comes to 2018 and PSD2. Athletes train for years just to compete in the Olympics but banks must become API Olympians within 18 months and the clock is ticking. We are now six months away from PSD2 coming into effect.
Just like Olympic athletes, banks are going to have to find a way to break through pain barriers to realize their PSD2 goals but unlike the Olympic cycle, banks do not have 4 years to prepare for the PSD2 event so speed and efficiency really do matter here. Fortunately, velocity in technology adoption can be helped by learning from someone else’s experience, it's not a individual event.
There are many reports that discuss the challenges and opportunities for banks when it comes to PSD2 at a strategic level and at a business level but what does that actually mean for the software delivery teams? How do the conversations around PSD2 governance map to tangible tasks?
In some ways it is as simple as this:
- What staff do I need to analyse the API requirements? a. What APIs do we need?
- What staff do I need to implement the requirements and do I have them? a. Dev Leads and Developers
- How do I build the APIs efficiently and consistently?
- How do I deliver the APIs?
- What is the schedule?
- What is the budget?
b. What are the requirements for each of the APIs?
b. Test Leads and Testers
c. Delivery Leads and Delivery Engineers
d. Process Leads and Process Coaches
Creating and deploying top class APIs to a production environment is difficult. Organizations who have been doing this for years have learned from their experiences (i.e. things going wrong) and have over time modified their supporting processes. Phrases such as “Fail fast and fail early” have emerged from these experiences. An experienced Development Lead used to say to me on a daily basis “if it’s hard to do then just do it more often” and he was right. The problem is that setting up an API delivery pipeline is difficult and the old way of doing the least amount of work possible, hoping that someone downstream will catch the problems (because hey – it’s their job) and then playing a game of “hot potato” with a test team is a complete waste of time. Olympic quality requires consistent dedication at every step of the process. If you’re delivering more than one API then you need consistency – we strongly recommend considering the Open API specification (aka Swagger) as the standard for RESTful API development.
This is your ‘Step 1’. Start with the wrong API type and/or definition type and you risk downstream re-work or worse, wholesale confusion. If you have a Swagger /OAS file already, please use our Swagger / OAS Validator for free (and please share too!) to see how your definition rates and how it can be better. Just register and sign in and follow a few short steps at:
You can help! Please share this tool by clicking here:
This tool will generate a list of swagger file errors, warnings and useful suggestions for your dev team to work on to ensure your definition file is compliant. This is ‘Step 1’. Please use the tool regularly and let us know what your thoughts, we’ll get through PSD2 (and beyond) together!