Why isn't Banking more Boring? Part Three

In the second instalment we discussed Frederick P. Brooks' perspective on essential vs. accidental complexity. We hypothesised that we have taken the essentially straightforward problem of banking and made it hard through the accidental complexity introduced through the technology choices we have made.

But is it really that simple? Is 90% of the operating model and technology landscape really accidental complexity that doesn't need to be there? And if it is, why have we allowed it to happen?

If you look inside a typical bank today you will find

• At least one origination platform and one servicing platform for each of Mortgages, Unsecured Loans, Secured Loans, Credit Cards, Current Accounts, but more likely two or three of these for each product type
• Each product platform with its own copy of customer data and its own transaction history and financial ledger. There will also likely be some real-time or batch integration with a (single) customer view platform
• There will be multiple decisioning platforms that make account opening or lending decisions for each specific product type, i.e. separate systems for Loans (Unsecured, Secured), Credit Cards, Mortgages, Current Accounts
• Each decisioning platform will work on copies of summarised transaction data that come from across all the product platforms as well as inputs of other customer activity. This will typically be internal data but increasingly includes more and more external data (wider than credit bureaus)
• There will be distinct Risk, Finance and Treasury applications that work on copies of data taken from each of the product platforms, the decisioning platforms and the customer platform(s)
• There will be reconciliation systems to identify any differences between the multiple copies of data held by each application and match/ merge routines to validate that transactions belong to the same customer
• This will all be a mix of commercial-off-the-shelf applications and bespoke software, including integrations with third-party APIs and services, which will run on half-a-dozen operating systems (x 2 to 3 allowing for versions) that will be deployed on a dozen or more hardware platforms.

Described like this it does seem more complex than one of those simplistic diagrams a consultant will draw to illustrate how a bank architecture works. To contrast, the consultant's picture typically has six easily described pieces

• A common ledger for all transactions
• A single view of customer
• A product processor that can process any type of (financial) product and posts transactions to the common ledger
• A decisioning platform that uses the common ledger and other data sources to form predictions and make decisions
• A reporting platform that uses the common ledger and other data sources to generate management information for internal use and external reporting
• Customer interactions driven by events received and sent.

However, as simple as it might seem, these six easy pieces aren't very far from the essence of what is required. We have been describing this conceptual banking architecture for decades and it has always been relatively simple, because banking is relatively simple. The difficulties always arise when we try to realise it. But why?

Neal Ford's explanation is the most accurate I think. To paraphrase his core argument, we put a lot of square pegs in round holes. As Architects or Engineers we choose over-engineered frameworks. As CIOs or IT Executives we choose vendor solutions that promise more than we need. As Business Executives, we prefer 3rd-party services or off-the-shelf applications so we can avoid dealing with the other two groups of decision makers and get to our features (and hopefully value) quickly.

As a consequence, from what look like very reasonable choices and decisions, our perfect concepts and abstractions become bent out of shape. We take a straightforward problem and make it harder. In the end our architecture looks precisely like what it is. An assembly of bits and pieces. A collection of square pegs in round holes. If you squint and use your imagination you can just about map it back to the concept you started with, but in reality it is nothing like it.

Traffic is driving me nuts, I'm just going to start digging

Now imagine you are starting a new bank and have to design an architecture from scratch to support it. What would it look like?

I suspect most of us would revert to type and start to put square pegs in round holes. From an external perspective it certainly looks like many of the new banks - challenger or otherwise - are doing just this. If this is the case, the slightly better assembly will give some advantage in the short term but it is likely to end up in the same place in the long run. APIs may save the day, but I doubt it (more on this in Part Five). I think the Boring Company of Banking is unlikely to emerge through this route.

What's needed is a different perspective. When Musk started his latest endeavour he said, "We have no idea what we're doing - I want to be clear about that". That's the sort of perspective required. Not because those who think they are crazy enough to change the world are the ones that do. That would be strategy by inspiring quote. No, we need a clean perspective because the software architecture required to support banking is in essence very simple and it must be realised differently than in the past.

I believe The Boring Company of Banking is far more likely to come from those engineering from the ground up. The combination of micro-services, cloud runtimes and machine intelligence represent the best opportunity we have ever had to do this - to engineer a platform that achieves only the essence of what is required, rather than assemble something from a set of new or existing parts that drag complexity with them.

What will this physically look like? By definition, done well it will tend towards the simple picture described above

• Product platforms reduce to micro-services encapsulating only the essential features of each product type (or potentially specific products)
• Product-platform copies of customer data, transaction data and local financial ledgers are eliminated and become instead a highly-scaleable common ledger of data
• Decisioning platforms become machine-intelligent algorithms that run against the common ledger and make API calls for other data where required
• Reconciliation platforms and other checks-and-balances processes are eliminated, as algorithms and services are shipped to the data they need, not the other way around.

We will return to the architecture more fully in Parts Five and Six, but in Part Four we turn our attention to the other half of our problem. How do we move one bank's customers and transactions from one set of IT systems and operating model to a completely different set of IT systems and operating model?

We will examine why this has been so difficult and costly historically, and why most banks wouldn't consider doing this a strategic option even if a dramatically more cost efficient target was available to move to. We will use this insight to derive the characteristics that any new architecture should have if it is to fundamentally change our ability to tackle this problem.