Name: Tom Beynon

Company: Formulate Digital & LiquidityChain

Job Role: CTO

Personal bio/overview: Tom has been building web applications his entire career - he quickly found himself working with the likes of ITV and McDonalds after proving he has an outstanding talent for delivering complex products with accuracy, speed and intuition. Since moving to Formulate Digital, the technical partners for LiquidityChain, his role has been to lead the development of LiquidityChain as CTO.

Q: What first excited you about working on LiquidityChain?

A: LiquidityChain is an awesome project to work on - it’s a distributed, micro-service oriented application; which means instead of building a single ‘monolithic’ application, we instead built a number of separate ‘services’, each with very clear responsibilities, which work together to provide the full application. This is quite different from how a normal marketing website would be built, so it provided an interesting challenge to architect and build.  

Q: What was the reasoning behind the key technical elements which make up LiquidityChain? 

A: LiquidityChain is primarily built in Ruby with a Javascript front-end. Ruby is our language of choice at Formulate; it allows us to build large applications very quickly, and with very clear code. To make it scalable, we built it as a number of separate ‘services’, each of which is load balanced and independently scalable. We’re expecting high volumes of traffic, particularly during peak times, so it was very important to make sure the was no single point of failure in the application. A message queue is used to provide the backbone of the system; system events such as a pairing occurring is posted onto a queue, and each service can read from these queues and action as required. Some of the services also expose REST APIs which the application uses to get data to show to the user.

Q: What has been your favourite thing to build? 

A: The most exciting part of the system was definitely the pairing engine. This uses ElasticSearch to query and aggregate the huge amount of data we have in the system, and determine which of our user’s interests are suitable for pairing. NASA use ElasticSearch to aggregate data from the Mars Rover, so you can image the scale of data it’s able to deal with!

Q: How did you approach the challenge of securing sensitive information the platform gathers from users?

A: Security was the first and most important consideration for LiquidityChain; we know how important our users’ data is to them, and how it MUST be kept secret. To provide the first line of defence; each of the LiquidityChain services is firewalled to only allow access where required. Only two of the services are public facing; the rest are restricted to only allow access to the other servers in the LiquidityChain network, and on the specific ports they require. 

The second line of defence is achieved using API tokens. Each service only allows requests with a valid API token, and each service has a unique token to communicate with each of the other services. 

Users are required to login using 2 factor authentication; once they’ve gained access with their email and password, a one time passcode is sent to their mobile device which must be provided to the system before access to the application is granted. Authentication is provided by a dedicated service which returns OAuth style tokens; a short lived access token, and a longer lived refresh token. 

These tokens are stored and checked by the server on each request, and are never exposed to the client. One final unique token is generated and provided to the client and restricted to an IP address and device fingerprint. A user is only allowed access if all of these different measures are provided and validated. 

Using a number of different security factors means we can be a sure a user is who they say they are, and that we can prevent access to anyone who seems to have malicious intent. 

Q: How is LiquidityChain built for scalability?

A: This is all related to what I've touched on earlier - LiquidityChain is a micro-service oriented system. Having dedicated applications to provide each part of the system means each service can be scaled independently; both horizontally (more servers) and vertically (bigger servers). Each service is behind a load balancer, which is able to check the current load for the various servers it controls. If it detects that any servers are struggling, new servers will be spun up automatically to provide more capacity. This can happen almost immediately, meaning we can handle huge spikes in traffic, incredibly quickly. This setup is also able to detect any application failures and replace the servers automatically.

The application has also been developed with the expectation that additional client applications will be developed in the future. For example, an iOS and Android application is very much on the horizon. Because of this, it was even more important that clear APIs were developed, and made as scalable as possible to handle this increased load when it does happen. I can totally imagine a Watch based application being developed soon after, using the same APIs,  which will allow you to keep an even closer eye on your pairings!

Q: Where could integrations with other innovative teams take this network? 

A: LiquidityChain has some extremely powerful search and aggregation functionality, so I’d love to provide a search and statistic service to any FinTech company that has a use for it. We see LiquidityChain becoming a single point of reference for liquidity in the bond market, and to provide this data via APIs to other companies would be a great integration for both parties. This could even go a step further with automatic feeds from trader’s portfolios being pushed into LiquidityChain, and immediately providing them with an indication of the amount of liquidity in their portfolio. 

Q: What is your ethos moving forwards, for adapting the platform? 

A: We will be working very closely with our day-one partners to further determine their uses for the platform, and see where we could improve existing functionality or provide new features to suit their needs. Ultimately this system is entirely dependent on traders using it and uploading their portfolios, so it’s imperative we implement the features they need, in a way that streamlines their processes as much as possible. It’s also critical that we retain the dark pool restrictions we have to adhere to from a legal standpoint.

Richard Smith

Richard Smith
Founder & CTO


Share this article on LinkedIn

Press Enquiries

Right now, we are focused on creating the best possible product. Please get in touch to request updates and further information.

Become a Press Contact

Keep Me Updated

If you'd like to be the first to hear our news, delivered straight to your inbox sign up here.

Keep Me Updated