Context Proposal: Order

[nemery-flextrade]

Order

Use Cases

• Portfolio manager has designed an order and wants to send this to OMS/EMS directly
• Portfolio manager has designed an order and wants to send this to a trader via a chat application
  • It should then be possible for PM / trader to stage this order in to OMS/EMS from the chat application

Property	Type	Required	Example
id	Object	Yes[1]	'OMS': '123456789'}
sendingTime	String [2]	Yes	'2022-03-30T15:44:44+00:00'
timeInForce	fdc3.timeRange[3]	No
orderLegs	List (fdc3.orderLeg)	Yes
partyIdentifiers	List (fdc3.partyIdentifier)	No
notes	String	No

[1] - Must contain at minimum one identifier

[2] - sendingTime format: UTC timestamp

[3] - timeInForce Omission of timeRange.startTime means order is active immediately. Omission of timeRange.endTime acts as good till cancel. Omission of timeInForce defaults to day.

OrderLeg

Property	Type	Required	Example
type	String	Yes	fdc3.orderLeg
id	object	Conditional[1]	{'OMS': '123456789-leg1'}
product	object	Yes	{'instrument': {'ticker':'MSFT'}}
quantity	object	Yes	{'units': 100000.0}
currency	String (Currency Code)[2]	Yes	'GBP'
side	String	Yes	'B' | 'S' | 'P' | 'R'...
price	object	No	{'limitPrice': 123.45}
settlement	fdc3.settlementData	Conditional[3]	{currency: 'USD'}
allocations	List (fdc3.allocation)	No
positionIndicator	String	No	'O' | 'C'
partyIdentifiers	List (Party Identifier)	No	{role: PartyRole.OriginatingTrader, source: PartyIdentifierSource.Custom, value: 'TRADER1'}

[1] - referenceIdentifier is mandatory only when the count of legs > 1. Must be unique within the context of this trade (at minimum).

[2] - currency valid values are ISO currency codes + additional codes as defined by ISDA

[3] - settlement block required only when some detail (date and/or currency) differs from market convention or where there there is no market convention

Product

Property	Type	Required	Example
instrument	fdc3.instrument	No	{'ticker': 'MSFT'}
productDefinition	object	No	{'ISDA': {...}, 'FpML': {...}}

Quantity Data

Property	Type	Required	Example
units[1]	Double	Conditional[1]	10000.00
cashValue[3]	Double	Conditional[1]	50000.00
proceedsFrom[4]	object	Conditional[1]	'OMS': '123456789-leg1'
executedUnits	Double	Conditional[4]	100.00

[1] - units refers to the standard unit of trade for a given instrument (shares for equities, contracts for options etc.)

[2] - One of units, cashValue or proceedsFrom must be specified

[3] - cashValue is expressed in terms of the currency specified for this order leg. The downstream system is responsible for calculating the quantity in units based on cashValue and current market price (cashValue / marketPrice, for discreet units round down when buying and up when selling).

[4] - proceedsFrom indicates that the proceeds from a previous order should be used as the cashValue limit for this trade. This creates an implicit requirement that the specified order leg has been executed.

[5] - executedUnits required if order is partially/fully executed.

Price Data

Property	Type	Required	Example
limitPrice	Double	No[1]	123.45
stopPrice	Double	No	124.56
executedAveragePrice	Double	Conditional[2]	123.80
strikePrice	Double	Conditional[3]	125.00
priceType	String	No	'absolute' | 'percentage' | 'yield' | 'spread'

[1] - Omission of limitPrice indicates a market order

[2] - executedAveragePrice required if order is partially / fully executed.

[3] - strikePrice required for options

Settlement Data

Property	Type	Required	Example
type	String	Yes	fdc3.settlementData
tenor	String	Conditional[1]	'SP' | 'SN' | '1W'...[]
date	String (UTC Timestamp)	Conditional[1]	'2022-03-30T15:44:44+00:00'
currency	String (Currency Code)	Conditional[2]	'GBP'

[1] - One of tenor or date is required when settlement deviates from the market convention for the instrument (for example T+2 for equities)

[2] - currency required only if settlement currency differs from the currency specified at the order leg level

Allocation

