By itself, the humble API is many things, none of which include “new,” “innovative,” or, often, even “interesting.” But it has underpinned a boom in technologies that can be described as such, thanks to its versatility: it can be used as a data delivery mechanism that gives firms greater control over how they access ever-increasing volumes of datasets, or bridge the chasms between disparate applications, at a time where connectivity, interoperability, and consolidation are market demands.

APIs have been around for decades, and they’re relatively cheap and quick to create, making them an accessible tool for small startups and small trading shops alike—at least, that’s the perception many in the tech community have.

But there’s a difference between a working API by technical standards and an API that works for its users, a distinction not totally made by all those who build and use them.

“If you build an API, it’s a highly complicated thing to do, and everybody thinks it’s fairly straightforward,” says Thomas McHugh, CEO of Finbourne Technology, a buy-side technology provider established in 2016. “And what you end up with is people getting confused about what an API is supposed to be versus what a function is supposed to do.”

Finbourne offers what’s essentially a data fabric layer that sits in the middle of other data providers and internal systems and translates that data across different languages, protocols, and terminologies. Underneath sits a data aggregation engine, and in the middle, an entitlements engine. On top is a data visualization layer.

The company builds the interfaces to other providers like Salesforce, Snowflake, or Google BigQuery, so that when a user enters a command into Finbourne’s query engine, it knows how to communicate with the other platforms’ systems.

McHugh says that even though APIs are ubiquitous, he would like to see the industry achieve a greater understanding of business intelligence when building the next generation of them; for example, by creating associated ontologies so that different machines working with the same data can know what one another need.

(Semi)Intelligent design

While interoperability is a generic term—computer systems or software exchanging information—it’s perhaps most interesting currently in the context of a subset of financial technology known as desktop application interoperability (though this name is misleading these days, as those working on desktop interop are expanding to incorporate back-end and mobile capabilities).

In desktop interop, container technologies such as Electron wrap desktop applications into a package, in which each app can share context and information via APIs tailored to FDC3 standard, an open set of codified API specifications under the governance of the Fintech Open Source Foundation. Ongoing development of the standard, which just recently unveiled its version 2.0, is contributed to by desktop interop platform providers such as Glue42, Cosaic, and OpenFin, as well as any interested parties inside and out of financial technology.

Interop and FDC3 have been well received since their inception—notably among the sell side, among which Citi, State Street, UBS, NatWest, and Bank of America are adopters—but it hasn’t been the sea change that some in the industry have hoped, says Glue42’s head of product, Reena Raichura.

Raichura says that the current desktop interop offered by providers is still only at a basic level of connectivity, partially because vendors limit what vendors like Glue42, Cosaic, and OpenFin can do within the offerings. Traditional companies that already reach thousands of customers aren’t necessarily incentivized to open their products, and because the applications that they can connect for users are developed as “islands” in isolation, the workflows between them don’t necessarily become intuitive or efficient.

“One of my frustrations now is with vendors themselves. Because they’re halfway houses—either they’re closed or they’re partially open—we’re not really getting the traction that we should be getting for desktop interop,” she says. “Vendors say they have APIs, but when you actually speak to a user, and the user wants to go from A to B, or they want to do something specific, it might not actually be available in the API.”

Raichura says that many historically closed-off vendors have opened up through APIs to meet demand for collaboration and integration, but too often don’t build them with a user’s workflows in mind. Her main objective is for those who build and use APIs to achieve “straight-through workflows”—a play on straight-through processing—which, in a literal sense, means cross-application workflow automation on the desktop. But for Raichura, it’s much more about an overhaul of the design process in the way enterprise technology is built.

“Let’s blur the boundaries of applications and look at what the business is doing, what the user is doing, and analyze those end-to-end business processes and workflows first before building a solution. That’s when you’re going to get a solution that actually matches the needs of a business and has real business impact. I think that’s where the mismatch is today.”

Never change

Desktop applications and interoperability have become nearly synonymous in recent years, but interoperability—and therefore APIs—extends well beyond apps. It also goes beyond equities trading, the most technologically sophisticated asset class, to those that are still playing catch-up, such as fixed income.

Founded in 2018, MultiLynq is a startup that uses one API to connect bond market participants to the growing realm of electronic trading venues. Its service connects to 10 electronic trading venues—including Tradeweb, MarketAxess, Intercontinental Exchange’s BondPoint, MTS BondPro, and others—via their own APIs, and allows clients to connect to all marketplaces via MultiLynq’s single point of access.

Co-founder Patrick Scheideler says that the time it takes for a client to connect to any single venue’s API on its own takes anywhere from three to six months, and the process includes a variety of hurdles. Different venues use different Fix messaging to communicate similar material such as “Where do you send your quote?” versus “Where do you get the order?”

These small but specific specifications task firms’ trading infrastructure managers with trying to identify how to make their own internal platforms—and their own configurations—work inside a new venue. Often, that scenario plays out many times across many venues for a single firm.

“The simple thing [would be] changing the messages, right? But that only gets you 5% of the way there,” Scheideler says. “There’s a lot more that goes into it. What does the workflow look like? Where are the edge cases? There’s just a lot of time that goes into it.”

The specifications end up being very long, very confusing, and still aren’t always comprehensive—the only way to find out what’s under the hood, he says, is to do the integration. And that’s not the fault of venues nor firms. Any spec is difficult to maintain, and multi-party connectivity, by definition, requires a lot of inputs, resulting in sometimes huge numbers of permutations that can’t be covered in a single document.

It’s the same conundrum that saw the advent of Fix and FDC3, both of which make communication between systems easier, but not truly easy—a side effect Scheideler attributes to an inability, or at least unwillingness, to go backward. Because APIs are often years and decades old, countless technology layers and specifications have been built over their once simple foundations.

Even poorly built or particularly old APIs rarely see updating, much less overhauling, says Finbourne’s McHugh. The ones he’d classify as either are those not built according to frameworks that would make them efficient, such as the OpenAPI Specification, a standard interface to Rest APIs which allows humans and computers to discover and understand service capabilities without access to source code, documentation, or through network traffic inspection. The standard began as an open source initiative in 2015 under the Linux Foundation, led by giants such as Google, IBM, Microsoft, and others.

For example, McHugh says, if a vendor ships a software kit in C\# or C++, but the end-user wants to use Go, that user would have to spend weeks or months building their own client for that unless the provider’s product is compliant with OpenAPI or a similar framework. But if done the right way, APIs can be left on their own, he says.

“If they write an API, they are never changing it once it hits production status because they get that foundation correct. They have 10-, 15-year-old APIs, and they will not change it. And that’s part of the contract. If you have a look publicly at our API, we have six, seven, 800 of them and if it hits production and enough customers have used it, we are never changing it.”