benjamin van vliet - 2004 - modeling financial markets using visual basic net and databases to c

In addition youwill need to understand how databases are constructed andaccessed using computer code to do financial research and developtrading and risk management algorithms and system

Want to learn more?

We hope you enjoy this McGraw-Hill eBook! If you’d like more information about this book, its author, or related books and websites, please click here.

Using Visual Basic.NET and Databases

to Create Pricing, Trading, and

Risk Management Models

BENJAMIN VAN VLIET

ROBERT HENDRY

McGraw-Hill

New York Chicago San Francisco Lisbon

London Madrid Mexico City Milan

New Delhi San Juan Seoul

Singapore Sydney Toronto

any means, or stored in a database or retrieval system, without the prior written permission of the publisher

0-07-144288-X

The material in this eBook also appears in the print version of this title: 0-07-141772-9 All trademarks are trademarks of their respective owners Rather than put a trademark symbol after every occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the trademark Where such designations appear in this book, they have been printed with initial caps

McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs For more information, please contact George Hoare, Special Sales, at george_hoare@mcgraw-hill.com or (212) 904-

4069

TERMS OF USE

This is a copyrighted work and The McGraw-Hill Companies, Inc (“McGraw-Hill”) and its licensors reserve all rights in and to the work Use of this work is subject to these terms Except as permitted under the Copyright Act of 1976 and the right to store and retrieve one copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon, transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill’s prior consent You may use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited Your right to use the work may be terminated if you fail to comply with these terms

THE WORK IS PROVIDED “AS IS.” McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE, AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE McGraw-Hill and its licensors do not warrant or guarantee that the functions contained in the work will meet your requirements or that its operation will be uninterrupted or error free Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless of cause, in the work or for any damages resulting therefrom McGraw-Hill has no responsibility for the content of any information accessed through the work Under no circumstances shall McGraw-Hill and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that result from the use of or inability to use the work, even if any of them has been advised of the possibility of such damages This limitation of liability shall apply to any claim or cause whatsoever whether such claim or cause arises in contract, tort or otherwise

Introduction to VB.NET:Algorithm Development 31

3 Getting Started with VB.NET 33

4 Value Types and Operators 47

13 Structured Query Language 219

14 Introduction to Data Structures 243

15 Advanced Data Structures 257

SECTION FOUR

Advanced VB.NET: Implementation 269

16 Software Connectivity and Interoperability 271

17 Connecting to Trading Software 281

18 XML 301

19 XML Protocols in Financial Markets 323

SECTION FIVE

Object-Oriented Programming:Risk Management 341

20 Unified Modeling Lanaguage 343

References 379

Acronyms 383

Index 385

Andrew Kumiega, Nithiphong Vikitset, Anton Karadakov, DavidNorman, Keith Black, Pamela Reardon, Alex Deitz, Melanie Winter,Siriporn Treetanasawat, Mulianto The, Debbie Cernauskas,Michael Modica, Jerold Lavin, Duana Wooters, Thomas E.

“Burma” Shea, Sagy Mintz, Kenneth M Horjus, Mark McCracken,Julia Spaulding, Dave Kuipers, Rich Pombonyo, Paresh Akbari,Cliff Ensing, Brain Huyser, Mark Groenenboom, Bruce Rawlings,Gary Lahey, Hank Perrit, Jack Wing, Varsha Pitre, Michael Ubis,Jason Malkin, and Irma Baines

Although this book follows the layout of a programming book, theunderlying theme is financial modeling and quantitative tradingsystem development In a sense, this book really marries fourdisciplines—computer science, quantitative finance, trading strat-egy, and quality development—into one, financial engineering Thefollowing chapter, Chapter 2, outlines the Kumiega–Van VlietTrading System Development Methodology, which as you will seeprovides the underlying structure for the rest of the book As thechapters progress, we present gradually more complex program-ming ideas along with mathematics and trading applications toillustrate the steps along the Kumiega–Van Vliet paradigm So thisbook is not just about Visual Basic.NET (VB.NET) and databases It

