A digital bond does not acquire a new interest convention because its ownership register runs on a blockchain. The amount payable still depends on the contractual principal, rate, accrual period, day-count fraction and rounding rules. A payment date then determines when that amount must be delivered. Confusing those inputs can produce a perfectly executed transfer for the wrong sum.
The issue is especially easy to miss when a token interface shows interest increasing continuously. That display may be an estimate between payment dates rather than the contractual calculation. Our article on tokenised bond servicing covers the wider process. Here the focus is the small conventions that change the cash.
A rate needs a fraction of a year
For a simple fixed coupon calculated by day count, the basic relationship is principal multiplied by the annual rate multiplied by the contractual fraction of a year. Actual/360 uses the relevant actual number of days divided by 360. Actual/365 Fixed uses a fixed denominator of 365. A 30/360 convention uses a prescribed approach to counting months and days rather than simply counting elapsed calendar days.
Those names are families that need precise identification. Different 30/360 variants treat month ends differently, and Actual/Actual variants do not all use the same calculation. FpML's day-count coding scheme distinguishes such conventions and their reference definitions. An integration field containing only actual is insufficient reference data.
Code should therefore store the agreed convention with its version or governing definition. A developer's familiar library default is not evidence that the bond uses it. The calculation must also specify which endpoint is included, how stub periods work and whether the outstanding principal changed inside the period.
One hypothetical coupon, two results
Assume a hypothetical $10 million bond pays 6% annual simple interest for a 90-day period. Under Actual/360, the amount is $10 million multiplied by 0.06 multiplied by 90/360, or $150,000. Under Actual/365 Fixed, the same inputs produce approximately $147,945.21 before any instrument-specific rounding treatment.
The difference is approximately $2,054.79. No market move, credit event or blockchain fee caused it. It follows entirely from the denominator. This example illustrates two different contractual choices; a real bond has one governing choice, which the payment engine must reproduce.
Now imagine the period is an irregular first coupon. Dividing an annual coupon by the usual number of payments can be wrong if the documents require a specific stub calculation. The rate and notional remain correct while the payment becomes incorrect. Testing ordinary six-month periods alone will not discover the defect.
Keep three dates apart
The scheduled period end, adjusted accrual boundary and adjusted payment date can be different dates. A business-day rule may move only the payment date. It may instead adjust calculation boundaries where the terms require it. A delayed transfer therefore does not automatically imply additional coupon accrual.
Consider a hypothetical scheduled coupon date falling on a Sunday. The documents specify payment on the following business day, unchanged accrual boundaries and no additional interest for that adjustment. Payment moves to Monday, assuming Monday is a business day under the relevant calendar. Adding one extra day's interest because the blockchain has reached Monday would override the agreed calculation.
FpML's date-adjustment model treats business-day conventions and business centres as explicit data. It is a useful reminder that the adjustment rule and the calendar are separate inputs. A following rule cannot operate correctly until the system knows which days count as business days.
The calendar belongs to the instrument
A bond denominated in one currency can involve a paying agent, settlement infrastructure or listing venue in other locations. The applicable terms determine which financial centres and calendars matter. The investor's home-office calendar does not decide the issuer's payment obligation, and the blockchain's availability does not override a stated banking calendar.
Calendar maintenance is consequently a servicing responsibility. Scheduled holidays, exceptional closures and changes to calendar sources require version control. A correction should record which future dates changed and whether already published notices need replacement. An undocumented edit to a calendar file can alter thousands of projected cash flows without any change to the bond contract.
End-of-month treatment deserves deliberate tests. A rule that moves a non-business date forward may cross a month boundary. A modified-following rule can instead move it backward when the forward adjustment would enter the next month. The expected answer should be taken from the contractual convention, not an assumption that all weekend dates move forward.
Accrued interest between coupons
A secondary trade can involve a quoted clean price and accrued interest, producing the dirty price or total settlement price. Accrued interest allocates the relevant portion of the coupon under the applicable market and instrument conventions. It is not a second coupon issued to the seller by the blockchain.
The entitlement date matters alongside the accrual calculation. A buyer can own a token at settlement while the next coupon belongs to another party under the instrument's record-date or ex-coupon rules. A smart contract that pays whoever owns the token when the payment transaction executes can depart from the intended entitlement.
Our explanation of corporate actions and entitlements addresses that distinction. In the coupon engine, keep the valuation of accrued interest, the identification of entitled holders and the payment instruction as separate calculations that reconcile to each other.
A token transfer after a record date should preserve the distinction between the coupon receivable and the security sold. Finance needs both entries to explain a position that has gone while its final interest payment remains outstanding.
Precision should survive the whole path
Payment arithmetic often passes through a high-precision calculation, a currency rounding rule and a token with its own decimal precision. Rounding early at the daily level can produce a different amount from rounding once at the end of the coupon period. Distributing a rounded aggregate among many holders creates another possible residual.
The documents and operating procedures should determine where rounding occurs and who receives or retains residual units. A reconciliation that merely proves the paid token units equal the instruction proves little if the instruction was rounded incorrectly. Compare the contractual amount with the calculation output before examining the transfer.
A useful acceptance file contains expected answers for a leap year, a short first period, a long final period, a month-end adjustment and a holiday added after issuance. Include at least one example where the payment date moves but the interest amount does not. Finance and the calculation agent should agree those answers before execution is automated.
The strongest evidence is independent reproduction of the amount using the signed terms and dated reference data. Once that agrees, onchain settlement can make delivery easier to observe. It cannot rescue an ambiguous coupon definition, and it should not make an incorrect calculation look authoritative.