Principles of Quantitative Development

Manoj Thulasidas

• Publisher: Wiley
• Year: 2012
• ISBN:
  9780470971529
• Edition: 1
• Topic: Business
• Subtopic: Finance
• Index: Business

Principles of Quantitative Development is a practical guide to designing, building and deploying a trading platform. It is also a lucid and succinct exposé on the trade life cycle and the business groups involved in managing it, bringing together the big picture of how a trade flows through the systems, and the role of a quantitative professional in the organization.

The book begins by looking at the need and demand for in-house trading platforms, addressing the current trends in the industry. It then looks at the trade life cycle and its participants, from beginning to end, and then the functions within the front, middle and back office, giving the reader a full understanding and appreciation of the perspectives and needs of each function. The book then moves on to platform design, addressing all the fundamentals of platform design, system architecture, programming languages and choices. Finally, the book focuses on some of the more technical aspects of platform design and looks at traditional and new languages and approaches used in modern quantitative development.

The book is accompanied by a CD-ROM, featuring a fully working option pricing tool with source code and project building instructions, illustrating the design principles discussed, and enabling the reader to develop a mini-trading platform.

The book is also accompanied by a website http://pqd.thulasidas.com that contains updates and companion materials.

Chapter 1

Introduction

Purpose-built trading platforms have become indispensable tools for exotic trading in most modern banks. One reason for their success and prevalence is that exotics and structured products business is highly lucrative to a financial institution. One prerequisite for success in exotic business is the ability to price the products. For pricing model development and hedging or risk analysis, the financial institution can resort to its mathematicians and the quantitative models they develop.

Another vitally important prerequisite is the capability to assess and manage the associated risks. The risks arising from market movements are related to pricing and are managed through sensitivity analyses. However, in order to manage credit and operational risks, especially when the business volume grows, banks need robust trading platforms supporting and augmenting the mathematical effort.

A carefully designed and deployed trading platform can easily recuperate its development costs within a few short months of going live, and turn into an important profit centre for banks. Once they started appreciating the necessity and profitability of an in-house trading system, banks and other financial institutions began to invest resources into developing in-house trading systems.

Resource allocation attracts professionals with highly specialized skills to move into the field. However, their skills, at times, work against them. They think of quantitative development as a purely technical endeavour. Although, at its heart, trading platform development is a technical challenge, it is the myriad of business processes around it that will eventually make or break its viability. The proverbial devil is really in the details.

1.1 WHAT IS A TRADING PLATFORM?

The goal of this book is to help design a robust, durable and reliable trading platform. The first question then is: What exactly is a trading platform (or system)? For our purpose in this book, I define it as a program or a collection of programs that meets the following broad requirements.

1.1.1 Model archival

One of the problems that the quantitative analysis effort in any modern bank faces is the archival and reuse of their pricing models. A trading platform acts as a repository for the quantitative intelligence generated within the bank. A model developed for a particular product is all too often so specialized that it is difficult to deploy it to tackle another product. This lack of reusability results in duplicated effort. A well-designed trading platform can help by imposing the right quantum of structure and standards to encourage generic programming and to enforce reusability. Furthermore, it will hold all the pricing models with standardized interfaces in one place where they can be found, examined and reused.

1.1.2 Incremental deployability

A trading platform should provide means by which the new quantitative models developed or implemented in the bank can be easily integrated and deployed into the revenue generating work streams of the bank. In other words, even after the trading platform is commissioned, as new and innovative products are developed by the mathematicians and structurers, we should be in a position to augment our system to make use of the innovation. This requirement of incremental deployability drives the whole architecture and design of the trading platform, as you will see in later chapters. It also imposes the necessary rigidity in the form in which quantitative analysts deliver their pricing models, facilitating the first requirement.

1.1.3 Live data feeds

