0

Is it possible for user to change the future fixing dates and gearing of the floating leg in Quantlib?

First, when Quantlib calculate the NPV for floating leg, it will go into couponpricer.hpp to call inline function BlackIborCouponPricer::swapletPrice(). Inside this function, there is a parameter called gearing_. This parameter is automatically setting to 1 in my case. If I need to change this to other value, say 0.8, where shall I make this change?

Second, all my future fixing dates are the same as the date vector generated in floating leg schedule. i.e. fixing dates are the same as accrual period starting dates. Is it possible to change these fixing dates to be different from the accrual period starting dates, say 2 business days before accrual starting dates subject to normal business day convention adjustment? Alternatively, is it possible for me to pass a date vector to store these fixing dates?

Many thanks.

Ben10
  • 121
  • 1
  • 13

1 Answers1

1

VanillaSwap doesn't take gearings as a constructor argument (I guess the idea was to keep it simple). Instead, you can create the fixed and floating legs separately using the FixedLeg and IborLeg classes and pass them to a Swap instance. You can see an example of that in SwapTest::testInArrears(), in the test-suite/swap.cpp file.

As for the fixing dates: when you build the IborIndex instance to be passed to IborLeg, you can pass a number of fixing days to its constructor. If you're using the available indexes such as Euribor or USDLibor, though, they already use 2 fixing days (as well as the correct calendar and business-day convention).

Luigi Ballabio
  • 4,128
  • 21
  • 29
  • a further question on fixing date: I set the `IborIndex` as `USDLibor` with 3m tenor. I generate the schedules for both fixed leg and float leg with start date(15,4,2016) and end date(18,4,2017) with tenor 12m and 3m, respectively. The schedules generated are as expected. However, when I pass them to price a swap, Quantlib complains that 'cannot calculate forward rate between April 18th, 2017 and April 18th, 2017:non positive time (0) using Actual/360 daycounter'. If I change the starting date to (18,4,2016). This issue solved. – Ben10 Nov 23 '16 at 11:42
  • Are the schedules as expected, or is there a duplicated date at the end? – Luigi Ballabio Nov 24 '16 at 09:50
  • Also, this should probably be a different question, so that it's easier to find it if someone else runs into the same problem. – Luigi Ballabio Nov 24 '16 at 09:51
  • After debugging into the source code, I know how this error generated. It does come from the schedule generation. Since Quantlib can only take either forward/backward generation as STUB, so the last two schedule dates are Date(15,4,2017), Date(18,4,2017). This causes class IborCoupon::IborCoupon generate the same fixingValueDate_ and fixingEndDate_ for last period. In practice, we normally have 4 different STUB: front short, front long, back short and back long. In this case, if I use back long, the last period in shcedule will be Date(15,1,2017) to Date(18,4,2017). – Ben10 Nov 24 '16 at 12:32
  • Agree. It really should be a separate question. – Ben10 Nov 24 '16 at 12:33