How the “Potemkin effect” obstructs a full digital banking transformation

INDUSTRY VIEW

1 November 2018

From short text messages and online banking onwards, banks and their technology teams have struggled to keep up with the challenges of digital channels for more than two decades. Today, banks use technologies and business applications that allow them to support a variety of customer touchpoints such as various mobile channels and the online channel – often in a flexible, cross-channel fashion that can create great customer experience.

However, banks typically stick with existing monolithic back-end applications that are in many cases decades old. The resulting lack of flexible business capabilities does not allow for new banking products and services to be easily designed and quickly delivered, or enable banks to respond to customer information requests and transactions in near-time and connect to business partners easily. This focus on touchpoints – on the digital front end – prohibits banks from creating the seamless digital end-to-end experience that retail and corporate customers need. Forrester calls this the “Potemkin effect”.

What are the reasons? The same solutions that banks need also create transformation risks. Undocumented functional extensions, complex integrations, monolithic design and a lack of experts still knowledgeable in old technologies and languages such as RPG and Cobol make digital transformation planning difficult and its execution a risky endeavour. Forrester survey data shows that decision makers in at least one third of financial services firms prefer the reduced customer experience of the “Potemkin effect” over transformation risk.

Even if a bank’s decision-makers tend to commence a digital end-to-end transformation, there is no guarantee that it will be successful. Discontinued large-scale transformation projects such as those of Co-operative Bank, as well as painful go-lives such as – more recently – that of TSB Bank are the exception rather than the rule. But incidents such as this shape the perception of huge transformation risk and further reduce the will to transform, even though thorough planning could have avoided these disasters.

In the meantime, business requirements are stacking up. Banks need to deliver compelling customer experiences, create innovative products, rationalise their product portfolio and comply with regulatory requirements. They also need to become more productive, increase their profits, compete with the attractive point-products of fintechs and remain competitive in the world of open banking. And they need to accomplish all that using an obsolete technology base and in a market with diminishing margins. The transformation imperative won’t vanish, but what are the options?

A bank may opt for a perfectly tailored custom-built solution to mitigate risk and maximise delivered business value. However, this is hardly an economically sustainable approach anymore. Off-the-shelf banking software packages represent one more alternative. However, only a small group within the thousands of off-the-shelf banking applications can cope with at least the majority of the stacked-up requirements – and only a small minority can easily deliver the business agility that banks will need in the next decade and beyond.

Today, banks can follow one of two similar paths. They can either design an architectural target state around APIs for business-to-consumer, business-to-business and application-to-application scenarios as well as modern technologies and concepts such as artificial intelligence (in its various flavours), embedded analytics, high coherence, lose coupling, microservices, and SaaS and hook custom-build and off-the-shelf business software capabilities into this architectural framework. Or they can opt for one of those banking software vendors that already advance in the same direction and use their architecture as a backbone.

With this solution, banks don’t need to consider the coarse business software modules of the past anymore. Application landscapes will become an ecosystem of capabilities rather than a set of hardwired and integrated software products. A banking application will become a composition of business capabilities. Software artifacts from a bank’s development team, the bank’s financial services partners, maybe a joint venture for factory-type capabilities and service and software vendors will jointly deliver onboarding and origination processes via microservices – for example (see figure), with data securely stored in the bank’s in-house vintage core banking application and further (third-party) data stores.