Financialization and software

Finally, I want to look at a particular case of the obscure objects of financial mediation, in particular the interesting notion of dark pools in finance. This is a useful case study due to the close relationship between a society which is softwarized and its financialization.

One of the most innovative and softwarized industries globally is the financial services sector of the economy, including banking, financial trading, stocks, bond and government debt markets. These have become somewhat better known following high-profile crashes, such as with the ‘Flash Crash' in May 2010, and other mini crashes that appear to have been triggered by algorithmic trading. Here, I want to look at the specific instance of counter­party credit risk as a site of softwarization, particularly due to its closeness to the everyday operation of the financial system, and by definition the ‘real' economy.

Software/code can be used as an important resource for understanding and explaining many of the forces of capitalism operating today, particularly in relation to financial markets.¹¹ For example, software leaves traces through various forms of inscription and information cascades that can be analysed by scholars, from the software design documentation, to interviews with computer programmers, and even to the more dramatic examples of stock market volatility due to software errors and bugs. By careful close and distant readings of software/code, it is possible to see how particular forms of capitalism are embedded within the software/code layer to enable certain forms of market activity.

In order to fully understand these financialized practices and products, we need to develop methods to be more attentive to the software and computer code that acts as a condition of possibility for financial markets.¹² By learning how to read and decode the structures embedded within software, researchers could develop understandings of the dark arts of computer programmers and hackers and connect them more clearly to the way in which technology enables the diffusion of financialization practices.

Similarly, when understanding code there remain these difficult ‘mysteries' and we must place them in their social formation if we are to understand how code and code work is undertaken. This is a very useful way of thinking about code, and draws attention to the way in which code and the practices associated with it are constantly evolving as new technologies are developed and introduced. We no longer program computers with a soldering iron, nor with punch cards.

For example, it is surprising to know how similar the production of code is to practices of craftsmanship, such as carpentry. First the programmer starts with rough broad strokes to outline the general program ends, and then narrow it down through iterative processes of development to a more precise mechanism. Indeed, the programming environments are built to give the programmer the feedback on how the code is doing - something that is rather surprising to outsiders to programming who often view it in idealistic or unrealistic terms. Although programming is a lot more sophisticated too - in the visual programming environments it is becoming more like graphic design than the geeky ‘programming' we often see in movies. As with carpentry, code is modular, programmers build it from bits (modules, snippets, fragments, classes, objects), each of which the programmer writes and tests separately, rather like the way a table is assembled from the different parts that make it up: top, legs, brackets, feet and so forth. Indeed, code is amply structured for the division of labour and the capitalist process of accumulation.

Code/software is the ‘doing of processing', which we can only understand by actually reading the code itself and watching how it operates, its Computationality - this mostly we do at the level of the codal. It is interesting that after financialization came under attack following the credit crunch of 2008-10, digital technologies continue to be offered as a panacea - we could think of this as a computational economic imaginary. This certainly reveals the finance industry's commitment to a form of technological determinism or perhaps computational ideology. In other words, that technology can solve the problem of financial instability itself, but also a belief by traders and companies that the crash was caused, to some extent, by a lack of technology rather than a surfeit. Indeed, management, ‘quants' and technical staff have continued to develop computational systems where statistical analysis and high-technology solutions can be leveraged to manage, if not mitigate counter­party risk, however misplaced that belief might be. For example, software which renders the display of a financial risk portfolio information in a very stylized, simplified form, often with colour codings and increasingly with rich graphics.¹³ It is also increasingly clear that not only do few market participants fully understand risk as a statistical category, but also the familiar bell-shaped curve of Gaussian distributions displayed on mobile screens encourages a kind of ‘domesticated' approach to risk that makes it appear familiarized and benign (see Langley 2008).

Here, following the credit crisis of 2008, which resulted in failures of relatively high-profile firms (Jorion and Zhang 2009), much more attention has been focused on counter-party risk and how it might be mitigated by a computational turn. With the collapse of Lehman Brothers between the 10th and 15th September 2008 following a reported $4 billion loss and unsuccessful negotiation to find a buyer, and with one of Wall Street's most prestigious firms filing for bankruptcy protection (Stampoulis 2010), concerns about counter­party risk were heightened still further.

What is your real-time exposure at any point in time?That's the question that regulators will be asking,” says Alan Grody, president of the New York-based risk advisory firm Financial InterGroup... The answers, especially urgent in light of the counterparty-risk deficiencies exposed by the 2008 collapse of Lehman Brothers, will require new and improved capabilities that bring about some form of real-time risk management. (Heires 2009: 35)

Counter-party credit risk has now emerged as a key issue for banks and other lenders, particularly following the losses associated with the high- profile failures of monoline insurers and investment banks. Many now argue that no counterparty can ever be considered immune to financial instability (including sovereign counterparties) (Gregory 2009a, b). The traditional approach of controlling counter-party credit risk has been to set limits against future risk exposures and to verify new trades against defined limits. For example, requiring a certain proportion of collateral to be ‘posted' or else using an external measure of the credit-worthiness of the counterparty.

Increasingly, however, banks are moving towards dynamically pricing, in real time, the calculated counter-party credit risk directly into new trades. Credit Value Adjustment (CVA) uses computational processes to quickly determine an institution's credit risk at any moment (Algorithmics 2009; Beck n.d.). This ‘real-time stream' of data is not just an empirical object; it also serves as a technological imaginary and enables new financial services, which produce and govern markets through a particular temporal order. For example, financial markets are undergoing an intensification of fast-moving data streams that measure time in microseconds, as such the moment under which a decision is taken whether to trade or not is getting shorter (Berry 2011a). For example, in the ‘flash crash' on 6 May 2010, $500 billion dollars worth of value was momentarily erased from the market by high-frequency trading and the Dow plunged nearly 1,000 points in just a few minutes, a 9.2 per cent drop, half a trillion dollars worth of value was erased from the market and then miraculously returned again 20 minutes later (HTCWire 2010).