is about modeling financial instruments in code and putting thepieces, or models, together to create an automated trading or riskmanagement system using a programming language, which in thiscase is VB.NET Let’s get started

Financial markets are in a constant state of evolution, frombuttonwood trees to trading floors to computer screens Over thelast 40 years, owing to the invention of computers and thedevelopment of quantitative tools for market analysis, the pace ofthis change has increased dramatically The revolution inderivatives market analysis really got into full swing in the early1970s when, soon after the Chicago Board Options Exchange(CBOE) began listing options on equities, Texas Instrumentsdeveloped a calculator to price options using the Black-Scholesformula (Berstein, 1996, pp 310–316) Over the coming years, onemajor outcome of this revolution may very well be a complete

automation of the trading process (Norman, 2001, p 236) In thefuture, computerized investment models and trading algorithmsand instantaneous trade execution could render human traderscompletely obsolete (Van Vliet and Kumiega, 2000).

Human traders, using strategies based on technical indicators,fundamental factors, or even plain old market savvy, are becomingincreasingly scarce More and more each day financial engineersare quantifying trading systems that can watch hundreds ofsecurities and derivatives in real time and execute hundreds ofstrategies instantaneously and simultaneously The trend thatstarted decades ago with Moore’s law (a doubling of speed incomputer processing power about every 18 months), coupled withthe decreased cost of technology and market data, means that in thefuture all profitable trading strategies may be, through mathema-tics and statistics, quantifiable and programmable

The equities trading industry caught on several years ago withprogram trading and index arbitrage, using computers to generatehundreds of orders simultaneously The options exchanges,however, have in the past prohibited automated order entry in aneffort to protect market makers But it appears now that such rulesmay very well be abolished in the near future, if they have notalready been by the time this book is published The BostonOptions Exchange (BOX), which will be opening for business inmid-2003, currently has no bylaw prohibiting automated orderentry, which will likely have the effect of forcing the other optionsexchanges to amend their rules

Whatever the future holds, however, make no mistake—thetrading game will be as it always has been: The first person, orcomputer, to recognize a profitable opportunity and execute a tradewins It’s just that being first is no longer measured in the splitseconds it takes to click your mouse button, but rather themilliseconds it takes a computer to react The financial engineerwho can program a computer to recognize profitable tradingopportunities and execute trades is really the trader of the future(Van Vliet and Kumiega, 2000)

In the trading industry, a key job performed by financialengineers, among other things, is to formalize trading strategiesbased upon quantitative research, back-test algorithms against

historical data, construct or supervise construction of necessarysoftware for automation of order execution, and, after implemen-tation, manage the risk of the trading system Of course, not allthese duties are always performed by just one person, but rather,usually, by a team of financial engineers and programmers.

If you intend to have a career in trading in the financialmarkets, you will likely work on such a team, which will requirethat at some point you will be required to either write computercode yourself, manage programmers, or work and interact withprogrammers on projects This will necessitate an understanding

of, at the least, Microsoft Excel spreadsheet and the Visual Basic forApplications (VBA) environment, but likely also Visual Basic.NET

or a higher-level language such as C/Cþþ or Java In addition youwill need to understand how databases are constructed andaccessed using computer code to do financial research and developtrading and risk management algorithms and systems

All financial research requires data, and the efficient ment and storage of data is crucial to the profitable operation of atrading system “Data is the lifeblood of electronic markets,” asDavid Norman states in his book Professional Electronic Trading(2002) Industrial-strength relational database management sys-tems, such as Oracle or MS SQL Server, can store gigabytes of suchthings as historical market data and firmwide trade and positioninformation (Norman, 2001) Often, historical market data is sim-ply the opening, high, low, and closing prices or other time-incremented data such as implied volatilities, but it could also bemore qualitative, economic, or fundamental data such as earningsreport data, stock splits, or Fed actions Whatever the case, analysis

manage-of data requires not only the knowledge manage-of quantitative methods,but also the programming tools to implement that analysis in a real-life environment This book addresses topics that are critical tothese aspects of trading system development

