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.

The structure of Middle Office in a typical bank is depicted in the slide below. The functional units within Middle Office work hand in hand with those in Front Office to handle the inception approvals and regular processing of trades.

Middle Office is different from Front OFfice in that it has little interaction with the external world. Its primary (and perhaps only) customers are the Front Office traders and teams. As usual, most of the interactions among the teams within Middle Office and Front Office take place via the trading platform, which acts like the boundary interface between the two Offices, as shown in the slide.

In later posts, we will go through the functions of each of the business units described as a box in the picture. For now, as a general summary, we can see that the Middle Office functions are of two kinds: those related to trade approvals based on projected risks and limits, and those related to regular trade monitoring. But these functions are vast in their scope, and require large systems, data flows and an army of professionals to carry them out. They are organized under the business units with names like Product Control, Trade Control (or Treasury or Business Control) Unit, Market, Credit and Operational Risk Management), Limits Monitoring, Rates Management, Compliance and Regulatory Reporting, Analytics, Asset and Liability Management etc. Again, keep in mind that this description of Middle Office is from the perspective of quantitative development relevant to structured products trading.

If Quantitative Developers look like the heart of everything that goes on in the Front Office (according to the following slide, that is), there is a good reason for it. This series is written from the perspective of Quantitative Development. After all, the series, the talk, and the book are all titled “Principles of Quantitative Development.” From that vantage point, sure, we are at the center of the universe.

To be fair, in structured products trading, quantitative development and quantitative mathematics play a crucial role. As we will see in later posts, almost all the aspects of trade lifecycle management are mediated by the end product of these quantitative professionals, which is the trading platform. Crucially, the trading platform defines the interface between Front Office and Middle Office. Within Front Office, quantitative developers act as the conduit of integrating the pricing models developed by quants into the platform, thereby making them accessible for profit making by trading desks. Because of this buffering role that the quantitative developers play, they have to field almost all of the support requests from trading desks and sales personnel in Front Office, as well as from anyone who uses the trading platform.

In the corporate organization, quantitative developers may find themselves under the information technology department, supporting the trading platform from afar. From a career perspective, this organization is less than ideal for them because IT is a cost center, not a profit generator and the compensation and remuneration schemes reflect that fact. Besides, IT tends to be considered as being outside the core business of the bank. Far better for them would be to find themselves embedded within the Front Office setting, where the quantitative developers can offer direct support to the stakeholders from within and enjoy the prominence and prestige that comes with the critical role of managing the vital in-house trading platform.

At the heart of Front Office are the trading desks. In terms of prestige and power, they really are the reason for the whole infrastructure of Front Office, including economists, sales, structuring, quants, quantitative developers etc. After all, they make the profits. And consequently, the vocal and volatile traders hold enormous sway. At their beck and call, quantitative developers provide instant service on trading platform issues; quants develop pricing models based on their requirements.

Trading desks interact with the external world of brokers and counterparties. They take their input on market moves from highly responsive market data providers and base their positional views on staff economists. They have an army of trading assistants (junior traders themselves) who help them book and monitor their trades with the help of risk management professionals associated with the desks.

Their interaction with the rest of the bank is mainly mediated by the trading platform. When the book a trade, for instance, it goes into the trading platform and ends up with some middle office professional who will decide whether to accept it or bounce it back for further modifications. Various risk management staff from the middle office also will take a hard look at the trade, as we shall see later in the trade lifecycle.

The desk risk management team get their cues also from the Middle Office risk management, in terms of approved limits and daily marked-to-market and sensitivity reports. All these channels of communication need to be facilitated in the trading platform.

Those in sales tend to be personable, extroverted and persuasive people. A good salesman can sell a refrigerator to an eskimo, I’m told. IN the context of the front office in the global treasury or global markets, sales people are tasked with sniffing out trading needs from their customers and offer compelling products from the trading and structuring desks to fulfill them.

The life of a sales professional is a tough one. They need to meet progressively more aggressive targets in sales volumes to stay in the game. The moment they meet the target one year, it jumps the next year to an even more unattainable level. The sales staff, therefor, find themselves under constant (or even increasing) pressure. Knowledge of mathematical finance, while useful, is not a pre-requisite for sales jobs. In fact, mathematically inclined folks tend to be reserved and introverted, and tend not to have the qualities that make for a good salesman. In other words, if you are a quant, your most ideal role is not in sales, although the structuring side may offer some interesting opportunities.

