finos
Use Cases and Workflows Discussion Group - 4th December 2025
Group overview
Newly rebranded "Use Cases and Workflows" discussion group for FDC3, replacing "Context Data and Intents".
The remit of this discussion group is:
- talking about existing or potential financial use-cases
- unlocking the power of standardisation
- discussing new ways to collaborate either inside the organisation or firm-to-firm
- sharing expert insights about how to make the most out of FDC3
- and collaborating to shaping the future of financial workflows.
Relevant issue tags
Current open issues that relate to the discussion group:
Specific issues will also be tagged with the labels:
Meeting Date
Thursday 4th December 2025 - 10am (US eastern timezone EST) / 3pm (London, GMT)
Zoom info
- Join Zoom Meeting
- Meeting ID: 969 4029 4948
- Passcode: 636931
- Dial-in:
Country International Dial-in Toll-free Dial-in US +1 929 205 6099 (New York) 877 853 5247 UK +44 330 088 5830 0800 031 5717 France +33 1 8699 5831 0 800 940 415 Find your local number https://zoom.us/u/ad2WVnBzb8
Meeting notices
-
FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.
-
All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.
-
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact [email protected] with any questions.
-
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
-
A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard.
Participation Requirements
Note: Meeting participants are expected to accept the terms of the FDC3 license (Community Specification License), understand the governance process and have a CLA in place.
Please click the following links at the start of the meeting if you have not done so previously.
- View the CSL
- View the GOVERNANCE of the Project
- Click here to start a PR.
- Edit the page to add your details.
- Hit the save button.
- Click "Create Pull Request".
- Click "Accept" on the EasyCLA dialog in the PR's discussion section.
- Click here to send email to become a voting participant on the FDC3 Project
Tracking Attendance
Note: Meeting participants are expected to add a comment to this GitHub issue in order that we can track attendance of FDC3 project meetings. Please do this at the start of the meeting.
Agenda
- [x] Convene & roll call, review meeting notices (5mins)
- [x] Review action items from previous meeting (5mins)
- [ ] #1698
- [ ] FIX logical model as payload for FDC3 messaging (30 mins)
- [ ] Continuation from discussions at #1626 with Jim Kaye
- [ ] Exploring MCP-UI and Ai across FDC3 | @novavi (10 mins)
- [ ] #1669
- [ ] Open floor discussion around FDC3 topics (5 mins)
- [ ] AOB & Adjourn (5mins)
Minutes
- ...
Action Items
- [ ] ...
Untracked attendees
| Full name | Affiliation | GitHub username |
|---|---|---|
Minutes
FIX
@jimkayefix
- introduced idea of FIX protocol. Three parts. Logical Model. Encoding (tag - an ISO Standard or XML, JSON), Session - manages encoding, heartbeat etc.
- Would like the possibility of the FIX logical model to be a payload in FDC3. To avoid re-invention. e.g. order information.
- Similar approach to CDM, has many similar concepts including the logical model.
@lspiro-Tick42
- wasn't FIX a really big mess? Lots of work translating from engine to engine. No governance around what's in the. Maybe it's changed?
@jimkayefix
- the standard is actually pretty rigid... tightly defined in certain ways.
- Workflow is written down.
- Standard defines the base level of what you can do. Order must contain a certain number of things.
- Everything else is where you get the flexibility.
@robmoffat
- Is there a JSON schema? The lack of a published CDM schema has held up our integration work there.
- If we could get one, it might allow us to work through this argument.
@jimkayefix
- There is an XML schema. There should be ways of converting from XML to JSON...
- Also, you could have "cut down" versions of the full schema for particular FIX scenarios.
@lspiro-Tick42
- In FDC3, context is nouns, as JSON. The two things we might import from fix : instrument, order trade.
- You could imagine something where we map an instrument from fix tags. You might put FIX messages as intents (?)
@kriswest
- The way FDC3 handles mapping to external types (e.g. country code, symbol), is to establish a convention of a field where we place that.
- Is it always useful to see what to attach?
@jimkayefix
- FIX does set limits and requirements on fields.
- I like the idea of creating a mini-schema for this. We could take a fairly basic use case (e.g. order execution workflow) and use it for a relatively well-defined range of asset classes, we could come up with a compact, well-defined schema for that.
@iansloyan
- Location for schemas: https://central.sonatype.com/artifact/org.finos.cdm/cdm-json-schema/versions
@robmoffat unfortunately, we need these expanded out.
ACTIONS:
- @jimkayefix to work on cut-down schema and bring this back to the meeting for further analysis. @lspiro-Tick42 recommends to focus on the "nouns" in the space.
- @robmoffat to ask Ian to address the schema issue since he left the meeting already.
MCP
@novavi
- working on the issues around MCP-UI apps starting within a chat. Problem is, MCP starts new windows for each thing.
@robmoffat
- FDC3 and MCP-UI are so close.. but I think FDC3 allows the sub-windows to talk to each other whereas MCP-UI doesn't.
@novavi
- This is something they're thinking about in MCP-UI. But there's nothing yet. FDC3 could fill this role.
- To be useful in our use case, MCP needs to be able to change the context on existing UI components, like FDC3 does.
@rmcneely-interopio
- Are they using the chat as the orchestrator (desktop agent)?
@novavi
- Conceivably you could have an embedded app talk back by the original chat / agent and affect what's going on there.
- There are so many different ways to assemble this in FDC3.
- Big danger that MCP tries to duplicate FDC3 but badly.
@kriswest
- We should probably keep separate the MCP and MCP-UI issues. We do need to improve the information in the AppD record (to feed an LLM). We need to describe what happens when you raise an intent. That would help resolve better too.
ACTIONS
- @novavi - can we introduce FDC3 to the MCP community?
@kriswest @novavi apologies this morning i intended to join on the conversation but pulled away. Had some things i wanted to cross-pollinate back to fdc3. i'll follow up in issues and in the group.
@novavi I've made fdc3 known to the transports and the financial services working group and will relay next week on some progress with both that will be relevant to.