Contents in h1 headings alphabetical order apart from Introductions(top) and Glossary (bottom) headers

Mule Connector Building and Installation mule transport currently on Riscton svn, and requires a 1.5.3 build of quickFix form the sourceforge svn http://sourceforge.net/p/quickfixj/code/HEAD/tree/tags/QFJ_RELEASE_1_5_3/

Currently builds to a usable jar, not a dev kit connector

Using the Connector The two expected uses cases are

• using the connector as a client
• using the connector as a server
• configuration options
• persistence (jdbc etc)

Options: Mule instance running a Fix inbound endpoint Saves to Riak instance locally Testing and Demo-ing

Part I The goal is to demonstrate a high volume mule fix implementation ideally both client and server.

• the primary goal is to demonstrate qfix
• a nice to have is to have nosql db in the mix to show how modern and cool we are

Part II

• Quickfix/J the library used in the mule connector uses “Session state storage plugins either: JDBC, File, SleepyCat/JE, In memory”. It would be nice to try levelDb which is the latest thing in fast file storage.

Quickfix to Mule Devkit http://www.mulesoft.org/documentation/display/current/Using+the+DevKit+Maven+Archetype+for+Modules

To create a custom module:

mvn archetype:generate -DarchetypeGroupId=org.mule.tools.devkit \ 
-DarchetypeArtifactId=mule-devkit-archetype-generic -DarchetypeVersion=3.4.0 \
-DarchetypeRepository=http://repository.mulesoft.org/releases/ \ 
-DgroupId=com.mycompany -DartifactId=cool-module -Dversion=1.0-SNAPSHOT \
-DmuleVersion=3.4.0 -DmuleModuleName=mule_qfix \
-Dpackage=com.ricston.muleqfix \
-DarchetypeRepository=http://repository.mulesoft.org/releases

then the module needs to be annotated to expose the services, where mulesoft’s documentation goes very vague (shit!!) .The list of annotations are at: http://www.mulesoft.org/docs/site/devkit/3.4.0/

Also handy the DevKit Glossary: http://www.mulesoft.org/documentation/display/current/DevKit+Glossary

Caveats outbound endpoints go to “wrong” flow endpoint outbound refs go to flow inbound endpoint defined in the config for the outbound refs

Example Fix conversations use http://www.critchley.biz/js/FIXProtocol.html to decipher rejection (in bold)

Membership Enquires: Andrew Salgado - Andrew.Salgado@fixprotocol.org EMEA: Daniella Baker Daniella.Baker@fixprotocol.org

FIX general Info documentation Links

These are very helpful when reading FIX manuals because you can look up the FIX numbers in the specification to see the grand scheme of things.

For example you can look up the tag number 70 here and it will tell you all about it. specification for the FIX versions http://www.fixprotocol.org/specifications/ latest version(5) is here:

• http://www.fixprotocol.org/FIXimate3.0/?language=en&version=FIX.5.0SP2

Allocation <J> message http://www.onixs.biz/fix-dictionary/4.0/msgType_J_74.html Common fix tags (put tags in here if you feel they are good to know) Perhaps create your own picture memory aid in your head to remember the numbers better body fields never appears in the header fields

Header fields Body fields

Use “[N/A]” for products which do not have a symbol|

Generally speaking, the correct response to an invalid message is just a session level reject (message type 3) that includes a sequence number of the message that it refers to in tag# 45 (RefSeqNum). The rest.. http://stackoverflow.com/a/15468348

You cannot really test “performance” until you are connected to the exchange - most exchanges provide a development connection http://stackoverflow.com/a/15746652

Synchronous or Asynchronous processing strategies with fix.. Under the queued-asynchronous processing strategy, the receiver does not have to wait before accepting the next message, and the processing speed for the rest of the steps in the flow is effectively multiplied, because multiple messages are being processed at the same time. However, the increased throughput facilitated by the asynchronous approach comes at the cost of transactional reliability. Also, the queued-asynchronous approach, which uses two threads to process each message, is not suitable for request-response exchange patterns, which need to be performed entirely on a single thread.

Mule Solutions Saving bulk data

