By Israr Ahmed
Overview
A Flash PnL is a PnL that is calculated and available for the FO on demand before the official End Of Day PnL (usually available by T+1) is generated. The Flash PnL should take into account new trades, trade amendments and impact of price/volatility changes (if new prices are available at time of Flash run).
| There are a number of possible solutions for Flash PnL. In this article we will concentrate on the solution that Runs Flash PnL on the Servers and saves down result in BLOB format. |
Flash PnL Process List of attributes
Not all clients will have the same Flash PnL requirements but we think the following list does specify a good basis for a Flash PnL design:
- Should be able to be run at any time by the FO and to be done so repeatedly if required
- Should show movements in PnL from previous days EOD PnL
- Should allow the PnL to be shown in the same format as the official EOD PnL from Endur
- Should not take too long to calculate
- Should allow drill down to identify any pnl values that need investigating
- Should be accompanied by PnL Explained
Possible Flash PnL solutions
1. APM
Viewing Flash PnL via APM is possible and has certain benefits (mostly from a visual representation/grouping perspective for the FO) but there are a number of issues, which can be overcome but require additional customization:
- The PnL in APM does not have Price Sensitivity so will not update with price changes
- Usually have to add in Impact Of Delta / Gamma as a separate result to existing trades PnL.
- Or possibly restart the APM batch but this has performance consequences and cannot usually be done on an ad-hoc basis.
- Usually have to add in Impact Of Delta / Gamma as a separate result to existing trades PnL.
- More geared to showing LTD PnL rather than Daily PnL move
- Reports usually not in same format as the official EOD PnL so more difficult for MO to reconcile
- Doesn’t have the full PnL Explained data
2. Running Flash locally
This can be done in the form of a simple saved simulation or a script that runs the simulation and creates the reports(s). This approach can be simple or complex depending on the functionality required ( to run on pre-defined books , to run on saved queries , to run on user selected books etc ) . It potentially needs new scripted reports to present the simulation data. It may also have performance issues if there are a large number of trades to be reported on. The biggest issue may be however when running for multiple portfolio’s – where this would have to be coded into the script to look through each portfolio at a time.
3. Running Flash on Servers [ Subject of this Article ]
At client sites where the following factors apply, then this is a good grounds to use design a flash process that runs on servers as described in this article.
- Flash needs to be run across multiple portfolio’s
- Running locally could create memory issues so need to run on server
- Have already got well defined EOD PnL reports that report from the EOD Blobs ( these can be re-pointed to look at the Flash PnL Blobs )
Designing Flash PnL to run on Servers
As listed above, where a client has following conditions, running Flash PnL on the servers is a viable solution:
- Flash needs to be run across multiple portfolio’s
- Running locally could create memory issues so need to run on server
- Have already got well defined EOD PnL reports that report from the EOD Blobs ( these can be re-pointed to look at the Flash PnL Blobs )
Outline of Running Flash on Servers
The Flash PnL Process can be designed to run on the servers by
- Setting it up like the EOD Batch Simulation setup
- Using a different Reval Type
- The trigger to be a FO trigger rather than timed EOD
- To use the latest Universal prices rather than saved close prices
- Creating versions of the existing EOD PnL Reports that simply look at the new Reval Type Blob
- A broadcast/message layer that tells FO when the Flash has started and when it’s finished
|
The following are the main area’s which require setting up for this Flash PnL Process :
(a) Reval Type
A new Reval Type to be set up. The crucial setup detail is that the Prior Reval needs to be the official EOD Reval Type.
(b) Flash PnL Batch Simulation
A new simulation needs to be set-up. This simulation should not contain any Greeks as its purpose is to calculate PnL and PnL Explained as quickly as possible. So the results in this should contain:
- The PnL simulation result that’s being used at the client site ( could be PnL Detail or a UDSR )
- PnL Explained and Base PnL Explained sim result
(c) Batch Simulation Definitions
Flash Batch simulation definitions to be set up – grouping all the portfolio’s together that require flash pnl together. The same queries as the official EOD queries can be used (unless New tran status trades are to be also included).
(d) Batch Simulation Run Script
These will be like the standard batch sim run scripts but with the difference that they will be parametrised to use Universal Prices rather than Save Closing Prices.
(e) Trigger Script
As the FO Trader will be starting the Flash PnL process, there will be a task that they run, which sets off the appropriate flash pnl workflow on the server. This trigger script can also be enhanced to send a message to the FO Trader / MO / Support to let them know that the Flash PnL process has started to run.
(f) Broadcast Scripts
A separate message script can be written that runs at the end of the Flash PnL workflow to let FO Trader / MO / Support know that the Flash Process has finished.
(g) The Flash PnL and Explained Reports
Any existing PnL reports / process that looks at the existing EOD Reval Type can be parametrised to look at the new Flash PnL Reval Type.
(h) Services Manager Layer
This is where the workflows would be setup to run on the server (to be triggered by the FO task). The workflow would have the following structure:
|
pro’s and cons
| Pro | Con |
|
|
PnL Explained enrichment to Flash
The above design will work without PnL Explained. But having a PnL Explained in the same set of Flash reports is quite a powerful tool to see where the PnL moves come from. In addition, it does not add any significant calculation time to the process.
However, it will reply on a well-designed PnL Explained configuration set up in the EOD process. If the EOD is designed to calculate greeks and the simulation parameters are set in an appropriate manner, then the Flash process can simply utilize this set-up and not have to calculate any greeks itself.
The setup of PnL Explained is a separate field of expertise in which KWA have extensive experience.
Other people's views
The script that runs the Flash Sim can also look to Index Rates sim results ( which gives the list of curves used in the simulation ) and check to see which of these curves have had prices published.