Context Data and Intents: Core FDC3 Standards

The goal of FDC3 (Financial Desktop Connectivity and Collaboration Consortium) is to provide universal connectivity and standards for all desktop applications across the finance industry. It’s a common language for financial applications to be able to communicate with each other. FDC3 looks to enable faster decision-making, improve productivity, and streamline workflows through desktop interoperability.

In any multi-step workflow, there are actions and responses to actions. These actions are composed of data context and intents—the core of FDC3. In this post, we’ll break down two key specifications of FDC3 to give them a closer look.

What is FDC3 Context Data?

The best way to think of context data is to think of nouns – such as instruments, contacts, or countries. FDC3 creates a standard message format for apps to understand each other. Its purpose is to address a number of use cases where these pieces of data or “nouns” need to be shared.

This standard message format gives us a great foundation for sharing context between apps. This works great when the message being shared is almost always universally understood, like the name of a country — China is known as China across all apps. However, we run into trouble when our “nouns” are not exactly the same, even when they mean the same thing (an elevator in the US is a lift in England).

Depending on which app we are using, we often see a unique set of identifiers for securities or entities. This means if the app sending a message uses the FDC3 format and the receiving app understands the FDC3 format but uses a different set of identifiers, we’re not going to achieve our goal of multi-app communication.

For example, if a user visits Yahoo! Finance and wants to look at Microsoft, they enter the ticker symbol MSFT. When they pull up Eikon, they enter MSFT.OQ. As a person who speaks both “languages” this isn’t a difficult task, but the apps themselves do not share this common language and therefore cannot talk to each other.

The assumption is that each application that is sending and receiving context messages knows and can provide all of the vendors’ IDs for Microsoft, though that’s almost never the case. If the receiving application is a Bloomberg Terminal and the BBG ID (“MSFT:US”) has been left out, the context message would be received, but the terminal wouldn’t understand which security to show.

As an implementation, it’s up to you (or the vendor you choose) to either translate or enrich the message so that the receiving app can understand. With io.Connect as your desktop agent (more on desktop agents below), you can insert a layer to pick up the message, reference a symbology master to retrieve the missing IDs, and then enrich the message before sending it along to the receiving apps.

What are FDC3 Intents?

Now that we have a standard language for context messages (the nouns) we need a way to express the actions (verbs). Intents are a standard way for an application to request an action — such as open a chart. If you combine the intent (open a chart) with the context data (let’s say, AAPL) we now have a completed workflow. We can now request an APPL chart.

When an app (based on its own logic or based on user input) raises an intent, something needs to be listening. That “something” is the desktop agent.  You cannot have an FDC3-enabled application communicate with another FDC3-enabled application without a desktop agent. There are vendors that build this architecture for you — such as interop Inc., and OpenFin  — and there is always the option to build this yourself. But it’s important to remember: Without a desktop agent, all you have is a cluster of apps.

The intent to open a chart is raised, and the desktop agent is listening. That agent will then resolve the intent by deciding which app can and should take the action. In io.Connect’s implementation, the resolver will ask the user which app they want to handle the intent (much like when your iPhone asks you which mapping app you’d like to view an address in) and can be set to remember the user’s preferences for the future. If the user doesn’t have an app that can handle the intent, they can search an app directory to find one.

The list of FDC3 intents that are supported continues to grow (StartCall, StartChat, ViewChart, ViewContact, ViewQuote, ViewNews, ViewAnalysis, ViewInstrument, etc.). This set of verbs definitely covers the basics, though when you think about how many commands something like a Bloomberg Terminal accepts, you realize it’s still limited. For additional commands, not to mention more complex workflows, extending the standards (using a desktop agent or building yourself) becomes critical.

FDC3 standards pave the road for interoperability

Passing a message (context data) and an action request (an intent) is certainly powerful, and enables synchronization of context (all of your apps updating at the same time) and launching an app with context. Real-world workflows like responding to an RFQ, handling a trade break, or doing pre-trade analysis require many more steps, dependencies between apps, and state management.

The FDC3 standard is at the heart of interoperability in finance. Where you go from there to implement the standard is up to you.