Summary of Financial Objects and Use Cases - Working Group
Red = Mandatory
Orange = Optional
Blue = Reference IDs (at least one must be provided)
Green = Mandatory Object Reference
Financial Object Type | Product | Sub Product | Use Case | Object Attributes and Examples - Working Version | Contributors | Next Meeting | Target Outcomes and Review | Version |
|---|---|---|---|---|---|---|---|---|
Trade Object | Rates | Interest Rate Swap (IRS) | Ability to define and pass through a structured object between buy-side, sell-side and financial eco-system partners. This will allow a specific trade and instrument context E.g. Rates trade object to be passed in a use case workflow to satisfy a pre-trade, trade, post trade workflow. The goal is to enable and foster greater open collaboration between creators of Financial Objects and with the users of Financial Objects starting with trade objects.
Type of interaction, stage of trade-life-cycle, extensible objects that can be enriched (from core essential objects) | <Fundamental Trade Object>: Product: IRS CCY: CHF Maturity: 10Y Clear: LCH
Example: IRS, USD, 10Y, LCH (Vanilla Swap), IRS, USD, 10y/5y, LCH (Vanilla Swap - 5y swap 10y fwd) If multi-leg all the above details for the other legs. Fundamental trade object would be expanded for Curve Trades, Butterflies, Basis, Cap/Floors, Collars
| Citi, JPM | 29th November 2018 |
| Draft and in-progress |
RFQ Object | Rates | Interest Rate Swap (IRS) | The RFQ object will be an extension of the trade object by identifying the additional attributes over and above the trade object to determine the status of RFQ - inquiry, response, state change data fields. | <RFQ>: Requestor Unique ID: [Entity A] Direction: two-way market Notional: 36,830,000.00 Start Date End Date Roll Convention <Fundamental Trade Object>: Product: IRS CCY: CHF Maturity: 10Y Clear: LCH
<RFQ Response>: Responder Unique ID:[Entity B] Receive Fixed Level: [x.xx]% Pay Fixed Level: [x.xy]% <RFQ>: Requestor Unique ID: [Entity A] Direction: two-way market Notional: 36,830,000.00 Start Date End Date Roll Convention <Fundamental Trade Object>: Product: IRS CCY: CHF Maturity: 10Y Clear: LCH
Example: IRS, USD, 50m, 31/08/2018,31/08/2028, IMM, LCH, 2 way (Vanilla Swap), IRS, USD, 31/08/2018 10y/5y, IMM, LCH, 2 way (Vanilla Swap - 5y swap 10y fwd) If multi-leg all the above details for the other legs. Fundamental trade object would be expanded for Curve Trades, Butterflies, Basis, Cap/Floors, Collars | Citi, JPM | 29th November 2018 |
| Draft and in-progress |
Order Object | Rates | Interest Rate Swap (IRS) | The Order object can be enabled and triggered from a blotter or similar application to place an order.
Let's compare to an IOI object to see if there is a delta in attributes [ Feedback - 9th Aug 2018] | <Trade Order>: Requestor Unique ID: [Entity A] Direction: Receive Fixed Notional: 36,830,000.00 Start Date End Date Roll Convention <Fundamental Trade Object>: Product: IRS CCY: CHF Maturity: 10Y Clear: LCH
<Trade Order Response>: Responder Unique ID: [Entity B] Receive Fixed Level: [x.xx]% <Trade Order>: Requestor Unique ID: [Entity A] Direction: Receive Fixed Notional: 36,830,000.00 Start Date End Date Roll Convention <Fundamental Trade Object>: Product: IRS CCY: CHF Maturity: 10Y Clear: LCH
Refer to example from Rates RFQ Object above | Openfin, Opendoor, Citi, JPM | 29th November 2018 |
| Draft and in-progress |
Instrument | Reference | Single Item | Several use cases and workflows rely on that all parties involved can understand what instrument is being referred to - be it a simple chat message "why is Apple up today?" where the receiver wants to look up details about the company mentioned or a complex financial object - involving several securities - that will be parsed by a system. An object with standardized names would allow for the use of several IDs to define the instrument - including all well-known data-sets and open symbology reference data as well as custom inhouse IDs if needed. The main idea is for each participant to send as many IDs as exist in the system and be able to receive/understand as many as possible.This will ensure compatibility with existing applications while at the same time allow for a potential "most-favored" ID to become a future standard. | <Instrument> Name Id ticker
For an example of how an Instrument object can be sent using FDC3 Context Data, please see https://github.com/FDC3/ContextData/blob/master/src/examples/Instrument.ts | FDC3 Context Data WG |
| None of the IDs are mandatory and empty IDs should not be send. It should be considered bad practice to put "incorrect" data into an object reference. Eg if a system for some reason don't have SEDOLs for all instruments and make up custom IDs for internal use - these must not be sent out externally as SEDOLs. | 1.0.1 |
Contact | Reference | Single Item | An object with standardized names would allow for the use of several IDs to define the contact - including all well-known data-sets and open symbology reference data as well as custom inhouse IDs if needed. | <Contact> Name: Bob Smith Id email
For an example of how an Contact object can be sent using FDC3 Context Data, please see https://github.com/FDC3/ContextData/blob/master/src/examples/Contact.ts | FDC3 Context Data WG |
| None of the IDs are mandatory and empty IDs should not be send. | 1.0.0 |
Organization | Reference | Single Item | An object with standardized names would allow for the use of several IDs to define the organization - including all well-known data-sets and open symbology reference data as well as custom inhouse IDs if needed. | <Organization> Name: Id LEI
For an example of how an Organization object can be sent using FDC3 Context Data, please see https://github.com/FDC3/ContextData/blob/master/src/examples/Organization.ts | FDC3 Context Data WG |
| None of the IDs are mandatory and empty IDs should not be send. | 1.0.1 |
Country | Reference | Single item | An object with standardized names would allow for the use of several IDs to define the country - including all well-known data-sets and open symbology reference data as well as custom inhouse IDs if needed. | <Country> Name: United States of America Id ISOALPHA2 | FDC3 Context Data WG |
| None of the IDs are mandatory and empty IDs should not be send. | 1.0.0 |
InstrumentList | Reference | List | A standardized format for a lists of Instruments. | <InstrumentList> Name: Instruments: Instrument Array
For an example of how a InstrumentList object can be sent using FDC3 Context Data, please see https://github.com/FDC3/ContextData/blob/master/src/examples/InstrumentList.ts | FDC3 Context Data WG |
|
| 1.0.0 |
ContactList | Reference | List | A standardized format for a lists of Contacts. | <ContactList> Name: Contacts: Contact Array
For an example of how a ContactList object can be sent using FDC3 Context Data, please see https://github.com/FDC3/ContextData/blob/master/src/examples/ContactList.ts | FDC3 Context Data WG |
|
| 1.0.0 |
Position | Reference | InterOp | A standardized format to transfer an Instrument and unique meta data for each position, with possibility to extend what is included for each position, including custom inhouse IDs if needed. | <Position> Name: Instrument: Instrument Holding
For an example of how a Position object can be sent using FDC3 Context Data, please see https://github.com/FDC3/ContextData/blob/master/src/examples/Position.ts | FDC3 Context Data WG |
|
| 1.0.0 |
Portfolio | Reference | InterOp | A standardized format to transfer Positions and unique meta data for each portfolio, with possibility to extend what is included for each portfolio, including custom inhouse IDs if needed. | <Portfolio> Name: My portfolio Positions: Position Array Id id
For an example of how a Portfolio object can be sent using FDC3 Context Data, please see https://github.com/FDC3/ContextData/blob/master/src/examples/Portfolio.ts | FDC3 Context Data WG |
|
| 1.0.0 |