Brainstorming ideas for Context Data & Intent use cases and workflows

[rikoe]

During the most recent Context Data & Intents Discussion Group meeting, we brainstormed some ideas for particular uses cases and workflows to discuss in future meetings.

This is the list so far:

• Basic data type building blocks (date, currency, country code, etc.) - field types/vs. full context types
• Orders and trade linkage, e.g. EMS child orders or parent orders, or the street orders that make up an instruction from the client
• Order/price request/RFQ - generating tickets, generate prices - very nice to have RFQ standardised
• ViewOrganization intent - is it an omission from current intents? E.g. seeing the issuer for a product. Or would you simply use an Organization context with another more specific intent, e.g. ViewNews?
• Formatted text for messages or notifications, structured content - sending payload?
• Text searches / search queries, intents for search? search results with actions?
• Use of existing intents but with generic text - e.g. ViewNews for a text search string
• Improve documentation about usage of intents so intention becomes clearer
• Data series for blotters/charts
• How to represent singular/multiple e.g. Instrument vs. InstrumentList
• Intents for issuing calculations / execute trade requests, etc. (also e.g. receiving details on trades via Symphony)
• Show trade ticket / show order ticket with different modes
• Show IOI, quotes - show vs. create vs. amend vs. cancel vs. clone
• Standardise form / conventions for intents, currently only have "view" - what others should there be

Please feel free to add any additional use cases, workflows or discussion topics by replying to the thread below.

[agitana]