Property	Type	Required	Example
type	String	Yes	fdc3.allocation
account	String	Yes	'account1'
quantity[1]	Double	Yes	1000000.00
positionIndicator[2]	String	No	'O' | 'C'

[1] - quantity is with respect to the side of the order leg

[2] - positionIndicator refers to the position effect with respect to this account only

Party Identifier

Property	Type	Required	Example
role	fdc3.partyRole[1]	Yes	PartyRole.RestrictedCounterparty
value	String | fdc3.contact | fdc3.organization	Yes	'BROKER1'
source	fdc3.partyIdentifierSource[2]	No	PartyIdentifierSource.LEI

[1] - I propose that fdc3.partyRole be a primitive enumeration 1 to 1 mapped from FIX tag 452. Not using raw codes here increases human readability but having the underlying enumeration value will allow existing systems to reuse processing logic from FIX

[2] - I propose that fdc3.partyIdentifierSource be as above for FIX tag 447. Omission of this field is assumed to indicate that value is a proprietary identifier (analogous to FIX tag 447 = D).

Additional Information

Below is feedback from our working group members during previous workshops around this proposal. These are guidelines which should be taken into account when working on this proposal.

• FDC3 Intents and contexts are not meant to be used for verbose asynchronous transactions;
  • They only need to provide just enough data to allow an end user to find, or start to create, the order or trade in question in the target application
  • When creating orders or trades, it is expected that the target application will still have some work to do. This may involve validation of data received and asking for additional information. E.g.
    • Prompt the user to select a trading desk
    • Work out the settlement date based on its security static data and good business day calendars
  • It is expected that the end user will inspect and enrich any order or trade created by an intent before submitting it; FDC3 is merely facilitating the process, making the workflow less arduous and reducing the risk of manual error on the fundamentals.
• FDC3 is not meant to replace existing protocols – FIX, FIXML, FpML, SWIFT etc all have their place in the world and should still be used where appropriate.
• FDC3 is not expected to understand the nuances of a particular market or sector. For example, if your application always quotes on British shares in pence, that does not mean FDC3 needs to transmit prices and quantities in minor currency units. Rather, FDC3 will use major currency units, understood by all, and your application will need to do the transformation between formats when required.

[nemery-flextrade]

Just off the top of my head I can think of the following suggestions for types/enumerations.
Enumerations:

• Size Type
  • Shares
  • fdc3.currency (FX)
  • Contracts
• Price Type
  • Limit
  • Par
• Order Type
  • Limit
  • Market
  • Stop
  • ...

Additional Types:

• Allocation Information
  • Account
  • Size
• Counterparty Restrictions
  • fdc3.organisation
  • Directed / Restricted

[nemery-flextrade]

Additionally I expect this would be an alternative payload for ViewAnalysis

[timjenkel]

I think its better to use codes for the side, like
B = Buy
S = Sell
SS = Short Sell
BS = Buy Cover (not sure if this is standard)

[WatsonCIQ]

@nemery-flextrade could orderId be changed to be id?
This would then match the fdc3.trade proposal too.

[nemery-flextrade]

@WatsonCIQ I have been working on a revamp of this proposal with @dominicgifford, I think we're close to something that should handle most use cases. I will update this issue over the next day or so so that others can get a sneak preview.

[nemery-flextrade]

@dominicgifford I have brain dumped here - I'm guessing we should split this out in to smaller issues?

[WatsonCIQ]

@WatsonCIQ I have been working on a revamp of this proposal with @dominicgifford, I think we're close to something that should handle most use cases. I will update this issue over the next day or so so that others can get a sneak preview.

Thanks for the updates @nemery-flextrade & @dominicgifford ! 👍

[hampshan]

I think we need to support % values. E.g. % strike

[nemery-flextrade]

@hampshan I'm afraid I'm not familiar with % strikes hence the omission. More generally though, I agree - alternative price types was something I think @dominicgifford mentioned during one of our chats but including it must have slipped my mind.

Would you be happy with a field indicating the priceType ({absolute, percentage, yield, etc.})?

Also would you be willing to circulate on your side for any further feedback as (I think I remember) you said on the call? 😄

[mistryvinay]

@hampshan would the above inclusion of a priceType field that is being proposed by @nemery-flextrade address the requirement you raised?