This page was written in 2003 and we have created two updates.

1. This link is a post giving a review of what actually happened between 2003 and 2019.

2. This link is a post giving a new forecast for banking technologies for 2019 onwards.

Cutting Costs

The Banking sector has been the scene of huge change in recent years and operations departments have been at the forefront of these changes.

The thrust of current strategies in Banking Operations departments is focused on substantially reducing the unit costs of the key drivers (e.g. cost per current account). These reductions are being achieved through a combination of automation, outsourcing and moving the work overseas.

The graph below illustrates how we believe the cost profile will change in the next 3 to 5 years, with less being done in the Bank’s own branches and call centres, none in its own processing centres and more being done in outsourced centres or offshore.

While we expect the amount of work that is automated to increase we anticipate that the unit cost of automation will fall dramatically thanks to plunging IT unit costs. Since banking operations cost billions of pounds a year in the UK the prize is well worth getting.

Key Strategies

So what are banks doing to achieve these cost savings? We have identified …

• 5 Banking Operations Design Ideas
• 5 Business/Technology linking ideas
• 5 Technologies being invested in

… that, taken together, we believe form the bones of a current industry wide strategy in the Banking Operations function.

These ideas are very much about current strategies but we do expect this analysis to remain valid for at least a year or two.

Banking Operations Business Design Ideas

• Centralised and specialised processing delivers economic efficiency in Financial Services Groups
• Financial Services Companies will be less vertically integrated with much more activity outsourced
• Product Processing Engines will be brand indifferent
• Don’t mix sales and service
• Clearly separate service and processing and make service multi product

Business/Technology linking ideas

• Only electrons move in the bank
• Simple CRM for customer contact
• All forms are filled in electronically, preferably by the customer
• Legacy software will be an important design point
• Web browser to bring together lots of systems on the desktop

Technologies being invested in

• Image processing
• Browser technology
• E-Mail is an under used technology
• Gradual break up of legacy banking software
• Package software

Banking Operations Business Design Ideas

“Centralised and specialised processing delivers economic efficiency in Financial Services Groups”

Most Financial Services Groups are moving this way at a speed convenient to them although there is still a lot of room for further process centralisation and specialisation. For example, many banks have already taken multiple processes out of branches into district, area or regional centres. Now they are taking this a step further by re-dividing the work so that each process is carried out nationally in only one centre, increasing specialisation and realising even greater economies of skill and scale.

As the headcount in branches associated with operations falls those that remain increasingly have to dedicate their time to sales and customer service. An obvious corollary of this trend is that the cost of branches (staff, property etc.) has to be justified (or not) much more by income growth and customer satisfaction (See a discussion of the impact of this strategy on Branches in Service Channels and Recent Banking Strategies).

“Financial Services companies will be less vertically integrated with much more activity outsourced”

Many of the large Financial Services groups currently carry out all the activities in their “value chain” with their own staff in their own premises. Further, these staff only do the work for products sold by their Group, sometimes only for one brand in the Group. Individual banks have already been obtaining economies of scale by centralising processes within the group (see “Centralised and specialised processing delivers economic efficiency in Financial Services Groups”). It is increasingly recognised that further economic efficiencies can only be achieved by

• getting an economy of scale that one bank alone cannot (e.g. funding an IT development that is not economic at too low a volume)
• taking advantage of an economic edge not available to the institution (e.g. managing a function in a low cost area of the world such as India).

To achieve these higher levels of economic efficiency, Financial Services Groups are now looking to buy and sell much more of the “intermediate” stages of the value chain from each other or (more likely) from specialised BPO outsourcers. In particular, the product processing engines are extremely likely to be outsourced (see Banking Engines for an explanation of what product processing engines we are referring to).

“Product Processing will be brand indifferent”

Product Engines are the combination of back office services and systems that carry out the day to day activities associated with a product such as a current account or a home loan. One of the key aims for banks is to achieve economies of scale in back office processing. In order to achieve this banks are increasingly using a single product engine to serve many markets (i.e. multiple customer segments, many geographies, etc). Product engines are therefore increasingly brand indifferent as customers interacting with different brands use the same product engine.

However, banks are aware that customer service needs to be clearly aligned to the brand promise; hence one back office product processing engine may have to deal with a number of different customer service approaches. This is an important reason why many banks now see the value of separating customer service from back office processing (see “Clearly delineate Service and Processing and make Service Multi Product”).

“Don’t mix Sales and Service”

There is a tension in the banking industry between sales and service. One school of thought is that customer service centre staff should be selling much more than they do. It is certainly true that when a customer phones with a service request he may be signalling a need for a product or service (e.g. a correction to a standing order detail may be an opportunity to promote an electronic banking solution so the customer can resolve matters himself). However in these cost conscious times many in the industry are not following this school of thought. This is probably because three key aspects of service provision militate against the ability to try and sell and service simultaneously