Economists have too many hands. On the one hand, they may feel that oil prices are going to go up because of increased demand from emerging giants like India and China. On the other hand, there is a global slowdown, and the overall demand is likely to fall, putting downward pressure on the prices. Then again, the rampant corruption and inherent deficiencies in markets like India might push the prices high. On another hand, price-driven improvements on the supply-side (like better production techniques) may eventually push the prices down. My ex-boss, an economist himself, once told me that he wished he could chop off some of these hands!

But seriously, economists are the mouthpieces of the bank. When you see someone from an investment bank on TV making an intelligent observation about the market outlook, it is likely to be a staff economist. If you manage to navigate through the jumble of hands, you will hear what the bank wants to say to the world.

That is precisely why you have to pay close attention and try to read between the lines. You are listening to what the bank wants you to hear. When you listen to a Morgan-Stanley economist assert that Facebook is the best thing since sliced bread, should you trust him, given that they were the investment bank behind Facebook IPO? Of course, the lingo you will hear from the economist would be a lot nicer, subtler and more convincing than I can muster. But you should still ask yourself, “Is there a hidden agenda?”

Economists may seek to influence the market; they also distill and condense their take on the market and share it with the traders and executives so that they can formulate and fine-tune their tactics and strategies. Thus, they play an important role in the directional views that banks take when navigating the tricky waters of trading and speculating.

The Front Office looks quite complex in the slide below. All we need to remember is that the “Front” in Front Office is for world-facing. So in the slide below, you can see functional teams, some of which interact with the external world. These teams are:

• Economists who talk to the media and receive market inputs that they condense into useable intelligence for the rest of the bank.
• Sales and Structuring teams who talk to customers to sniff out potential opportunities.
• Trading Desks, interacting with their peers in other financial institutions and other counter parties.

One level removed from this layer of customer or world-facing teams are the quants and quantitative developers of Front Office, along with the risk managing professionals associated with the desks. They play supporting roles to the first layer of teams. Quants develop pricing models, quantitative developers roll them out into trading platforms, and the desk risk management team helps traders monitor and hedge their exposures. Note that almost all the interactions among these teams are mediated by the trading platform. The platform also acts as a conduit between the functions of Front Office and Middle Office. The nature of these functions and interactions of each team will be the topic of the next few posts, starting with the economists. Stay tuned.

The trading arm of a bank consists of three so-called “offices” — the Front Office, the Middle Office and the Back Office. The Front Office (which may go by the names Global Treasury, Global Markets etc.) is the customer facing part. It houses the loud and strong-willed traders, extremely articulate economists, personable sales staff along with some mathematicians with thick glasses and bulging foreheads. The Front Office is considered the profit-making part of the trading activity — it is a profit center. All other teams in the other two offices are cost centers, which is a fact that is well reflected in the compensation structure.

The Middle Office faces the Front Office, not the external world. They busy themselves with trade validation, lifecycle management, risk calculation, monitoring, limits enforcements etc. The Back Office is far removed from the Front (and from the sphere of influence of a quant or a quantitative developer). They take care of vitally important aspects of trading — namely settlements, taking and paying money. They also control the numbers that appear in the very visible annual reports.

By the way, the naming of the offices has nothing to do with their geographic location — a fact I learned early in my banking career about seven years ago when my boss wanted to take me to meet someone in the Back Office. I couldn’t figure out why he wasn’t actually leading me to the back of the building, I am embarrassed to admit.

All the Offices are supported by multiple departments in the bank, most notably the Information Technology (which may go by the names Group Technology or any other transmogrificaiton of it). Also supporting everything happening in a bank (or in any corporate body, for that matter) would be Human Resources, Finance etc.

Before we conclude this post, we have to highlight a couple of caveats. The structure described above is by no means the whole bank. It is only the trading arm of the investment banking side of a modern bank. This part happens to be the one most relevant to quantitative developers. Even in this limited remit, the details of the structure (which we will get to in the subsequent posts) are not cast in stone. Each bank may have its own partitions, naming conventions and organizational and hierarchical structures around the various offices. Despite such differences, the static topology of the various offices haas enough commonality that we can talk about it general terms. As we will explore how the omnipresent trading platform mediates almost all interactions among these offices and their teams in the subsequent posts, we will get into more details of the structure.

