A regulated exchange is a big complicated way to facilitate one thing – bringing buyers and sellers together to trade in a legally and regulatory compliant manner.
Behind that simple one line are a considerable number of other features that are required within the value chain (not necessarily within the same firm)
- For CSD based equities, a delivery-versus-payment mechanism to ensure that no-one loses all of their stock or cash.
- For a derivative exchange a clearing mechanism that can calculate IM and VM and ensure member margin accounts are maintained to a sufficient balance
- Market surveillance to ensure bad actors are kept out of the market
- FIX Connectivity for orders/executions
- FIX Connectivity “drop-copy” for post-trade workflow
- Binary market data over UDP/Multicast for latency sensitive firms
- Integrations with market data vendors such as Activ, Refinitiv, Bloomberg and many more
- Co-location offering
- KYC/AML/CFT processes to ensure regulatory compliance
- Persistent storage for instrument static data
- Persistent storage for member data
- Persistent storage for connectivity configuration data
At the heart of it though is what is a very simple set of functions within a software application:
- Receive orders from member firms
- Add an Order to an OrderBook. That Order then does one of three things (potentially more than one sequentially)
- executes in full
- executes in part
- rests on the order book
- Manage the state of the order book
- Any execution must be notified back to the member firm that sent the order
- Any execution must be notified to market data recipients with the appropriate level of anonymity
As a odd-and-ends project I decided to see how hard it could be. The parameters/constraints are:
- Implementation in Java using OpenJDK
- Use a sensible number of threads (Client Simulator, Main, one thread per order book)
- Use of QuickFIX/J with FIX 4.4
- No High Availability
- No Disaster Recovery
- Write clean code – use annotations, enumerations, interfaces, constants, exceptions
- Write the code so that JavaDoc can execute to provide documentation for developers who look at this in the future.
- Do not spend more than six days on this.
- Use MIT license and open-source the whole thing
- Use https://github.com/AlignmentSystems/MatchingEngine
- Build in client simulators such that orders & executions can be sent in.
- Build a stub for market data, if possible use SBE-FIXP-SOFH for the market data implementation (start with TCP/IP unicast but again, if possible, switch to UDP/Multicast for the Transport)
- Limit Orders only (I have promised myself I won't got into a market microstructure rant but unlike some exchanges I think there is an imperative to ethical behaviour in system architecture)
- Simple partial fills as first implementation with order restatement and more realistic behaviour to follow
Let’s start from a blank piece of hardware. To encapsulate and isolate the matching engine from your existing environment we will use VirtualBox to create an instance of Ubuntu on which to develop the software.
Then download Eclipse, Gradle and QuickFIX.
- https://www.virtualbox.org/wiki/Downloads
- https://ubuntu.com/tutorials/install-ubuntu-server#1-overview
- https://www.eclipse.org/downloads/
- https://gradle.org/install/
- https://quickfixj.org/downloads/index.html
- https://github.com/AlignmentSystems/MatchingEngine
Serious footnote PLEASE READ THIS....
To be clear, this is NOT a project to build a real-world matching engine. If you want one of those, there are numerous vendors in the space with whom I have worked and retain positive relationships.
This is also not, Clarkson jokes aside, a showcase for my ability to write Java.
This was a way to fill in some quiet time and work some parts of my brain that have not been in day-to-day use for a while.
Comments
Post a Comment