• Selling involves exploring a customer’s needs and therefore takes time whereas the aim of service is speed and efficiency (to reduce costs);
• Selling requires a different set of skills and motivations to that of a service provider;
• Another one of the emerging industry design ideas (see “Clearly delineate Service and Processing and make Service Multi Product”) is to provide a customer with only one service contact covering a wide variety of products. These contact staff will be stretched to provide quality service across lots of product areas. It will involve lots of training. It seems implausible that they could know them sufficiently well to sell them as well. (A possible solution for sales is to produce analytic software that reviews customer service interactions to generate sales leads which can be passed to “proper” salesmen).

“Clearly delineate Service and Processing and make Service Multi Product”

It is now recognised that, even with the introduction of more automation, banks will still have a lot of basic processing to perform; such as name and address changes, mandate setup and maintenance, etc. This is because –

• Some customer segments will not use electronic banking (i.e. they will only use phone, mail or branch)
• Some things are not time critical (mailed instructions, forward dated items)
• Some processes take a long time and involve third parties

 

 

This reality throws up a key design challenge for Banking Operations functions. This is illustrated by the diagram above.

There is a real tension between providing the customer with a single point of contact for a range of products and product specific processing centres where greater specialisation and productivity can be achieved.

On balance, we believe that the industry is leaning towards a customer service function that should be customer centric and hence if the bank has a wide variety of products and services, the service function should front the whole range of these products and services. Obviously it would be nice if the service provider (a branch person or a call centre operator) could fulfil all service for all products. However we don’t think this will be feasible in terms of skills. Nor would it be desirable for such skilled (and presumably expensive) staff to carry out work that can be done cheaper. As a consequence we believe it is inevitable that there will be background processing centres specialising in different service/product areas (International payments, account maintenance, insurance claims). Nonetheless banks feel it is important that as much customer contact as possible is carried out by a single service contact to build up a “trusted provider” relationship between a given customer and a given person/team that can represent the whole bank/brand. Customers continually state they appreciate having a single point of contact that knows them. Given the drive to reduce processing costs it seems to us that a separate service function spread over multiple products (and separate from sales) is a very important banking operations strategy.

For an analysis of the impact of this strategy on Branches and Telephone service see Service Channels and Recent Banking Strategies.

Business/Technology linking ideas

“Only Electrons move in the Bank”

Although banks still use paper and fax a lot to make work happen efforts are now afoot to reduce this. Paper is currently still used to pass “work in progress” from one department or building to another. Many of the documents that are faxed / moved are produced by systems internal to the bank. Printing, manual handling and then ‘re-keying’ data is high cost and banks are enhancing their use of email and intranets, already universally available to bank staff, to drive this cost out.

Documentation required from a source external to the bank (e.g. Land Registry documentation, deeds, passport copies, etc.), from what we can see, will be captured as an image at the first point of entry to the bank and then filed with either a customer or account record. Apart from eradicating manual handling, the use of images allows multiple departments to see the entire file (e.g. for a loan application) at the same time, hence speeding up processing by allowing activities that previously had to be serial, to run in parallel (See “Image Processing”).

For an analysis of the impact on this technology on Account Maintenance and Lending Security processes see Core Banking Processes and Recent Banking Strategies.

“Simple CRM for Customer Contact”

Customer Relationship Management (CRM) as a phrase ended up covering a vast plethora of business ideas from sales pipeline management through to complex analytics on call routing. Given the very large customer bases that banks have, with significant variations in customer behaviours and preferences it is inevitable that a given service proposition will have to be supported through a number of delivery channels (see Banking Channels). As a consequence many banks are seeking to maintain a record of customer interactions, particularly for service, that is independent of delivery channel; i.e. outside the branch, call centre, and product processing centre.

“All Forms will be filled in Electronically, Preferably by the customer”

Much of the documentation that moves within a bank and between a bank and its customers are paper forms. The ambition for many banks is to see every customer form available on the Internet. If a customer fills in a form via the internet/Email there are great benefits

• Software can sift the customer keyed data and input it into core systems (A/C opening, credit applications) and so avoid bank staff having to key data; and
• The customer should never get faced with an out of date form.

Customer signatures would still be required in many cases (although digital certificates, might alleviate this) and the customer would have to print and sign a version of the form, which would get mailed to the bank as follow up (and probably scanned in as an image – see “Only electrons move in the bank”.)

Banks are also applying the same ideas to internal forms. The aim is for bank staff to retrieve them from the intranet, key them and Email them.

“Legacy Software will be an Important Design Point”

We have not heard of anyone in a branch based bank saying “let’s design our processes as if branches don’t exist”, and the reason is that it is such a large part of the current state of the bank that it has to be a major consideration. In many respects, the legacy software base is as large an investment as the branch network. Thousands of man-years of effort have gone into developing it and it will not go away. In the past banks have often tried to deal with the legacy software issue by one of two strategies

• Launching a major programme to replace the “Gordian’s knot” that is the legacy software base
• Backing a technology that purports to allow the bank to develop new systems that interface with/wrap around the legacy software as if it were not a constraint.

Both approaches have generally failed.

However, banking operations planners and strategists are now investing more time in understanding the legacy systems and how they work, where the pinch points are, what things are simple to change and trying to find an evolutionary way forward (although some IT planners in banks believe Web services may do what previous interface and wrapping technologies have failed to do). See “Gradual break up of legacy banking software”.

