Digital Maturity Model for Banks' Digital Transformation

As I noted in my last post, Banks should define their roadmap for Digital Transformation, But it is mandatory to have in hand the definitive Digital Maturity Model, something like the well-known CMMI for the Software Industry. This model should provide levels of maturity for Banks. I´ve been amazed to see a lot of banks struggling with their own models. Consultants imposing their models, models built on the GO.

Since the Banking industry, just try searching the web for this term and easily there will be more than 250K results, none of them is a clear standard, none of them comes from a common source. So, as we are in such a state of multiple efforts to have a good model, the only way out is to evaluate the success possibilities around and take one. Any other suggestions? Yes, right, the best path eventually be not the best one. We fail in the dilemma of choosing the best based on the nearest truth. This means, that after benchmarking the market that affects the bank, something will come up and that will be the ideal model. Sad but true, as Metallica´s song says??. Not at all, the truth is that the banking industry is big, the threats vary from place to place, and it is not practical to compare one bank in New York to another one in Sri Lanka. Different realities? yes. In the end, there are different approaches, full of good intentions. This means that the bank across the street will implement a different model than its neighbor.  boooo, scary!

It is scary just if you think that Bank 1 considers that the level of digitalization for, let´s say its front office is roughly 80% and the Bank 2 assumes that for them the same level is 70%, but wait, The Bank A has 40 applications and Bank 2 has 110 applications. Sorry for Bank 2, now is paying for having a lot more in applications than its rival.

Now, the point here shows how important is to adopt the right Maturity Model and be prepared to understand where is located the bank in question. Something like the problem of two-speed runners, the first one like Bolt, tall, slender, etc, the second one will be a small man from X country who runs 100 m just 0.2 seconds behind Bolt. It is clear that regardless of the runner´s height and other physical factors, the winner is the one who scores less time for the same distance.

A common approach to measure the maturity index is to consider

1. Front Office
2. Middle Office
3. Back Office

and determine the percentage of Medium, Basic and Advanced degree of digitalization in everyone.  As far as now, the Front Office in all banks has more chances to improve its digital face, nevertheless, all 3 have an impact on Customer Experience and are affected by Service Design. Again, the Maturity Model comes to show that it is important to measure Digital Maturity as a whole. What an intersting point,  isn´t it?

Keep in mind to have KPIs and adopt a standardized model.

Most solutions fall in Customer Service digitalization, but the real Digital Transformation is a whole.   Hence, the maturity model should encompass internal and external actors affected by systems and operations.

Back in 2011, the vision of the branch of the future defined a revolutionary approach in customer service at the branch level, it depicted integrated channels for service, Mobile as the biggest container, then inside these web applications that covered call center and the call center keeping inside the traditional Branch and the philosophy behind the concept is to have a continuous process of performance improvement. The missing concept behind this proposal was the model itself, there are thousands of banks, each one living a particular reality, that is why we need a common framework, no less no more.

Flexible risk-based pricing models. Is it possible with outdated cores?

The term is quite simple to remember "What-If", something that has been used ever and ever for simulations. Yes, and Risk is a kind of simulation when Banks deals with loans such as mortgages. What-If the customer has a good credit record, what if the customer does not? Is it possible to negotiate a lower interest for a  higher down payment?

So, in cases when banks try to capture more customers, it is very important to be flexible, to have a 360 degrees view of customer´s products and historical behavior for existing customers and have other means to qualify new customers. Something that old fashioned legacy systems have never offered.

This only feature reflected and available in all channels can make a remarkable difference among all the competency. But, why is that not all banks have implemented such tool? Well, mainly because current core systems do not support this feature and sometimes, maybe the in almost all cases, the process to transform or implement such functionality is complex, expensive and sometimes incomplete. There a number of things to consider, beginign with customer file records (the repository commoly known as CIF: Customer Information File), customer´s products in the bank, credit records from credit bureaus, data from other sources such employment history, insurance, etc. So, in plain words, modifying an aging core system to fullfill the highest requirements for achieving risk-pricing is a titanic enterprise. At all sights the first possible solution should be to aquire an standalone application that integrated with the core system. This means more interfaces, more user screens but at the end, the institution could have its solution up and running.

Using the right data analysis it is possible to identify the customer´s  position in the right relationship tier that the bank has defined. It means that depending on the customer pre-qualification, some prices, fees, rates and considerations are autmaitcally applied, this can lead to less negotiating time expent with every customer. Chances to deploy campaigns oriented to capture more customers and turn leads into profitable sources. As San Francisco based Bank of the West defines, this is a "realtionship pricing".

i f we consider the difficult track to walk starting from old legacy core systems, the more advisable solution is to migrate to a new core banking solution, with modern technology, far away from Cobol and related technology elements. Since a system, to deal with all the features that risk-pricing stands for, requieres technical features such services management to capture and share information with external systems.  And the chances do not end with servicing current customers or to aquire new ones that come from other institutions but to serve "unbaked" or "underbanked". There is an endless possibility to create and maintain risk analytics databases. 

There is a "must consider" step under the current consideration, to expand service capabilities to all channels, it means renewing or uptating Internet Banking, Mobile Banking and Self Service Hardware (ATMs, Automatic Deposit Terminals, Kiosks, etc). This question always arises when speaking about modernization, and the answer is "Do it now", because doing it now is not a short process, it requieres to change a lot of things, begining with administrative process and diving deep in software changes and sometimes hardware. Always thinking on old cores as the starting point.

This lead to outstanding competitivity, because chances to keep gold medal customers increases as rates and services get better, and on the other hand attracts good profiles to obtaint the same benefits. Other page has to do with risk reduction because high rates and stiff rules for customers with low qualification that constitute high risk reduces the chance of loosing money.  With this model in production , it is easier than for other banks to approach to unbanked in some specific services and to attract them. 

For institutions that own an old cores, this is more that changing habits, renewing process and implement a new island to its archipelago. Thinking about chances to have a Frankenstein living under the hood of modern servers, upgrading and aquiring a new core and implement new products and services around  this last one is a better choice.