Getting Closer to the Metal in Financial Technology

At ValueStream Labs, we’ve seen an explosion of early stage financial technology. An unprecedented number of individuals are leaving their roles at established financial institutions and stepping into more entrepreneurial shoes. The availability of new Web frameworks (like Ruby on Rails) and the abundance of developers in New York City allow a person to experiment, and these individuals often view technology as a way to automate and scale their previous position.

We love meeting entrepreneurs with a deep understanding of their industry -- even more so when they’re leveraging technology in their next endeavor -- but what really excites us is when we see entrepreneurs getting closer to “the metal.” In programming, “getting down to the metal” refers to a developer’s decision to forgo pre-built frameworks in favor of working in a more base-level computer language. While frameworks allow entrepreneurs to develop rapid prototypes, they sometimes come at a serious performance cost -- every layer the developer adds to the technology stack increases the computing cycles required for execution.

If there is one thing we know about Financial Services, it’s that this is a performance-driven industry. Have you ever met an MD that thought it was okay to take a little while longer to complete a report? Or a PM that thought a couple scenarios were enough to run? How about a trader that thought a few milliseconds was fast enough? Neither have we.

Though the shift in Financial Technology from a network-server environment to Web browser and cloud-based environment is a big step forward, these technologies were initially developed for a consumer and large enterprise market. Financial Services is more demanding on technology in almost every aspect -- from latency and calculations per second to data storage and security. As a result, we often find that existing web technology, while superior from an interoperability standpoint, was not designed to meet the performance demands of our industry.

Hence our excitement when we meet entrepreneurs who are “getting down to the metal” (or at least closer to it) to build Web-based technology that is uniquely suited to financial applications. The ChartIQ team realized HTML5 was not designed for high-speed chart rendering and set out to build a high-fidelity visualization engine on top of HTML5. Estimize began revising its select consensus numbers on the fly by moving the correlation calculations out of slower Ruby code and into Go, a faster statistical calculation language developed at Google.

For even more examples, check out our friends at OpenFin and its recent post on the rising importance of AngularJS (a programming language created by Google) in developing the next generation of financial applications. Mazy Dar and his team at OpenFin understand that the future of Web apps is rich user experiences capable of supporting complex operations at high speeds.

All of these teams have two things in common: They have built core technology that goes a level deeper than just delivery through the browser, and they know just how demanding an institutional finance user can be.

After all, this industry builds microwave relay towers to shave off nanoseconds between New York and Chicago. We don’t do page refreshes.