alignmentsystems/matchingengine

A toy implementation of a matching engine. Don't use this in the real world, it's a toy!

MatchingEngine

A toy implementation of a matching engine. Don't use this in the real world, it's a toy!

The purpose here was to simply show that for a specific use-case of (a) Low volume (b) Unregulated to no need to conform with IOSCO pFMI

Then a toy can do the heavy lifting and there is no need to pay the big vendor tax for a matching engine.

If you have arrived here thinking this is a fully-featured matching engine ready for prime-time, please leave now.

This is not and will never be so!

matchingengine's Issues

Kill-Switch

Alongside cancel-on-disconnect essential for an institutional exchange

Partial fills

This is something a proper matching engine must have. Maybe one day to implement this.

Downstream feed - Hyperledger fabric

The FIX drop-copy feed listens to Kafka and transforms AlignmentSBE to classic tag=value FIX4.4.

Take the Kafka listener and then use that to take the binary message and send that into Hyperledger fabric.

Consider idempotency, deduplication, throttling, stability and associated high-availability and disaster recovery requirements.

24x7 Operation

This would be relatively easy to follow the guidelines available here from the work by the working group

To deliver this we would also have to modify one of the dependencies of the Alignment Matching Engine. The dependency is QuickFIX/J which is not 24x7 compatible – yet!

Market Data Enhancements

Provide an orderbook snapshot service on a periodic basis over UDP/Multicast

Provide an orderbook replay service over TCP/IP

Persistence de-coupling

Allow the PersistenceServer component to have an API drive abstraction to allow multiple destinations such as a file system, RDBMS, message queue and so on...

Cancel-on-disconnect

This is something a proper matching engine must have. The challenge is to implement the logic at a scale that fits the use-case – consider the logic in an institutional equity exchange versus an institutional options exchange. The throughput requirement is quite different in each case. Do you “spoof” incoming FIX cancel messages or iterate through an orderbook in-memory and remove affected messages?

FIX Orchestra

As the creator of the forerunner to FIX Orchestra FIIDL (FIXInteractive Interface Definition Language) and the person who chose the name FIX Orchestra, I have been involved since the start. See for example this and this.

Implementing FIX Orchestra for the Alignment Matching Engine is one quick win which is a solid contender for future development after implementation of cancel-on-disconnect and partial fills.

Counterparty Static Data

Allow a counterparty to have specific static data
Collection of Connections
Yes/no cancel-on-disconnect flag
Self-trade-protection
FIX Version

Scaling-out

At the moment the whole platform runs on one box. This is not viable for production use. The APIs between the components would need to be reworked inside the implementation, such that

the number of FIX engines can be increased and distributed to multiple boxes
the number of OrderBooks can be increased and distributed to multiple boxes
market data distribution can be performed from a specified set of UDP/Multicast ports

Binary Order Interface

An implementation using SBE, SOFH and FIXP can provide a fast to parse message format that can contribute to a low-latency environment. Parsing, coercion and other requirements of the string-based FIX message format mean that moving to a binary interface is a worthwhile performance improvement.

Volume testing

This is a much more complex task to see the real bottlenecks in the platform. Use something such as Corvil to spot problems.

HA/DR

This is something a proper matching engine must have. Along with the thematically linked cancel-on-disconnect. This impacts on all aspects of the system – persisting parts of the system data to disk while not impacting performance is a balancing exercise.

GraalVM

See https://hackernoon.com

GraalVM home

Gradle plug-in

Tick database

Persist tick-by-tick data
Column store database

Downstream feed - Classic FIX drop-copy

Implementation of a standard FIX drop-copy feed from the matching engine.

Gradle Package Deployment

See https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-gradle-registry