Unlike quants, quantitative developers are more product-centric. Their job is to take the pricing models (the output of the quant effort) and make them deployable and accessible to the traders, sales teams and the middle and back offices. Their primary unit of work is a product because when the product definition changes, regardless of whether it uses a new or an existing pricing model, they have to integrate it into the system. Even if it is merely a product variant, they have to implement all the infrastructure and take care of the approval processes for its downstream handling. For this reason, the work paradigm that makes most sense to a quantitative developer is product-centric.

Compared to the quants, the quantitative developers are closer to the day-to-day activities on Front Office and Middle Office. They view the trades (identified by unique IDs) as instantiations of products. Once booked, they end up in the trading platform database as distinct objects with attributes defined in trade inputs. In addition to trade input, they use market data feeds to price a product in the form of a trade. The trading platform comes with a pricing interface which combines trade information and market data. It also runs in what they call batch mode — regularly at a given time of the day to compute prices and sensitivities of all trades. Since it is the trading platform that performs the batch job, the quantitative developers may take care of the associated resources like the grid computing platforms, market data feeds, trade databases etc. In this respect, their product-centric perspective may get diffused into a trade-centric view.

If you are a quant, you are a mathematician with an advanced degree in mathematics or physics. Your work is based on both academic research and professional, peer-reviewed publications. You take your inputs from them, apply your own formidable intelligence to come up with a stochastic pricing model that you think will work exceptionally well for a class of products. You will also need the details of the products. Your output is, of course, a pricing model of your own, or an implementation of a pricing model from the literature. This is your primary work unit.

In order to make use of this pricing model, it will have to be validated. Then a set of products using the pricing model will be defined and submitted for approval. Once approved, with the help of trade inputs and market data, each of the products can be priced and booked into the trading platform. But such activities are outside the sphere of interest and influence of the quant. To them, how a product is instantiated into a trade is pretty irrelevant and trivial. It is merely a question of specifying the trade and market inputs to the pricing model. Even how various products are derived is mechanical, and all the “real” work is done in the pricing model.

This perspective, though accurate and functional for a quant, is pretty far removed from the view of the rest of the bank, which is why quants sometimes have the dubious reputation of being out of touch with the industry. The point is not so much that they have to change their perspective, but they should appreciate that there are other equally valid perspectives held by other business units they interact with, and make an effort to know them.

The last section of this post series is on trade perspectives. In fact, our earlier sections on the static structure of the bank and the temporal evolution of the trade have been in preparation to this last section. In the next couple of posts, we will see how the quants, quantitative developers and the middle office professionals (and the rest) see trades and trading activity. Their views are important and need to be accommodated in the design philosophy of any trading platform.

Where do these perspectives come from and why do we need to know about them? Trade perspectives are based on the work paradigm specific to each business unit. Because of what aspect of the trading activity a group focuses on, they evolve a paradigm, or a mental model, that works best for them.

In order to understand, let’s take a look at how we work with a modern personal computer. The paradigm we are presented with is one of a desk and a filing cabinet. So we have a desktop, folders and files. They have become so natural for us now that we cannot imagine another way of interacting with a computer at all. The Internet, on the other hand, is built on a paradigm of something that hovers over us, which is why we “down”-load stuff from it and “up”-load stuff into it. But the programmers and architects who develop such paradigms often do work with different and less known paradigms as well; for instance we have ports and sockets and streams and so on.

If we do not appreciate the work paradigm, we will find the jargon that comes with it mysterious and incomprehensible. This is especially true if we are to work on projects that cut across multiple business units with differing paradigms.

To illustrate it further with an example from our trading world, let’s look at how we identify a trade. The quants really do not care about the trade identification number; for them, it is the pricing model that is the basic unit that they work with. The quantitative developer, on the other hand, would like the identifier to be something unique per trade. A structurer would like to have one identifying reference for the trade with possible sub IDs for the individual sub trades that make up a structure. While this requirement is easy enough to implement, the software architecture also has to cater to trade cancellation and amendment requirements from Front Office and Middle Office. What happens when a structure is modified or canceled? How do we find and deal withall the related trades? This problem will almost invariably ends up requiring a link ID in the database. Trade number amendments on a live deal create problem for documentation and operations staff as well, who might demand another immutable external reference number attached each trade. Audit will require integrity and indelibility on everything, demanding database record duplication. As we can see, the perspectives and work paradigms of each business unit translate to often conflicting requirements on the program design at a fundamental level. It is for this reason that we will take close look at the trade perspectives in the following posts of this series.

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.