By Richard Knight

Introduction    

Endur system supports advancing the ‘Trading’ date to the next working day ( for traders ) whilst leaving other user groups on the previous ‘Business’ date to allow them to complete end-of-day (eod) processing before their session date is rolled forward.

Endur also supports the creation of additional ‘sets’ of system dates to support trading operations in different regions and time zones – Endur ‘Trading Locations‘ functionality.

This article describes a typical scenario requiring the use of an additional set of dates and highlights some of the main considerations when implementing multi-region trading in Endur.

The Scenario

A London based Gas business, where the UK gas day starts at 5AM, has operators balancing positions up until 3:30AM ahead of the start of the next gas day. Trades executed up to this hour must be included in pnl and position calculations/reporting for the current day.

Consequently eod processing is scheduled to kickoff at around 4AM, at the start of which the system ‘Trading’ date is rolled so that traders arriving at 7AM will logon to Endur and see the ‘current’ date.

The same company now opens a Singapore office trading renewables, their traders arrive at midnight LDN time (8AM Singapore) and expect their Endur session dates to reflect the local date as well as pnl, position and exposure reports for the prior day to be available for review and sign-off.

Potential Solution

A second set of system dates are configured for Singapore and linked to Singapore users. This allows the ‘Singapore’ system dates (Trading and Business) to be rolled independently of ‘London’ dates supporting separate end of day workflows ( dates, close prices, close pnl etc.) for each region.

So for example, in our scenario above, eod processing for the Singapore business could start at 10PM London time completing by midnight (8AM Singapore) whilst eod processing for LDN could remain scheduled to start at 4AM.

Implementation Considerations

• Hardware: Aside from handling the additional transactional load arising from the new business, the above scenario would typically require additional hardware so that processes can be dispatched by and run on separate ‘LDN’ and ‘SNG’ server sessions.
  

Readers may be familiar with functionality which provides the option for a task to be run on a remote server node using either the dispatching user’s id or that of the server node. For example, user A can run a task on user B’s session (a remote server) and the task will be processed with user A’s security profile and also user A’s ‘current’ system date.

Relating this to the scenario above, when SNG ‘dates’ have rolled forward, tasks in the SNG eod workflow can be run on LDN servers ( which are still on ‘LDN’ dates ) providing that the tasks are dispatched by an SNG user.

This functionality could mean that rather than requiring the procurement of an additional set of servers to independently process the SNG eod tasks it could be possible to deploy SNG server(s) just to dispatch tasks, allowing you to take advantage of availability on existing LDN servers.

Note, however, that not all eod processing consists of running plugins in a task and the dispatching functionality described here may not be available. For example, it has been observed when running Report Builder in V10 that the despatcher id does not persist to remote server nodes. APM services may also require separate server nodes.

• Licensing
  
  • Users: In addition to the cost of procuring additional hardware, implementing multi-region eod typically requires procurement of additional server licenses in addition to licenses for Singapore users.
    
  • Features: ‘Trading Locations’ is a separately licensed feature by OpenLink and therefore may incur additional procurement cost.
    
• Market Datasets per region. In addition to configuring a set of system dates for SNG eod processing, it is also possible to implement separate closing market datasets for each trading location. Doing so allows each location to independently save and subsequently retrieve the market data used in the SNG and LDN eod’s which is very useful, however, there are likely to be some curves that are common to be both datasets, typically FX and Interest Rates.
  

  The implications of having two close price data sets, taken at different times, for the same curve may require some consideration, for example, if regional exposure is aggregated into a global risk engine or marking of portfolios for end of month accounting.
  

• Increased complexity and test effort to release new functionality. In addition to the overhead of implementing a new market in the system, the following are an example of further design considerations:
  
  • Reporting: Existing reports ( there’s often in excess of 50 reports in a typical production instance of Endur) which now need to include SNG eod data may all require update – here’s why:
    

    During eod processing Endur saves calculation results: pnl, position, exposure etc. as compressed data packets per portfolio and tagged with a default ‘eod’ calculation or ‘reval’ type. Reports which retrieve this data are typically ‘hardcoded’ to retrieve this ‘eod reval’ type.
    

    If the SNG eod is to run with its own close price dataset then Endur’s multi-region functionality requires the results to be tagged with a separate ‘reval’ type, for example ‘eod_sng’. Therefore, existing reports which must now additionally include SNG eod results will need to be updated to point to the new reval type ‘eod_sng’
    

  • Traders who need to operate in both regions?  Endur supports a user being assigned to both LDN and SNG trading locations and also provides a facility for the trader to flip between the two for purposes of deal entry, however, if this is a business requirement it’s likely that some additional controls would need to be implemented alongside.
    
  • Agreement on how to close trading books at the end of each day. The ‘traded date’ stamp on a deal is most often used as the cutoff criteria and in the above scenario for gas and renewables this would probably work well, however, where different regions of an organisation are trading the same markets or where trading books are handed over to another region this approach may not be appropriate.
    
• Support overhead. Running separate EoD workflows has an additional support overhead, for example, new ‘on-call’ arrangements may be required for a 1st line team to provide support at the times when eod workflows are running.