Position Calculation

Synopsis

In order for Reflector to accurately enforce risk limits, the system must have a logical method to determine the net open position (NOP) of a user at a given time. Reflector achieves this using the methods outlined below.

Overview

Reflector tracks positions in two separate places:

In the first instance, Reflector tracks the position using the actual runtime and in the second instance in an execution database. The runtime version tracks open orders in addition to executed fills, but is heavily optimized for latency. This means every possible effort to reduce memory usage is employed. At the end of the trading day, the process does not know how much to roll over.

The database, in contrast, runs at a moderate rate maintaining track of the details that relate to the identity & position of every execution. Therefore, during the rollover, a list of updates that must be applied to the reflector runtime process is computed, stored into an event log, and then executed from that log.

Calculation

Every reflector instance has an associated fill database. The database is queried for every fill that belongs to a customer or user (e.g ExampleFund Ltd) where fills are deemed eligible for entry if they are deemed valid and have not expired*.

Note

Expired* as mentioned in the statement above, is taken as meaning that the accumulated positions will expire on reaching their settlement date.
In circumstances where the use of "Evergreen" positions are implemented, a user or customer can request that the accumulated positions never expire.

A Reflector instance can have users with either the expire at settlement definition whilst also having separate users with expiration defined as "Evergreen". However, a single user will not be able to submit orders using a combination of "Evergreen" and expire at settlement.

Reflector begins by identifying the user account, before connecting to the fill database. Reflector will then identify the relevant schema for the user before running a query for the entire set of fills (belonging to the credentials of the user that are valid and have not expired) an example of what such results may look like is displayed in the table below.

exec_id	credential_id	seq_num	internal	validity	buy_ccy	sell_ccy	buy_amt	sell_amt	trade_date	settle_date	venue_name	comp_id	taker	client_id	expires_at_settlement
123	21	74119	f	t	NZD	EUR	60114.96	36000	20170124	20170130	FIX_Venue	76000/109331	True	6792	True
1234	21	74172	f	t	NZD	EUR	83491.5	50000	20170124	20170130	FIX_Venue	76000/109331	True	6792	True
12345	21	74284	f	t	NZD	EUR	417382.5	250000	20170124	20170130	FIX_Venue	76000/109331	True	6792	True
123456	21	74293	f	t	NZD	EUR	83476.5	50000	20170124	20170130	FIX_Venue	76000/109331	True	6792	True
1234567	21	74294	f	t	NZD	EUR	250428	150000	20170124	20170130	FIX_Venue	76000/109331	True	6792	True
12345678	21	74737	f	t	NZD	EUR	1017186.5	605000	20170124	20170130	FIX_Venue	76000/109331	True	6792	True

In the example above the trades, all involve the same security pairs. Therefore, it is straightforward to determine the user's present position by creating a total of the NZD amounts and the EUR Amounts, where the user is up in NZD (upside) and down EUR (downside) as the user has orders to buy NZD and sell EUR.