Top financial engineers estimate that only a fraction offinancial engineering actually deals with mathematics The lion’sshare of time applies to the actual construction and analysis ofmodels and forecasts and technology development

This majority of a financial engineer’s time engaged inconstruction, though, is not simply spent coding Rather, the entire

development process requires this amount of effort; actual timespent coding should be just a part of it As you grow in yourunderstanding of programming and trading and/or risk manage-ment system development, you will become increasingly awarethat comprehensive blueprints, or plans, or development method-ologies, of a project must be laid out before any nails are hammered

or computer keys pressed The value of a development paradigmcannot be underestimated

A good methodology, though, does not mean that anengineered trading system is infallible Not every trade and notevery system makes money There are certainly dozens, if notthousands, of examples or anecdotes trotted out by “nonquant”market participants that attempt to disprove the ability ofautomated systems to outperform human traders over the longrun To be sure, the markets are “replete with examples of ‘fattails’—unusual and extreme price swings that, based on a reading

of previous prices, would have seemed implausible” according toRoger Lowenstein in his book When Genius Failed (2000, p 229) Inthe past, quantitative systems, like that of Long Term CapitalManagement, which were built on historical data have blown upquite spectacularly during financial meltdowns, or tenth standarddeviation events, when all correlations go to 1, as they say But wedon’t stop engineering bridges just because one in London felldown No matter what anybody says, using a bridge to cross a river

is still an improvement on taking a boat across Over time, withmore experience and better engineering, financial models andforecasting will improve and become more able to weather thoseonce-a-millennium floods that seem to come around every couple

of years A computer can’t beat Kasparov at chess yet But give it afew more years Our money is with Deep Blue, or Deep Junior asthe case may be, over the long haul

The real strategy for quantitative trading systems is to knowahead of time, through research, the probability of the success of aparticular trade or series of trades, and assuming the odds are inyour favor, to play as often as possible, all the while keeping a closeeye on risk and the changing trade winds (Lowenstein, 2000, p 134).Developing a profitable trading system is no small task,however One options trader we talked to estimates that it takes a

$10 million investment just to get in the game That $10 millionpays for building a network infrastructure, hiring high-levelquantitative analysts and programmers, and conducting at least ayear of research and development before you even make your firsttrade Much of this expense, though, may be dedicated to creatingand installing proprietary software and hardware that connects toexchanges through their application programming interfaces(APIs) APIs can be thought of as “pipelines” to the market overwhich third parties, such as exchange member trading firms, canaccess exchange data and place orders electronically Installingand maintaining a communications network for data andorder execution, however, involves a terrible tangle of inter-connecting hubs, routers, switches, and fiber optics, not to mentionconstant software redevelopment as exchanges upgrade their APIs(Norman, 2001).

Rather than incurring the time and expense it takes to buildfrom scratch, it is also possible and much less capital-intensive tolicense third-party trading software and take advantage of theexchange connections and built-in functionality for data feeds,order entry, and risk management Then proprietary analytics andtrading algorithms can be added on top of this software via theirown APIs Many of these third-party vendors have over 10 years’experience building front-end systems for futures and optionstraders and are, in terms of development, well ahead of even somemajor U.S trading houses (Norman, 2001)

In this book, we will show you how to use Visual Basic.NETand several quantitative tools to begin development of sometrading strategies and to analyze data, and we will share someideas about how to connect to industry software via APIs tomonitor financial markets and execute trades Figure 1.1 showsgraphically how to implement a trading system in this way In thisfigure the arrows represent APIs

One limitation to this architecture, however, is that nosingle front-end trading system connects to all markets around theworld So it may necessary to create proprietary software thatconnects to a multiplicity of front-end trading system APIs toprovide access to all the different markets and products (Norman,

2001, p 175)

The term front-end trading system refers to the “clientworkstation [and software], or order entry point, on the exchangemember local area network (LAN) that a trading firm uses to accesselectronic exchange services” (Norman, 2001, p 242) An exchange

