With that we have come to the end of our discussion on trade lifecycle. We talked about pre-trade activities such as the quant work on pricing model, and its validation by an independent team. On a per-trade basis, we have the sales and credit check activities. Once a trade is initiated, it goes through the initial validation work by Middle Office, followed by regular processing by a large number of teams, such as Market Risk Management for limits monitoring and reporting, Product Control for valuation checks and reserve calculations, and trading desks for hedge rebalancing and risk management. During the termination phase of the life of a trade, it is the back office teams that are active in settlements and reporting.

As we saw, most of the activities, especially during the inception and up to the termination of a trade, the trading platform plays a crucial role in mediating the processes and conveying the trade from one business unit to the next. But these different business units work with their own entrenched work paradigms, and their perspective on what a trade is or what their work involves can be radically different from one another. Since the trading platform cuts across multiple teams, it has to cater to these differing perspectives, which is the last section of this series starting the next post.

The last lifecycle event of a trade is, of course, its termination. It can be triggered for a variety of reasons. Whatever the reason may be, when a trade is terminated, it calls for settlements and documentation archival by Back Office. In addition, it may trigger public disclosures (in an aggregate form) by Finance, and incentive adjustments by Human Resources.

The common reasons for trade termination and the workflow it triggers are depicted in the figure below.

• Trade Maturity: When a trade or an option reaches maturity, it gets terminated, which is the most uneventful mode of trade termination.
• Option Exercises: If the bank or its counterparty exercises an option, it gets terminated. Exercises can take place any time during the lifetime of a trade, or only on specific dates, depending on the termsheet description of the product involved.
• Barrier Breaches: Barrier options (or knock-in and knock-out options) may breach the pre-defined barriers and may get terminated generating settlements or new trades.
• Target Triggers: Instruments that accumulate toward a target (such as range accruals or target redemption forwards) may get terminated when the target is reached.
• Trade Novation: Novation is the special process by which the trade counterparty changes. In effect, the original counterparty sells the the trade or the option to another one. When a novation happens, the original trade is terminated and a new one initiated with special characteristics.

Once a trade is booked into the trading platform database, it triggers a whole chorus of validation and daily processing. The validation process is a to-and-fro dance between the trading desks in Front Office and the control units in Middle Office, all mediated by the trading platform. The traders may insert a trade on an experimental basis. Once they are convinced that it is a viable trade, they push it to a confirmed state, which will be picked up by the treasury control unit. If the traders decide to discard the trade, the trade ends up in the trash pile (but never deleted permanently). The control unit typically works in a four-eye, double validation mode. They verify the trade inputs, and control limits such as the number of trades allowed for a particular product. If the trade passes their tests, they set its status to a validated state, which triggers a second level of checking. If the trade fails either level, they are pushed back into a state that allows the traders to either amend it or discard it.

Once the trade is fully validated, the processing part begins. It involves multiple teams and multiple perspectives, starting from how a trade should be identified to what the basic information unit that should be identified.

As shown in the figure above, regular processing takes place in various business units.

• Trading Desks monitor trades for hedging and rebalancing, monitoring profit and loss (P/L), and staying within the risk limits. The senior traders get distilled information from the junior ones through this regular processing and take appropriate actions.
• Middle Office plays a crucial role in regular process. They monitor target and barrier breaches, rate fixings and option exercises, cash flow generation, and spawning other cash trades. They generate (with the help of the trading platform) appropriate accounting triggers for Back Office to act on, in order to perform settlements, trade confirmation, documentation archival etc.
• Product Control is another business unit embedded within the middle office that actively monitor the P/L on a daily basis, with a view to explaining their movements based on the sensitivities and market movements, providing an independent computation of the profitability of the trading activity. Their computations of reserves feed into the finance and human resources departments and affect trader incentives and compensation.
• Market Risk Management also has hordes of staff employed to perform daily monitoring of trading limits (such as notionals, delta-equivalents etc.) as well as VaR computation, Stress VaR tests. In most banks, they also handle compliance reporting to regulatory authorities and provide concise and actionable intelligence to the upper management who decide the trading strategies.

As we shall soon see, the different and specific focus of each business unit demands a unique projection (which we will call a perspective) of the trading information from the trading platform. This requirement is one of the things that make its design and implementation so challenging.

The inception events of a trade can be classified into two categories. The pre-trade activities are those that have to take place even before the first trade is booked. The per-trade inception activities are the ones specific to each trade.

