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	Walk through of use case Example of Rates - Trade Object	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	Definition of additional RFQ Object Attributes	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	Proposal reviewed - Order Data Structure, (Leg Data Structure, Security Data Structure) potential to cross leverage at (Trade Object) level	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 ISIN CUSIP SEDOL RIC BBG PERMID FIGI FDS_ID 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 FDS_ID 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 PERMID FDS_ID 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 ISOALPHA3	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