Financial companies are rolling out new technologies all the time to give them an edge in the marketplace, such as ‘dark pools' (also called ‘dark liquidity'), which are off-market trade matching systems working on crossing networks which give the trader opaqueness in trading activities, such as when trying to sell large tranches of shares (Bogoslaw 2007). Dark pools are ‘a private or alternative trading system that allows participants to transact without displaying quotes publicly. Orders are anonymously matched and not reported to any entity, even the regulators' (Shunmugam 2010). Dark pools are markets that by definition represent computal opaqueness in such a way as to facilitate a financial transaction whereby parties are matched within a non-transparent mode of off-exchange transaction (obfuscated markets). Dark pools are computationally created and algorithmically sustained opaque markets designed to be anonymous spaces for trading and financial flows.

These real-time data streams are created, managed, distributed and stabilized through the use of software/code, particularly software platforms that are custom built on low-latency hardware in order to enable rapid trading. In June 2010, Risk Professionals (from the Banking sector) reported that 50 per cent of their institutions calculated CVA monthly, 25 per cent daily and 25 per cent in real time (Stampoulis 2010). However, ‘for many financial firms, achieving an institution-wide, real-time view of risk and profit-and-loss is the Holy Grail of risk management' (Heires 2009: 34).

This is the ‘softwarization' of the problem of counter-party credit risk and forms the basis of the algorithms that finally generate visualized interface and reports. Indeed, it is very unlikely that either the traders or management have an active involvement in the software/code used and are unlikely to problematize the seeming 'objectivity' of the results it generates.This is where the computer as 'truth machine' becomes a highly trusted device for analyzing risk. Of course, widely shared algorithms of CVA equations also demonstrate a form of softwarized monoculture, whereby financial organizations are using very similar, if not almost identical algorithms for calculating their credit default exposure (see Zhu and Pykhtin 2007), although admittedly implemented in different programming languages. Even where the organization buys off-the- shelf credit counter-party risk analysis software, such as Murex, Kondor or Calypso, internally there are similar mathematized standardized algorithms and equations implemented from a small number of vendors. One wonders if the seeds of the next crisis in finance are already being laid in the code and software that lies hidden underneath these systems.

Here, we see the movement or translation between the temporal generation of the discrete elements of the stream and the computational storage through what Kittler calls time axis manipulation. This is the storing of time as space, and allows the linear flow to be recorded and then reordered, in this case financial data held as time-series data. The shifting of chronological time to the spatial means that things can be replayed and even reversed. This is the discretization of the continuous flow of time. For example, without it the complexity of financial markets would be impossible and the functions and methods applied to it, through for example the creation of new abstract classes of investment such as credit default swaps, collateralized debt obligations and asset backed securities, would be extremely difficult, if not impossible to create and trade. However, we must not lose sight of the materiality of computation which is nonetheless inscribed within a substrate on the physical, logical and codal layers.

Here, in risk calculation, computation is being applied to all counterparties of a financial trade by way of counter-party risk algorithms. This software/code attempts to quantify the likelihood of default, not only for corporations but also for sovereign nations, who were previously thought to be of only marginal risk as counterparties. Even more interesting is the development in using self-analysis, whereby in a curious process of introspection, the company performing counter-party risk analysis includes its own credit default likelihood in its own equations as a possible credit counter-party risk, so-called bilateral counter-party risk credit valuation adjustments.

In this more encompassing vision, a firm would obtain a real-time view of its risk exposures on a cross-asset, cross-trader and institution-wide basis, combined with profit and loss, coupled with the computerized ability to swiftly identify events that might introduce risk, instantly analyse those events against a variety of risk models and, if necessary, take appropriate risk-mitigating actions - all in the blink of an eye (Heires 2009: 34). The reliance on these systems to perform such mission-critical real-time decision analysis brings to the fore the problem of the great trust we are placing in these systems. It also shows how many of these systems that rely on ‘finding alpha', that is ‘the skill required to choose individual assets that will outperform the market', or ‘beta', where it is the ‘return achieved from exposure to the overall market, for example, via an index fund' or even the newer notion of ‘smart beta' that uses quants and algorithms to beat traditional beta returns, are increasingly reliant on these software systems (Economist 2013).

There is no doubt at all that software is a hugely important global industry, and that software is critical to the functioning of financial companies, governments and non-governmental institutions (Berry 2008). In the case of financial markets, software has completely changed the nature of stock and commodity trading, creating 24/7 markets and enabling the creation of complex derivative products and services. Perhaps not surprisingly, sharp-eyed firms have also realized that credit counter-party risk is itself hedgeable, and consequently have begun to trade counter-party exposure itself as a category of financial instrument (Canabarro and Duffie 2004: 133). That is that risk itself as a computable function becomes subject to capitalist valorization.

More work is needed in this area to understand the ways software/code instantiates softwarized finance and particular computational imaginaries linked to finance capital. Equally important is the task of mapping and tracing the use of the computal in practice. Here, real-time credit counter-party risk and real-time data streams are a useful example of how algorithms tend to be delegated trust, and used to construct ‘truth-machines' in finance and other areas of everyday life.¹⁴ Indeed, more work is needed to critically explore the way in which software/code serves as the condition of possibility for stabilizing ‘truth', risk, credit and financialized society more generally.

88