Community

Interesting post but I don't agree that the banking infrastructure is broken. I would argue that the way we are using and managing infrastructure is problem here.

"Legacy systems" are blamed for an inability to innovate and move quickly. This is generally a euphemism for 'old mainframe' technologies that were and are still extensively used today. They have and are still successfully handling countless transactions daily.

The problem in my opion is the two speed IT processes that we have. The front office justifiably want to move quickly and are rewarded for doing that. The back office want to keep the lights on and are rewarded for doing that well. They are totally contradictory as the best way to turn the lights off in an organization is to change something so change is done slowly, carefully and responsibly.

To that end, changes to the most modern back office infrastructure will also be slow so it has little to do with technology and more to do with process.

As an industry, we have been very poor at fully prototyping solutions moving from plan to implementation immediately which leads to a lot of project issues and wasted time making changes to the back office that are not required.

So while I would agree there is a problem, I'm not sure it's the infrastructure but the processes that we are using for prototyping, developing and deploying new applications and functionality that is the problem rather than the infrastructure itself. 

This is a great article clearly documenting why developing financial software is almost the polar opposite to building social media software. There is simply no room for errors. 

However, I would take issue with the statement that ' there is very often no legacy code or systems to work with'. I would suggest that if you are developing Fintech software, integrating with existing back office systems is a must have to do anything meaningful. I have ceased seeing 'legacy systems' as being older mainframe technologies. Today, 'legacy' IMHO is any system that has been deployed because once deployed, the system is (for good reason) wrapped in kid gloves and very difficult to access. Therefore testing with these systems is a major challenge in the Fintech space.

Excellent and comprehensive article. It can't be emphasised strongly enough that creating and enforcing API standards here is a must. PSD2/Open Banking around Europe is being hampered by the fact that while the UK took a strong stance and created a standard for all the banks in the UK (and Ireland),this was not done across the EU. Therefore, if you wish to access open banking APIs across the EU you must learn to live with different APIs and standards which essentially defeats the intention of the PSD2 directive. Can the insurance bodies across the EU take note and please do this properly not if, but when this takes off as I believe it will. 

A broader set of APIs makes sense but if every bank does this in their own way, it doesn't help anyone as a different interface will require work to access each and every bank.

Where PSD2 fell down is that it said what must be done but did not say how so we now have multiple standards across the EU.

While OBIE has it is by no means perfect, I believe their direction is the correct one. Ultimately we don't want to care what bank we are dealing with, we just want to use the APIs. When the banks want to innovate and create premium APIs, wont that be a fantastic place to be.

At the same time, the intent behind PSD2 was good in that if the banks were not mandated to do this, we would simply not be where we are now.

This is interesting reading. Having participated in a recent conference with a number of banks participating, many seem to feel that simply offering a shared sandbox which simply responds correctly to API requests is all that is needed. From talking to developers on the other hand, many will want more functional sandboxes and an ability to potentiall have their own individual read/write sandbox for their own testing. Having stand alone individual sandboxes will be key for an agile development CI/CD process so that automated tests can be run without being tripped up by other users.