Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to do financial trading IT right: Behind the scenes at Liquidnet

Matthew Heusser | July 3, 2013
With massive amounts of data, low latency, hundreds of connection points and no margin for error, financial trading is grown-up IT. Liquidnet does it in more than 40 markets with a staff of just 300. Here's how the company makes it work.

Kutko started at Liquidnet five years ago as a programmer, working on internal trade support applications. He's currently working on a platform that allows late-stage private companies on the verge of going public to let employees and early founders sell shares to strategic investors. This reuses the Liquidnet model for block trading to provide an application that lets buyers purchase institution-sized blocks of private company shares.

Liquidnet's architecture makes this all possible-there's a clean break between the front-end, which is usually Web-based, and the back-end Web Services, Kutko says. Services are generally RESTful, passing JSON, and can therefore be repurposed for any GUI application.

It also means training to write front-end applications is easier. Kutko's teams is programming in Node.js, so developers simply need to know HTML, JavaScript and the company's API to call its Web services and program the user interface. There's no Flash here, Ruby there, Java there and JavaScript over there. That means less specialization, fewer silos of knowledge and more flexibility for programmers to transfer among roles, functions and teams.

In addition, Liquidnet has standardized on Google Protocol Buffers messaging technology, which lets common services communicate in both synchronous and asynchronous patterns. If the customer wants a real-time operation, they can wait for the transaction to finish or put it in the messaging queue. The protocol supports both methods and works both for the trader application, a Windows application written in C#, and C++, along with node.js and Java Web-based technologies.

After chatting with Kutko, I meet Matt Moss, the head of middle office technology. His role involves building that database to connect buyers and sellers, enabling the messaging system that other application teams can hook onto, collecting operations reports and sending them securely to the Order Audit Trail System (OATS) established by the Financial Industry Regulatory Authority. Moss also manages the system test area and a copy of the aforementioned messaging system and database-not only to test his own changes but also as a platform for teams to test changes in a life-like trading environment.

It's not just large, on-off trades, either. The trades often don't quite line up. One company might want to purchase 45,000 shares of one stock, and the other firm wants only 40,000. Or no large institution wants to buy the stock any time soon. To solve that problem, the company has an algorithm that breaks large transactions into smaller ones, then sends them onto the stock exchange in an unpredictable pattern throughout the day so the trades minimize market impact.

Remote Software Pushes Help Make It All Work
As I talk to the software leaders, I keep thinking about that thick front-end client, written for Windows in C#. That means new versions need to get pushed to the desktop, in an environment that is generally highly regulated and (software) change-averse. How does that work?


Previous Page  1  2  3  4  5  Next Page 

Sign up for Computerworld eNewsletters.