The PSD2 conversations that I’ve been involved in have largely focused on concerns such as governance and authentication but I can’t help but feel that there’s another few elephants in the room – the API delivery strategy and the API itself!
I totally agree that there is a challenge that exists around authentication and that governance is exceptionally important but let’s be clear - there are MANY technical challenges (and underlying cultural challenges) that will impact the PSD2 API rollouts.
We’ve grown accustomed to building and deploying software with a user interface; to most people it’s something tangible that you can talk about and quickly see if it does what you think it should do. API’s – not the same thing at all and if anyone says or assumes otherwise then let me just say that they’re in for quite a surprise.
We've been around this space for quite a while and here are some of the biggest issues that we see which we know will impact PSD2 API delivery:
Lack of trained personnel: Where are the API dev teams suddenly going to appear from (i.e. the team of 3 API amigos; analyst, developer and tester)? Even after providing training, there’s still a significant learning curve involved before becoming proficient as an API analyst, developer or tester. Are you struggling to get the right API talent? Can you afford the “good” talent? More importantly, are you able to tell the difference (because everyone looks great on paper)? Do the staff you have hired possess real world experience or are they less experienced than what you’d hoped? We seldom see the top people available in the market and, yep they usually know what they’re worth! So, unless you strike gold, there will be expertise gaps in your implementation and delivery teams, gaps that pose serious risks and that must be filled and unfortunately it may take a few mistakes before you are even aware of those gaps. Smart use of tooling can help with this personnel issue.
Performance, Load, Stress gaps: If you do not have a plan to test your API performance under load then, I'm afraid, you do not have a credible API test strategy (and multiple calls to a single end-point is not a load test). Get this sorted ASAP.
Operational gaps: Redundancy / DR, monitoring, load balancing, regional considerations: In practical terms, regular outages are not an option under PSD2 and incident / outage prevention must be prioritized over cure. If Environment A isn't doing the job, Environment B must be ready to assume control seamlessly, it’s that simple. Discussing a major incident with the financial regulator will be a painful and time-consuming conversation.
We can say with confidence that there is a good chance of banks getting governance and authentication right for PSD2 but there is a serious risk of their APIs not working from functional and non-functional standpoints. Why do we say this? Well, the entire delivery strategy must be tailored in order to deliver high-quality APIs. Trying to use traditional delivery strategies is a bit like trying to automate a mobile app test without resource_ids ... it’s slower, less efficient and in the end it just won’t work.
Your action plan? Get the right mix of people, process and tools.
People & Processes
Start with finding an experienced pragmatic person capable of building and leading an API development team. You need someone who can talk about what they learned from their mistakes, someone who can establish an efficient API process and then support a team within that process. Once you have the right people, you've then got to trust them and provide them with the tools and environment they need.
A super place to start the tooling discussion is around the API type and the API definition and documentation. We can give you a head start right now. Strongly consider adopting RESTful APIs and the Swagger standard (i.e. OAS 2.0, soon to be replaced by swaggerless OAS 3.0) as the standard for all your API development. This will promote efficiency in every step of your process from its very genesis, minimize downstream re-work and focus on API quality all the way through.
Swagger / OAS 2.0 Compliance
Make sure your swagger files are compliant with the Open API Specification standard and make sure all your APIs are consistently developed. Do this by getting static analysis of your swagger (OAS 2.0) definition file underway immediately. This means testing your swagger file every time it changes to ensure that it is compliant with the Open API Specification, that it is testable and that it is functionally robust. If you pass a poor Swagger file to a test (or documentation) team then you’re wasting time. Reduce the feedback loop and get this right first. You can use our Swagger / OAS validator for free, just click here:
You can help! Please share this tool by clicking here:
Within seconds you will have a list of errors, warnings and useful suggestions for your dev team to work on to ensure your definition file is not just compliant but solid. This is the first step to PSD2 RESTful API happiness. Let's not forget about the APIs in all the PSD2 chatter. Please use the tool regularly and please share this useful tool with your network and let us know what your thoughts are.