Tag Archives: quantitative finance

Sales and Structuring

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.

Front Office

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.

Front Office

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.

Structure of a Bank

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.

Trading Platform

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.

Trading Platform

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.

Trading Platform

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.

Trading Platform

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.

Why a Trading Platform

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.

How to Get a 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.


In the dog-eat-dog corporate jungle, there always is a hidden agenda. Always. In writing this series of posts, I have a hidden agenda as well. It is to promote my book – Principles of Quantitative Development. Everything I say here is described in much more detail in the book. And, the book goes into topics that I do not plan to touch upon here – like a review of computing principles for quants, quant developers and people involved in trading and trade lifecycle management. Finally, the book comes with a mini trading platform illustrating many of the principles described.

Hidden Agendas

If these compelling reasons have failed to convince you to fork out fifty or so dollars to order the book from Amazon, consider your own hidden agenda. Why are you reading these posts? You are probably considering a lucrative career as a quantitative professional in a bank. Or, as a junior quant professional, you would like to know more about how the whole thing works. And Principles of Quantitative Development may help you in that quest.

To get back to my point, there always is a hidden agenda, and the associated petty politics. If you cannot play the political game, a bank is not the right place for you. That may sound like bad news to you. Let me give you the good news. Almost everybody is better at politics that they think they are, And almost everybody in the bank, regardless of how high they are, goes about feeling that they are not doing as well as they should, because they don’t play the political game . So don’t worry too much about it even if you fee that you are not good at it — you are probably better than you think you are.

My real point is just that you should be aware of hidden agendas — in day-to-day interactions, corporate memos and announcements etc. For instance, let’s suppose you get a congratulatory email from your big boss about a project you are working on, saying you did an excellent job, it’s going to save or make so many millions of dollars, and everybody is mighty pleased about it. You may also feel mighty pleased about the message, and start thinking of that big break, promotion, bonus, corner office, expense account etc. But it may turn out to be a precursor to letting you go — after all, you did such a wonderful job, and your work here is done!


Regarding the agenda of these posts, this series of posts will cover the items listed in the picture above. In the next post, we will go through what we call a Trading Platform because that is the arena of Quantitative Development. The next few posts will be on the structure of an investment bank, from the perspective of a quant and a quantitative developer. The structure, in some sense, is the static topology. How trades flow through it will be the subsequent few posts, which will be the dynamic evolution of a trade. As ia trade moves from one department to another in a bank, the players involved use their own work paradigms and perspectives to view and deal with it. It is important to understand these perspectives so that a quant developer can understand and appreciate the myriads of requirements thrown at him. After all, his product — the trading platform — mediates everything.

In order to give you more of a flavor for the workings of a bank, the whole series of posts will be peppered with some little tidbits of information that may read like newspaper columns — after all, I started my writing career as a columnist. In my book, these tidbits are called the BIG PICTURE.

Off the Beaten Track

Recently, I gave an invited lecture to the Master of Financial Engineering students at the Nanyang Technological University in Singapore. I thought I would make a series of blog posts out of my talk with the belief that there is a wider audience out there who would like to know how an investment bank (or, more precisely, the structured and exotic products trading side of a bank) works.

Principles of Quantitative Development

First things first. I work for Standard Chartered Bank, Singapore. But the views expressed here in the talk and in this series of posts are my own. They are not influenced by my employer’s policies or client relationships. They are not meant to be any kind of investment or career advice. This disclaimer is a legal necessity before I can say anything related to banking and finance.

Off the Beaten Track

Since the talk was originally given to MFE students, who are expected to be pretty well-versed in the mathematics of quantitative finance, and possibly of computing as well, I tried to tell you something different. In any case, all the mathematics and computing stuff is something you can pick up from any number of standard text books. The stuff I’m about to share with you is something you will learn from only a few books, or by working in a bank for a while. That brings me to my hidden agenda. (Well, not so-hidden after this introduction.) And to the first moral of this lecture — there always is a hidden agenda in the corporate jungle. I will have more to say about it in the next post.

Since this series of posts is not quite on quantitative finance, nor on computing, it is a bit off the beaten track. Hope you enjoy it. In any case, you will develop and appreciation for the “Big Picture”. A few years ago, I published a well received article in the Wilmott Magazine on the same theme, and the positive feedback I received from it was the inspiration to write my book.

