# Setting up Schedule for an amortizing floater in QuantLib

I am unsure as to the exact arguments required for the Schedule function for an amortizing floater - my code is listed below. Specifically, my question pertains to whether the schedule should always start from the issue date of the bond or should it start from the settlement date if the bond is seasoned. I seem to have seen usage both ways in some of the examples on the web so I am a bit confused.

I would expect that the NPV functions index into the right cashflow based on the settlement date provided but just checking.

Also, if anyone has a working example of an AmortizingFloatingRateBond which calculates the DM given a price (or vice versa) using a notional schedule,that'd be much appreciated.

Code Snippet:

QuantLib::JointCalendar calendar = QuantLib::JointCalendar(QuantLib::UnitedStates(),QuantLib::UnitedKingdom(),
QuantLib::DayCounter dayCounter = QuantLib::Actual360();

QuantLib::Integer fixingDays = 1;
QuantLib::Natural settlementDays = 3;

QuantLib::Date issueDate(25,QuantLib::July,2013);

QuantLib::Period p1m = QuantLib::Period(1,QuantLib::Months);

// Number of payments
int num_cashflows = 120;
QuantLib::Date maturityDate = issueDate + num_cashflows * p1m;

QuantLib::Schedule mySchedule(issueDate,
maturityDate,
QuantLib::Period(QuantLib::Monthly),
calendar,
QuantLib::DateGeneration::Forward,
false);

QuantLib::AmortizingFloatingRateBond MyFloater(settlementDays,
Notional,
mySchedule,
libor,
QuantLib::Actual360(),
fixingDays,
std::vector<QuantLib::Real>(1,1.0),
std::vector<QuantLib::Rate>(),
std::vector<QuantLib::Rate>(),
true,
issueDate);

MyFloater.setPricingEngine(bondEngine);

std::vector<QuantLib::Date> paySchedule = mySchedule.dates();
std::vector<QuantLib::Date>::iterator pIter;
QuantLib::Date priorDate;

for (pIter = paySchedule.begin(); pIter != paySchedule.end() && *pIter < settlementDate; ++pIter){
priorDate = *pIter;
}

-

As for the first question, the schedule should start from the issue date. The bond will manage cash flows correctly based on the evaluation date.

The second is a bit trickier, and I don't think I have working code handy. The general idea is: if you want to add a spread to the rate of the bond (to go from discount margin to price) you'll have to modify the term structure you pass to your Libor instance. Instead of linking the term-structure handle to the Libor curve, create an instance of ForwardSpreadedTermStructure passing the Libor curve and a quote holding the spread; something like

boost::shared_ptr<SimpleQuote> spread(new SimpleQuote(0.0));
libor = boost::shared_ptr<IborIndex>(
new USDLibor(1*Months,


If you initialize the bond with the Libor instance above, you should be able to write:

spread->setValue(0.002);


and see the bond price change accordingly.

To go from price to DM, you have to invert the above in some way. The easiest is probably to create a function object that takes a spread and returns the difference between the target price and the price calculated with the current DM (it will probably have to hold a reference to the bond and perform the calculation I outlined). Once you have the function object, you can pass it to any of the 1-D solvers available in the library. The solver will return the spread that gives a null price difference; that is, the spread for which the price equals the target price.

-
Luigi - thanks for your prompt response - so just to be clear, my understanding was that the IborIndex serves to generate the future index values for the floater and the coupon on the floater is the sum of this index value + the spread argument in the bond constructor. Shouldn't the DM come into the discounting part through the PricingEngine? What I attempted initially was to create 2 instances of flat termstructure, one with a flat curve of 7.15 + 0.25 which drives the coupon and the other as a yield of 7.40 used as a discount - however this gives me a substantial premium above par for price. –  HookahBoy Sep 24 '13 at 17:03
Yes, the coupon amount is the index value plus the spread in the constructor, but you can't change the latter once the bond is built. My suggestion to add a spread to the forecast curve instead was to avoid instantiating a new bond at each solver step. Also, if you want the spread to affect discounting, you'll be able to use the same quote instance to add the spread to both forecast and discount curve. –  Luigi Ballabio Sep 25 '13 at 8:04
As for the price, you might want to check the compounding you're using. With the default parameters, a flat 7.40 curve means 7.40 continuously compounded, which doesn't give a 7.40 Libor fixing. –  Luigi Ballabio Sep 25 '13 at 8:12