KaiTrade Accelerator Overview

KaiTrade has a toolbar that provides its basic functions; extended functions are all loaded as plug-in extensions. The strategy pad is a central part of the KaiTrade system since all strategies (one or more orders) are managed and executed using the strategy pad. The strategy pad uses triggers (internal and external, for example a CQG condition) to initiate strategies for processing.


The plug-in interface and loader are provide an efficient, simple and robust way to add extended functions and an algorithm to KaiTrade – there is a kit for 3rd parties to develop their own plug-ins


The KaiTrade facade gives plug-in and external functions with a single point of full access to the platform. KaiTrade uses extensive use of interfaces and provides a Factory to create objects to simplify the development of plug-in.


The driver manager controls the operation of all the drivers (a driver is used to connect to a broker or exchange) attached to the system; it allows the rest of KaiTrade to have a consistent way to use external brokers so that it is simple to have strategies that use multiple drivers (brokers) in a seamless way.

The drivers are dynamically loaded at runtime based on the user’s profile. The user profile is returned by the sign on server when a user signs onto the system. The IDriver interface defines how all drivers will behave; there are four types of functions supported:

• Order Routing – based on FIX 4.4
• Standing Data/Product definitions – based on FIX 4.4
• Real-Time Data (Prices L1 & L2) – using the KaiTrade internal publish-subscribe
• Time series data and Triggers – using the KaiTrade internal publish-subscribe
  
  
  

At this point in time KaiTrade is working on:

• TT XAPI – under test
• CQG - complete
• FIX – conformance testing
• Photon API (Futurepath) – testing
•  

We are planning to write to TD Ameritrade and Interactive brokers in 2009Q2


The system uses a provisioning system that controls what functions an individual may use, this works with the server that authenticates users access.

© KaiTrade LLC 2009

Thoughts on Plug-INs

I have just about finished the provisioning mechanism for KTA (KaiTrade accelerator) and this will allow us accurately control what features an end user(Trader) can use in the application when they connect/authenticate at startup.

We are now writing a plug-in for a client that needs custom C# functions for thier trading and so have designed a reasonable mechanism for plug-ins that I think addresses some key issues:

Location, you can easily locate a plug-in anywhere on a target PC, the provisioning lets you choose where to load the plug-in from - this may seem obvious, but many plug-in systems control the locations making it hard for a 3rd party to manage their deployment.

Dependences, we have minimal dependencies, the plug-in developer just needs the KTA interfaces assembly to write a plug-in. This is a whole lot better than those cases where the plug in developer requires access to a set of the parent applications assemblies, especially if they will not be put in the GAC during installation.

While we may have some other issues and limitations my hope is that its going to be easy for 3rd Parties to add software to the platform.

The value of Plug-Ins

1 Motivation

Plug-ins are a major part of the KaiTrade Accelerator platform. Our customers want ways to add complex algorithms using C++ and C# for speed and efficiency; our mission is to allow them to do this independently and then add these to the platform to reap the benefits of our connectivity and order handling.

We wanted our own way to extend the product, while managing cost and time to delivery, and keeping the system robust. Separating algorithms and custom user interface elements from the base platform allows true rapid development.

We envisage that 3rd parties will develop or port their algorithms to reach a wider audience; we can provide their developers with the tools they need to do this.

2 KaiTrade Plug-in Support

KTA is able to dynamically load plug-ins, enabling us (and 3^rd parties) to deploy add-on applications as separate offerings to KTA. These can be installed independently from KTA by simply adding the name of the plug-in and the location of its assembly.

The plug-in developer can add a rich set of user interface elements by passing a list of user controls to KTA. These are added to the list viewers from which the user can select. The plug-in is given a reference to the application, which, in turn, gives the plug-in developer access to a factory object, giving access to key components such as the product, order and strategy managers.

KTA makes extensive use of interfaces, enabling the developer to substitute his/her own components, and allows us to let 3rd parties access the key parts of the platform.

In general, a wide range of design patterns is used (Factory, Observer/Publish Subscribe, Strategy, Interface and Singleton) and standards such as FIX Protocol. This helps reduce the learning curve for the plug-in developer.

In summary, we believe plug-ins are a crucial element of any modern trading platform, and it is a top priority to make this safe, efficient and easy to use.