The pre-trade activities are related to new product on-boarding and approval. As we saw, in-house trading platforms are designed to be nimble and responsive. In principle, it should take little time for a new product to be on-boarded. The last system I worked on, for instance, was designed to deploy a new product idea in a matter of minutes. But the architects of such systems tend to forget the human, process-related and control elements involved in it. As the slide above illustrates, a new product idea or a new pricing model originates from the work of a model quant or a structurer in Front Office. But before it gets anywhere near a production system, the pricing model needs to be validated, typically by the analytics team in the Middle Office risk management group. Once validated, the product goes through a tortuous approval process that may take weeks or months, and then a formal deployment process, which may again take weeks or months. When that process is completed, the product is available for trading in the trading platform.

Once available, the product can be instantiated as a trade. Each trade instance goes through its own validation and approval process. The trade request may originate from the sales or structuring team in Front Office. They will also prepare the term sheet and other legal documents. Once these tasks are completed, a trade is booked into the trading platform.

These inception events are depicted in the second slide above. One of the crucial steps in the approval process is the credit control. As we described earlier, the credit risk management team uses a variety of tools to assess the risks involved. With their approval, and with the traders understanding of the market price of the product, a product available in the trading platform becomes a trade in the database. And the lifecycling fun begins.

With the last post, we have reached the end of the second section on the static structure of the bank involved in trading activities. But a trade by itself is a dynamic entity. In this third section, we will look at the evolution of a trade, and see how it flows back and forth between the various business units we described in the last section. We will make the this section and the next into a new series of posts because the first series (on How Does a Bank Work?) has become a bit too long.

As with most dynamic entities, trades also have the three lifecycle stages of inception, existence and termination. What we need to understand clearly is what the processes are around these general stages. What are the business units involved at each of these stages? What do they do? And how do they do it?

We will see that from our perspective, the lifecycle interactions are all mediated by the trading platform. It is not so much because everything is contained within the trading platform, but because we are interested only in that limited set of processes that are. In some sense, the last section was about the physical, spatial description of the bank, and this section is going to be on the temporal evolution and dynamics of how things work on that structure.

We have now completed our discussion on the general structure of a typical investment bank trading arm. We went through the Front-Middle-Back Office divisions and the functional and business units contained within. Note that we looked only at those units that have a bearing on trading and quantitative development activities. Note also that this structure is fluid and may be implemented with different names and hierarchies in different banks depending on their corporate strategies and focus. We presented the trading platform as the enabler or backdrop of most of these activities of the global treasury (where exotics trading activities take place) and the associated business units (that handle various aspects of the trade workflow) mainly because we are looking at the whole thing from the quantitative development perspective.

From this perspective, you see the trading platform as the most important tool (or collection of tools) in the bank. It mediates almost all the interactions among the various business units. Furthermore, as we shall see in future posts, the trading platform defines the trade workflow and lifecycle management. Therefore, it will also become important for the quantitative developers to understand how these business units view trades and the trade booking and management process. Their trade perspectives will have to influence the design of the trading platform.

From the quant and quantitative development perspective, Back Office is a distant entity. Their role is vital in the trade lifecycle, as we shall see later, but they are outside the sphere of influence of the quants and developers.

Back Office concerns itself mainly with trade settlements and accounting. Upon maturity, each trade generates a settlement trigger usually with the help of a vended trading or settlement platform, which will be picked up and acted upon by the Back Office professionals. They also take care of cash and collateral management.

Finance functions are closely related to Back Office operations. Among a host of accounting related operations, they have one critically important task, which is to produce annual reports. These reports get publicly scrutinized and determine everything from the stock price to performance bonuses, salary levels etc. Finance professionals may require quant and analytic help for certain tasks. In one of my previous roles, I was asked to estimate the fair market value of the employee stock options (ESOP) for the purpose of accounting for them in the annual reports.

The process of pricing ESOP is similar to (although a bit more complicated than) normal call option pricing. Among other things, you need the volatility of the underlying stock in order to calculate the price. I used the standard exponentially weighted moving average method to estimate it from the published stock prices over the previous two years or so to compute it because that was all the data I had access to. Before that time, there was some corporate action and stock ticker name had changed (or did not exist, I don’t remember which). In any case, I knew that the impact of adding more data prior to that date would be negligible because of the exponentially diminishing weights; it would be much less that the round off error in quoting the price to four decimal places, for instance. But the accountant who was asked to look at the computation was upset. She came to me with her rulebook and referred me to page 57, paragraph 2, where it was specified that I was supposed to use ten years for the EWMA computation. I tried, in vain, to explain to her that I couldn’t. She kept saying, “Yeah, but page 57, para 2….” I went on to explain why it didn’t really make any difference. She said, “Yeah, but page 57, para 2….”