A trading platform should talk to the external world to obtain market data (either as live feeds or as snapshots at regular intervals) and archive snapshots of market conditions for bulk processing. Market data feeds reach the trading platform from several data providers who use dissimilar, and often incompatible, technologies and interfaces. For this reason, the market data handling may become another auxiliary project in its own right, providing a uniform interface to the trading platform regardless of the origin of the data provided. This market data project often has its own database back-end for data persistence.

1.1.4 Trade persistence

A trading platform should be able to save trade data into a database and manage all the associated inception and life-cycle events. The database layer of a trading platform has many stringent requirements on security, performance and record-keeping integrity. It should be capable of handling the inception events such as cancellation, cancel and amend, reissue, novation (changing the ownership) etc., consistent with the policies of the financial institution. A cancellation, for instance, is never a database operation of deleting a record, for a complete deletion would erase the necessary audit trails. In addition, the database layer may reside in geographically dispersed locations, and the trading platform may be called upon to provide data replication services that can be challenging when the trade volumes grow.

1.1.5 Regular processing

A trading platform should facilitate and mediate all aspects of regular downstream processing, such as risk management, trade transformation, settlements, etc. This requirement, although summarized in one bullet point, is very vast in its scope, as you will appreciate by the time you finish this book.

It is instructive to benchmark a vended system (such as the trading system currently in use in your bank) against these requirements. All vended systems do an admirable job in meeting the last two requirements. However, they fail miserably in the first two. In fact, the pricing models implemented in vended solutions are the principal intellectual properties that the vendors jealously guard. They have no incentive in facilitating easy deployment of in-house custom models using their trading systems.

The pricing tool that comes with this book is near the other extreme: it implements the first two requirements wonderfully. Using the pricing tool, you can define and deploy new models without even recompiling the core program. However, it has no market data feeds, not even a clear notion of a market, and it does not provide a database layer. The only data persistence it offers comes in the form of XML files that store pricing scenarios.

Most in-house trading platforms find their place in between these two extremes. They do not try to handle every aspect of trade life-cycle management, but they are far more than the prototyping or proof-of-concept pricing programs that the mathematical brains of the bank generate. Depending on the implementation strategy of a particular bank, the in-house trading platform may end up focusing on different aspects of the requirements listed above. In all cases, however, an in-house trading platform attempts to bridge the gap between quantitative pricing models and a deployed and supported system out of which the bank can generate profit. Its emergence has engendered the relatively new domain of quantitative development. Trading platforms are the domain of the quantitative developers (computer scientists who deploy the models) in the bank, who are distinct from the so-called ‘quants’ (mathematicians who develop pricing models).

1.2 QUANTS AND QUANTITATIVE DEVELOPERS

The term ‘quant’ is short for quantitative analyst. They are mathematicians who develop pricing models and keep abreast with the cutting edge research on stochastic calculus and quantitative finance. They transform the academic knowledge they assimilate into programs that can generate revenue and profit. Quants usually have an advanced degree in mathematics, physics or other quantitative fields. Ideally, quants have a sound knowledge of markets, business and products, as well as computer science.

The input to quants’ work is research and the academia. Their outputs are pricing models, often delivered as programs or functions in a library, aptly called the quant library. They may also deliver standalone pricing programs, usually as spreadsheets and add-ins.

Quantitative developers are computing professionals who make the output from the quants widely usable, often through the in-house trading platform. Their functional duties fall in between the quant output and the programs used at trading desks. Ideally, quantitative developers would have the same skill set as the quants (mathematical aptitude, product/business knowledge and computer science), but with less emphasis on mathematics and much more focus on computing and software engineering. How separated quants and quantitative developers are in terms of job functions and organizational hierarchies depends on the human resourcing strategies of the bank.

In our discussions in this book, we will assume a clean separation between the duties of quants and quantitative developers. The developers start their work from the quant library, the fruits of the quant’s labour. The end point of their work is an in-house trading platform and other maintainable quantitative tools.

1.3 NEED FOR SPEED

