Last week, at the Open Source in Finance Forum (OSFF) in London, Finos announced a new version of the FDC3 protocol, ticking over its mileage counter from 1.2 to 2.0.

Kris West, principal engineer at Cosaic and lead maintainer of FDC3, told the audience that as a single-API standard, FDC3 has been working as intended to get apps to talk to each other, speeding up the deployment cycle. Users are seeing the benefits of desktop agents and applications working in standardized ways, allowing users to rebuild their desktops, and drag-and-drop apps as needed, thus avoiding vendor lock-in and the single-use customizations that slow the cycle of acquiring and deploying an application.

“You might ask, then, if FDC3 is so successful, why did it need major revision?” West told the audience. “We are rolling that first digit of the version number, which is conventionally done when you are making breaking changes to something. It’s something that, as a software vendor, you try to do very, very carefully.”

FDC3 is an open standard under the guidance of the Fintech Open Source Foundation (Finos), the financial services tech umbrella of the Linux Foundation, and development of the standard continues amid increasing adoption at financial services firms.

Of course, Finos wants FDC3 to be ubiquitous on financial services desktops, but ubiquity also brings challenges. More users from the vendor community, the sell side, and the buy side means widening user requirements.

“Hence we needed to seize the opportunity to change things before it got too difficult,” West said.

The four pillars of the FDC3 standard are API specs, a Rest-based application directory (or AppD), and constructs called intents and contexts. These four pillars are complementary. For example, a trader at a buy-side firm could use the vendor’s desktop agent to contact the AppD to discover available applications. Because of the standardized APIs, these various vendor apps can be slotted into or out of the desktop with ease, so users can always go with the app that meets their needs best.

FDC3 intents are often described as “verbs”—they specify what actions apps can execute, such as starting a chat or searching a blotter for an instrument—and the contexts are like nouns, specifying within what data structure the intents can work.

The new version made many major refinements to the API specs, AppD, and the intents and contexts. The most impactful, however, according to West, is that the system of raising intents is now more of a two-way street. Earlier versions of FDC3 made it easy for a user to send requests to apps by raising an intent in their desktop agent, but they didn’t get any information back. For example, a user could create an order, but would not get back details about the order once it was filled.

That kind of data exchange is now baked into FDC3, West said.

“Essentially, you can now automate any form of ‘Crud’ (create, read, update, and delete) operations you need to do from one application to another. You can send it over there, get back the update—you can have the updated record back. Then you can carry on your workflow with that data,” he said. “You can also create APIs to deliver datafeeds, such as pricing streams, streams of trades, streams of orders, details, updates, customer activity that can then be handed on to other applications.”

Growth spurt

In 2018, OpenFin and industry participants unveiled the FDC3 protocol—a set of codified specifications that aims to enable traders’ desktop applications to share information and interoperate—under an Apache 2.0 open-source license.

Vendors, notably OpenFin, Glue42, and Cosaic, emerged to provide interop platforms, known as desktop agents, and some firms are building their own desktop agents internally, with FDC3 as the standard. Consultancies like Adaptive Financial Consulting and Scott Logic are building tech on top of these platforms and using FDC3 in implementations with buy- and sell-side firms, seeing opportunity in the market that involvement in the development of FDC3 affords them.

And adoption among financial firms is increasing, primarily on the sell side, with firms like Citi, UBS, State Street, NatWest, and Bank of America all officially using tech built on FDC3.

Another sign that FDC3 has evolved is that new projects are growing up in its ecosystem. Nick Kolba, a veteran capital markets technologist and an originator of FDC3, contributed a project to Finos earlier this year. The project, called Electron FDC3, offers developers a neutral reference point and the full stack of FDC3 implementation, including a desktop agent and an application directory. (Kolba has since formed his own company that looks to take interoperability out of the desktop and put it into the cloud.)

As FDC3 sees more uptake, Finos has received a lot more user feedback to work with. This feedback has formed the backbone for improvement of the standard, which mostly takes place through frequent and regular discussion groups, and led to the recent update of FDC3.

Riko Eksteen, head of desktop strategy at Adaptive and co-lead maintainer, said that users were asking questions like, “How can I have intents that return data back?”, “How can I target a particular app instance?”, “What context and intents should I use—there aren’t enough?”, “How can I publish my app easily?” or, “How can I make it work across different containers?”

Eksteen, West and others, shared the view that the standard was confusing in having four specs that were also complementary, and some of the APIs needed clearing up, Eksteen added.

“‘How can we ensure each desktop agent will work the same? We need more examples and tools!’” Eksteen said. “These were all things we were hearing from people, and it was daunting to figure out how to cover all of them. But that’s where the discussion groups came in.”

Hammer, meet nail

Future improvements to the standard will now be additive—rather than breaking changes—with, for example, more intents available. For some in the FDC3 community, this is a good time to broaden the conversation away from just the technical specs of the standard.

Adaptive CEO Matt Barrett tells WatersTechnology that when the project began, it was in the hands of technologists who were very much getting into the weeds of the specs. They were followed by the vendors that built out capabilities and products based on FDC3. But the next stage of the discussion should be around the business benefits of FDC3 and the outcomes for users, rather than the technology itself, he says.

“Technologists tend to talk about the tool: ‘Look at my shiny hammer—isn’t that a great hammer? What would you like me to do with this hammer?’ But I don’t want a hammer; I want to put a nail into a wall. This is not a criticism; this is a natural phase of projects like this, and FDC3 is well-placed to do the next phase,” Barrett says.

Barrett adds that, based on conversations with Adaptive’s clients, the most desirable outcome for both sell- and buy-side users is ease of application and workflow enablement. Large buy-side firms want to be able to breach silos—for example, allowing cost-effective, multi-asset execution—while the sell side wants to be able to supply this kind of execution functionality to their buy-side clients.

“Gone are the days of the full-fat, department store-style single-dealer platform being built by a universal Tier 1,” Barret says. “I mean, they have them still, but I’m not sure that if you didn’t have one, you would build a new one. Instead, they are now looking to deploy smaller pieces of functionality that are sticky with clients’ workflows. So rather than having to build the entire department store, you build just the bit that really differentiates you as a business. FDC3 is about the interop, but the broader demand is about capability deployment on the user desktop.”