“back end” is the point where an electronic order reaches theexchange and passes through to the exchange’s matching engine(Norman, 2001, p 242) Electronically routed orders pass from afirm’s front end to the exchange back end and then, once the tradehas been executed, again to the front end as a trade-fill confirmation(Norman, 2001, p 243)

In derivatives markets, related products are often traded ondifferent markets For example, Dow futures trade on the ChicagoBoard of Trade, S&P 500 futures trade on the Chicago MercantileExchange, and S&P 500 cash options trade on the Chicago BoardOptions Exchange Shares of IBM stock trade on the NYSE and

F I G U R E 1.1

other stock exchanges, while IBM stock futures trade on OneChicago and NQLX and options on IBM trade on the variousoptions exchanges Given the disparate technological infrastruc-tures and trading rules for the different exchanges, connecting to all

of them for automated trading of related products can be somewhat

of a nightmare

So as you may be able to see from Figure 1.1, it is possible, forexample, to build an automatic hedging device through the type offramework we described MicroHedge is a popular institutionalsoftware package with connections to the options markets AndTrading Technologies’ X_Trader software is a popular front-endsoftware system for futures trading on electronic markets Thus, wecould create a system to trade the CBOE’s S&P 500 cash options, via

a market connection through MicroHedge’s API, that could alsoprovide real-time delta hedging with the E-Mini S&P contract onthe Chicago Mercantile Exchange via connection to TradingTechnologies’ API (Norman, 2001)

As we mentioned earlier, there are four disciplines that go intoautomated trading strategy development: computer science,quantitative finance, trading strategy, and quality development.This is a lot to learn We do not attempt teach you all of it Rather webring together some important ideas from math, technology, projectmanagement, and the financial markets that are required to build areal-world automated trading system

Development Methodology

So what is an automated trading or risk management system, andwhat process do we go through to create one?

A trading or risk management system, as we define it, consists

of the rules for automated entry into and exit from a position orpositions and the technology used to make them happen Theserules are a set of logical or mathematical operations that can bebased upon qualitative, technical, or quantitative research Manybooks and papers currently available outline stock and futurestrading system development from a purely technical analysisstandpoint, often using a retail software package to optimize a set

of trading rules based upon moving averages and oscillators Inthis book, however, we will focus on quantitative analysis ofequities, equity indexes, and options on equities and theprogramming of professional, proprietary software using VisualBasic.NET

Several steps are involved in creating a quantitatively basedtrading system, and while clearly not exhaustive since there areliterally an infinite number of potential quantifiable tradingstrategies, this book presents some of the necessary steps to create

an automated system, with lots of code examples along the way.Before we begin, however, we should define the steps to go through

or the process of creating an automated system

In their paper “An Automated Trading System ment Methodology” (2003), Andrew Kumiega and Ben Van Vlietpropose a process for trading system development that consists offour phases: research and documentation of calculations, backtesting, implementation, and portfolio and risk management

Develop-KUMIEGA – VAN VLIET TRADING SYSTEM

DEVELOPMENT METHODOLOGY

By their nature, all implemented and functioning automatedtrading or risk management systems must manage two concurrentprocesses: (1) trade selection and (2) portfolio and risk manage-ment However, prior to implementation the process of develop-ment should follow a well-defined, well-documented flow of stepsalong a development methodology In 2001, Kumiega and Van Vlietfirst proposed a software development methodology for finan-cial markets that laid out the steps to codify trading and riskmanagement algorithms This earlier model is encompassed withinthis broader methodology, which outlines an entire trading systemdevelopment paradigm

Kumiega and Van Vliet propose a standardized model for thedevelopment of automated trading systems that will ensurerapidity, desired by senior management, and consistent qualitystandards, desired by financial engineers While the idiosyncrasies

of the securities and derivatives trading industries require a uniquesystem development paradigm, this methodology owes a largeportion of its structure to a combination of the traditional waterfallmodel (Royce, 1970) and the evolutionary spiral models (Boehm,1988) The combination of these two models seeks to gain fromtheir respective strengths as well as to overcome their respectiveweaknesses

