They really don’t have a choice here. And yet, in this “everything is customizable and personalize-able” world in which we now live, we have grown to expect that there is always an infinite spectrum of choices available. Not so much when it comes to banks’ spending on technical infrastructure.
It turns out that internally-developed software costs (which we believe includes both proprietary and consultant-developed software) are the fastest growing component of our technology total cost of ownership (TCO) framework, which includes hardware, software, data and human capital. Of the 50+ large global banks that we have modeled so far, most of them throw off a similar picture as the one in the sample exhibit below of a large APAC bank. Here the accumulated net carry value of software is being driven almost exclusively by spending on internally-generated software – and far outstripping the growth in spending on computer hardware / equipment.
Furthermore, it doesn’t matter if the bank is in the Americas, Europe, Asia or anywhere in between. Most of the world’s largest banks – and we believe, these are those that are mired in the crucible of satisfying unprecedented and transformational regulatory mandates – are in a similar position vis a vis their software solution capabilities. Simply stated, there is no off-the-shelf solution available to satisfy the evolving global regs. Of course, this is almost by default. How could there be solutions – as in, enterprise-grade solutions – for regulations that have just been recently inked? And in many cases – such as that of MiFID II in Europe – those regulations are still (more than 5 years since the GFC) in the process of being vetted and codified.
Moreover, we have concluded that if the bank is not demonstrating this “shape” in spending, then it is a strong indication of a distinctly separate narrative altogether. Banks that DO NOT exhibit this pattern are either in decline OR not part of the global final regulatory juggernaut (which is the primary catalyst for these software spending increases). A sweeping statement for sure, particularly since the standards of reporting technology expenses (and technology related asset values) are non-existent.
All that said, we have determined that satisfying regulatory mandates via custom software development has a significant budgetary “crowding out” effect. This knock-on effect is impacting the rate of adoption of new IaaS (Infrastructure-as-a-Service) offerings. This is where the technology paradox between banks’ spending on software vs. hardware come in – and why there really is no choice on technical infrastructure going forward.
The picture below from a noted custodian banks provides the critical evidence. It shows that capital expenditures (“capex”) on software not only dramatically exceed that of the other primary categories (namely, computer hardware, building and leasehold improvements, and furnishings) but the allocation to software development has been increasing consistently since the GFC. In this example, the proportion of annual capex has grown at a 7-year CAGR of 10.4% (since 2007) representing an aggregate increase of over 22% of total capex to 80%. Going a step further, we would argue that this dramatic shift in capex allocation has “crowded out” investments in other common property, plant and equipment categories, most notably technical infrastructure. Again, in this example, capex for computer hardware has declined at a 7-year CAGR of -1.8% representing an aggregate decline of nearly 50% to 10.3% at the end of 2014.
In order to make “room” in the budget for software development to satisfy new global regulations something else is going to have to give. We think this comes at the expense of new investments in technical infrastructure that are now being moved from capex to operating expenses (“opex”) – and which fuel a new trajectory in adoption of IaaS offerings.
There is one other option, however. Increasing software development needs can be met by raiding the budgets of computer hardware investments by simply stretching the lives of legacy installations. Certainly, some players are making this choice today. But the problem with this, of course, is that extending legacy capabilities is really only a temporary (and risky) solution. In the final analysis, banks really have no choice on their technical infrastructure strategy going forward.
