John Cryan’s recent assertion that Deutsche Bank staff need to think and behave like FinTech staff is quite revealing. I am not sure what the Head of the U.S. Dollar Equities desk thought about that, but she or he has probably been the beneficiary of millions of Dollars or Euros of sunk technology cost already.
The point, surely, is that it is not necessarily the U.S. Dollar desk that makes the Bank tick; it is all of the activity that goes on in the background, that keeps the Bank in business, and this includes the Network Management function. When all of those SIFIs, the Systemically Important Financial Institutions, failed their original Living Will tests on Wall Street, it was because the Banks had focussed almost exclusively on Front-Office biased workouts. In reality, it would be the Back- and Middle-Office functions that would largely be responsible for cleaning up the mess. Once the Banks worked in far greater provision for improved Management Information Systems, the U.S. Regulators looked more benignly at their Living Wills.
The plain fact is that Network Managers, indeed Vendor Managers of any and all persuasions, need access to more data, more quickly; they need the data to persist through time; and they need the data to be secure. These are the big themes we see emerging from Client meetings, conferences, press articles and blogs. Whilst the emergence of the “Developer-driven Bank” would give most Bank Boards palpitations – and is some way away, given the collision of regulatory compliance and technology – the role of the CIO has changed categorically since the Financial crisis and the emergence of much new thinking around technology.
It is legacy systems that are the root cause of much constipation for technology investment: too much “bad” or unsuccessful sunk cost in the past is off-putting for current and future investment. But the legacy is just that: such legacy systems are becoming legacy, much faster. To say that in-house builds never work is too bold; it would be fair to say that they rarely work to fill the brief fully, on time and to budget.
We have double-digit examples in just the last two years of major Financial Institutions who have been pressured into choosing in-house development but these projects have subsequently stalled and/or stopped at a frustratingly incomplete stage. The cost of in-house builds, it emerges, is actually not the most economical way of delivering functionality.
To return to John Cryan’s comments, the “Bank-as-a-Platform” concept is gaining traction as a concept. Bank staff need to come to terms with changing roles, not least at CIO level, and to start thinking about open-sourced solutions which need integration, not development; staff need to think about Service-oriented Architecture and about Software-as-a-Service which is defined, designed, developed and deployed specifically for their needs, not those of the IT Department.
Is it too early to say that the days of internalising development are over? Almost certainly ‘yes’ because the Banks’ commitment to self-sufficiency will persist for a long time to come. But Bank acquisitions of technology companies readily demonstrate the direction of travel. And if you layer in the need to keep cost off the Balance Sheet, then figuring out how to resolve this conundrum is the way forwards.
Do more with fewer staff = use technology
Since technology is moving too fast for Banks to keep up with, in many cases, the pressure to stop internalising solutions and look externally for more rapidly deployable technology continues to grow. The constant flow of new rules and regulations mean that Banks, particularly in this space, are constantly fire-fighting with tactical solutions and not stepping back and doing the important things, rather than doing the urgent things: there is a big difference between the two.