fields ValidateFieldsOutOfOrder=N Quickfix by default puts that as Y, can cause problems with repeating Groups Testing Using the pure Fix J library Load Testing (NewOrderSingle x 100000 - sent via client.dispatch in for loop) For an initial stage of testing we have currently setup 2 separate multithreaded tests for a NewOrderSingle to indicate how scalable the mule FIX endpoints are.

The first thread (really just the load client) performs like so:

	@Test
    public void loadTestNewOrderSingle() throws Exception {
   	 
   	 MuleClient client = muleContext.getClient(); 
   	 for (int i = 0; i < Executor.MAX_REQUESTS; i++) {

   		 client.dispatch("http://localhost:5552", new DefaultMuleMessage("", muleContext));
   	 }
   	 
    }

on the processing side of things we had 2 approaches to the Executor (The logic for the FIX server). In both cases we had use static thread safe variables so that the testing thread could verify the results of the FIX processing thread.

 
public class Executor {
    
    public static Long MAX_REQUESTS = 100000L;
    
    private static long nanoSecsStart = 0;
    private static long nanoSecsEnd = 0;

    public static AtomicLong requestsReceived = new AtomicLong(0);

public void processMessage(quickfix.fix41.NewOrderSingle order){

//logic for ExecutionReport goes here

//increment the static var so that the other thread can get the info of requests received
long requests = requestsReceived.incrementAndGet();   

if(requests == MAX_REQUESTS) {
//get the cpu time the thread has been running
   		 nanoSecsEnd = ManagementFactory.getThreadMXBean().getCurrentThreadCpuTime();
   	 }
}

Test 1 VM outbound We tested 100000 messages being sent to the FIX engine with a vm receiving the Excecution reports: Current issues We are finding significant bottlenecks

Test 2 JMS outbound We tested 100000 messages being sent to the FIX engine with a JMS queue receiving the Execution reports: Current issues We are finding significant bottlenecks

Test 3 invoking the Flow directly very poor performance, about 100/s

org.mule.construct.Flow flow = muleContext.getRegistry().lookupObject("client_invoke");

   	 for (int i = 0; i < 100000; i++) {
   		 MuleEvent x =  getTestEvent("hello");
   		 flow.process(x);
   	 }
</code<

Test 4 Sending an array to the vm
 sending an array to the vm got me about 2000 fix messages processed a sec

<code>
  <vm:inbound-endpoint exchange-pattern="one-way"
   path="testFixOutboundBatch"></vm:inbound-endpoint>

  <foreach collection="#[payload]">
   <fix:outbound-endpoint ref="clientEndpoint" />
  </foreach>

 </flow>
	@Test
    public void loadTestNewOrderSingleBatch() throws Exception {

   	 MuleClient client = muleContext.getClient();

   	 quickfix.fix41.NewOrderSingle data[] = new quickfix.fix41.NewOrderSingle[10000];
   	 for (int i = 0; i < data.length; i++) {
   		 Random rand = new Random();

   		 quickfix.fix41.NewOrderSingle newOrder = new quickfix.fix41.NewOrderSingle(
   				 new ClOrdID(Long.valueOf(
   						 System.currentTimeMillis() + (rand.nextInt()))
   						 .toString()), new HandlInst('1'),
   				 new Symbol("LNX"), new Side(Side.BUY), new OrdType(
   						 OrdType.MARKET));
   		 newOrder.set(new OrderQty(1));

   		 data[i] = newOrder;
   	 }
   	 client.send("vm://testFixOutboundBatch", new DefaultMuleMessage(data,
   			 muleContext));

   	 Thread.sleep(1000000);
    }



  <vm:inbound-endpoint exchange-pattern="one-way"
   path="testFixOutboundBatch"></vm:inbound-endpoint>

  <foreach collection="#[payload]">
   <fix:outbound-endpoint ref="clientEndpoint" />
  </foreach>

