Module records 

An instrument’s cashflow schedule as column-oriented records.

The finest grain the crate reports: one row per coupon, with the dates it accrues over, the rate it fixes at, the amount it pays, and what that is worth. It is what reconciles a valuation period by period, and what a study shows when it claims two engines agree.

This is a priced read, not a passive one. A projected rate, a pay-date discount factor and a present value all need curves, so this takes the same things a leg walk takes. The passive half of a schedule — the dates and the year fractions — is available without them, but it is not worth a second entry point that returns half a table.

Four rules the columns encode, and all four are choices:

• amount is what that row pays. Almost every row is a coupon and pays on its own date. A coupon inside a leg that accumulates pays nothing — the leg pays once, at the end — so such a coupon’s row carries its dates, rate, year fraction and notional with its money columns empty, and the leg adds one settlement row for the payment it actually makes. Decomposing that payment across the strip would invent a schedule the trade does not have.

• kind comes from the coupon, not the leg. A Leg classifies itself only by Direction, which is pay-or-receive and says nothing about fixed-or-floating. The coupon set is closed over Fixed, Ibor, Overnight and Redemption, so reading the kind off the coupon is both available and strictly finer: a leg mixing a coupon with a redemption yields two kinds where a leg-level label would give one.

  The one exception is Settlement, an accumulating leg’s single payment. It is the leg’s row and not any coupon’s, because no coupon makes that payment. The exception is stated here rather than left to be found, and it is the only row in the table that a coupon does not stand behind.

• A coupon is projected off the curve it names. The walk takes Projections rather than one forward curve, and asks each coupon for its own index key. One curve for a whole table reports a two-index product’s second leg off a curve that leg never reads.

• amount is unsigned and pv is signed. The amount belongs to the coupon and the sign belongs to the leg. Leg::npv applies the direction once for the whole leg for the same reason; collapsing the two here would lose which is which.

Every row names its leg and its index. leg is the leg’s position in the order the instrument declares them, and index is the registry code the row resets on, empty for a fixed coupon or a redemption, so two legs on the same coupon kind split by column rather than by row order.

The table reports what is still owed. A coupon whose payment date is at or before the valuation date is omitted, exactly as Leg::npv’s own walk omits it, and an accumulating leg whose payment has been made contributes no rows at all. Discounting a payment already made is a query behind the curve’s own reference date, which the curves refuse — so a seasoned trade would otherwise have no table rather than a shorter one.

A cell with no value is empty rather than the row being dropped: a fixed coupon has no fixing date, a redemption accrues over nothing. An absent date is Date(None); an absent number is NaN, which a dataframe reads as null — and which means a test comparing emptiness must check is_nan() rather than equality. payment_date is nullable like every other date column, because a coupon inside an accumulating leg has no payment date to report.

Structs

Conversion 🔒

How a non-deliverable leg’s rows convert: the currency its payments settle in, and per payment (in Leg::payment_dates order) its FX fixing date — none for a payment converting at an agreed rate — and what one unit of the leg’s currency paid that day is worth today in the settlement currency: the conversion and the discount in one factor, as the valuation reads them. A payment already made carries NaN.

Projections

The projection curves a table may read, each under the key the market resolved it from.

Row 🔒

One row’s worth of numbers, before they are transposed into columns.

Constants

CASHFLOW_COLUMNS

The column names this producer emits, in order.

Functions

assemble 🔒

Rows transposed into the table’s columns, in CASHFLOW_COLUMNS order — the one place a column’s name, order and cell type are decided.

cashflow_records

One instrument’s cashflows as records: a row per coupon, over legs in the order the instrument declares them and coupons in payment order within each.

converted_cashflow_records 🔒

direction_label 🔒

cashflow_records, with a Conversion for each non-deliverable leg (by position; a missing or None entry is a deliverable leg). A converted row reports its amount in the leg’s own currency, discount_factor as the conversion’s factor, pv in the settlement currency, and the two settlement columns; every other row leaves those columns empty. A leg’s side as the direction column spells it.

kind_of 🔒

The coupon variant’s name, which is the row’s kind — the core’s own AnyCoupon::kind, so a new coupon shape cannot be spelled twice.

leg_cashflow_records

One leg’s cashflows as records: the same table cashflow_records builds, over a single leg.