database
Dec 09, 2024

Bitemporal TraderX - augmenting a sample trading system

Adding XTDB and Clojure into a sample microservices trading application for the FINOS 2024 Tech Sprint

author picture
Michal Pisanko
Software Engineer
image

Joining FINOS: The Fintech Open Source Foundation

In case you missed the news, JUXT is now a member of FINOS! The Fintech Open Source Foundation (FINOS) is an umbrella organization under the Linux Foundation, whose purpose is to accelerate collaboration and innovation in financial services through the adoption of open source software, standards and best practices.

Throughout August and September I was the lead engineer on a team from JUXT who took part in the FINOS 2024 Tech Sprint - a multi-week hackathon centered around one of the FINOS projects called ’TraderX’. Unlike most of the other projects that FINOS hosts, which are used in production by various member organizations, TraderX is essentially an example system (think ’Pet Store’) that is intended purely for educational and training purposes. TraderX was initially developed by Morgan Stanley.

What we achieved in the 2024 Tech Sprint

Here’s a short video that the team put together which gives an overview of the system and some of the changes we made:

In summary, we:

  • Lightly modified the TraderX microservice architecture to implement blotter history and reporting capabilities based on a central XTDB database that stores bitemporal versions of all data, allowing for strong auditability and correction/adjustment facilities
  • Extended the blotter dashboards to show pricing data, and added ‘sliders’ to control the as-of reporting windows, giving users an ability to trivially understand the evolving state of their portfolio of positions
  • Used XTDB’s bitemporal SQL features to easily model the TraderX domain with limited code changes. The underlying data model now allows for all reference and pricing data to be auditably adjusted, and for all trades to be amended or cancelled retroactively, while providing complete visibility to the end user
  • Opened a PR to propose these changes back to the main TraderX repository

This work was showcased at the FINOS ‘OSFF’ conference in New York in October, where my colleague Jeremy (XTDB Head of Product) also presented on the importance of bitemporality more broadly - you can read/watch more about this here.

Changes implemented in our PR

The existing application has been extended in several ways…

Basic UI Tweaks

Firstly, we cleared up the sample data and added some basic constraints to the Angular UI. We noticed that some initial trades are on the ‘Sell’ side - which should not be possible if the securities sold are not owned - so we changed all the initial trades to be on the ‘Buy’ side and now only allow selling owned securities to the limit of quantity owned - to simulate a real world portfolio.

View of TraderX showing a modified dialog component

We introduced changes to the trade ticket component (used for creating trades):

  • It displays error messages in case some fields are not filled or have incorrect values.
  • Only allows buying if you don’t own selected security
  • Only allows selling up to amount that you own

We added unit prices to the trade blotter. We added market value and cost of transaction to the position blotter. We then added an additional ‘Closed Position’ blotter for displaying positions that have been closed - i.e. show when all securities have been sold, along with final PnL and current market unit price.

New ‘Report’ tab with sliders

We introduced a ‘Report’ tab which displays largely similar data to the ‘Trade’ tab, but using XTDB as backing store. Positions with a net gain (where the cost of buying securities is lower than the current market value) are highlighted in green, while those with a loss are highlighted in red. Positions also have a ‘Calculation’ column representing how we’ve arrived at the current position value (by summing up trades values).

This tab also adds two sliders:

  • Trade timeline slider - allowing the user to quickly understand how trades unfolded (as best known, and ignoring the system_time audit timeline)
  • Price history slider - allowing the user to explore how aggregate positions would appear at a specific past price point (again, using prices and data as best known)

A re-imagined ‘Reference Service’

In support of all these UI additions we created a new microservice to replace the existing ‘reference-service’. It is written in Clojure and is split across several clearly delineated namespaces. This service now does a few things:

  • Fully replaces and supersedes the existing ‘reference-data’ microservice for serving up ‘static’ / lookup data (securities and accounts)
  • Provides bitemporal storage for trades, positions and prices
  • Generates a year’s worth of daily prices (initial value randomly generated, thereafter - last price varied by 10% so that we have an approximation of how prices change over time on the market - prices rise and fall)
  • Generates initial ‘seed’ trades for seven securities for every account within fifteen days before the starting date - so that each account starts with some open positions (and some potentially closed). This gives us realistic demo data.
  • Sends current ‘market’ prices via websocket to the clients (so that the prices displayed in the app are ‘fresh’). Current prices are generated and stored every 10 seconds (to simulate a ‘live market’ price stream).

The reference-service is written in Clojure, which we chose for expedience, but it also neatly showcases how succinct Clojure can be compared to the other language stacks found in the TraderX repo (Spring, TypeScript etc.) The service exposes endpoints using the Aleph webserver and implements streaming using the Manifold library.

The service interfaces with XTDB via vanilla pgJDBC and SQL, which is possible thanks to XTDB v2’s compatibility with the Postgres wire protocol. This also meant that during development we could access the database using tools like VSCode’s SQLTools and Metabase to debug our queries and data, without the need for custom drivers or unconventional tools.

Overall the project was quite straightforward as all the pieces fit together nicely. However, having worked with many other databases previously, I had strong first impressions when picking up XTDB for this project and plan to share more details on that soon. Stay tuned!

Upcoming XTDB Tech Talk on 11th December and a Call for Design Partners

The XTDB team is running a webinar in conjunction with FINOS on 11th December, you can learn more and register for that here.

Finally, JUXT is collaborating with several Design Partners who are using XTDB and helping us discover missing features - we cannot responsibly take on too many partners (as we do need to support those features!), but if you feel like XTDB is the right fit for your problems, please do get in touch: hello@xtdb.com

Recommended Resources
Head Office
Norfolk House, Silbury Blvd.
Milton Keynes, MK9 2AH
United Kingdom
Company registration: 08457399
Copyright © JUXT LTD. 2012-2024
Privacy Policy Terms of Use Contact Us
Get industry news, insights, research, updates and events directly to your inbox

Sign up for our newsletter