In this talk, and in my book, I lay out the foundations of Quantitative Development. Quantitative Developers (who tend to be computer science professionals) are different from Quants (who tend to be mathematicians). Quants tend to develop pricing models or other mathematical tools for the rest of the banks to use, and make them available in the form of prototype programs, or the so-called quant libraries. Quantitative developers make them available in existing, familiar systems (“productionize” them, to use the horrible jargon) so that the rainmakers of the bank can bring in profits. In that sense, their role in the bank is sandwiched between the model quants and the traders, from a functional perspective. If you don’t like that perspective, and would like to have a more abstract, mathematical sort of view, you can think of quantitative development as being in between pricing models and systems (which we will call Trading Platforms very soon). Or from a corporate hierarchy perspective, the job of quantitative developers falls in between the front office and the information technology division, so much so that they can actually be integrated with either one of them.

Risk – Wiley FinCAD Webinar

This post is an edited version of my responses in a Webinar panel-discussion organized by Wiley-Finance and FinCAD. The freely available Webcast is linked in the post, and contains responses from the other participants — Paul Wilmott and Espen Huag. An expanded version of this post may later appear as an article in the Wilmott Magazine.

What is Risk?

When we use the word Risk in normal conversation, it has a negative connotation — risk of getting hit by a car, for instance; but not the risk of winning a lottery. In finance, risk is both positive and negative. At times, you want the exposure to a certain kind of risk to counterbalance some other exposure; at times, you are looking for the returns associated with a certain risk. Risk, in this context, is almost identical to the mathematical concept of probability.

But even in finance, you have one kind of risk that is always negative — it is Operational Risk. My professional interest right now is in minimizing the operational risk associated with trading and computational platforms.

How do you measure Risk?

Measuring risk ultimately boils down to estimating the probability of a loss as a function of something — typically the intensity of the loss and time. So it’s like asking — What’s the probability of losing a million dollars or two million dollars tomorrow or the day after?

The question whether we can measure risk is another way of asking whether we can figure out this probability function. In certain cases, we believe we can — in Market Risk, for instance, we have very good models for this function. Credit Risk is different story — although we thought we could measure it, we learned the hard way that we probably could not.

The question how effective the measure is, is, in my view, like asking ourselves, “What do we do with a probability number?” If I do a fancy calculation and tell you that you have 27.3% probability of losing one million tomorrow, what do you do with that piece of information? Probability has a reasonable meaning only a statistical sense, in high-frequency events or large ensembles. Risk events, almost by definition, are low-frequency events and a probability number may have only limited practical use. But as a pricing tool, accurate probability is great, especially when you price instruments with deep market liquidity.

Innovation in Risk Management.

Innovation in Risk comes in two flavors — one is on the risk taking side, which is in pricing, warehousing risk and so on. On this front, we do it well, or at least we think we are doing it well, and innovation in pricing and modeling is active. The flip side of it is, of course, risk management. Here, I think innovation lags actually behind catastrophic events. Once we have a financial crisis, for instance, we do a post-mortem, figure out what went wrong and try to implement safety guards. But the next failure, of course, is going to come from some other, totally, unexpected angle.

What is the role of Risk Management in a bank?

Risk taking and risk management are two aspects of a bank’s day-to-day business. These two aspects seem in conflict with each other, but the conflict is no accident. It is through fine-tuning this conflict that a bank implements its risk appetite. It is like a dynamic equilibrium that can be tweaked as desired.

What is the role of vendors?

In my experience, vendors seem to influence the processes rather than the methodologies of risk management, and indeed of modeling. A vended system, however customizable it may be, comes with its own assumptions about the workflow, lifecycle management etc. The processes built around the system will have to adapt to these assumptions. This is not a bad thing. At the very least, popular vended systems serve to standardize risk management practices.

Risk: Interpretation, Innovation and Implementation

A Wiley Global Finance roundtable with Paul Wilmott

Featuring Paul Wilmott, Espen Haug and Manoj Thulasidas


How do you identify, measure and model risk, and more importantly, what changes need to be implemented to improve the long-term profitability and sustainability of our financial institutions? Take a unique opportunity to join globally recognised and respected experts in the field, Paul Wilmott, Espen Haug and Manoj Thulasidas in a free, one hour online roundtable discussion to debate the key issues and to find answers to questions to improve financial risk modelling.

Join our experts as they address these fundamental financial risk questions:

  • What is risk?
  • How do we measure and quantify risk in quantitative finance? Is this effective?
  • Is it possible to model risk?
  • Define innovation in risk management. Where does it take place? Where should it take place?
  • How do new ideas see the light of day? How are they applied to the industry, and how should they be applied?
  • How is risk management implemented in modern investment banking? Is there a better way?

