[This message was posted by Srihari Adya of Siemens <[EMAIL PROTECTED]> to the "Algorithmic Trading" discussion forum at http://fixprotocol.org/discuss/31. You can reply to it on-line at http://fixprotocol.org/discuss/read/795a5c6e - PLEASE DO NOT REPLY BY MAIL.]
How can I thank you Rick? Thank you so very very much :) > Srihari, > > >I am a student in 7th semester of engineering. I want to build a mini- > >stock exchange. > > Wow! that's a very cool project. The key to completing it will be to > limit functionality to the bare bones. Otherwise the complexity is going > to bog you down. > > FIX is a HUGE specification. For now I suggest you try only to learn the > barest minimum to build your mini-stock exchange. You can go back later > and expand the model after that. > > In FIX look at: > > newOrderSingle for equities only, for a single type of order: limit, > good for the day only > > Remember that an exchange is really like two ebay type auctions going > on, back to back: > > 1. put SHARES on the auction block and sell to the highest bidder of > CASH. (Bids) 2. put CASH on the auction block and sell it to the > highest bidder of SHARES(Offers) (OK, the quantity of shares is > what’s fixed by the auction house, and quantity of cash varies, > however you get the idea. At the end of the day cash leaves the > auction house and shares arrive on this side. ) > > Start the day by opening each auction. Build the order book just prior > to the open. The exchanges then matches any possible trades, reports > executions and takes those defunct bids and offers off the order book. > > To make life easy for you, just use FIX to send the FIX newOrderSingle > Messages to the exchange and have the exchange generate FIX execution > messages back to the "winners" as they occur. > > Figure the Exchange reports the order book data, and the last sale price > and volume data in any format they wish (not necessarily FIX). So don't > get hung up with using FIX here. Just throw that data up in a grid > window and deem it "distributed to the whole marketplace." > > Skip all the parts about FIX heartbeats, setting up sessions, > check summing, FIX engines, etc. Just figure out how to format two > messages on top of an assumed reliable message pipe: > newOrderSingle and ExecutionReport. NewOrderSingle goes in one > direction only - to the exchange, ExecutionReport goes in one > direction only - from the exchange. > > Take a look at the following excel spreadsheet which has the entire Fix > 5.0 data model. > > http://www.itsdoc.org/wiki/tiki-file_galleries.php Fix Related -> FIX 5 > Data Model > > Start with MsgType tab and limit to "SingleGeneralOrderHandling" then > you see the two messages you want: > > ExecutionReport - note that is MsgID 9 NewOrderSingle - note that > is MsgID 14 > > For now just ignore the rest. > > Once you know the the MsgID's (9 and 14 above) go to the msgContents tab > to look up the contents. Just set the column MsgID to limit to 14 - > NewOrderSingle > > O.K. freak out - there are a lot of fields! But wait, most are > not required, so go to the column Reqd and set that to 1 (true) > That's better. > > However some rows are for components (groups of fields) vs just simple > fields, In this case for a newOrderSingle the groups are: StandardHeader > (1024) Instrument (1003) OrderQtyData (1011) StandardTrailer (1025) > > No problem, just "drill down" into each group. Set the MsgID to that > number (eg 1024 for StandardHeader) and you will finally see the > individual fields that make up that group (yes, there will be many > optional fields you can ignore). > > Once you know all the fields you want in your message you can go to the > fields tab and get full instructions on what goes into that field, how > to format it, and then on to the enums tab to get any enumerations. (Try > only to use the minimum enums you need. No need to support them all!) > > Once you can do all that, build your exchange and turn your project into > your professor. > > Forget for now anything about how your exchange will actually settle up > the trade (collect cash from one party, pay to the other; collect > securities ownership from one party, transfer ownership of those > securities to the other. Those transactions are not in FIX protocol > anyway. Welcome to standards wars, turf battles, impediments to straight > through processing, etc. ) > > AFTER THAT, look at the following: > > http://www.fixprotocol.org/documents/2518/MDOWG_Book_Mgt%20v20.doc Book > Management Recommended Practices Version 2.0 - This document explains > the proper conventions for managing an order book using FIX message > formats and attribution. > > That's really how you do your order book. Then again if you are building > an exchange be sure to also hire HPC people to do the internal matching > algos and tweak the exchange hardware and communication circuits for > maximum performance. And set up the regulatory/surveillance/audit > department to police everything to keep the markets clean. Charge > outrageous fees for the market data. Figure out how you will hook into > other markets so you can display only the Global Best Bid and Offer > (including bids and offers outside your exchange system). Figure out how > to price trades (usually large discounts for people who post liquidity > vs. people who hit liquidity and remove it, so add those data hooks). > Sell memberships in the exchange but be aware that those members will in > turn resell access via those connections to others Called "Sponsored > memberships" in the U.S. Then try to regulate what those "sponsored > members" are actually doing at any particular point in time. Bottom line > - things get very complex very quickly. > > and see > > http://trac.marketcetera.org/trac.fcgi/wiki/Marketcetera/Simulators > > That is a very nice market simulator. > > Remember the FIX protocol covers a very wide territory. Most of the time > you only need a few parts of it. At the newOrderSingle level its very > straightforward and simple to learn. Get your tag=value pairs lined up > and send them out. Once you have mastered the basics you can ramp up the > complexity of dealing with more esoteric things. > > Also note too - the specification is not "tight". It only provides a > general environment that is part of a full, detailed, specific > implementation. From FIX you must have detailed information from the > counter party on exactly how they have applied it. Without that > information the FIX specification alone is too loose. A huge reason to > have a FIX engine is to store all that "customization data" which is > highly specific, party-to-party. In building your exchange simulator you > are going to have to provide the specific choices for your system (e.g. > are you going to trade with security symbols or are you going to require > CUSIP numbers? What will your targetID be? How will you validate the > inbound orders?). > > Remember the FIX protocol has evolved from a handful of point to point > links with counter parties agreeing each time on the specifics. > > Most large firms have a single person (or more) dedicated 100% to > working on FIX connectivity. The estimated cost to implement FIX just > a few years ago was minimally $50/k year for FIX engine, a few > dedicated IP lines, related software and minimal support, etc. Some of > that has changed with lower cost Internet connections VPN's etc. > However much of that point-to-point heritage and party by party > detailed requirements remain. > > Rick [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
