Of the 76 recommendations coming out of the Royal Commission into misconduct in the financial services industry, recommendation 1.17 about BEAR product responsibility particularly piqued my interest. That recommendation was:
“After appropriate consultation, APRA should determine for the purposes of section 37BA(2)(b) of the Banking Act, a responsibility, within each ADI subject to the BEAR, for all steps in the design, delivery and maintenance of all products offered to customers by the ADI and any necessary remediation of customers in respect of any of those products.”
Referring to the cause of administrative and processing errors, Commissioner Hayne singled out two factors he believed to be industry wide issues worthy of specific mention:
- the number and complexity of products
- the absence of “end-to-end” accountability.
Intuitively, both have a part to play, but digging a little deeper into these factors can lead to surprising results.
Large, mature financial services organisations have many products within their portfolios. Even if each were individually simple, managing so many would be challenging. Radically reducing the number of products makes sense, particularly if the 80:20 theory applies, with the lion’s share of revenue coming from relatively few products. Of course, simplification without legacy issues may require assistance from regulators.
However, the number of products may not be the primary driver of complexity. In the retail context, most products (except for sweeps and offsets for example) tend to be relatively simple. What drives the complexity are the decisions that have been made in isolation, over time, to enhance existing products, introduce new ones in a turbulent environment rife with discontinuities. Without an overall design intent, process framework or architecture to guide them, this sequencing of decisions can have a compounding effect, inexorably leading to the tangled web of processes so prevalent in many institutions today. For example:
- Product and channel primacy preclude process thinking – many elements of a product are designed and built from scratch even though the same elements are used by many other products within the portfolio e.g. verification, account opening, signature capture, statement generation.
- Siloed goals and incentives – teams prioritise achieving their own goals even though a better outcome for the organisation may be to wait for another project that’s building 80% of what they need.
- Business model changes – new markets, new geographies, M&A activity, divestments etc. are rarely integrated fully.
- Revolving door – constant restructuring of operating models and portfolios impedes prioritisation and continuity. New ideas and new thinking are essential but need to be given time to bed down.
- The quest for ‘quick wins’ – which results in the harder bits being left behind and resolved through manual workarounds and partial solutions.
- Inadequate funding – “we’ll get to it in phase 2”, a phase that never eventuates and hollowing out of systems rather than decommissioning add to the corporate clutter.
- Inconsistent regulatory impost – different states requiring different treatment.
- Misguided thinking that re-use of existing systems (that don’t talk to each other, hence bequeathing manual workarounds) will save money.
A word of caution for those looking for Agile solutions to this complexity: minimal documentation and a “fail-fast” mentality ironically may mean that the real cost of failure is not known for many months or years. In addition, squad missions that inherently overlap, but are operated in a different silo, will more than likely exacerbate the situation.
The consequence of this environment is process proliferation. It’s this that drives the complexity.
Accountability can be a strange beast in financial services. As the saying goes ‘Success has many fathers.’ If there’s a chance to build an empire or acquire investment funding, many volunteers put their hand up to own a process. When the process fails and the responsible parties are asked to step forward, it is unsurprising that the same people would choose to take two steps back.
The Report notes:
“There should be one person in the bank responsible for those tasks in respect of all the bank’s products.”
The Report also suggests that this individual should be responsible for the design, delivery, maintenance and, if relevant, remediation. Breaking “delivery” into product marketing, selling, fulfilling and servicing probably makes it a little clearer in terms of setting boundaries. I suspect that on its own this is not a job for the faint hearted.
Two questions come to mind: is there a need for single-point accountability and what does accountability mean?
In terms of single-point accountability, having ‘one throat to choke’ may be convenient but is probably ineffective unless the individual is the CEO. Just as it takes a village to raise a child, many of the services delivered by a bank requires the skills, expertise and commitment of people across the organisation. Any one of them can make a mistake that can have negative consequences for one or many customers.
Financial institutions have probably tried every conceivable combination, looking for the ‘Goldilocks’ structure. Aligning by segment, by product, by geography are all sub-optimal. The problem won’t be solved by structure, but by thinking, behaving and working differently.
Today an IT systems failure may be viewed as the CIO’s fault, but the CIO might point to upgrades that were requested but not funded. The business may say that the request for funding was submitted but it wasn’t prioritised at the investment forum. The CFO replies that, with only so much money to go around, this initiative wasn’t deemed to be a priority. The CRO may consider that more money should have been invested only to be countered by the CEO claiming that this would have led to missing return objectives set by the Board. Who’s accountable – the CIO, the business owner, the CFO, the investment committee, the CRO, the CEO or the Board (for not recognising the risk they were exposing shareholders to)?
The answer is either: a) all of the above; or b) it depends.
Food for Thought
The underlying intent of the recommendation is to lift quality and reduce the incidence of administrative and processing errors. To this we need to take a process perspective. Processes are the foundation of everything we do. They are the building blocks of work that deliver the products and services customers need. Addressing a poor-quality process would typically involve answering the following questions:
- Who are our customers?
- What services do we provide to these customers?
- What processes are required to deliver these services?
- Who is responsible for designing these processes?
- Who is responsible for running these processes?
- Is there a standard way of running these processes?
- Is it written down?
- What are the outputs from the processes?
- Who funds the resources to run the processes?
- How is process performance measured and monitored?
- Who specifies what ‘good’ looks like for these outputs?
- What can go wrong with these processes?
- Who accepts the risk and the consequences when it does go wrong?
- How capable is the process to deliver these outputs?
- Who can change these processes?
- Who prioritises the change?
- Who funds any changes?
This is where BEAR really comes in. The Report has reinforced the need for BEAR and recommends that its application is extended beyond ADIs to the wider industry. But there is no mention of process. If you want accountability, it must be set at a process level. It would be surprising if many senior executives knew how many processes they are accountable for today. The errors that are generated are the output of processes that are used day-in, day-out. Operational risk doesn’t happen at a high-level in a framework, it happens in the process detail. For an Accountable Person to be accountable, they must be able to answer the questions above.
The only issue with this approach is noted earlier. Process proliferation and underlying fragmentation today means there are tens, if not hundreds, of thousands of processes. Good governance requires all of these variants to be documented, operationalised, learned, resourced, risk assessed, control tested, audited etc. The cost of poor quality is exorbitant.
To address this requires a radical culling of the product portfolio, which in turn necessitates thinking differently about product. A touch of Marie Kondo magic will no doubt reveal that very few, if any, of the products will spark joy. A root and branch decluttering and tidy up is a good place to start. The beauty of financial services is that there are only two products: money and the movement of money (or for the traditionalists there are three – loans, deposits and payments.) All the other bits and bobs that are clustered and packaged together today are just attributes: the type of applicant, loan or deposit, term or at call, secured or unsecured, if secured what type of security, CR or DR transaction. These are all attributes which when you bring them together in a specific way enable a financial institution to understand the risk profile and hence price the product.
I’d be amazed if there isn’t some blockchain application that emulates all of a bank’s products on a single distributed ledger. If you think about products in this way, you can then modularise them e.g. create re-usable building blocks with a set number of parameters for each – there are only so many applicant types: individual, joint, family trust, tenants in common, corporate etc. This way a customer’s needs can be met by a standard set of attributes and a finite menu of options. Manufacturers figured this out over thirty years ago in the era of mass customisation. Every car that rolls off the production line is different but there are a fixed number of options. Ask for a 3.25l, 7-speed, hot pink, right hand-drive, 6-seater, with lime green plush velour interior and it won’t be available, not just for reasons of good taste.
Moving to a concept of two products is probably a leap too far for most institutions. Reducing to 6 to 8 product families e.g. transaction accounts, secured loans, unsecured loans, term deposits, payments etc. and then modularising from this point is eminently achievable.
Starting again is clearly one option. In the meantime, the alternative is to dramatically rationalise the number of products, consolidate the residual process variants, then start standardising and simplifying, nominating an Accountable Person armed with the right questions for each or all product families along the way.
With an added benefit: it will simplify your digital transformation!