Fpml User Guide

[Mariko Bloomgren]

Thestandard is developed through the Community Specification open governance process, and underlying code assets are released under the Community Specification License 1.0. For versions before 4.0.0 and other license details, check Notice.md.

For a more detailed overview of the existing Working Group and standard Participants, Editors and Maintainers, please see Governance.md. For more information on discussions and announcements subscribe to our mailing list using the following link.

A proposal can be defined at a conceptual level or a logical level (i.e.in code). In each case, the proposal must be developed in line with theCDM design-principles andagile-development-approach and submittedto FINOS staff and the Architecture & Review Committee for approval. Insome instances, the proposal may not be immediately approved but may beassigned to an existing or new Working Group for the purpose ofreviewing, revising or extending the proposal.

2.1.0 Any Participant may propose a Working Group. Proposals for the formation of a new Working Group are made by completion of a new new CDM Working Group template, clearly stating the objectives, deliverables and committed maintainers/editors for the proposed Working Group.

2.2.3 CDM Steering Working Group Decision Making: As outlined in governance.md, The CDM Steering Working Group will operate by consensus-based decision-making. Maintainers are responsible for determining and documenting when consensus has been reached. In the event a clear consensus is not reached, Maintainers may call for a simple majority vote of Participants to determine outcomes.

2.2.4 CDM Steering Working Group Appointment of the Editor(s): Editors will review and implement pull requests not expressed in code, test and release new functionalities, resolve bugs and implement approved improvements.

The CDM is developed, built and released using standard softwaresource-control management. Each new released version is announced tousers via a release note that describes the change introduced by thatnew version. The CDM release history is available in the ReleaseSection of the CDM documentation.

The minor, patch and pre-release numbers may sometimes increment by morethan one unit. This is because release candidates may be created but notimmediately released. Subsequently, a version associated with the nextincremental unit may be released that includes the changes from theearlier release candidate.

The purpose of this section is to detail the CDM design principles thatany contribution to the CDM development must adhere to. The CDM supportsthe market objectives of standardisation via a set of design principlesthat include the following concepts:

To achieve standardisation across products and asset classes, the CDMidentifies logical components that fulfil the same function andnormalises them, even when those components may be named and treateddifferently in the context of their respective markets. By helping toremove inefficiencies that siloed IT environments can create (e.g.different systems dealing with cash, listed, financing and derivativetrades make it harder to manage aggregated positions), such designreaffirms the goal of creating an inter-operable ecosystem for theprocessing of transactions across asset classes.

An example of this approach is the normalisation of the concepts ofquantity, price and party in the representation of financialtransactions. The CDM identifies that, regardless of the asset class orproduct type, a financial transaction always involves two counterpartiestrading (i.e. buying or selling) a certain financial product in aspecific quantity and at a specific price. Both quantity and price arethemselves a type of measure, i.e. an amount expressed in a specificunit which could be a currency, a number of shares or barrels, etc. Anexchange rate between currencies, or an interest rate, also fit thatdescription and are represented as prices.

This approach means that a single logical concept such as quantityrepresents concepts that may be named and captured differently acrossmarkets: e.g. notional or principal amount etc. This in turn allowsto normalise processes that depend on this concept: for instance, how toperform an allocation (essentially a split of the quantity of atransaction into several sub-transactions) or an unwind, instead ofspecialised IT systems handling it differently for each asset class.

It is imperative that any request to add new model components orextend existing ones is analysed against existing components to findpatterns that should be factored into common components and avoidspecialising the model according to each use case. For instance, in themodel for averaging options (often used for commodity products,whereby multiple price observations are averaged through time to becompared to the option's strike price), the components are built andnamed such that they can be re-used across asset classes.

To ensure re-usability across different markets, the CDM is designedas a composable model whereby financial objects can be constructedbottom-up based on building-block components. A composable and modularapproach allows for a streamlined model to address a broad scope ofoperational processes consistently across firms' front-to-back flowsand across asset classes. The main groups of composable components are:

In this paradigm, the type of object defined by the CDM, whether afinancial product, business event or legal agreement, is not declaredupfront: instead, the type is inferred through some business logicapplied onto its constituents, which may be context-specific based on agiven taxonomy (e.g. a product classification).

The benefit of this approach is that consistency of objectclassification is achieved through how those objects are populated,rather than depending on each market participant's implementation touse the same naming convention. This approach also avoids the modelrelying on specific taxonomies, labels or identifiers to function andprovides the flexibility to maintain multiple values from differenttaxonomies and identifier sets as data in the model related to the sametransaction. This has a number of useful application, not least forregulatory purposes.

To facilitate adoption by market participants, the CDM is madecompatible with existing industry messaging formats. This means thatthe CDM does not need to be implemented "wholesale" as a replacementto existing messaging systems or databases but can coexist alongsideexisting systems, with a translation layer. In fact, the CDM is designedto provide only a logical model but does not prescribe any physical dataformat, neither for storage nor transport. This means that translationto those physical data formats is built-in, and the CDM is best thoughtof as a logical layer supporting inter-operability between them.

Note:Although the CDM features a serialisation mechanism (currently inJSON), this format is only provided for the convenience of representingphysical CDM objects and is not designed as a storage mechanism.

The need for such inter-operability is illustrated by a typical tradeflow, as it exists in derivatives: a trade may be executed using thepre-trade FIX protocol (with an FpML payload representing the product),confirmed electronically using FpML as the contract representation, andreported to a Trade Repository under the ISO 20022 format. What the CDMprovides is a consistent logical layer that allows to articulate thedifferent components of that front-to-back flow.

In practice, mapping to existing formats is supported by synonymmappings, which are a compact description in the CDM of how dataattributes in one format map to model components. In turn, those synonymmappings can support an ingestion process that consumes physical datamessages and converts them into CDM objects.

The CDM recognises certain formats as de-facto standards that arewidely used to exchange information between market participants. Theirsynonym mappings are included and rigorously tested in each CDM release,allowing firms that already use such standards to bootstrap their CDMimplementation. Besides, because most standard messaging formats aretypically extended and customised by each market participants (e.g. FpMLor FIX), the CDM allows the synonym representation for those standardsto be similarly inherited and extended to cover each firm's specificcustomisation.

The CDM is designed to lay the foundation for the standardisation,automation and inter-operability of industry processes. Industryprocesses represent events and actions that occur through thetransaction's lifecycle, from negotiating a legal agreement toallocating a block-trade, calculating settlement amounts or exchangingmargin requirements.

While FINOS defines the protocols for industry processes in itsdocumentation library, differences in the implementation minutia maycause operational friction between market participants. Even theprotocols that have a native digital representation have writtenspecifications which require further manual coding in order to result ina complete executable solution: e.g. the validation rules in FpML, theRecommended Practices/Guidelines in FIX or CRIF for SIMM and FRTB, whichare only available in the form of PDF documents.

Traditional implementation of a technical standard distributed in prosecomes with the risk of misinterpretation and error. The process isduplicated across each firm adopting the standard, ultimately adding upto high implementation costs across the industry.

By contrast, the CDM provides a fully specified processing model thattranslates the technical standards supporting industry processes intoa machine-readable and machine-executable format. Systematicallyproviding the domain model as executable code vastly reducesimplementation effort and virtually eliminates the risk ofinconsistency. For instance, the CDM is designed to provide a fullyfunctional event model, where the state-transition logic for allpotential transaction lifecycle events is being specified anddistributed as executable code. Another CDM feature is that each modelcomponent is associated with data validation constraints to ensure thatdata is being validated at the point of creation, and this validationlogic is distributed alongside the model itself.

3a8082e126