The Trade Object, RFQ Object and Order Object for the current rates product focus are correlated, which is why that is combined into one working group.

As FO grows and takes on more asset classes and other lifecycle areas, e.g. settlement, we will set up additional working groups.

Individuals are encouraged to put forward proposals and use cases for additional focus areas, where we can leverage the processes established by this initial working group.

The group discussed whether now was the right time to extend, with general agreement that it is. Comments/points from the discussion include:

• Work coming out of the FDC3 Use Cases working group can help drive direction and and identify new focus areas.
• It is very valuable to tie the objects back to a real implementation so people can see the connection between the theoretical object and use in the real world.
• Having put a sample out we now need validation and need to get others to review and use it. This could be done, for example, by defining a challenge/use case and then understanding how the object works to address this.
• We need a neutral source that can test these and we need help from FINOS to help address the formats.
• We need another push with Lawrence from Symphony to promote using the objects within the Symphony workflows being discussed and also within FDC3.
• It would be valuable to tie in the use cases from FDC3 with the objects that have been produced here, potentially starting with the top 1 or 2 use cases that will have the biggest impact. This could be, for example, passing an intent from one app to another app to place an order in that system, consuming some of these objects as part of increased interoperability. This is something to raise to the PMC.

There was no new feedback on the RFQ Order Object.

Object Repository - Requirements

The group has been discussing the best way to capture the objects and have shared these thoughts with the FDX/ODP group. Key requirements include:

• Easy access for all users without the need for an ID
• Should be simple text so it is accessible
• Must support a matrix type structure, including expanding, collapsing and categorization
• Ability to search and filter (particularly important as the repository grows)
• Versioning support for each component
• Easy to add new components to cater for future changes and adaptations
• Standard tagging and taxonomies to enforce some level of organizational consistency across the platform
• Appropriate permissioning - edit, read, write, etc.

The group should first address making objects available in “layperson” terms, but may later need to consider “codifying” aspects, such as a need for technical IDs on the language or data structure.

The requirements are meant to be forward thinking to address longer term requirements.

Hammad Akbar

Follow-ups:

• Johan and Tim to look at the objects and provide feedback.
• Review use cases from FDC3 and start defining/identifying the use cases that will help drive/define next focus areas in this program.
• Rob to review requirements and implementation and share within FINOS

Moving the working group meeting time was raised and members should send feedback on what might work best.