Just don’t fail (Part Five)

I have spent this week looking at the systemic implications of AI, cloud and digital currencies, but there is an obvious question left hanging over all of this. If you are the CEO of a bank or fintech, what are you supposed to do about it?

The answer is not to become an expert in large language models, cloud architecture, stablecoins or tokenisation. That is why you employ experts. The CEO's job is far simpler and far more important: make sure the bank doesn't fail. The problem is that the definition of failure has changed because the bank you are running today bears little resemblance to the bank you might have been running twenty years ago.

Back then, the CEO worried primarily about credit, capital, liquidity, markets, operations and regulation. Those things still matter enormously, but today the CEO also runs an institution whose infrastructure is increasingly rented from technology companies, whose decisions are increasingly influenced or made by machines, whose customers are permanently connected and whose money is becoming globally transferable at machine speed. The biggest change is therefore not technological at all. It is managerial, because the CEO has to understand how to remain in control of an institution when more and more of the things that make that institution work sit outside their direct control.

That is why, if I were running a bank, I would stop asking for presentations about how wonderful our technology is and start asking people to show me how the bank fails. I don't want to hear that we have a multi-cloud strategy. I want somebody to prove that we can lose our primary cloud provider tomorrow morning and continue operating. I don't want to hear that our AI models have excellent governance. I want to know the damage a machine could cause if it is authorised to make decisions without human approval, and how quickly somebody can stop it. I don't want to hear that our payments platform has 99.999% availability. I want to understand what happens during the 0.001%.

That changes the conversation because banks are very good at demonstrating how things are supposed to work and far less enthusiastic about demonstrating what happens when they don't.

Every board receives reassuring dashboards filled with green lights, availability statistics, cyber reports, resilience measures and risk assessments, but the CEO should be interested in the red lights that aren't there:

What is the dependency nobody has noticed?

Which supplier cannot be replaced?

Which AI model is making decisions nobody fully understands?

Which supposedly independent backup system depends upon exactly the same underlying infrastructure as the primary system?

How quickly can customers move their money if they lose confidence in us and, increasingly, how quickly can their machines move it for them?

In fact, I would make this a regular executive exercise. Put the CFO, CRO, CIO, CTO, CISO, head of operations and head of payments in a room and tell them that something important has just failed at 8:30 on Monday morning. It doesn't particularly matter whether it is payments, the cloud, an AI model, a cyberattack, a corrupted software update or a sudden digital run on deposits because the purpose is not to predict the next crisis. The purpose is to discover how the organisation behaves when the crisis nobody predicted arrives.

I would then want to know what happens at 8:31, 8:35, 9:00 and midday. Who discovers the problem first; who decides whether it is serious; who has the authority to intervene; who shuts down an autonomous system; who talks to the regulator; who protects liquidity; who communicates with customers and who ultimately takes control?

If the answer requires several committees, a series of conference calls and somebody trying to find the chief executive on WhatsApp, then congratulations: you have just discovered a major vulnerability without losing a penny.

This is important because machine-speed banking requires machine-speed management.

You cannot build an institution in which AI makes decisions in milliseconds, money moves globally in seconds and customers react instantly, while management still operates through committees that meet every Thursday.

That doesn't mean handing control to the machines.

It means deciding long before the crisis exactly where machines have authority, where humans have authority, when human intervention becomes mandatory and who has the power to stop the whole thing when something starts behaving in a way nobody expected.

There is another question I would put on the agenda of every bank board, and it is deceptively simple: what do we actually own?

This matters because banks increasingly rent almost everything.

They rent computing power from cloud providers, software from technology companies, intelligence from AI companies and distribution from platforms. Customer interactions increasingly take place through third-party ecosystems and, as stablecoins, tokenised deposits and programmable money develop, even the movement of money itself will take place across infrastructures the bank does not necessarily control. Outsourcing these capabilities makes enormous economic sense, but outsourcing everything eventually raises the uncomfortable question of what remains of the bank.

That doesn't mean rebuilding your own data centres, writing every line of software internally or creating your own artificial intelligence model. That would simply recreate the technological mess banks have spent decades trying to escape. It means deciding which things are so fundamental to the institution that control over them cannot disappear. Maybe that is identity, customer data, liquidity, risk decisions, payments, the ledger or the customer relationship itself. I suspect the ultimate answer is trust, because that is what banking has always sold, but every CEO should be able to state clearly what the institution will outsource, what it will share and what it will never surrender.

I would also change what the board measures because most boards still measure technological success using the language of transformation. How much have we moved into the cloud? How many processes have we automated? How many AI use cases have we deployed? How much legacy technology have we retired?

Those are useful management measures, but they tell me very little about whether the institution survives when something goes wrong.

I would rather know how long the bank can operate without its primary cloud provider, how quickly it can isolate a corrupted AI model, how many critical suppliers have no viable substitute, how much money can leave the institution in ten minutes, what percentage of material decisions are now made autonomously and how long management takes to regain control when an automated system behaves unexpectedly. Most importantly, I would want to know when we last proved the answers rather than merely documented them.

In other words, I would deliberately break the bank on a regular basis. Not the real bank obviously, but a sufficiently realistic simulation that management genuinely discovers things it did not know. Switch off a cloud region, kill an API, corrupt some data, disable a payment connection, make an AI model behave irrationally, simulate a sophisticated cyberattack or create a social-media rumour that the bank is in trouble and then unleash thousands of simulated treasury agents that immediately start withdrawing deposits.

Don't give management three months' notice, a consultancy report and a beautifully choreographed crisis-management exercise.

Give them the problem and see what happens.

That is far more valuable than another strategy presentation because the nature of banking crises is changing. The Northern Rock bank run involved worried customers queueing outside branches while television cameras broadcast the panic. The next bank run will look completely different. There may be no queues, no television pictures and no warning because machines will quietly move billions of pounds while executives are still trying to understand why the liquidity dashboard has suddenly turned red. The difference is not simply technological sophistication. It is speed.

That is why I would ask every senior executive another question: what decision are you currently allowed to make in an hour that you will need to make in a minute?

AI compresses decision-making, cloud compresses deployment, digital money compresses settlement and autonomous agents compress customer behaviour. The organisation therefore has to compress management without destroying governance, and that requires deciding today who has authority tomorrow when there is no longer enough time to convene a committee.

This also changes how I would think about digital transformation. I would stop measuring how successfully we are transforming the bank and start measuring how successfully we can survive the transformation if things fail.

None of this means slowing down. Quite the opposite. Use AI aggressively, exploit the cloud, prepare for stablecoins and tokenised deposits, automate operations and build for autonomous commerce because the institutions that don't will become increasingly irrelevant. The strategic mistake is believing that adopting more technology automatically creates a better bank. Technological sophistication without control simply creates a more sophisticated way to fail.

That, ultimately, is the CEO's job. It is knowing exactly what the institution depends upon, exactly what it refuses to surrender, exactly who takes control when something fails and exactly how quickly the organisation can respond when the world suddenly starts moving faster than the humans running it.

After spending a week talking about AI risk, cloud risk, cyber risk and digital currency risk, I therefore come back to something far simpler. Stop asking whether your bank is ready for the future and start asking whether it will survive the future, and don't accept a PowerPoint presentation as the answer. Make them prove it because, at the end of the day, there is only one technology strategy that really matters for a bank CEO: just don't fail.