[This message was posted by Richard Labs of CL&B Capital Management, LLC <[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/243e366e - PLEASE DO NOT REPLY BY MAIL.]
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 -~----------~----~----~----~------~----~------~--~---