Accountants and Finance professionals can be that way. They can be a bit “technical” about such things. In hindsight, I guess I was being naive. I could have just used a series of zeros to back-populate the missing eight years of data (after all, if the ticker price was not quoted, it is zero), and redone my ESOP valuation, which would have given an ESOP price identical to what I computed earlier, but this time satisfying both Finance and the quants.

A team which quantitative developers work closely with is Information Technology. They are charged with the IT infrastructure, security, networking, procurement, licensing and everything else related to computing. In fact, quantitative development is, as I portrayed it earlier, a middle layer between IT and pure mathematical work. So it is possible for quantitative developers to find themselves under the IT hierarchy, although it doesn’t work to their advantage. Information Technology is a cost center, as are all other Middle and Back Office functions, while Front Office units connected to trading are profit centers. Profit generators get compensated far better than others, and it is better to be associated with them than IT.

If you play in the market, you run the risk that it may move against you. This risk is, of course, market risk and we have a Middle Office team to manage it. Market Risk Management (MRM) ensures that the risk limits on the volumes and types of products traded are set in accordance with the risk appetite prescribed by the senior management. It also ensures, through regular processing and monitoring, that these limits are adhered to.

What is monitored are risk measures such as the Greeks and Value at Risk (VaR). The Greeks are the first and second order derivatives of the price of a security with respect to various market variables such as the price of the underlying, interest rates, volatility as well as trade specific entities like the time to maturity. The VaR is a statistical end point measure estimating the amount of loss at a given confidence level in the case of an adverse market movements, and is typically computed using the historical market movements over the past year or so. These risk measures are aggregated, sliced and diced in various ways to make it easy to monitor them, and reported to senior management, risk control committees, trading desks etc. The MRM team is also responsible for reporting to regulatory agencies, both in the form of regular compliance reports as well as ad hoc reports in response to drastic market moves.

Quants can find opportunities in the Analytics team embedded within MRM. This team is in charge of pricing model validation, which is the process of ensuring that the mathematical models deployed in trading systems and other valuations engines are both appropriate and correctly implemented. There is a significant overlap between the work that MRM analytics quants do and their Front Office counter parts (whom we called pricing or model quants). The Analytics team also takes care of any other quantitative tools needed in MRM or risk management in general. Such tools could include potential future exposures (PFE) for credit risk management, liquidity modelling for Assets and Liability (AML) etc.

Risk management is a critical function of Middle Office. Credit risk is the risk that somebody who owes you money may not be able or willing to honor their obligation. In other words, they may default on their credit obligation. This risk is managed in a bank using a variety of statistical tools.

When a bank issues you a credit card, it takes on credit risk that you may not pay up. You pay an insanely high interest rate on your outstanding balance precisely because of this credit risk. The risk is not secured. A mortgage or an auto loan, on the other hand, is secured by the equity of your property, and you pay a significantly lower interest because of the collateral.

The Middle Office team of Credit Risk Management (CRM) operates using the same two paradigms. Much the same way as you have a credit limit on your credit card or line of credit, each counterparty that the bank trades with has a certain credit limit based on their credit rating as published by credit rating agencies such as Moody’s or Standard & Poor. The problem with this mode of managing credit risk is that the bank has no way of knowing how much credit is loaded against a counterparty’s rating in other banks. Nor does it have a means of finding out how many credit cards you have. In Singapore, the regulatory authority, MAS, tries to minimize the risk of people going bust be requiring that their credit limit be twice their monthly salary. Bt they may get as many credit cards as they want from different banks against the same limit, effectively nullifying the good intention behind the requirement.

This overloading against credit rating is avoided when the risk is managed using collaterals. Much like you cannot take two mortgage loans on the same property (not without adequate equity, any way), counterparties in trading also cannot use the same collateral for multiple trades. Banks and counterparties typically use bonds as collaterals and physically exchange them during secured transactions.

Before the Front Office trader can enter into a trading agreement with a counterparty, they will need to get approval from the credit controllers who will assess exposures and check them against predefined limits. The exposure assessment uses techniques such as potential future exposure (PFE) based on a large number of simulations of potential future markets.

In addition to the risk of counterparties defaulting during the life time of a trade, CRM professionals worry about the potential for default during the delay in settlement — after the maturity of a trade (where the bank is in the money) and its settlement. This risk is aptly called the settlement risk.