How does an Investment Bank work?

This article describes at a high level how an Investment bank works from a systems and operations point of view. It is by necessity a simplification of reality but conveys the essence of the game. We break the article down into two parts.

  • The Core Trading Business Model
  • The Investment Bank Structural Overlay

The Core Trading Business Model

The diagram below illustrates the beating heart of most investment banks. They nearly all have an operation which at its simplest buys and sells things and by so doing hope to make a profit.

Sales & Trading Core Trading Business Model

For some banks the Sales and Trading is the main thing and other activities (e.g. Mergers and Acquisitions) are an add on, for others it is the other way round. They have to have a trading operation in order to be able to be credible in their main banking services. For all investment banks there is some degree of business leverage between Sales and Trading and other activities (e.g. deal flow from their other activities to feed this Sales and Trading operation).

The core Sales and Trading activities can be broken down into the areas illustrated in the diagram.

trading business model

Front Office

This area of activity in our model covers crucially quoting prices and deal entry. In practice it is often the largest area of IT expenditure as firms try to get advantage.

Examples of activity include dealing rooms, various forms of online/electronic trading, sophisticated pricing and analytic engines looking for arbitrage. Generally each front office is specific to a particular product or instrument. Most Investment banks trade a wide variety of instruments and new ones emerge all the time (for example the recent growth in credit derivatives).

The Front office “positions”; i.e. quantities of instruments that they have to sell or trade are also an important part of the front office.

Another facet of the Front Office is ensuring that there is an accurate record of the deals (e.g. phone tape records; computer systems auditing).

Back Office

Although deals are usually entered via the Front Office, often only the bare details are put in to be able to adjust the positions. Normally to get the deal fully set up and incorporated into all aspects of the bank’s systems back office staff have to check it has all been correctly entered. The “second pair of eyes” is an important control against rogue trading. Again much of the back office functionality is specific to each product

Confirmation / Settlements

In the past each Product Back Office area would send out deal confirmations and settlement (payment) instructions. As the years have gone by and more of this activity has been automated Investment Banks have tried to create Confirmations and Settlements utilities which support all the different areas. They aim to achieve high levels of STP (Straight Thru Processing) by taking messages from the product back office systems and converting them into standard SWIFT messages. Conversely they also aim to automatically reconcile incoming SWIFT messages against the back office records of deals and Settlement instructions.

Credit Risk

The different (product specific) front office areas can be dealing with a particular client or counterparty in parallel. Hence it is important that some staff and systems are monitoring the overall exposure of the Investment bank to a particular counterparty.

In the past each product area would have a limit for a particular counterparty and once the limit was reached that was it for the dealer involved. This was inflexible because there may be unused credit “capacity” in some other product area. Hence, nowadays a limit spanning all or multiple product areas is more commonly used/monitored. This presents systems challenges;

  • The maths involved in getting all the different instruments into a common “value” to be compared to an overall limit is very complex.
  • The potential losses involved change with market prices and so real time/intra day re-calculation is required.

The potential losses involved change with market prices and so real time/intra day re-calculation is required.

Credit Risk systems have been the object of major investments by banks for many years now.

Market Risk

Credit Risk is evaluating the potential impact of a counterparty defaulting on his obligations. Market risk assesses to what extent the bank is vulnerable to major movement in an economic variable (e.g. the $/£ exchange rate, the FTS100 index or the price of Brent Crude. Obviously the $/£ rate will affect the value of the position on the FX Front Office. However, it may well affect many other trading areas as well (oil traders quote all prices in $, even in a sterling based bank). Hence again market risk needs to be assessed across all product areas, and, like Credit risk the maths and real time nature of the markets means the market systems have to be pretty smart.

Accounting

The management need a “true and fair” view of the financial position. They also need it pretty darn quick (at least by Retail Banking standards. Traders and their managers expect to have a daily profit and loss statement by product and by Trader. This is important as traders and salesmen are on very high bonus structures linked to P&L.

Static Data Maintenance

In order for all these different areas to work together very quickly, deal information has to flow very fast from the top of the diagram to the bottom. This means that there has to be a high level of common understanding of static data. For example, for Credit risk to work all the different product areas have to have a common means of identifying a particular counterparty with whom they are dealing. Similarly for accounting and market risk purposes there has to be a common view of a benchmark index or rate across all product areas.

Maintenance of this common static is particularly important in controlling fraud. E.g. maintaining standard settlement instructions should be kept separate from people making deals or releasing settlement payments.

 

The Investment Bank Structural Overlay

The core trading model could exist as described in the previous section, however it is very raw and every Investment Bank finds ways of bringing its power to different communities of clients. The communities could differ by geography, by nature (individuals or institutions) or by need. Overlaying this approach to clients generates a lot of complexity; some of which is embedded in systems controls but much is incorporated into policy and procedures.investmentbankstructure

The following paragraphs cover the classes of complexity in relation to the core trading engine.

Internal Legal Structure

The core Trading Business Model looked as if it were one business. This is right. For example an equities trader will (within his limits) trade all the equities held within the Investment Bank group to maximise profit/minimise loss for the whole group. From his perspective he is not interested what legal entity within the group holds them and why. In practice, varying tax and compliance laws mean that there are many legal entities within the Investment Bank and they place all sorts of constraints on where and how positions are held and traded. This shows up particularly in complexities in the accounting areas and back office (the deals have to be carefully entered to ensure they get booked against the right legal entity combination.

Chinese Walls

A large Investment Bank will be providing different services to different classes of customer. By so doing they are in danger of facing conflicts of interest and so information about deals in one area of the bank have to be carefully hidden from other areas. For example, bankers working on an M&A deal or on an IPO have to be careful not to provide privileged information to dealers or analysts. On the other hand credit risk officers do have to see positions from both the M&A teams and the dealers to ensure the bank as a whole is not too exposed. This leads to lots of complexity in user authorities and permissions, down to individual deal or record levels.

Regulatory Compliance

Regulators generally require behaviour from investment Banks, particularly when they are dealing with individuals. This in itself would not be too onerous but most investment banks are dealing across borders and most countries have differing regulatory requirements; from things like disclosure to clients to summary data for external supervisors; the complexity rapidly mounts.

Internal Business Structure

An investment bank is in many ways a loose affiliation of lots of groups of staff in groups of a few to a few tens of staff. Overall they may employ thousands but in lots of small units. These units do quite different things; an M&A team is completely different in its activities from an FX dealing desk is completely different from an equity analyst is different again from bond book runner and so on. The bank works because the groups form an ecosystem that cooperate on deals and processes however there are not many economies of operational/IT scale (at least in comparison with retail banks with thousands of branches doing the same things). This means lots of complexity for systems and processes as they cut across the units.