The Conflict Between Banking Innovation, Fintech and Infrastructure

OstBlog fintech banking safe

Banks of all types around the world want to innovate and, in fact, they must innovate if they are to compete with the emerging online banks and various other threats to their business. Banks are showing this willingness to innovate by their interest in and support for the various Fintech companies and clusters that are emerging and supported through events like the Accenture Fintech Innovation Lab run in New York, London and Dublin.

So while the banks want to innovate, this requires an agility to respond quickly to market trends and deliver new and improved apps to customers in weeks. The technologies that deliver apps can easily adapt to this speed of delivery, however, this then leads to a conflict in requirements from the infrastructure teams.

The infrastructure teams are responsible for keeping the bank running and as such will have literally thousands of customers and bank staff depending on their services being available 24/7.

With such a requirement, changes must be made slowly and generally one at a time. Many a support person has learned to their cost what problems can occur when more than one change is made when things go wrong. Which one caused the problem? Does it take longer to back out the two changes instead of just one?

Changes to the infrastructure actually don’t just mean changing the system. A major change is needed when connecting new apps to the core IT infrastructure as every additional usage will have an impact so this is a risky business. Reduction of risk to as near to zero as possible is key to keeping the infrastructure servicing all of the customers and employees depending on the key infrastructure.

Some Core IT Team Challenges

Along comes a new Fintech offering something the bank would dearly like to implement and roll out for whatever reason. It has key requirements from the core IT Infrastructure (normally data of some kind) to enable it to function properly.

The core IT teams have a backlog of many months of requirements from various teams it must fulfil so they cannot respond in the time required. Often when the requirements are delivered, things have moved on and the requirements have changed leading to another set of requirements being requested.

This cycle then becomes self-perpetuating with more requests being generated with the backlog getting longer. The requirements being delivered are not what is needed or are no longer needed, leading to an excessive amount of time being wasted by valuable key infrastructure resources. In fact the gap is getting wider and wider because of the pressures being put on the infrastructure.

Prototyping / Testing without connectivity to the core infrastructure

What is needed is a mechanism to enable the new Fintech or app to prove itself without connectivity to the core infrastructure. This can be done by creating simulate versions of the connectivity to the core infrastructure so that prototyping and testing can take place without any changes or even connectivity to the core infrastructure. This has the following benefits:

  • New apps can be fully prototyped and tested without the core infrastructure being used.
  • This leads to better focussed requirements from the infrastructure teams because it will be clear exactly what is needed to support the new apps deliverable.
  • The infrastructure teams can audit in advance how a new app will interact with the infrastructure and can therefore reduce risk by ensuring that it is using the infrastructure correctly.
  • This audit can also ensure that the infrastructure teams can establish the additional load that will be put on those systems by the new app and can plan for this accordingly.

With a process like this, it is possible to build up more trust between the two differing sets of requirements and this enables the banks to implement more Fintech deliverables or apps with less risk within their organizations. It also ensures that more projects can be delivered with the same resources as less time will be wasted on badly specified requirements.


See Case Studies, whitepapers and more on our resources page.

Learn more about what we offer on our services page.

Written by : John Power