Our panel of internationally respected experts include Dr Paul Wilmott, founder of the prestigious Certificate in Quantitative Finance (CQF) and Wilmott.com, Editor-in-Chief of Wilmott Magazine, and author of highly acclaimed books including the best-selling Paul Wilmott On Quantitative Finance; Dr Espen Gaarder Haug who has more than 20 years of experience in Derivatives research and trading and is author of The Complete Guide of Option Pricing Formulas and Derivatives: Models on Models; and Dr Manoj Thulasidas, a physicist-turned-quant who works as a senior quantitative professional at Standard Chartered Bank in Singapore and is author of Principles of Quantitative Development.

This debate will be critical for all chief risk officers, credit and market risk managers, asset liability managers, financial engineers, front office traders, risk analysts, quants and academics.

Physics vs. Finance

Despite the richness that mathematics imparts to life, it remains a hated and difficult subject to many. I feel that the difficulty stems from the early and often permanent disconnect between math and reality. It is hard to memorize that the reciprocals of bigger numbers are smaller, while it is fun to figure out that if you had more people sharing a pizza, you get a smaller slice. Figuring out is fun, memorizing — not so much. Mathematics, being a formal representation of the patterns in reality, doesn’t put too much emphasis on the figuring out part, and it is plain lost on many. To repeat that statement with mathematical precision — math is syntactically rich and rigorous, but semantically weak. Syntax can build on itself, and often shake off its semantic riders like an unruly horse. Worse, it can metamorphose into different semantic forms that look vastly different from one another. It takes a student a few years to notice that complex numbers, vector algebra, coordinate geometry, linear algebra and trigonometry are all essentially different syntactical descriptions of Euclidean geometry. Those who excel in mathematics are, I presume, the ones who have developed their own semantic perspectives to rein in the seemingly wild syntactical beast.

Physics also can provide beautiful semantic contexts to the empty formalisms of advanced mathematics. Look at Minkowski space and Riemannian geometry, for instance, and how Einstein turned them into descriptions of our perceived reality. In addition to providing semantics to mathematical formalism, science also promotes a worldview based on critical thinking and a ferociously scrupulous scientific integrity. It is an attitude of examining one’s conclusions, assumptions and hypotheses mercilessly to convince oneself that nothing has been overlooked. Nowhere is this nitpicking obsession more evident than in experimental physics. Physicists report their measurements with two sets of errors — a statistical error representing the fact that they have made only a finite number of observations, and a systematic error that is supposed to account for the inaccuracies in methodology, assumptions etc.

We may find it interesting to look at the counterpart of this scientific integrity in our neck of the woods — quantitative finance, which decorates the syntactical edifice of stochastic calculus with dollar-and-cents semantics, of a kind that ends up in annual reports and generates performance bonuses. One might even say that it has a profound impact on the global economy as a whole. Given this impact, how do we assign errors and confidence levels to our results? To illustrate it with an example, when a trading system reports the P/L of a trade as, say, seven million, is it $7,000,000 +/- $5,000,000 or is it $7,000, 000 +/- $5000? The latter, clearly, holds more value for the financial institution and should be rewarded more than the former. We are aware of it. We estimate the errors in terms of the volatility and sensitivities of the returns and apply P/L reserves. But how do we handle other systematic errors? How do we measure the impact of our assumptions on market liquidity, information symmetry etc., and assign dollar values to the resulting errors? If we had been scrupulous about error propagations of this, perhaps the financial crisis of 2008 would not have come about.

Although mathematicians are, in general, free of such critical self-doubts as physicists — precisely because of a total disconnect between their syntactical wizardry and its semantic contexts, in my opinion — there are some who take the validity of their assumptions almost too seriously. I remember this professor of mine who taught us mathematical induction. After proving some minor theorem using it on the blackboard (yes it was before the era of whiteboards), he asked us whether he had proved it. We said, sure, he had done it right front of us. He then said, “Ah, but you should ask yourselves if mathematical induction is right.” If I think of him as a great mathematician, it is perhaps only because of the common romantic fancy of ours that glorifies our past teachers. But I am fairly certain that the recognition of the possible fallacy in my glorification is a direct result of the seeds he planted with his statement.

My professor may have taken this self-doubt business too far; it is perhaps not healthy or practical to question the very backdrop of our rationality and logic. What is more important is to ensure the sanity of the results we arrive at, employing the formidable syntactical machinery at our disposal. The only way to maintain an attitude of healthy self-doubt and the consequent sanity checks is to jealously guard the connection between the patterns of reality and the formalisms in mathematics. And that, in my opinion, would be the right way to develop a love for math as well.