Standardize a context representing a Trade
Enhancement Request
Create a context type to represent an individual Trade.
Use Case:
Represent an individual transaction relating to a specified security, which may be visualized (e.g. on a pricing chart) or used to compose another context type, such as a Position context.
Contexts
Trade
A Trade represents a holding's duration, value and location. It may form a key component of a Position context.
The trade can either be open or closed. This is expressed with the population of the fields pertaining to the end time/value (leave out the end times and close properties for an open trade).
The Trade type goes hand-in-hand with the Position type, which represents multiple trades in a combination of dates, values, or locations. It may also be used to construct a list of historical trades.
Details
| Property | Type | Required | Example Value |
|---|---|---|---|
type |
string | Yes | 'fdc3.trade' |
id |
object | No | { 'tradeId: "ABCDE123455" } |
instrument |
Instrument | Yes | { type: 'fdc3.instrument', ... } |
tradeTimeRange |
TimeRange * | Yes | { type: 'fdc3.timeRange', ... } |
settleTimeRange |
TimeRange * | No | { type: 'fdc3.timeRange', ... } |
quantity |
object | Yes | (see sub-fields) |
quantity.units |
number | No | `123.4561 |
quantity.value |
number | No | `-50000.00 |
quantity.CURRENCY_ISOCODE |
string | No | "GBP" |
open |
Valuation ** | Yes | { type: 'fdc3.valuation', ... } |
close |
Valuation ** | No | { type: 'fdc3.valuation', ... } |
location |
string | No | 'London trading desk' |
account |
string | No | cash |
* See issue #646 ** See issue #652
Example
const trade = {
type: "fdc3.trade",
instrument: {
type: "fdc3.instrument",
id: {
ticker: "AAPL"
}
},
tradeTimeRange: {
type: "fdc3.timeRange",
starttime: "2020-09-01T08:00:00.000Z"
},
settleTimeRange: {
type: "fdc3.timeRange",
starttime: "2020-09-02T08:00:00.000Z"
},
quantity: {
value: -50000.0,
CURRENCY_ISOCODE: 'GBP'
},
open: {
type: 'fdc3.valuation',
value: 50000.0,
price: 405.0,
CURRENCY_ISOCODE: 'GBP'
},
location: "London Trading desk",
account: "cash"
};
fdc3.broadcast(trade);
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.
I don't think it's valid to make units a required field.
Some instruments (e.g. Mutual Funds) are commonly traded as value-based trades where the open order is an instruction to subscribe to, or redeem, sufficient units to realise a specified amount of currency. e.g. "raise 50k in cash"
We often talk about referring to prior art (well, @rikoe does :-) ) and FIX has already solved this by requiring an OrderQtyData block that consists of either an OrderQty or CashOrderQty.
It seems silly to go backwards in this respect. Can I suggest a similar concept here, e.g.
const trade = {
type: "fdc3.trade",
instrument: {
type: "fdc3.instrument",
id: {
ISIN: "LU1988889314"
}
},
tradeTimeRange: {
type: "fdc3.timeRange",
starttime: "2020-09-01T08:00:00.000Z"
},
settleTimeRange: {
type: "fdc3.timeRange",
starttime: "2020-09-02T08:00:00.000Z"
},
quantity: {
units: 123.456
},
open: {
type: 'fdc3.valuation',
value: 50000.0,
price: 405.0,
CURRENCY_ISOCODE: 'GBP'
},
location: "XYZ",
account: "cash"
};
fdc3.broadcast(trade);
as well as:
const trade = {
type: "fdc3.trade",
instrument: {
type: "fdc3.instrument",
id: {
ISIN: "LU1988889314"
}
},
tradeTimeRange: {
type: "fdc3.timeRange",
starttime: "2020-09-01T08:00:00.000Z"
},
settleTimeRange: {
type: "fdc3.timeRange",
starttime: "2020-09-02T08:00:00.000Z"
},
quantity: {
value: -50000.0,
CURRENCY_ISOCODE: 'GBP'
},
open: {
type: 'fdc3.valuation',
value: 50000.0,
price: 405.0,
CURRENCY_ISOCODE: 'GBP'
},
location: "XYZ",
account: "cash"
};
fdc3.broadcast(trade);
Sorry for the stupid question but what does location stand for and how should it be used?
@dominicgifford updated with your quantity suggestion. Marked quantity required, but not the sub-fields. However, I can probably finesse that in the actual schema (e.g. require units or value + CURRENCY_ISOCODE). What do you suggest?
Also I have no idea what a realistic location value would look like.
P.S. this context is probably a good candidate from an experimental label