Context Data and Intents: The Core Standards of FDC3

The goal of FDC3 (Financial Desktop Connectivity and Collaboration Consortium) is to provide a universal connectivity and standards for all desktop applications for 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 interoperability of desktop applications.

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 (whereas intents are verbs, such as open a chart, chat with a contact etc). FDC3 creates a standard message format for applications 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 applications. 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 applications. 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). In the finance world we often see a unique set of identifiers for securities or entities depending on which application we are using. 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 applications themselves do not share this common language and therefore cannot talk to each other. Unfortunately, the finance industry doesn’t have a single standard for symbology, and FDC3 doesn’t solve for that.

As an example, here is a FDC3 Instrument message:

const instrument = {
type: ‘fdc3.instrument’
name: ‘Microsoft’,
id: {
ticker: ‘MSFT’,
RIC: ‘MSFT.OQ’,
BBG: ”
ISIN: ”
CUSIP: ”
FDS_ID: ”
FIGI: ”
PERMID: ”
SEDOL: ”
}
}

That context message is completely valid, despite the sending application only knowing the ticker and RIC for Microsoft.

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.

FDC3 doesn’t address this. As an implementation, it’s up to you (or the vendor you choose) to either translate or enrich the message so that the receiving applications can understand. With the io.Connect desktop agent, we 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 applications.

FDC3 1.1 currently supports nine different context messages (Contact, ContactList, Instrument, InstrumentList, Organization, Country, Position, and Portfolio) which is a good base to build from.

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, and we can now request an APPL chart.

When an application (based on its own logic or based on user input) raises an intent, something needs to be listening. That “something” is the desktop agent.

In this post, we’ll break down two key specifications of FDC3 to give them a closer look.

The intent to open a chart is raised, and the desktop agent is listening. That agent will then resolve the intent by deciding which application can and should take the action. In io.Connect’s implementation, the resolver will ask the user which application 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 application that can handle the intent, they can search an application directory to find one.

As of FDC3 1.1, only eight official intents are supported (StartCall, StartChat, ViewChart, ViewContact, ViewQuote, ViewNews, ViewAnalysis, and ViewInstrument). 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 quite a limited vocabulary. For additional commands, not to mention more complex workflows, extending the standards (using a desktop agent or building yourself) becomes critical.

FDC3: Paving 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 applications, and state management.

FDC3 is a standard only, but it’s at the heart of interoperability in finance. Where you go from there to implement the standard is up to you.