In today’s financial markets, opportunities are transient. The skyrocketing commodity prices of early 2008, for instance, generated a strong demand for cost-effective hedging. Banks that could roll out structured products to meet customized hedging requirements reaped handsome benefits from this demand. Hedging essentially caps the customer’s upside exposure while subjecting them to unlimited downside risks. Because of the dizzying fall in commodity prices (especially in energy) that soon followed during the second half of 2008, the banks that could provide the hedging structures again made even more profit. Rolling out such hedging solutions on short notice to benefit from the market fluctuations of this kind necessarily calls for the agility and flexibility that only an in-house trading system can provide.

Due to such enticing profit potential, an increasing amount of assets under management gets earmarked for exotics trading. In fact, this influx of institutional investments was at least partly to blame for the wild fluctuations in commodity prices. However, the influx also underscores the importance of exotic and structured products. Coupled with this emphasis on exotics trading is the increasing sophistication of the clients who demand customized structures reflecting their risk appetite and market views.

The net result of the changing financial market attitude is the need for more mathematical modelling and speedier deployment than ever before. The need for speed, in fact, goes beyond exotics business. In spot FX trading, the time scale of profit making opportunities is measured in seconds or milliseconds. The so-called high-frequency trading tries to capture such small, but prolific, market opportunities. High-frequency trading modes are too fast for human intervention and rely heavily on machine intelligence and algorithmic approaches. The management of high-volume tick data and the real-time decision making requirements hold a challenging fascination for quantitative developers in this field as well.

1.4 IMPLEMENTATION OPTIONS

Once we appreciate the need for a trading platform through which new products can be launched rapidly, we have a few options to choose from.

1.4.1 Outsource to vendor

We can request our vendor to custom-design and integrate the new products into our existing systems, which we are already familiar with. This approach has the attraction that the new product will be native to the existing system, assuring perfect integration, especially in the back-end. In the front-end also, the familiar look and feel of the interface will enhance usability and productivity.

Vendor development, however, tends to be heavy and slow. When we come up with an innovative product, we do not want to wait for months before we can launch it. An innovative product stays innovative only for a brief span of time.

Another disadvantage of this implementation option is that the cost of custom design can be prohibitive, especially if we demand exclusivity on the product developed. The perceived profit attraction of the innovative product can soon evaporate because of the development cost involved. The nonexclusive mode is clearly not attractive because we will see our innovation in the hands of our competitors.

Vendors may be reluctant to accept our quantitative intelligence because of intellectual property considerations. This resistance makes our in-house mathematical talent superfluous. Due to these reasons, vendor development is not the preferred route for deploying new models and products.

1.4.2 Use vendor API

One way to overcome some of the disadvantages of asking the vendor to write code for us is to use their application programming interface (API) ourselves. In principle, this approach should work well. After all, we will have full control over the intellectual property associated with our new product ideas and pricing models. Furthermore, vendor API provides the same level of integration to the downstream processing systems as the vended trading system.

In practice, this approach also suffers from many disadvantages. The vendor provided APIs tend to be incomprehensible and inflexible, which has to be expected because vendors of trading systems have no incentive in encouraging in-house development.

In addition to the shortcomings of the API, we end up battling the process issues related to the release cycles of the systems as well. The vended systems are deployed by the IT team, not by quantitative developers, and the deployment involves the vendors heavily. Thus, deploying new products through the API may still be delayed by the scheduling priorities of other teams over which the product innovators of the front office have no control.

Since the vendor API is usually complicated, it is only one or two key developers in the quantitative development team who turn out to be familiar with it. This concentration of a crucial skill results in significant key person risk to the financial institution.

Finally, vendor APIs are not cheap – after all, it is not in the vendors’ interest to help us be totally self-reliant. (However, they do tout the existence of the API as a key selling point.)

Despite these disadvantages, in-house development using vendor APIs is the chosen route for a large number of mid-tier players in the financial industry. If the level of innovation in the bank is low, this implementation option may prove to be the most cost-effective one.

1.4.3 Develop in-house

For larger pla...