There is further discussion of this issue under “Customer Accounting Processes” in Core Banking Processes and recent Strategies.

“Web Browser to bring together lots of systems on the desktop”

Currently a member of staff in a branch or call centre can only access a limited number of the bank’s product engines. For example they might be able to logon to the Bank Customer Accounting system to access current and savings account details but not be able to access the group’s mortgage, credit cards or insurance systems. The principal reason for this is the technical incompatibility of the different product engine systems. Banks are increasingly standardising on web browser interfaces to all systems and hence opening up the opportunity to allow staff to carry out work (e.g. customer service work) across a wider range of products than was hitherto possible (See “Browser technology”),

Further discussion of Browser technology in relation to Branches and Telephone services can be found in Service Channels and Recent Banking Strategies.

Technologies being invested in

“Image Processing”

By image processing we mean central stores of images with an index. Banks are on the brink of a step change in eliminating paper from their business processes. Technology is now being employed to ensure all cheques, mandates, application forms, supporting documentation, customer letters, etc. are “imaged” and stored against customer or account records. The technology running costs (disk storage and telecoms line capacity) are plunging and are, it is believed, already within cost justifiable ranges. The up front costs are principally scanners and these too are now very cheap. Apart from the staff/manual handling cost savings, there is an expectation that many of the new costs could substitute currently incurred costs in the form of internal faxes, photocopier costs and paper storage and purchase. (See “Only electrons move in the bank”)

“Browser Technology”

Here we mean simple browser based presentation technology which has some aspects that are particularly attractive for banks

• The web browser is becoming a very standard user interface and communications protocol, in a way that was never achieved with client server technologies. For example, a mainframe 3270 based customer accounting application may well be impossible to implement on the same desktop as a UNIX based client server Mortgages application for various technical incompatibility reasons. It is very likely that both applications are now the beneficiaries of companies selling components that allow a web browser to access both server applications without significant (expensive) changes to those server applications
• Banks have very large populations of users; some of the core banking applications will have 30K users concurrently using them in a fairly intensive way. Client Server systems had the benefit of Graphic user interface technology but banks monotonously broke them for performance and scale reasons. Fortunately for banks, many internet sites have vast numbers of users and banks believe there will be highly scaleable proven software components that are available for them to use in a way that was not true of Client Server technologies.
• Again because of the large numbers of users, client applications had to be distributed in thousands of PC’s, often in hundreds of sites. This gave huge desktop maintenance costs. Web technology simply requires an industry standard browser on the desktop, which banks expect to yield a much lower maintenance cost.

“Email is an under used Technology”

Email is pervasive, both inside banks and in a large proportion of the bank’s customers; particularly in the small business and corporate customer segments. For communication between customers, third parties and banks the technology is rather under used (see “All forms are filled in electronically, preferably by the customer”).

Within the Bank many of the benefits associated with workflow technology may well be gained by using Email (queues of work, passing work requests from team to team, logging etc). This is likely to be developed by user departments using the tools on their desktops in creative ways, rather than by major IT programmes and may well end up costing a fraction of expensive workflow developments.

The use of email technology for Lending Security and Account Maintenance processes is discussed further in Core Banking Processes and Recent Strategies.

“Gradual Break-up of Legacy Banking Software”

For most banks, the current (often 1970’s generation) core banking systems will still form the backbone of the banks’ systems base in ten years time. It does not appear that banks can justify the hundreds of millions of pounds and massive consumption of resources required to replace these systems.

Given this backdrop, any asset that is going to be around for ten years or more will need a “repairs and refurbishment” budget. For core systems this could be used to break up the core systems into more manageable chunks alongside normal business projects. For example the launch of a new current account mortgage product, if complemented with some “refurbishment” budget might allow the interest processing to be disentangled from the core systems. Similarly a move to improve cash management offerings to corporate customers could allow “Group account processing” to be disentangled.

See Customer Accounting Processes in Core Banking Processes and Recent Strategies.

“Package Software”

Big banks are one of the last bastions of very large bespoke development projects (in house and outsourced) but increasingly they are being forced by experience to use packages. (By package software we mean software with fully developed data structures and business logic in the form of application code that has been implemented in other organisations.)

This is probably because package software forces difficult design decisions out into the open quickly (because the packages are never exactly what is wanted). They invariably have major challenges with the developments of interfaces to legacy systems. In practice these problems exist with purpose built (in house or outsourced) software but are usually ignored whilst the “fun” of designing/building the new functionality takes centre stage. Bespoke development requires the different areas to agree on what all the software ought to be/might be. In banks, with their very high division of labour and consequent multiplicity of project stakeholders, this agreement is very hard to achieve. The existence or otherwise of a specific function in a software package forces decisions from the multiple stakeholders on whether the function is needed more quickly because it is a more specific decision, i.e. stick with what the package offers or incur extra cost and delay to get something better.

Banking Operations Strategies: Example Scenarios

We have tried to bring together all the ideas distilled in this report in a couple of illustrative scenarios. These show how some very common banking business processes will look if the strategies discussed are fully implemented.