thank you for starting this @rikoe! For the first point "Basic data type building blocks (date, currency, country code, etc.) - field types/vs. full context types" check out the work the FINOS Currency Reference Data project (https://github.com/finos/curref-data) is doing. For anyone interested, their next meeting is on Tuesday, January 18th at 10am ET (see agenda and meeting details at finos/curref-data#6)

[timjenkel]

The FDC3 instrument context doesn't currently support FX currency spot/forward/swaps. Is this something that should be part of the curref-data project or the FDC3 context group?

[jgavronsky]

@timjenkel Thanks for your question. The curref-data project is focusing on standardizing definition of currency data. For discussions on standarizing FX currency trade definitions, a better venue is the Financial Objects SIG , which has a broad object model focus, currently utilizing the ISDA CDM.

[pauldyson]

A couple of things from the wishlist we've been writing as we take our first steps with FDC3:

1. Optional Contexts

It would be great to support multiple, optional, contexts. E.g. in an OMS you may see an order and click on the ticker, raising the ViewInstrument intent which comes with the Instrument context. But in an OMS, each order also has a counterparty organisation and, usually, the individual that initiated the trade and it's impossible to know whether the user is interested in the ticker in general or the ticker in relationship with the counterparty.

For some applications, like a price charting app, this is irrelevant, as they're simply going to chart the price of the instrument. But for a CRM we can potentially use that additional context in a useful way, e.g. showing all the ViewInstrument information as normal but with the specific counterparty highlighted, or just showing all the Instrument-specific information related to the counterparty organisation.

The point is it should be optional: ViewInstrument should still work when there is only the Instrument context, but recipients can choose to work differently if additional, optional contexts are provided.

2. Id Enrichment

The cornerstone of integrations like this is the Ids passed. Everything works if the intent raising system and the intent receiving system have the same id, nothing works if they don't. But, in practice, that is always going to be a possibilty.

As a CRM vendor, our customers often have a lot of cross-reference data about individuals and organisations. We will have an individuals email address (and sometimes more than one), their Bloomberg email, their Bloomberg Id, their IHS Big Dough and/or Refinitiv Ids. But we don't have the same data about instrument although this will be in most OMS.

So a 'hook' in the intent raising mechanism that asks relevant systems for alternative forms of Id before the intent is notified to the various listeners may improve the robustness of the overall solution.

E.g., a user raises a ViewContact intent for the person they are chatting with on Bloomberg to see their order history in the OMS. Bloomberg chat only has their Bloomberg Id and the OMS only has their email address. As part of the intent-raising mechanism, the integration vendor calls all of the systems registered to map the Ids of Contacts. The CRM, which has the Bloomberg Ids of individuals mapped to their email address(es) responds with the relevant emails. When the OMS received the View Contact event it comes with the Bloomberg Id and the relevant Email.

[kriswest]

Hi @pauldyson, I believe the first point is already satisfied. It's not explicitly spelt out in either the Intent specification or API docs, but an application can definitely support multiple different context types for a single intent. The intents spec uses the language 'Expected context' and list a single type, the individual intent reference pages list 'Possible contexts' (often with more than one type listed). In the AppD each application can list an array of intents it supports, each with an array of context types it will accept; information that is used to filter apps available to resolve a raised intent when any of the below functions are called through the API:

  findIntent(intent: string, context?: Context): Promise<AppIntent>;
  findIntentsByContext(context: Context): Promise<Array<AppIntent>>;
  raiseIntent(intent: string, context: Context, app?: TargetApp): Promise<IntentResolution>;
  raiseIntentForContext(context: Context, app?: TargetApp): Promise<IntentResolution>;

(the type of any context object passed is an optional filter when calling the findIntent functions, but required when the intent is actually raised).

Finally when adding an intent listener with fdc3.addIntentListener:

addIntentListener(intent: string, handler: ContextHandler): Listener;

a single handler is passed, which check the type of the context received and act accordingly, e.g.:

fdc3.addIntentListener("ViewInstrument ", (context: Context) => {
    if (context.type === "fdc3.instrument") {
        //handle an instrument
        ...
    } else if (context.type === "fdc3.order") {
        //handle an order (that will likely contain an instrument + additional info)
    } else {
        throw new Error(`Unsupported context type: ${context.type}`);
    }
});

All of this may not be obvious and clarifying content could perhaps be added to both the Intent specification and API docs. Would you be up for raising a relevant issue? I'd be happy to help get it done.

[kriswest]

Regarding your second request (ID enrichment of messages), I quite agree. I've been intending to raise an issue relating to enrichment of messages (not just contexts passed to raiseIntent, but also context broadcasts). I've seen at least one firm have to implement a non-ideal enrichment scheme as there was not a suitable mechanism defined in the API. They implemented enrichment for context broadcasts only by having their apps ignore messages that are missing required IDs and then have an app listening on most channels looking for those messages, which it then enriches and re-transmits.

A better mechanism would be an API hook that allows you to register an 'enricher' which would be passed messages of particular types to process/enrich and return before they a transmitted to other apps via either broadcast or raiseIntent. I see numerous applications, including CRM (Contacts, Organisations etc.), OMSs (Order IDs, Customer IDs etc.) and symbol masters (Instruments IDs, Sector details etc.).

There are likely some implementation issues to consider (such as the enriched becoming a single point of failure and/or introducing latency) as well as the form and function of the API hook (e.g. should it look for embedded contexts, pull them out for enhancement, then re-embed them in the parent context etc.) but I think the use-case is clear and supportable.

[pauldyson]

On 1, I can see that the example given solves the specific use case I mentioned but I'm not sure it satisfies the general point. It's fairly clear from the docs that some intents support one of multiple possible contexts, e.g. ViewAnalysis and ViewNews each take multiple different contexts. But my reading of the spec is that an intent only passes one context when it is raised. In the example, if there is an Order context (is that part of the next version?) then this provides all the data points I mentioned but what about the case where a salesperson is discussing APPL research on IM with a buy-side analyst and clicks APPL to raise the ViewAnalysis intent?

ViewAnalysis can take the Instrument so that's all good but the IM system also knows about the contact and this might be useful additional context. Sure, we could create a new context that combines ticker with contact info but what would we call that? And what do we do if the IM happens to also have some useful context on the country the contact is in? So what I'm suggesting is raiseIntent has an additional, optional, parameter:

raiseIntent('fdc3.ViewAnalysis', {
type: 'fdc3.instrument',
name: 'Apple Inc',
id: {
ticker: 'APPL'
}
}, [
{
type: 'fdc3.country',
name:'USA',
}, {
type: 'fdc3.contact',
name: 'Annie Ajayo',
id: {
email: 'annie.ajayo@example.com'
}
}
])

This adds as many or as few (default: none) additional contexts as the raising system has to offer and the listener only promises to deal with the mandatory context (the Instrument) in this example but may choose to use the additional contexts if that makes sense.

In our case we would show all the APPL research info but highlight anything specific to Annie and might display a very small amount of relevant info about Annie with links to quickly find out more. This relevant info might be filtered by country if that context is available (e.g. there is an upcoming Technology conference that has APPL representation in New York next week).

Anyway, this is very much a nice-to-have and if I've misunderstood the spec, I'll raise an issue to the effect. But I think this is a more generic enhancement than perhaps I managed to communicate.

[pauldyson]

On 2, yes latency and reliability are issues. What I've seen before is the original request has an id and gets broadcast immediately for consumption by the listeners that can make sense of it whilst, asynchronously, the enrichment hook is called and the request is re-raised when it has been enriched. If a listener can't comprehend the original it discards it but, hopefully, it can comprehend the enriched version. If the listener can comprehend the original it does its stuff and ignore the enriched version based on the id.