Waterfall MethodologyThe traditional waterfall model is a very powerful softwaredevelopment methodology and consists of four phases that, ingeneral, map to the four phases of the Kumiega–Van Vliet model—analysis, design, implementation, and ongoing system testing Atthe completion of each phase, the waterfall model requires adecision by management prior to advancing to the next phase Thisdecision is whether or not to continue development of the systembased upon the potential for profitable implementation

In a nutshell, the waterfall model forces financial engineers tothink about the system to be built and to come up with a plan forbuilding it, before they begin construction By following this model,

we can force ourselves to use a disciplined approach to the process

of development and to avoid the pitfalls of creating a system andwriting computer code before the blueprints of the project are welldefined and precisely laid out

The waterfall methodology does have a major drawbackthough: It puts too much emphasis on planning The waterfallmodel necessitates that all details and all plans be defined up frontbefore design and implementation begin That is to say, there is noroom for error and no process for handling feedback or problemsthat occur down the road In the fast-moving financial markets,where trading opportunities come and go quickly, the waterfallmodel may not be able to react quickly enough

As an example, suppose we find in an implementation phasethat a coherent trading idea will be impossibly complex in terms ofthe technology needed to make it happen As a result the projectfails Had the financial engineers been aware of this fact in theanalysis phase, they may have been able to modify the systemdesign so as to enable successful construction The waterfall modelhas no way of handling these types of situations Furthermore,technology these days is changing just about as fast as the marketitself The danger with the waterfall methodology is that by thetime a trading system is ready for implementation, the technology

it was built on may be obsolete and there may be a better, faster,easier technology already on the market

To overcome the shortcomings of the waterfall model, thespiral model was developed

Spiral Methodology

In the spiral methodology a small amount of time is initiallydevoted to each of four phases: research, planning, implemen-tation, and testing, followed by several repetitive iterations orcycles over each of them

As the cycles progress and the spiral gets larger, more detailand refinement are gained in each phase At some final point, it ishoped, each phase will be complete

In this way, the spiral method allows for feedback as problems

in the system are detected A problem can be dealt with either by

correcting it or, if the problem is fatal, by scrapping the entiretrading idea Of course, the truly fatal problem is the prospect oflosses If the system cannot or will not be profitable, for whateverreason, it will be discarded So intermittent or prototypeimplementations can provide feedback about the viability andprofitability of the trading system Also, as new discoveries inquantitative methods and system design are made, the system’sblueprints can incorporate them as they arise.

As with the waterfall method, the spiral method is not withoutits drawbacks The primary problem with the spiral methodology

is that the number of cycles can grow without end, using upresources There are no inherent constraints or deadlines This canlead to loss of project focus, messy logic, and extraneous orunnecessary digressions This is often called scope creep, when thescope of the projects gets continuously larger

As a result, the blueprints may never present a clear andconcise architecture of the trading system So in the spiral model,the cycling process must have a clear condition for termination.This lack of termination is common in Excel-based trading systems

To overcome the problems with each of these methodologies,Kumiega and Van Vliet have combined them into a singleparadigm for trading system development As Figure 2.1illustrates, the four phases progress in a traditional waterfall, butwithin each phase, four elements are connected into a spiralstructure At the completion of each phase, management mustmake a decision before proceeding to the next phase Aftercompleting the fourth and final phase, the methology calls forfinancial engineers to repeat the entire waterfall process forcontinuous improvement The phases are as follows:

Phase I Research and Document Calculations

1 Describe trading idea

2 Research quantitative methods

4 Check profitability.

Phase III Implement

1 Build vision and scope document

2 Build objects and program document

3 Program and document the system

4 Paper-trade and check profitability

Phase IV Manage Portfolio and Risk

1 Monitor portfolio statistics

2 Perform value-at-risk calculations

3 Document profit and loss attribution

4 Determine causes of variation in profitability

Repeat the entire waterfall process for continuous improvement

Here is some brief discussion on the 16 elements listed in theKumiega–Van Vliet methodology

F I G U R E 2.1

PHASE I RESEARCH AND DOCUMENT

