We have a real need for an object modelling language which can express OTC instruments at a level that makes sense to traders. That basically boils down to accepted defaults e.g. GBP swap is 6m libor, USD is 3m libor, LCH is the default clearer for both.
I've seen all sorts of ways of expressing this, sometimes via a deep hierarchy, sometimes with a bespoke symbology, sometimes using the Murex concept of generators. None of these are suitable for crossing organisation boundaries.
If Alloy is a solution to this problem, great. I think the fundamental issue with this problem space is that any solution has to be opinionated and that is very hard to do via consensus.

My view is that the existential questions for this project are first what should be its remit and then does that remit warrant continued existence.

WRT remit - I believe it is a flawed premise that the project should or can be a central clearing house or standards body for all of FINOS' modelling of financial objects. That remit is too broad and the project will either end up being a bottleneck, ineffective or both.

Alternatively, my recommendation is that the group's remit should be to focus on providing modeling / implementation for objects and processes where interoperability is required whether it be between entities, services / service providers, other FINOS projects, et al.

Under that remit, the project's first task would be, as the RFC cites, to focus on "specific, targeted, concrete and pressing problems / opportunities" which are common enough and significant enough that FINOS members and others in the industry would be prepared to commit or have already committed resources for its resolution. Project would continue if it can find those problems and get support for their resolution. If not, it should be dissolved or parked until a later time when more commitment exists.

This framework would allow other projects which are developing models for common objects (whether in Alloy or otherwise) to roll under the FO project umbrella as long doing that organization was for more than administrative reasons. If there isn't sufficient synergy those activities should remain standalone.

FDC3 working group have recently discussed the establishment of sufficient standardized types as an important hurdle that must be overcome in order for vendors across the industry to be able to implement the FDC3 desktop agent to integrate with each other without direct coordination with each other. Having worked with several vendors trying to provide support for FDC3 in their products, I've observed that each has had to create their own custom context data types to encode the data their clients need. That necessitates coordination between firms or the implementation of custom translation layers in the desktop agent or downstream in other components, eliminating much of the benefit gain from the API standard.

The FDC3 project doesn't want to get into data modelling specifically, but is heavily dependent on standardised or at least 'well known' context data models to realise the value in its API specifications and achieve widespread uptake. I believe that to be a concrete and pressing problem that could/should either be solved by providing a repository or venue to share context object schemas (from which standards may emerge...) OR by directly producing standards. The later is probably much harder to achieve without the former.

