social share alt icon

ANTICIPATE

THE BREADTH OF

COMING CHANGES

ADOPT

A SUPPLY CHAIN

MINDSET

CHANGE THE GAME

WITH AI &

COGNITIVE

ANTICIPATE THE BREADTH OF COMING CHANGES

Let us caveat the following statement before we make it—no two banks are really the same and there are deep cultural differences that make it hard to generalize. That said, a high-street bank becoming a mobile-only bank or even offering a mobile-only product can result in the biggest disruption imaginable for the bank. Let us highlight some of the biggest changes.

The always-on bank


All banks have seen increasingly larger percentages of business operations being transformed to become straight-through processes. However, the bank’s internal rhythms always remain tied to the operating hours of the branches.

With a mobile-only bank, the bank is always on; always transacting and always responsive to the customer. There is no alternative to straight-through processing. Anything that requires human intervention must be treated as a major disruption, analogous to a major system outage.


Not just transactions, their “side-effects”, too


It is also not enough to just think of the transaction process itself being automated; all the “side effects”–monitoring risk and compliance, booking to the General Ledger books, covering foreign currency positions, adjusting the bank’s overall liquidity ratios—must be done completely hands-off, radiating out from the core transactions.

Slight irregularities in processing that accumulated over generations of incremental changes and which were corrected through adjustments need to be eliminated, which usually means that the applications need to be rebuilt from the ground up.
Modern internet applications are built on the principles of microservices, which are ideal for cloud deployments. These are intrinsically better suited to the mobile bank world than traditional “big iron” solutions. This is why mobile bank initiatives are usually coupled with migrations of all the key systems to the cloud.

 

Modern internet applications are built on the principles of microservices, which are ideal for cloud deployments. These are intrinsically better suited to the mobile bank world than traditional “big iron” solutions. This is why mobile bank initiatives are usually coupled with migrations of all the key systems to the cloud.

 

You are setting up Dominos – not doing the work:

So we want all the operations in a mobile-only bank to be automated. Setting these up can feel like lining up Dominos or setting up a Rube-Goldberg machine. There is a huge loss of control when the operations actually run through the system.