in finance One problem is that most traders want to trade, not plan.And the second problem is that most planners never get to tradesince management in financial firms mainly rise from the tradingranks, which means they strive to optimize for the short term.Therefore, in financial markets we have a large number ofsimple systems being built again and again and again However,these simple systems do not result in maintainable excess returns

We have a few firms that do actually implement their long-termplans, and these plans do result in maintainable excess returns Thesmall-sized firms that become mid-sized firms eventually end upbeing sold to large firms The few large firms that continue to buildtheir proprietary systems end up dominating markets The mostinteresting feature of the business is that the best trading andmoney management firms seem to understand this, given the size

of their budgets for proprietary trading system development.Complex trading systems are built one step at a time, evolvingalong the way The first step toward building a trading system isnormally the hardest one It may seem elementary, but being able toclearly articulate a trading idea is extremely important Beingforced to describe an idea has the effect of clarifying your thoughts,

as well as communicating plans and defining goals and themeaning of success The more complex the trading idea, the moretime it takes to define and communicate it clearly

The description of the trading idea should contain the answers

to several basic questions:

1 What market or markets will be traded?

2 What capital will be traded?

a Short term

b Long term

c Midterm

3 Whose capital is it? Proprietary or investor capital?

4 How will success be defined? Is there a benchmark againstwhich to compare the results? Are there competitorsagainst which to compare results?

a Best/worst/average returns for a group

up phase Due to the low barriers to entry, one common situation inthe trading industry is the existence of multiple trading firms withlittle or no focus and, to make matters worse, meager start-upcapital

Research Quantitative MethodsResearch into quantitative methods may be in the form of thederivation of proprietary algorithms or the application of publiclyavailable research or white papers Furthermore, this research mayalso include gaining an understanding of the methodologies ofother successful systems

To be successful at quantitative research, you should take fulladvantage of the available resources such as the Internet andlibraries of academic publications Building a proprietary library ofquantitative methods is key to long-term system and firm success

Books and papers in this library should be cataloged by the author,the firm, and the nature of the quantitative method discussed.

Prototype in ExcelExcel is the most rapid development environment for testingtrading ideas However, large spreadsheets, especially those thatcontain historical data, can become increasingly difficult todocument and manage

Check Profitability

At any point in this or any other of the four stages, profitabilitytesting may show system failure That is, the trading system maynot be profitable This will necessitate a looping back to previousstages The goal is to quickly stop development on trading systemsthat have a low probability of success

PHASE II BACK-TEST

A back test is a simulation of an automated trading system againsthistorical data A back test determines what buys and sells wouldhave been made according to a prescribed set of algorithms.Successful system analysis and design necessitates research intopast market movement as a way to analyze and validate thesystem But not only should back testing confirm the validity andaccuracy of a system’s algorithms; it must also confirm risks andrewards of competing alternative algorithms

Gather Data

It may seem obvious, but being able to gather the necessary marketdata is very important Oftentimes data required may not exist atall or may be too expensive

Clean DataOne of the major obstacles to building a profitable trading system isthe unavailability of clean and timely data Many systems that aredependent upon the analyses of historical data are never fullyimplemented because data is either too expensive or not obtainablealtogether Therefore, prior to starting a project, the data feeds andtheir prices should be determined.

Perform In-Sample/Out-of-Sample TestFinancial engineers are keenly aware of the extent to which in-sample results of model fitting differ from results obtained on out-of-sample data Trading algorithms and quantitative models must

be examined against out-of-sample data prior to moving to theimplementation stage A well-developed system will performsimilarly out-of-sample as it does in-sample It is of courseimportant to save some of your historical data for out-of-sampletesting

Check ProfitabilityAgain, checking the profitability of the system will preventadditional time and resources from being spent on unprofitableprojects We may need to loop back to the initial research phase andreassess the quantitative methods and algorithms

PHASE III IMPLEMENT

Implementation of an automated trading system will requireconnectivity between and interoperability with disparate softwaresystems for trade execution and other processes such asoptimization This will require the creation of plans and blueprintsbefore programming in a language like VB.NET begins

Build Vision and Scope Documents

