My first task at the first job I took in investment banking technology was to read a paper describing a new model for interest rates (Heath Jarrow Morton) and mine it for use in swaption pricing software. It was illustrative of the state of the art at the time: take some maths, create a valuation and risk model, add a GUI and something in the way of booking and portfolio management, and thus render it tradeable. The measure of the value of the maths was the range of products it enabled you to trade.

Most of us with those roles eventually moved from small software firms to large banks since they placed a high value on building in-house expertise to offer new products faster than the competition. As markets got more technical – both mathematically and technologically – several of us ended up moving out of IT to run trading books.

The dynamic driving that career trajectory ended in 2008. The cause of this is well illustrated by the fact (according to a Wall Street Journal writer interviewed on the BBC World Service) that HSBC has around 25,000 staff working in Compliance and Risk. This solidly shows the two central facts of banking technology in late 2014: (1) the agenda is dominated by regulation, and hence standardisation over innovation; (2) there’s no money left for anything else. This has swept off the table IT investments in trading most complex products, which are now variously illegal, unprofitable or unfashionable.

The trading businesses that are left can be divided into:

  1. those from which any spread has long been squeezed out, such as Futures trading;
  2. those over which a cloud of regulatory uncertainty still hangs, such as Spot FX and agency/algo trading;
  3. risky lending (Credit), which is the business regulators want the banks to remain in (and from which almost all banking crises have sprung).

The consequence for IT departments is that they can no longer afford to run deep benches of experts maintaining proprietary trading systems. A positive result of this is a broader interest in fintech investments alongside an emerging desire to re-think the process of innovation. Organisationally, it has manifested itself within banks in the tendency towards empowerment of IT Architecture functions (or “horizontals”) whose aim is to rationalise IT investments across the Product X Region matrix. Historically, these Architecture groups have struggled to gain organisational traction since they lack a natural constituency amongst the parts of the bank that cover its costs. Now, though, they are amongst the least unrealistic of the desperate measures invoked in response to the industry’s desperate times.

Naïvely, Architecture groups have the aim of identifying the best stacks of software that a bank possesses, or could easily acquire, and standardising as quickly as possible onto those. This is an obvious approach to cost rationalisation. It is operatively how most Architecture functions at the largest banks construe their task today.

While this is sensible, it misses the mark. A far more powerful goal is to re-organise a bank’s software architecture so that as much as possible can be flexibly sourced. This more sophisticated approach to Architecture treats cost reduction as an industry portfolio question. Even if each of the Tier One banks that is spending billions of dollars annually on technology moved onto its own single stack there would still be a massive amount of duplication. Furthermore, opportunities to learn and improve excellence by adopting shared solutions would be lost. To unlock the maximum benefit banks have to migrate away from the practice of developing non-shareable software and establish the habit of successfully integrating software developed elsewhere. The best stacks approach does not achieve this by design nor will it achieve it by happy accident.

Exactly where this “software developed elsewhere” might come from is the question of the moment. Some try to bypass it altogether by looking for as a Service solutions in which either the bank’s software deployment footprint (in Software as a Service) or operational footprint (in Business Process as a Service) is significantly reduced. These ostensibly have both the emotional benefit of minimising the collaboration burden and the tangible financial benefit of making the bank smaller. However, they mask but do not avoid the questions of exactly what the software does, exactly how you check and change that and exactly how it interfaces to the software that you don’t outsource. While potentially transformational in some areas, as a Service strategies don’t reduce the centrality of implementation details – and since these become one or two steps removed, the need for transparency can be even greater.

As a large bank in the quest for a flexibly sourced IT architecture, the alternative software authors of choice might well be other large banks. After all, they are the firms who are also spending the most on banking technology and have thousands of live applications. The cultural shift that is needed for such banks to enjoy constructive discussions along these lines and then transact with the speed and frequency to be mutually relevant will be well understood.

Also not to be discounted as “dark pools” of technology supply are the large trading firms. They are notable both for agility and strength of technology, and although they lack the breadth of the banks – which is how they can afford to trade – they are a potentially significant part of the ecosystem.

If these are the dark pools, the light pools are the banking software community whose assets are well advertised. Traditionally, the “software vendors” have made their goods available only in closed (binary) form. While this can work, it has historically presented problems of transparency, adaptation and “vendor lock-in” and has lacked the plasticity that large firms need to embrace software successfully as their own.

More recently firms such as Paremus, OpenGamma, uTrade and OpenFin who have evolved in the Open Source era look to provide solutions that can be adopted more organically in a complex environment. The optimal business model for realising value from such firms is not yet robustly solved.

A flexible sourcing strategy that incorporates the IP of others while simultaneously curating a distilled base of in-house software is tough to pull off. It’s what we do now; it’s the rocket science of our times.