Fixed-Day Coupon Schedules in Local Bond Markets
Article Quant Q&A · Author: KiNest
Summary
The document distinguishes month-based schedule generation, which preserves a calendar roll date, from fixed-day periods, which advance by a constant number of days and therefore shift the calendar date. The example shows successive 91-day coupon periods in a local bond market using ACT/365 Fixed. It asks whether schedule generation is classified separately from day-count conventions and whether fixed-day schedules occur elsewhere.
The answers describe fixed-week or day-basis coupon periods in several emerging-market bond markets, including examples of 28-day, 91-day, 182-day, and 364-day intervals. Terminology varies across market references. One answer outlines a software approach using day-based frequencies and checking regular periods and stubs, and reports that a schedule module was later implemented in rateslib. The examples show that schedule rules and accrual day-count conventions are distinct choices, though both affect cash-flow calculations. The discussion notes market-specific exceptions, including occasional longer Russian coupon periods, so these examples are not a universal convention.
Key ideas
- Month-based schedules preserve a calendar roll date, while fixed-day schedules advance by a constant number of days.
- Fixed-day coupon periods are used in several local bond markets and are described with varying terminology.
- A day-count convention such as ACT/365 Fixed is distinct from the rule that generates coupon dates.
- Schedule software can represent day-based frequencies and infer regular periods or stub periods.
- Local bond conventions may include exceptions, so market-specific documentation remains necessary.
Tags
Full text
# Scheduling conventions used in markets
# Scheduling conventions used in markets
I'm aware of "roll day" convention when for generating a schedule roll day is used, such as: adding for instance 3M to a date dd/mm/yyyy means adding 3 to mm (for example by adding 3M to 15/01/2024 you get 15/03/2024). This particular rule is widely used for schedule construction in IRS contracts or US bonds for example which use ACT/ACT or 30/360 day count conventions.
However, in our local bonds market some sort of "fixed days period" rule is used for schedule construction with constant days number in the coupon period. Hence, end dates of coupon periods have different day in the date. See example in the table below.
| start | end | # of days |
| 25.12.2024 | 26.03.2025 | 91 |
| 26.03.2025 | 25.06.2025 | 91 |
| 25.06.2025 | 24.09.2025 | 91 |
What is remarkable is that all these bonds use ACT/365 Fixed day count convention.
I have several questions:
- is there any classification for conventions of schedule generation? Any sources are much appreciated.
- does schedule generation convention somehow depend on day count convention?
- Is the "fixed days period" scheduling convention I described used in the markets elsewhere? If yes, what is its correct name?
## Answer by Attack68 (score 3)
https://quant.stackexchange.com/a/81659
Having thought about this today my plan to implement this is as follows;
- As well as "M", "Q", "S", etc. for schedule `frequency` also permit inputs like `B21` or `D91` for 21 business days or 91 calendar days. This will provide the branching trigger for different scheduling logic.
- The other aspects of scheduling requires checking whether given `start` and `end` dates represent a "regular schedule" (one which aligns with the specified parameters). Usually part of this check is done by aligning the day of the month with the `roll`. If that fails you then usually fall back to requiring `stubs` or simply erroring. In this case checking whether dates form a regular schedule relies on making a calculation based on the number of calendar or business days between the inputs. I'm hoping this is a reasonably simple extension.
- Inferring stubs when the frequencies are a set number of months again usually has consistent logic. I don't see this as being that much harder to infer one-sided stubs when dealing with days (and ignoring the `roll`) rather than months.
- I will consider 4 weeks as "D28" and 13 weeks as "D52" etc.
In the rateslib API docs the only two private methods I actually left documented were the `_check_regular_swap` and `_infer_stub_date` because they were the two key, components that went into generalising schedule generation.
Will have to see how this pans out later in the year. Interested to hear if you find anything interesting or have any good ideas!
#### Update
As of 1st Aug 2025 `rateslib` implemented these ideas into a generic `schedule` module. Its Python facing docs are available here and its implementation in Rust is available here.
The general principle sets up frequency traits for getting the `next` or `previous` periods according to that frequency definition and therefore being also able to infer stubs or report invalid schedule definitions.
For example the Russian ISIN: RU000A102BV4.
```
from rateslib import * # rateslib 2.1.0, python 3.12
s = Schedule(dt(2020, 11, 11), dt(2027, 9, 22), "91d", stub="LongFront")
print(s)
freq: 91D, accrual adjuster: MF, payment adjuster: 2B,
Period Unadj Acc Start Unadj Acc End Acc Start Acc End Payment
0 Stub 2020-11-11 2021-03-31 2020-11-11 2021-03-31 2021-04-02
1 Regular 2021-03-31 2021-06-30 2021-03-31 2021-06-30 2021-07-02
2 Regular 2021-06-30 2021-09-29 2021-06-30 2021-09-29 2021-10-01
3 Regular 2021-09-29 2021-12-29 2021-09-29 2021-12-29 2021-12-31
4 Regular 2021-12-29 2022-03-30 2021-12-29 2022-03-30 2022-04-01
5 Regular 2022-03-30 2022-06-29 2022-03-30 2022-06-29 2022-07-01
6 Regular 2022-06-29 2022-09-28 2022-06-29 2022-09-28 2022-09-30
7 Regular 2022-09-28 2022-12-28 2022-09-28 2022-12-28 2022-12-30
8 Regular 2022-12-28 2023-03-29 2022-12-28 2023-03-29 2023-03-31
9 Regular 2023-03-29 2023-06-28 2023-03-29 2023-06-28 2023-06-30
10 Regular 2023-06-28 2023-09-27 2023-06-28 2023-09-27 2023-09-29
11 Regular 2023-09-27 2023-12-27 2023-09-27 2023-12-27 2023-12-29
12 Regular 2023-12-27 2024-03-27 2023-12-27 2024-03-27 2024-03-29
13 Regular 2024-03-27 2024-06-26 2024-03-27 2024-06-26 2024-06-28
14 Regular 2024-06-26 2024-09-25 2024-06-26 2024-09-25 2024-09-27
15 Regular 2024-09-25 2024-12-25 2024-09-25 2024-12-25 2024-12-27
16 Regular 2024-12-25 2025-03-26 2024-12-25 2025-03-26 2025-03-28
17 Regular 2025-03-26 2025-06-25 2025-03-26 2025-06-25 2025-06-27
18 Regular 2025-06-25 2025-09-24 2025-06-25 2025-09-24 2025-09-26
19 Regular 2025-09-24 2025-12-24 2025-09-24 2025-12-24 2025-12-26
20 Regular 2025-12-24 2026-03-25 2025-12-24 2026-03-25 2026-03-27
21 Regular 2026-03-25 2026-06-24 2026-03-25 2026-06-24 2026-06-26
22 Regular 2026-06-24 2026-09-23 2026-06-24 2026-09-23 2026-09-25
23 Regular 2026-09-23 2026-12-23 2026-09-23 2026-12-23 2026-12-25
24 Regular 2026-12-23 2027-03-24 2026-12-23 2027-03-24 2027-03-26
25 Regular 2027-03-24 2027-06-23 2027-03-24 2027-06-23 2027-06-25
26 Regular 2027-06-23 2027-09-22 2027-06-23 2027-09-22 2027-09-24
```
## Answer by Dimitri Vulis (score 2)
https://quant.stackexchange.com/a/81660
Market conventions involving a whole number of weeks are not at all unique to Russian bonds. Local law / local currency bonds use similar conventions: exactly 4 weeks = 28 calendar days for "monthly" (so Mexican "monthly-like" TIIE swap leg actually pays 13 times per year), exactly 13 weeks = 91 days for "quarterly", exactly 26 weeks = 182 days for "semi-annual", exactly 52 weeks = 364 days for "annual".. are used in many East European countries, including both Russia and Ukraine; Latin America, e.g. Mexican MBONOs and UDIBONOs; Africa, e.g. Kenya and Uganda, and many others. I don't know why they prefer it... but when they issue eurobonds - external law, denominated in USD or EUR, they use the market conventions more common in the West. (Related: https://github.com/lballabio/QuantLib/issues/731 )
Russian local bonds (OFZs) do have two other weirdnesses: one is rounding coupons (https://github.com/lballabio/QuantLib/issues/896) and the other "leap days" - very rarely an occasional coupon is 1 day longer than the whole number of weeks for no discernable reason.
I must share this "war story". Many years ago I used to work for Citi and needed a scheduler to support such emerging markets bonds. I reached out to two internal teams that already had schedulers - the Yieldbook team that's now in LSEG, and the London team that's now XiNG. They responded with hysterical screeches that would be difficult to imagine to today's more politically correct corporate atmosphere - how they won't sully their pristine library with support for market conventions invented by some savage unwashed heathen :) so I programmed my own.
I decided to look at the Bloomberg calc types document referenced here. It seems to use the terms "day payers" and "day pay basis", but the language is not consistent.
Uganda calc type 1389 says:
> These bonds are day payers that pay a coupon every 182 days.
Mexico calc types 856, 1023, 1294, Turkey calc types 1014, 1350, Egypt calc type 1553, and catch-all calc type 1269, used for the likes of Kenya, all say something like:
> Coupon frequency is on a day pay basis (7, 14, 28, 91, 182, 364 days).
Lebanese calc type 1339 says
> Coupon pays every 182 days.
Ukraine calc type 1234 says
> the bonds pay out on a 91 day or 182 day basis
Russia calc types (1155, 1487, etc)
> The coupon pay dates are either 91 or 182 days apart.
They all refer to exactly the same feature that you're asking about.
## Answer by marie albertini (score 0)
https://quant.stackexchange.com/a/81658
when you add 3M to a date you may have to dajst the resulting date if it is a holiday or week end....you have several choices de pending on marlets and countries :
use EXACT day i.e no modification
use PRECEDING day
use FOLLOWING day
use MODIFIED FOLLOWING day i.e following unless you change month in which case you use preceding
is that answering your question ?Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.