Hi guys,It is well known that the periods of a standard swap do not always coincide with the periods of the referenced Libor. For example if I roll out a 1Y swap referencing the 3M Libor starting on 18/3 I get the following period dates 18/3, 20/6, 19/9, 19/12That means that the 2nd Libor referenced by this swap is actually non-standard. If I use this swap to bootstrap my curve then my curve implicitly contains the convexity of this non-standard Libor. This now implies that if I value a standard FRA with period start on 20/6 (and period end date on 20/9) then I cannot simply value it off the curve but I actually need a convexity adjustment (to undo the implicitly stored convexity).I was wondering whether such an adjustment is the market standard or usually neglected.Thanks,Bernd

Neglected, in my experience... This is the very definition of splitting hairs, IMHO.

When the floating side accrual periods of a swap used to bootstrap a curve are not always equal the future spot LIBOR accrual periods, the input par swap will not quite value to par using the bootstrapped curve. This can happen from time to time and it was indeed discovered some time ago (I published something on this in 2000, for example). It is easy to show that the vanilla curve bootstrap algorithm assumes that the accrual periods are identical. Agreed with M that most people ignore this detail.

People fully project both accrual and projection end dates (so the two may differ for particular swap resets) but they will reprice without reference to convexity adjustments.Yes, the OP is quite correct that you end up with particular resets not being paid on the "natural date" for the underlying libor, but practically speaking there are plenty of other disturbances to projection levels that are more important to capture (year-end turns for all, more frequent turns for many). So the convexity adjustment is dropped in favour of concentrating on the other, more important problems.Nowadays, more than ever, you want your curve bootstrap to be as simple as possible, because you've got OIS discounting chucked into the mix. People tend to set up their pricing at the frontier of the overall complexity they can handle and so everything has to pay its way. Convexity corrections for yield curve libor projections tend to show comparatively poorly in terms of added complexity vs benefit.

i have seen convexity used or vanilla swaps where we have a 1 or 2 day natural payment delay (overkill) although it will depend on your bootstrapping software and most tedious subject of dates generation (the reset, reset accrual and payment accrual schedules etc), Royal weddings and funerals are also an issue in GBP