A trading platform is a program that enables the front office traders to price and book trades, the middle office professionals to manage the trade lifecycle and risk, and the back office staff to settle them. This definition contains a lot of jargon: front/middle/back offices, booking a trade, trade lifecycle, risk management, settlement etc. Don’t worry, we will go through the lingo in great detail in the subsequent posts. Some of it will become clear in this post.

First, let’s be clear about what we mean by a trading platform. It is a piece of software that answers to a set of requirements coming from the business side as well as from the software architecture perspective. From the business side, the trading platform acts like the repository of the pricing models coming from the in-house quants. Since most of these models would not be ready when the system goes live, we should be able to add models on the fly. In other words, the trading platform should be incrementally deployable. It should also have built-in sockets to receive and archive market data feeds from multiple providers. In addition to persisting the market data, the trading platform should have a database backend with a robust schema to persist the trade data. It should be able to support regular processes like daily marking-to-market of the trades, flagging fixings and cash-flow requests etc. As with all financial programs, the trading platform should be able to provide indelible audit-trails, coupled with a highly granular access control mechanism. These security and authentication features have become even more relevant in light of the high-profile rogue trader instances of last decade.

All these high-level business requirements translate to architectural choices in the program. The design of the trading platform calls for a higher level of code maintainability than is obvious in normal software engineering, because the banking field suffers from a rather large personnel attrition rate. In order to minimize the key-person risk, we should insist on detailed documentation in addition to sound development practices. The scalability requirement of a trading platform is also more stringent than is common in normal programs. The volume of trades can jump from a handful to hundreds of thousands in a matter of weeks when the system goes live. Similar to that kind of scalability is another requirement — the ability to incrementally add modules to roll out the pricing models originating from the mathematicians of the bank, which calls for a very careful design. The robustness of the system will also have to the very high even at single transaction level. We have to ensure transactional integrity (no half-booked trades, for instance), and zero downtime because, after all, time is money in the bank. The authentication and security mechanisms are to be top-notch. To top it all, the performance has to be top-notch as well. So the design of trading platform is a daunting task from a software architecture perspective.

The question is not whether a modern bank should have a trading platform. All banks do. In fact, they have multiple trading platforms. The question is not even whether they should attempt to build a trading platform in-house. Again, most modern investment banks do build their own in-house platforms. The question I want to explore here is regarding the advantages and disadvantages of doing so. And to study some of the options when it comes to deciding how deep we want to go in the endeavor of building a trading platform in-house.

The real impetus behind any endeavor in a bank, of course, is money. An in-house trading platform is essential to harness the efforts of the highly paid model quants. In its absence, their mathematical models and implementations will be a confusing mess of prototypes and spreadsheets. A well-designed quant library and a trading platform riding on it can turn them into revenue generators. If the trading platform is built in-house, it offers additional advantages of speediness to respond to transient market conditions. For these reasons, most modern banks decide to invest in at least one in-house trading platform.

Once we decide to build it in-house, we have a slew of choices. First, we can think of extending the existing commercial trading platform. We can ask our vendor to incorporate our models and thus customize the platform. But this option usually doesn’t work out well because it tends to be slow and expensive. Besides, once the modules are developed for us, the vendor might want to sell the system to our competitors as well, unless we are prepared to accept even more expensive terms and conditions. This aspect will pretty much nullify any profit motivations that the bank had to begin with.

Another option is a middle ground of using the vendor’s interfaces (API) to implement our models on the commercial system. Although it might initially look attractive, it’s allure diminishes at closer inspection; once we realize that vendors have no incentive in making it easy for the users to modify the system. If anything, it only increases their support headaches with uninitiated IT managers mucking up the core functionalities. Perhaps for such reasons, vendor APIs tend to be both expensive and incomprehensible. Besides, this route of designing a customized trading platform ends up creating highly-skilled and mobile key persons, with the associated risks.

For ultimate control and flexibility (and for most fun), nothing beats a fully in-house designed trading platform. It can be highly nimble and responsive. But it is also an adventurous and error-prone undertaking. Nonetheless, it is this route we will explore in great detail in my book, and to a lesser degree, in this series of posts.