Page History
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:
...
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*.
...
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.
Overview
Content Tools