I know there have been past attempts to establish similar standards. Is anyone familiar with the the financial extension from schema.org (https://schema.org/docs/financial.html), which appears largely forcused on accoutns and payments (rather than capital markets and trading) and whether it is/was used anywhere? I'm sure there are many other examples of similar efforts. Do such past efforts point to happy path?

REGnosys would be supportive of the Financial Objects project continuing and would welcome the opportunity to contribute resources and tools for the creation of standard data models.

As noted by other contributors it is important to have specific problem statements that the group aims to address. The source of these problem statements can be other FINOS initiatives such as FDC3, trade associations such as ISDA, or from member firms. However for the mandate of the Financial Objects initiative it is important to always maintain this link between sponsorship and deliverables. Significant investment has already been made to develop a common event and product model for financial markets transactions, the Common Domain Model, critical to the success of which has been the sponsorship of ISDA with an initial deliverable focus on the derivatives market. Such ambitious undertaking, of the kind aimed by the Financial Objects initiative, requires sustained industry sponsorship to commit the resources necessary to carry it out.

Assuming this sponsorship is in place the Financial Objects project would be a desirable place to house and clear all modelling discussions, separating out the considerations of platform open sourcing discussions, from modelling concerns. The group would then provide a place where all trade associations could come together to align the strategic direction of industry modelling initiatives, promoting interoperability and alignment while preventing bifurcation of methodology.

REGnosys recognises that one of the first hurdles to adoption is interoperability of data models through a translation layer. Topics previously raised by the working group and in responses so far identify the need for a solution that allows data standards to work together to facilitate integration across industry platforms. Recognising that there is already a growing number of tools used to express data standards, we further propose that the Financial Objects initiative should drive interoperability amongst existing tooling, by using open-source and freely available software to define a common way of defining data standards, such that conformant models can easily translate across different toolsets. As such, REGnosys can make tooling and expertise available to the group to facilitate and accelerate these discussions, leveraging our track record developing the Common Domain Model and helping integrate it for enterprise use. We urge the FINOS community to lean on existing technology and best practices that are already being developed as part of other, well-established open source initiatives (the Eclipse Modelling Framework being one such).

On a longer term basis, in a scenario where industry standard data models are contributed to FINOS this puts in place the requirement for a strong governance process to maintain and extend models. Dedicated expertise is required on a number of fronts to manage this process, for example hosting of code, project management, modelling capability and modelling expertise. Defining the Financial Objects working group correctly at this stage is important in order to position the group for this potential future phase.

@brooklynrob @jonfreedman @dschwartznyc @kriswest @nigelcobb thank you so much for the input in this important conversation.

After connecting internally with @brooklynrob @toshaellison and @maoo, in the spirit of divide and conquer, it might be wise to decouple the conversation regarding the future of the financial objects project from the conversation of where the Alloy pilots will land once completed. Here's a proposal to move forward with decisions below:

Future of Alloy pilots

• CDM work: let’s explore the creation of a formal FINOS project to continue developing extensions to the CDM with Alloy (such as the FX Option revisions done during the pilot). The CDM itself (https://gitlab.alloy.finos.org/alloy-pilot/cdm) has been imported into the hosted instance of Alloy and is available to be used for further modeling effort(s) within FINOS. Next steps would be to identify interest and maintainers for such a project and make sure ISDA is on board to avoid any forking. Chime in on issue community#64 to continue on this topic.

• Commodities Reference Data work we could expand the Security Reference Data project (if Maintainers @finos/dt-securityrefdata are agreeable) to “Reference Data”, which would then include the following three workstreams:

  1. Commodities Reference Data” as a continuation of the pilot work
  2. The existing “Security Reference Data” work
  3. The recently launched “Currency Reference Data” effort

  Next steps would be to discuss the groups consensus to move forward. Chime in on secref-data#31 to continue on this topic

Future of Financial Objects:

First off, I think it’s great to see the Community discuss the future of this project, and I am very aligned with the spirit and most of the ideas in this thread. But, having witnessed a couple of iterations of this project (cc @donbasuno @HammadNYC @DovOps), I think there’s consensus that collaboration cannot succeed without:

1. A clear scope for the activity (I personally think this is a good start)
2. Active participation (and ideally co-leadership) from at least two or more financial institutions + folks on this thread :)

So our proposal for next steps would be to focus this issue (and add to next week's FO meeting agenda) to see if there’s consensus for a clear scope. If:

• there’s no consensus, we can simply archive this project, even next week (we would still retain email lists and other collaboration mechanisms, so there's a central place for people to collaboration)
• consensus is reached, then we can continue onto socializing with the Community to explore interest, identify maintainers and most importantly as said above participation from more key players the industry and decide over time to continue as one or more software or standard projects or SIGs.

WDYT? Looking forward to your comments on the respective issues and thank you for your contributions and passion!

@mindthegab I can't make the meeting next week but I suggest you get someone from Tradeweb to comment - that's the main venue we would like to interop with

@mindthegab I will be following-up on this while REGnosys' @nigelcobb is away this week. To this end I'd like to take part in the next FO meeting where this is being discussed (if you can share the invite details offline with me). That said, given that the go / no-go decision seems to be an important one, we should ensure that a critical mass of reps can attend to chime in - it may mean at a later date if key folks are away?

@mindthegab I have made a further suggestion about use-case for FO under the "sister" Alloy discussion here: finos/community#64 (comment)

Cross-posting the decisions made at the August 25th Financial Objects meeting:

Decisions Made

• Commodities Reference Data: 
  • Reference Data Model: there was general agreement to move forward with the proposal that the current "Securities Reference Data" project expands its scope to become the "Reference Data project" and that the Commod. Reference Data underlier piece (i.e. the reference data model) moves into that project under its own "Commodity Reference Data" workstream. This proposal has been added to the agenda of the next Securities Reference Data meeting on September 1st for discussion.
  • Commodity Payout model: As the Alloy Commodity Reference Data working group is expected to finalize the commodity payout model by early September, there is no need to define a "home" for this working group's collaboration.
• Financial Objects: a decision was made to keep the FO project infrastructure (i.e. mailing lists, github repo) open and available to the group for asynchronous collaboration. Recurring meetings will be cancelled and meetings will be scheduled on an ad-hoc basis.all meeting attendees were encouraged to sign up to the Financial Objects project mailing list - which can be done by emailing fo+subscribe@finos.org. All communications relevant to the future and potential scope of the project will be carried out through the fo@finos.org mailing list and the GitHub issues raised in the Financial Objects GitHub repo (https://github.com/finos/finos-fo/issues).
• CDM: the group will continue discussing the creation of a FINOS project to continue CDM Extension work after the Alloy Pilot. It was acknowledged that this workstream could potentially move into the Financial Objects projects but will be explored as an independent workstream/ project for now.

On the back of the successful groups run as part of the Legend open sourcing last year, we are keen to set up two new groups to tackle new problem statements. These cover: i) reviewing and enhancing the ISDA CDM for commodities options and ii) creating a common template for product control price dissemination.

Financial Objects feels the right place to set these up and allows for the expansion into other problem statements over time.

Based on this, I am happy to host (and hopefully co-host) the Financial Objects project with a broad scope to provide a space for modelling opportunities driving and improving the interactions between parties in the financial industry.

Hi @ffionwiggins,

I agree with your proposal above and fully support you hosting the FO project. I will continue to work with the FDC3 project which will continue to propose context data standards to FO so we'll definitely cross paths in the future.

Best regards,

Johan

Thank you @ffionwiggins for stepping forward to lead the Financial Objects project. Following the support that your proposal has received over the past ten days via the FINOS community mailing list and on this GitHub issue, and the lack of objections from the community, we're delighted to confirm that you're the new lead for the FINOS Financial Objects project.

We encourage everyone to engage with the new FO modeling projects: Commodities Payout (commodities-payout@finos.org), and Product Control Common Template (product-control-common-template@finos.org) on the FO GitHub repository, and to reach out to the project mailing lists with any questions.