People are used to encoding a small percentage of the rules and context required—broadly following the 80/20 rule (Pareto’s principle: https://en.wikipedia.org/wiki/Pareto_principle). The corollary is that the twenty percent of rules that are not encoded can take four times as long as the effort taken in the past. The subject matter experts must have the self-service tools to define and test these rules themselves, without involving IT. 

This brings up the next impact.

 

Accountability is no longer shared:

Large projects put in place to implement business capabilities and enforce policies are designed to distribute the risk and work, allowing for multiple eyes and hand-offs to validate the rules. In a mobile-only bank, the business model intrinsically involves fewer hands on each product, feature, or rule. 

 

The actual transactions also have fewer hands involved. The actions of a few subject matter experts can impact hundreds of different business scenarios. The increase in accountability of these few individuals can be daunting. Even worse, the program owners may not even realize how accountability becomes concentrated in a few hands.

 

The center of gravity shifts to the customer:

Customer-centric banking has been a watchword of retail banking for over 30 years. In mobile banking, this becomes true in a unique way. The customer’s context—who they are, where they are, and what they are doing—is all known by the applications and devices the customers use for their banking. It has been proven over time that customers are willing to give up a portion of their privacy for convenience. This could be best illustrated with an example.

 

If you bring up your mobile banking app when you are at a car dealership, the link to open an auto loan should be the first or second link on the screen. The bank should already have a good guess on whether you are going to be approved for a loan and should make it as easy as possible to close the transaction. The customer expects to be driving the conversation and understanding what the different loan repayment options are. Additionally, if the bank has a relationship with the car dealer, the customer expects that to be pushed to the customer – “present this code to get the special 15% manager’s discount and oil changes for a year”.

Many institutions have held back on providing this level of empowerment and transparency to customers, retaining the right to optimize the offers to a customer based on an ever-changing set of factors. With the center of gravity shifting to the customer, this becomes hard to do. 

ADOPT A SUPPLY CHAIN MINDSET

DTO

There are several proven strategies to handle these changes. One of the most successful is to adopt a “supply chain” pattern. 

 

In a supply chain, each provider in the chain is responsible for relatively complete sub-assemblies. They take full responsibility for the delivery of their parts; including factors, such as like design and quality control. The final manufacturer assembles the parts from these individual parts to; creating a new product. 

 

This same operating model has been used successfully in organizations when creating cloud- 

ready, mobile applications. Each capability or functionality owner packages their responsibilities into microservices, which can, in turn, be assembled by the mobile channel team to create the services and offerings made to customers. 

 

When we package the functions into microservices, they need to be designed to take all the required inputs as values. This is different from traditional applications where modules are triggered by events, but have their own connections to shared data or repositories to pull the data that is required by each transaction.

 

This approach has been proven to help ease the transition. It provides each team with an operating model to understand their role in the new world, and how they can transition over. The loss of control in the larger context is offset by increased autonomy provided to each team. By tying these to microservices, there are no additional steps required to achieve the desired business transformation.

 

A few practical examples of supply chain thinking are as follows:

  • Suitability rules can be packaged into an engine that takes legal entity, service to be offered, and geography as an input. The engine can decide whether the specific service is allowed. This module can be used during account opening or maintenance to validate the set of services that are allowed. Additionally, if we recast transactions in the form of a service being provided to the customer, the same module could be used to validate whether a specific transaction is allowed.
  • A single module can handle the inflow of foreign currency into the bank. It will internally post to the appropriate cash ledgers. It will also be responsible for checking the net holdings in the currency against the guidelines for that currency, and deciding whether to hold or convert the currency. The same service can be used for any incoming foreign currency transaction event, including incoming transfers, reversals of transactions, etc.   

Building an Agile Business

 

The designers of the program will inherently be limited by their vision of a business operation that does not yet exist. It is a given that the market conditions and business needs will change during the lifecycle of the project. It is required that the program be resilient to this continuous change. 

 

In the mobile- only banking model, the channel owners have the empowerment to continuously change the business offerings. If we go with the supply-chain thinking, they have a set of well structured components that can be assembled in very different ways. Since each component encapsulates the policies and controls for that function, the channel can build new services, products or offerings from these parts with the guarantee that all relevant policies will be enforced. 

 

Additionally, each policy owner will have one or two components within which the policies would need to be enforced. Since the data required by the rules are packaged along with the data, they are decoupled from the individual business components. The interfaces to the modules clearly declare to the channel owner what is data is required to make the decision. This forces the channel owners to ensure that they collect all the data required before a decision can be made.

CHANGE THE GAME WITH AI & COGNITIVE 

A key expectation of end customers from a mobile-only bank, is the ability to see things from the customer’s point of view. For simple transactions, the customer can usually work out what is expected from them to complete a transaction. However, for those scenarios where they need guidance or additional help, we would need to add a set of cognitive tools to the mix.

These take in data that is outside of the core transaction data and using knowledge models, anticipate problems the customer might face, or pre-empt mistakes. Rich Internet Agents (RIA) are the most visible forms of this, interacting with the customer to ease their experience.

The same cognitive technologies are also being used to ease the interactions between the teams in the bank. Just like an RIA would understand the customer’s perspective and help suggest a course of action and prevent mistakes, cognitive technologies and AI tools can be inserted between services and can help ease the integration. When an unanticipated event occurs, these agents would need to be sent feedback, which would result in them monitoring the actions taken to resolve the situation. Machine learning algorithms can be used to discover patterns that can predict such events.

 

The burden of handling every edge case can be significantly reduced through this kind of use of cognitive technology.

 

We are currently working on the initial implementations of this kind of integration and are seeing excellent results in reducing the cost and time to implement very complex transaction lifecycles.

CONCLUSION

While a mobile-only bank may not be an immediate goal for your organization, many parts of this story would be relevant to all banks. The disruption to the normal “way things are done” from the new technologies is easy to underestimate.

We hope the suggestions in this paper can provide actions and solution approaches that can be taken by your project teams in their journey to help the teams better understand the new operating model and reduce the effort and time for the transition.


FURTHER READING

We recommend that you read our position papers on Microservices and Cognitive for a better understanding of these subjects.