Endur EOD PnL – Impact Of Cancelled Deals

Endur EOD PnL – Impact Of Cancelled Deals

by Richard Knight

 

Summary:
The Impact of Cancellations simulation result is a component of Endur’s PnL Explained report and calculates the movement in MTM as a result of cancelling a deal, however, there are design limitations which can present issues if your end of day batch isn’t run every day. This article highlights the issues and discusses solutions for consideration.

_______________________________________________________________________________

The Impact of Cancellations simulation result is a component of the PnL Explained report (which is itself a simulation result) and calculates the movement in MTM as a result of cancelling a deal. It is designed to be run only with the simulation ‘Reval Type’ set to EOD and additionally will work only when the following criteria are met:

  • the deal was Validated on a previous day
  • the deal is present in saved EOD results on the previous day

Unlike other ‘Impact of’ results, Impact of Cancellations does not search for any deals that have been cancelled since the last EoD batch but has a limitation in that it will only pick up cancelled deals where the cancellation event is on the date of the next EoD batch.

Consider the following scenario:

  • A validated trade existing in Friday’s saved EOD results
  • The deal was cancelled on the following Sunday evening by the operations team
  • The next EOD batch is run on the following Monday.

In this scenario the cancelled deal would not be picked up by the ‘Impact of Cancellations’ result, resulting in unexplained PnL.

Further, and potentially much more significant, the deal will continue to appear in the cumulative versions of PnL Detail: MTD, YTD as a validated deal with non-zero PnL requiring a corrective PnL adjustment to be applied for the remainder of the year.

Whilst not every client will have implemented EoD processing on the schedule described in the scenario, it is reasonably common for EOD batch simulations to be scheduled not to run on weekends so that the day-on-day PnL calculated on Monday (or the next working day following a weekend/ holiday) reflects the true move since the last business day rather than an artificial move were the batch to be run on non-working days.

So faced with misreporting PnL and managing adhoc PnL adjustments the following options could be considered to avoid the situation arising again:

  1. Block Cancellations – users could be prevented from cancelling deals on days when the batch simulations are not scheduled to run, either by business process or system enforced using TPM or Ops Service.

  2. Two-Step Cancellation
    – introduce a two-step cancellation process so that a deal is ‘marked’ for cancellation by processing to ‘Cancelled-New’ but only fully cancelled on next business day.

  3. Develop Custom PnL Results – User defined simulation results could be developed containing the rules required for correct handling of cancellations.

  4. Include Cancelled Deals in EoD Query results – Even though the ‘end of day’ queries (which retrieve the trades passed into the eod batch simulation) only retrieve deals at validated status, certain simulation results that require data from deals in other statuses such as: “Impact of Cancellation”, which needs to retrieve cancelled deals or “Impact of Closeout”, which needs to retrieve closedout deals, will automatically retrieve any necessary deals, even though the query did not explicitly include them. The simulation reval type needs to be set to EOD for these results to work as designed. Specifically, the EOD Reval Type does the following:

    1) Automatically loads Amended, Cancelled, Bought Out and Closed Out deals into the query.
    2) Calculates Realized PNL due to Match Off, Margin, and Closeouts.
    3) Seeds Cumulative Results with the full list of deals, not just the deals in the Reval

    Whereas the EOD Reval will retrieve any deals that have been Amended since the last EOD run, it will only retrieve Cancelled deals where the cancellation event date = EOD reval date.

    To work around this limitation, it is possible to modify EOD queries to retrieve any deals that were present in the last EOD but have subsequently been cancelled on a day in between the last EOD run and the current EOD run.

    In principal it is not recommended generally to include cancelled deals in the eod query criteria since cancelled deals could be included past the cancellation date potentially giving misleading pnl results, however, the targeted approach described above has proved to be an acceptable solution and will give reliable results.

Summary of Solution Options

SolutionProsCons
Block CancellationsAchieves correct EoD PnLRisk of leaving void deals in system. the implications of failing to cancel a deal are more severe than the problem of misreported P&L.
Two-Step CancellationAchieves correct EoD PnL
Deals processed to CancelledNew can immediately drop from APM position and PnL reports
Introducing a new transaction status could require changes to existing interfaces to trigger cancelation messages for trades at Cancelled NewUsers must ‘remember’ to fully cancel the deal on the next working day otherwise it would not be included in end of day processing. ( though users could be prompted to do this using a scheduled workflow that runs every hour on working days, sending an email alert if Cancelled New trades are found )
Develop Custom PnL ResultsAchieves correct EoD PnLComplex and expensive
Include Cancelled Deals in EoD Query resultsAchieves correct EoD PnL
Relatively simple to implement
Queries must be carefully designed to accurately select cancelled deals.More complex EoD query

KWA have experience in designing and implementing the solutions discussed in this article.
 


 
 

Have your say:

You Must Be A Member To Read This Article

We regularly publish great content from our experts advising you on how to maximise the efficiency of your trading software and business intelligence suites.  Become a member today to access them all, for free.

Download PDF version

This field is for validation purposes and should be left unchanged.