 </flow>
	@Test
    public void loadTestNewOrderSingleBatch() throws Exception {

   	 MuleClient client = muleContext.getClient();

   	 quickfix.fix41.NewOrderSingle data[] = new quickfix.fix41.NewOrderSingle[10000];
   	 for (int i = 0; i < data.length; i++) {
   		 Random rand = new Random();

   		 quickfix.fix41.NewOrderSingle newOrder = new quickfix.fix41.NewOrderSingle(
   				 new ClOrdID(Long.valueOf(
   						 System.currentTimeMillis() + (rand.nextInt()))
   						 .toString()), new HandlInst('1'),
   				 new Symbol("LNX"), new Side(Side.BUY), new OrdType(
   						 OrdType.MARKET));
   		 newOrder.set(new OrderQty(1));

   		 data[i] = newOrder;
   	 }
   	 client.send("vm://testFixOutboundBatch", new DefaultMuleMessage(data,
   			 muleContext));

   	 Thread.sleep(1000000);
    }

What are most common issues encounter when two FIX Engine communicates ? When Clients connect to broker via FINANCIAL INFORMATION EXCHANGE (FIX) protocol, there FIX engine connects to each other, while setting up and during further communication many issues can occur below are some of most common ones: Issues related to network connectivity Issues related to Firewall rules Issue related to incorrect host/port name while connecting. Incorrect SenderCompID and TargetCompID Sequence Number mismatch Issue related to FINANCIAL INFORMATION EXCHANGE (FIX) version mismatch

What happens if Client connects with Sequence No higher than expected? If Client FIX Engine connects to Broker Fix Engine with Sequence Number higher than expected (e.g. broker is expecting Sequence Number = 10 and Client is sending = 15). As per FINANCIAL INFORMATION EXCHANGE (FIX) protocol Broker will accept the connection and issue a Resend Request (MsgType=2) asking Client to resend missing messages (from messages 10 -15) , Now Client can either replay those messages or can issue a Gap Fill Message (MsgType=4 as per FINANCIAL INFORMATION EXCHANGE (FIX) protocol) in case replaying those messages doesn't make any sense (could be admin messages e.g. Heartbeat etc). Useful Links http://stackoverflow.com/questions/2959788/good-tutorial-about-the-fix-protocol http://stackoverflow.com/questions/tagged/fix# Interview Q&A’s http://javarevisited.blogspot.com/2010/12/fix-protocol-interview-questions.html

http://www.critchley.biz/js/FIXProtocol.html Commerical Fix solutions Fix analyser http://javarevisited.blogspot.com/2011/04/fix-protocol-tutorial-for-beginners.html

• Order Types What is NewOrderSingle, OrderCancelReplance and OrderCancel Reject message? These are the basic, most commonly used messages in Electronic trading via FINANCIAL INFORMATION EXCHANGE (FIX) protocol. NewOrderSingle message is denoted by MsgType=D and its used to place an Order, OrderCancelReplace Request is modification request denoted by MsgType=G in FINANCIAL INFORMATION EXCHANGE (FIX) protocol and used to modify Order e.g for changing quantity or price of Order.

* OrderCancelRequest is third in this category denoted by MsgType=F in FINANCIAL INFORMATION EXCHANGE (FIX) protocol and used to cancel Order placed into Market. Funari Order type? Funari is very popular Order type commonly used in Japanese and Korean market , its denoted by OrdType=I in FIX protocol , In Funari Order type Order will remain in Market as Limit Order but during Market Closing period , if there is any unexecuted quantity then it will turn into a Market Order.

• Orders Order: the quantity of some security that a portfolio manager wishes to buy/sell, independent of a broker/dealer. Odd lot and Board lot In Exchanges every Security traded in lot e.g. lot of 1, 10 or 100 or 1000. These are called Board lots and while placing order clients need to send Order quantity multiple of Board lot. If Clients sends any Order which is not a multiple of Board lot then its called Odd lot.

* Placement: the quantity of some “order” placed with a given broker/dealer (note that “placement” is defined just to avoid any confusion with the use of “order”) A given placement has an associated set of buy-side compliance constraints (e.g. agency/principal, no cross). A FIX placement uses the FIX New Order message and is identified by the buy-side ClOrdId(11) chain and sell-side OrderId(37) Placement-block: the set of executions from one placement. Allocation-block: a set of trades allocated by a given AllocationInstruction for one or more placements. The allocation-block is the traditional unit of communication between buy-sides and sell-sides (OASYS® allocation instructions specify blocks). Initial blocks are formed by aggregating executions from a given FIX placement. Typically the initial single-placement block is also the allocation-block, but in some cases placement-blocks are combined into larger allocation-blocks or split into smaller allocation-blocks. In these cases one side requests the other, for some block, to “know” the block as the combined or split quantity so that the allocation instruction will match. The allocation instruction references the aggregated block size. Note that placements combined by the buy-side into a single allocation-block/ticket are assumed to comply with the same set of conformance constraints. “Ticket”: common term used to identify allocation-blocks (e.g. start a new “ticket” for this placement). Block characteristics: broker, instrument, side, quantity, average price, trade-date Transaction: the account-level allocation Account Instrument, side, Quantity, average price, trade-date Transaction-id A buy-side generated identifier associated with each account-level allocation/transaction (account, quantity, average price, …) Allocation instruction components Allocation block characteristics Placements to be allocated Allocations (or transactions) Matching: the sell-side process of identifying the placements for a given AllocationInstruction message. The matching process can be performed by an intermediary (“central-match”) or bi-laterally (“local-match”) with no intermediary involved. Note that since equity allocations are average priced there is no direct linkage from an allocation instruction to specific FIX execution reports, only to the aggregated executions of placements. The process can be mathematically based upon the quantity and average-price of the placement and the quantity allocated from the placement. Economic match: matching by characteristics - instrument, side, quantity, trade-date, total and average price. The probability is low, but with automated economic matching algorithms the buy-side exand sell-side are not guaranteed to associate the same trades with the allocation. Generally, in economic matching, when the allocation-block is different from a placement-block some out-of-band communication is required to assure both sides are talking about the same set of trades. Exact match: matching by some identifier (i.e. ClOrdId(11)/OrderId(37)). ID-based exact matching can be automated, and then the buy-side and sell-side are assured that they are both referring to the same trades. Confirmation / Affirmation: after placements are allocated into transactions, the sell-side reiterates the final details (Confirmation) and the buy-side reviews and agrees (Affirmation). Parties Order origination firm: firm placing the orders Executing broker: broker executing the trades Clearing broker: broker responsible for clearing and settlement Broker of credit: broker of credit is paid some/all of the commission by the executing broker but the transaction is still cleared and settled by the executing broker. Step-out: refers to the complete transfer of transactions from the executing broker (step-out) to another broker (step-in) for clearing and settlement. Post-trade Outsourcing Some execution brokers outsource post-trade processing to another (clearing) broker.

Central Orderbook The use of a Central Orderbook is typical of electronic equity markets where executable orders are placed into a book, sorted by price, then time. A client can expect to execute at the price of the best order in the book or better. The markets are usually anonymous where the displayed price is firm and available to all parties. Precision and Depth A Central Orderbook is characterized by two fundamental concepts; Precision and Depth. Precision refers to the level of detail at which a book is kept and may be summarized by price level or comprised of individual orders. These are referred to as Price-Depth (Aggregate Order Book) and Order-Depth (Non-aggregated Order Book Detail) respectively.

Warrant Warrant is a financial product which gives right to holder to Buy or Sell underlying financial security, its similar to option with some differences e.g. Warrants are normally issued by banks while options are primarily traded in exchange.

Settlement of Securities? When Settlement does occur? In Simple term Settlement means money will deducted from buyers and account and security(Shares) will be credited to his account , normally Settlement occurs after few days of trade date for most of the exchange its T+3 (i.e. Three days after trade date) , T denotes Trade date means the date on which transaction has taken place. For some of the exchanges e.g. NSE India, SEHK Hongkong its T+2.

• Groups Repeating Groups QuickFIX has the ability to send messages containing repeating groups and even recursive repeating groups. All repeating groups begin with a field that indicates how many repeating groups are in a set. A group can be created by referencing a class named after this field scoped within the parent message or group

• Related Financial Glossary Collective Investment Vehicle (CIV) A collective investment vehicle is any entity that allows investors to pool their money and invest the pooled funds, rather than buying securities directly as individuals.