The purpose of the vision and scope documents is to ensure thatmanagement fully understands the end goal along with theexpected costs of the project before construction starts The visiondocument provides both the financial engineers assigned to theproject and management a brief overview of the current project.The information listed on the vision document should be at a veryhigh level so that the entire form can be completed in a couple ofhours

The scope document should clearly define the steps for theproject along with the documentation of all the detailedinformation about a calculation After management has approvedthe initial project concept and the vision document, then the scopedocument can be completed A full-blown scope document canrange from 2 or 3 pages to over 20 pages depending on the level ofdetail provided Its design should allow for multiple revisionsalong the way This is important in finance since many of the keyitems of a project get revised regularly as the details get flushed outwith prototypes

The following samples of vision and scope documentsprovide some basic information about the project in a consistentmanner from project to project

Project 1

Vision Document

Project Leader: Andrew Kumiega Date: 03/01/03

Project Originator: Ben Van Vliet

Sponsor: Bob Hendry

implemen-Resources:

This section should list the financial engineers involved inthe project as well as other support personnel, includingadditional programmers and hardware support

Project Type: _Formal _Ad Hoc

Initial Priority: A B C D E

Approved By:

Approved Date:

Project 1

Scope Document

Project Leader: Andrew Kumiega Date: 03/01/03

Project Originator: Ben Van Vliet

Sponsor: Bob Hendry

Project Definition:

This section should include a one-paragraph definition ofthe project Also, the project definition should be updated asadditional specifications arise or changes to the specifica-tions are made

Functionalities:

The entire list of functionalities of the application should

be fully documented in this section Beyond whatever may

be the obvious functionalities, here a few important things

to remember:

V Management will likely still want printed reports

V Bulletproof error handling must be incorporated toprevent trading errors due to bad data or erroneoushuman interaction

V The algorithms should be clearly explained

V The graphical user interface, as simple as it may turn out

to be, should be fully laid out

V A complete data dictionary should to be built along with

a data flow map

V Speed of execution is critical for many applications, and

so competing methods of implementation may need to beanalyzed

Steps and Milestones:

The purpose of the Steps and Milestones section is to keepthe project on track The goal is to document at a high levelall the major steps and milestones that are required tocomplete the trading system A simple, but key, element ofthe documentation of the steps is color-coding of work

items These steps should be updated at least weekly asprogress is made on the project.

V Standard black text is used to list steps and milestonesthat are progressing as planned

V Blue text is used to show steps and milestones that havebeen completed

V Red text is used to show steps and milestones that havestopped and are currently placing the project at risk

V Green is used to show scope creep

As we have discussed, scope creep can be the mostdangerous portion of a project as stakeholders requestadditions to the project Unnecessary digressions can doom

a project, and so it is important to focus on specific andrelevant functionalities However, as is typically the case,rejected additions will be used as an excuse if the tradingsystem loses money

Future Features:

This section should describe any additional features thatshould be started after the initial project is completed Thegoal of this section is to contain scope creep

Schedule:

A schedule should be presented in this section done inproject management software such as Microsoft Project.Detailed Documentation of Key Functionalities:

Key functionalities of the trading systems should be fullydocumented—for example, data, I/O, GUIs, calculations,error handling, and reports

Build Objects and Program DocumentBuilding a trading system in code is a bit like building a building.The bigger and more complex the building, the more importantblueprints are to the success of the project Likewise, the morecomplex a trading system becomes, the more important it is tocreate detailed architectural plans before construction in codebegins But how do we create these blueprints? The answer is theUniform Modeling Language (UML) UML is the softwareindustry’s graphical language that enables project designers andprogrammers to communicate the details of software design.Through the use of UML, programming problems can besolved in an object-oriented way before programming begins Asyou can imagine then, financial engineers who want to use UMLmust be familiar with object-oriented programming and theprocess of abstraction and application modeling (Don’t worry Ifyou are not familiar with these concepts, we will show you themover the course of this book.) Models written using UML will help

us visualize and document the structure of a software application

Program and Document the System

