Ibor calculation

Strata
1

below is a method in DiscountIborIndexRate.java

if the fixing date equals the curve date, then the fixing comes from history,
but I would have thought that the fixing date must be strictly before the curve date
to go to the historical resets, and if the fixing date equaled the curve date then the
rate would be calculated

can you please tell me where I am going wrong on this?

public double rate(IborIndexObservation observation) {
if (!observation.getFixingDate().isAfter(getValuationDate())) {
return historicRate(observation);
}
return rateIgnoringFixings(observation);
}

2

Logically, once the fixing value is known it should be used (why would you make a number up when it is now a fact). However, I know there are cases when this approach does not work. There is a rateIgnoringFixings() method on IborIndexRates which totally ignores the time-series, but that probably isn’t what you need either. So, the only good solution is to not populate the time-series until the end of day.

3

Agreed that calculating a number already present for lookup isn’t efficient.

However, suppose you want to parallel shift the forecast (ibor) curve. Specifically …

  1. extract the index curve from RatesProvider
  2. wrap it withing ParallelShiftedCurve.absolute(…)
  3. build new rates provider using the wrapped forecast curve

If you use this new rate provider to calculate par swap rates, the first floating point cash flow will be wrong, because it uses the reset rate from the original curve.

However, if you change the code in DiscountIborIndexRate::rate() to pull from the time series if the fixing date is before the valuation date (instead of on or before the valuation date) then the first floating point cash flow will be correct (i.e. consistent with the shift) since it will be calculated.

We could generalize this to any case where the underlying forecast continuously compounded zero rates are adjusted (e.g. parallel shifts, monte carlo calcl, etc.) . Calculating the first floating point would give the same reset rate that went into the calibration for an unmodified curve (albeit slightly sub-optimal in terms of efficiency) and give a consistent first floating point cash flow when the underlying zero rates are modified.

Does this make sense or is this just wrong?

4

I think what you are arguing makes sense, but I also think that it is supported by not populating the time-series with the data until the end-of-day (which is what we tend to do internally). You can even calibrate with the time-series value present, and then change the time-series to remove the value for the current date.

Obviously, there is no good way to pass a flag into the code to select whether to use the time-series or not on any given date. Such an approach would be very ugly/messy/confusing.

Is there something you can’t achieve by altering the input market data?