I was asked in the comments for April 20 whether the valuation shown by HIMIPref™ for BCE.PR.C was OK or not … it was showing a massive, massive positive number.
Well, no, it wasn’t … it dropped out of the math as designed, but division by small numbers can cause problems and huge results. The trading engine knows that this sometimes happens, however, and annulled the result without recommending a trade.
The riskRewardAnalysisBox showed numbers that all looked fairly normal, with the exception of portYieldReversion: this showed an exceptionally – ridiculously – high value of 135.443.
Therefore, one looks at the riskRewardAnalyticalValuesBox to find that this value depends upon some reasonable reversion factors and a pseudoModifiedDurationPort of -244.2194 … rather a large value, and with a funny sign, to boot!
The calculation of this variable may be examined via the pseudoPortfolioReportBox, which reports that a 2% change in price results in an absolute yield (and we are talking about portYield, remember!) change of -0.0082% and the large value of pseudoModifiedDurationPort.
Bringing up the details for the three yield calculations implicit in this value, we find that the high priced yield is 4.1622% with a price of 23.937 and the base priced yield is 4.1702% with a price of 23.70 while the low priced yield is 4.1540% with a price of 23.463.
Essentially, what is happening is that the probability of a near-term call at a price higher than market is goes up with price at a rate that nearly exactly matches the decline in yield of the far more likely limitMaturity, so that price changes, at this particular price level, have a negligible effect on this particular measure of yield.
*sigh* It happens.
Fortunately, though, an occasional blow-up like this is accounted for in the trading engine – even at the ridiculously high valuation, there are very few trades generated into this security.
When we look at the trade evalation report, into BCE.PR.C out of a randomly chosen security, we see that the bidToOfferPickup is negative. Negative? How can it possibly be negative when the valuation on the buy side is so high?
To answer that, we look at the pickup calculation box for this trade and find that, while the buyValuationAsk is much greater than the sellValuationBid, there is a large negative contribution to the total pickup from the parameter excessRewardDifferenceValuation, a parameter invented for just such occasions.
In the standard parameterization supplied with HIMIPref™, the parameter excessValuationCap is set to 1.00, while the excessValuationReduction is set to 2.00. This adjustment – one might almost call it a sanity check in the calculations – prevents the trade from being shown as desirable, both in live reports and in future simulations that will analyze this date as part of the continuing efforts to refine the parameterization.
OK, so it’s maybe a little complex. So?
This entry was posted on Monday, April 23rd, 2007 at 11:28 pm and is filed under HIMIPref News, Issue Comments. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
HIMIPref™ Valuation for BCE.PR.C Suspect but Trading Engine Recovers
I was asked in the comments for April 20 whether the valuation shown by HIMIPref™ for BCE.PR.C was OK or not … it was showing a massive, massive positive number.
Well, no, it wasn’t … it dropped out of the math as designed, but division by small numbers can cause problems and huge results. The trading engine knows that this sometimes happens, however, and annulled the result without recommending a trade.
The riskRewardAnalysisBox showed numbers that all looked fairly normal, with the exception of portYieldReversion: this showed an exceptionally – ridiculously – high value of 135.443.
Therefore, one looks at the riskRewardAnalyticalValuesBox to find that this value depends upon some reasonable reversion factors and a pseudoModifiedDurationPort of -244.2194 … rather a large value, and with a funny sign, to boot!
The calculation of this variable may be examined via the pseudoPortfolioReportBox, which reports that a 2% change in price results in an absolute yield (and we are talking about portYield, remember!) change of -0.0082% and the large value of pseudoModifiedDurationPort.
Bringing up the details for the three yield calculations implicit in this value, we find that the high priced yield is 4.1622% with a price of 23.937 and the base priced yield is 4.1702% with a price of 23.70 while the low priced yield is 4.1540% with a price of 23.463.
Essentially, what is happening is that the probability of a near-term call at a price higher than market is goes up with price at a rate that nearly exactly matches the decline in yield of the far more likely limitMaturity, so that price changes, at this particular price level, have a negligible effect on this particular measure of yield.
*sigh* It happens.
Fortunately, though, an occasional blow-up like this is accounted for in the trading engine – even at the ridiculously high valuation, there are very few trades generated into this security.
When we look at the trade evalation report, into BCE.PR.C out of a randomly chosen security, we see that the bidToOfferPickup is negative. Negative? How can it possibly be negative when the valuation on the buy side is so high?
To answer that, we look at the pickup calculation box for this trade and find that, while the buyValuationAsk is much greater than the sellValuationBid, there is a large negative contribution to the total pickup from the parameter excessRewardDifferenceValuation, a parameter invented for just such occasions.
In the standard parameterization supplied with HIMIPref™, the parameter excessValuationCap is set to 1.00, while the excessValuationReduction is set to 2.00. This adjustment – one might almost call it a sanity check in the calculations – prevents the trade from being shown as desirable, both in live reports and in future simulations that will analyze this date as part of the continuing efforts to refine the parameterization.
OK, so it’s maybe a little complex. So?
This entry was posted on Monday, April 23rd, 2007 at 11:28 pm and is filed under HIMIPref News, Issue Comments. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.