Having proved the trading system to be successful through sample and out-of-sample testing, we proceed with the crossoverstage of the system development process In this stage we crossover from Excel’s cell-based environment to VB.NET by convertingthe system’s functionalities into programming code

in-Paper-Trade and Check Profitability

This time when we check profitability, we will have some real-time,live data to go on The last step prior to opening an account andturning on a trading system is paper trading Placing simulatedtrades against real-time market data will give us a true and finaltest of the potential of a trading system

PHASE IV MANAGE PORTFOLIO AND RISKApart from the simplest trading systems, no individual trade exists

in a vacuum Rather, all the trades and subsequent positions will beviewed as a portfolio of positions

Monitor Portfolio StatisticsPortfolios of securities and derivatives require constant monitor-ing No system, no matter how well planned or well built, should

be left unattended A system for monitoring trade limits, riskfactors such as portfolio delta and gammas, and drawdownsshould be implemented and followed strictly

Perform Value-at-Risk Calculations

Value-at-risk calculations will give management a snapshot of thepotential losses given a portfolio However, while methods fordealing with extraordinary occurrences may be built into a tradingsystem, overnight volatility in the form of opening gaps mayrender them useless

Document Profit and Loss Attribution

A good way to monitor the success of a system is to keep track ofindividual trades and their respective payoffs These will bevaluable when reevaluating the underlying premise for the system

Determine Causes of Variation in ProfitabilityProfitable trading systems will not be so forever Eventually, themarket will close the door on our trade So systems will need to becontinuously tweaked, and in the end scrapped.The goal here is toquickly stop trading systems that lose their edge before they causelosses A successfully implemented trading system always requiresongoing profitability assessment

Repeat the Entire Waterfall Process for

Continuous ImprovementContinuous improvement consists of an ongoing effort towardbettering our trading systems When applied to a tradingenvironment, a continuous-improvement strategy involves bothmanagement and financial engineers working together in tradingteams to make small improvements continuously It is top-levelmanagement’s responsibility to cultivate a professional environ-ment that engenders constant improvement A culture of sustainedongoing improvement will focus efforts on eliminating waste in alltrading systems and processes of a trading organization Intelligentcompany leadership should guide and encourage trading teams tocontinuously improve profitability, increase efficiency, and reducecosts

Through small innovations from research and entrepreneurialactivity, trading firms can discover breakthrough ideas These ideasinclude, among other things, the creation of new trade selectionalgorithms, the application of existing systems to new markets, andthe implementation of new technologies for more efficient tradeexecution

SUMMARY

The advantage of the Kumiega–Van Vliet approach is that it allowsfinancial engineers to quickly deliver a prototype for evaluationand specifications prototyped in Excel that are scalable intoVB.NET or some other implementation language If the tradingsystem is deemed to have a high probability of long-termprofitability, financial engineers can proceed down the waterfall.There are four distinct advantages to using this methodologyfor trading system development:

1 The research and documentation stage along with itsExcel prototyping approach provides a mechanism fordocumenting the system requirements and for gainingbuy-in from senior management Financial engineers

should be able to explicitly state and demonstrate thealgorithms and profitability of a trading system prior toimplementation.

2 The iterative framework of documentation, prototyping,and testing of intermediate-level working versions of thesystem allows for feedback and reduces risks before theybecome problematic

3 This methodology allows for step-by-step testing of codedalgorithms against Excel’s built-in functions

4 Time to market is greatly reduced since the Excelprototype demonstrates the profitability of a system in ashort amount of time

The process of doing quantitative research in financialmarkets requires the completion of these four phases ofdevelopment resulting in four models: the algorithms model,data model, implementation model, and risk management model.Over the remainder of this book, each of these phases, and theirsubphases, will be addressed Along the way, we will learn a greatdeal about quantitative finance, Visual Basic.NET, ADO.NET,databases and SQL, object-oriented programming, XML, and UML

1 When developing financial models in Visual Basic.NET,how do we test whether or not our algorithms are correct?

2 What is a trading system?

3 What is meant by continuous improvement?

4 What are vision and scope documents?

5 What is UML used for?