Reply To: Can EPM’s be used to override the deals PnL Detail ?

#7285
Israr Ahmed
Keymaster

<<< writing into this Forum on behalf of Tom Graham >>

The EPM may return a single MTM for the deal – if it is some kind of B-S-like option model, this is likely.

Or it may return a value broken down by delivery month, or day, or whatever, in a single call – i.e. the MTM return is an array, not a single value.

The model may also return Greeks which correspond to some Endur Greeks – Delta by Leg, Gridpoint Delta, Theta.

Some EPMs return additional ‘Factor Sensitivity’ values which do not correspond to any existing Endur measure (we can put these in a UDSR.)

Generally, if the EPM is capable of giving you more results than just the MTM, you will tell it which you want when you call it: If you only want the MTM value, it would be inefficient for it to calculate all the extra greeks.

It is possible that the EPM may calculate distinct Realised & Unrealised components: If it does, it would be unlike any of the core Endur models: in Endur the split between realised and unrealised is calculated in sim results – outside of the core pricing model (I think this is always true).

If the EPM does calculate it’s own custom split of Realised/Unrealised value, and if you want to use this custom split in the output from PnL Details, then you *have to* implement a Result Calculator for PnL Details, to override the default calculation of Realised/Unrealised (notwithstanding the alternate ‘fudge’ USDR method, which has problems described previously).

Then the question is really just a technical detail of the implementation of the RC – how does it get the Realised/Unrealised values from the EPM.

It is a given that if we have an EPM, we will be implementing an OC Instrument Model, as a wrapper to the EPM, to get the MTM value: whenever we perform any operation in Endur with requires the deal MTM (run MTM sim, open the deal pricer etc) this will invoke the IM calcPresentValue method, so we put a call to the EPM inside this method. (Unless we are using the old pre-OC solution of a C-toolkit EPM wrapper to do the same thing).

There are a few possible ways to get the EPM Realised/Unrealised value into the PnL Detail Result Calculator:

• Call the EPM directly from within the RC – possibly the most straightforward.

• Have the IM (which nominally just returns the total value) take the Realised/Unrealised values from the EPM, and write then somewhere that can be accessed later by the RC. My suggestion is to have it write to the deal pricing details table: This is accessible from the RC, and since we know the IM will always be called before PnL Details is run, this data will be current.

• As someone pointed out – if you call the Transaction.getPricingDetails method, this itself will invoke the IM, so we don’t need to worry about this being current.

These are just Option 1 and Option 2 from the thread above.

I have no idea if your EPM does actually calculate Realised/Unrealised value. If not, and if you don’t implement and RC, PnL Details will output the Total value given by the EPM (via the IM), and will implement whatever is the standard logic to split this into realised/unrealised.

If the EPM does calculate separate Realised/Unrealised values, an RC is the only ‘correct’ way to get these into PnL Details: Option 1 and 2 simply describe alternative ways to implement the RC.

If you are not getting the Realised/Unrealised value from the EPM, but you wish to implement some other custom logic for PnL Details – which I think was the original question – then again an RC is the correct way to do this.

Download PDF version

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