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?
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.
Founder & CTO
Share this article on LinkedIn