In the previous article, I discussed Value Determination for InterestRatePayout — how contractual terms become calculated amounts through calculation periods, rate observations, day count fractions, compounding, and discounting.

But a calculated amount is not the end of the story. USD 2,616,889 is just a number. To become a financial fact, it needs a payer, a receiver, a settlement date, a currency, a settlement method, and a link back to the obligation that produced it.

That is what this article covers: the final F-PAL stage, Settlement / Realisation.

In ISDA CDM, the settlement / realisation module mainly anwers three questions, in sequence:

The order is fixed because each group depends on the previous one. You cannot describe an AssetFlow before you have a PaymentCalculationPeriod to link it to. You cannot describe a PaymentCalculationPeriod before you understand that settlement is cash and the currency is USD. The first group (contractual settlement rules) sets the conditions. The second group (payment representation) organises the calculated amounts into payment-level facts with lineage. The third group (the transfer) describes the actual movement of value. The article follows this dependency chain.

1. How Is It Settled?

The first question after calculation is: what rules govern the discharge of this obligation?

SettlementTerms

A calculated amount tells you how much. Settlement tells you how.

SettlementTerms answers a set of questions that arise after calculation is complete. What form does settlement take — cash or physical delivery? In which currency? On what date? Under what valuation rules, if any? Is the amount mechanically derived from the payout, or determined by a separate valuation process? If a credit event occurs, what recovery factor applies?

These questions are not cosmetic. A calculated amount without settlement context is incomplete. USD 2,616,889 is a number. Party B pays Party A USD 2,616,889 in cash on 04 Jan 2027 is a financial fact. SettlementTerms provides the structure that turns the number into the fact.

type SettlementTerms extends SettlementBase:
    settlementType SettlementTypeEnum (0..1)       // Cash, Physical, Election, CashOrPhysical
    settlementCurrency string (0..1)
    settlementDate SettlementDate (0..1)
    cashSettlementTerms CashSettlementTerms (0..*)
    physicalSettlementTerms PhysicalSettlementTerms (0..1)

For a plain interest rate swap, the common case is simple: settlementType = Cash, settlementCurrency = USD. But the model does not assume this. It makes it explicit. The type enforces a constraint: cash and physical settlement terms cannot both be present unless settlementType is Election or CashOrPhysical. You cannot accidentally specify both for a plain cash-settled trade.

CashSettlementTerms carries the detail when cash settlement applies:

type CashSettlementTerms:
    cashSettlementMethod CashSettlementMethodEnum (0..1)
    valuationMethod ValuationMethod (0..1)
    valuationDate ValuationDate (0..1)
    cashSettlementAmount Money (0..1)
    recoveryFactor number (0..1)               // constrained to [0, 1]
    fixedSettlement boolean (0..1)
    accruedInterest boolean (0..1)

Most of these attributes are empty for a vanilla IRS coupon. The amount comes from the calculation chain, not from a cashSettlementAmount. The valuationDate and valuationMethod are unused when the amount is mechanically derived from notional × rate × day count. But they exist in the model because the same SettlementTerms type must also handle CDS recovery settlements, cash-settled options, and non-deliverable forwards — where valuation dates, quotation methods, and recovery factors are essential.

The modelling lesson: a well-designed canonical type carries the union of what any product might need, but the cardinality (0..1 on most attributes) means a simple case populates almost nothing. The type is broad; the instance is narrow.

PhysicalSettlementTerms exists in the model for completeness — it carries  physicalSettlementPeriod,  deliverableObligations  (30+ CDS-specific attributes), escrow, and clearedPhysicalSettlement — but for a plain interest rate coupon it is always absent.

Principal Payments

Interest payments are not always the only cash movements. Some products involve principal exchange.

In a vanilla single-currency IRS, the notional is only a calculation basis — no principal changes hands. In a cross-currency swap, principal is exchanged at the start and end of the trade. These are different economic situations, and the model makes the distinction structurally through PrincipalPayments.

type PrincipalPayments:
    initialPayment boolean (1..1)
    finalPayment boolean (1..1)
    intermediatePayment boolean (1..1)
    principalPaymentSchedule PrincipalPaymentSchedule (0..1)
    varyingLegNotionalCurrency string (0..*)

The three boolean flags are the core of this type. They are mandatory (1..1) because every payout must answer three yes/no questions about principal, and together they cover the three points in a trade’s life where principal can move:

• initialPayment — Is principal exchanged at the start? In a cross-currency swap, Party A delivers USD 100M and receives EUR 92M from Party B on the effective date. In a vanilla IRS, nothing happens — false.
• finalPayment — Is principal re-exchanged at maturity? In a cross-currency swap, Party A returns EUR 92M and receives USD 100M back on the termination date, typically at the original exchange rate. In a vanilla IRS, the notional was never exchanged, so there is nothing to return — false.
• intermediatePayment — Is principal exchanged at points between start and end? This covers resetting structures where principal is adjusted periodically based on FX observations rather than only at maturity. In most swaps this is false.

The remaining two attributes handle cases where the flags alone are not enough. principalPaymentSchedule provides a detailed schedule when the exchange pattern is more complex than a simple initial/final pair. varyingLegNotionalCurrency identifies which currency leg’s notional varies with FX fixings in a resetting cross-currency swap — for example, "EUR" when the USD leg is fixed and the EUR leg resets. Both are optional and present only when the three flags indicate that something beyond the simple cases is happening.

Payment Delay

Some products delay payments because underlying cashflows are not immediately available — the canonical example is CDS on mortgage-backed securities, where RMBS typically have a 5-day delay between the reference obligation’s coupon date and the synthetic swap’s payment date.

In the CDM, this is a single boolean: paymentDelay on InterestRatePayout. The ordinary payment schedule is handled through PaymentDates. Special delay logic is represented separately. The two are not conflated.

2. How Is the Payment Represented?

Once settlement rules are established, the next question is how calculated period amounts become payment-level facts.

CashflowRepresentation

Value Determination produces period-level amounts. Settlement turns those into payment-level facts. The bridge between them is CashflowRepresentation:

type CashflowRepresentation:
    cashflowsMatchParameters boolean (0..1)
    paymentCalculationPeriod PaymentCalculationPeriod (0..*)

The cashflowsMatchParameters flag answers a simple but important question: does this projected cashflow match what the contract says should happen? When true, the projection is purely mechanical. When false, something has diverged and requires investigation. This can happen for several reasons:

• A stub or irregular period required special treatment. The contractual stub rules were underspecified, or the interpolation methodology produced a rate that falls outside the expected range of the two reference tenors. The amount was produced, but with a caveat.
• A fallback rate was applied. The contractual index (e.g., LIBOR) has ceased or was not published on the fixing date, and a fallback rate was used instead. The amount exists, but it was not produced by the contractual rate logic as originally written.
• A rate observation is missing. The fixing date has passed, but no rate was published — a market disruption, a holiday misalignment, a data feed failure. The cashflow may use a last-known rate, a curve projection, or a manual override. None of those are the contractual rate.
• The contract was amended. The trade was renegotiated mid-life — the spread changed, the notional was partially terminated, the payment frequency was altered — but the cashflow projection was generated before the amendment took effect. The number reflects the old terms, not the current ones.
• A calculation agent override was applied. In some products, the calculation agent has discretion to determine a rate or amount when the standard methodology cannot be applied. The resulting amount is contractually valid but not mechanically derivable from the stated formula.

In each case, the flag does not block processing. It signals: this number is present, but do not treat it as mechanically verified. Check it before you settle against it, value from it, reconcile to it, or explain it to a client.

For AI-native financial data, this is a crucial distinction. An AI agent asked to explain a cashflow should be able to say: this amount was calculated from the contractual formula, using the observed fixing on 28 Jun — or, if cashflowsMatchParameters = false, it should say: this amount exists, but it was not produced by the standard contractual calculation. A fallback rate was applied. Here is the fallback that was used, and here is why. The flag is the trigger for that second, deeper explanation.

PaymentCalculationPeriod

Each PaymentCalculationPeriod links one payment to its source:

PaymentCalculationPeriod:
    adjustedPaymentDate date (0..1)
    calculationPeriod CalculationPeriodBase (0..1)
    fixedPaymentAmount Money (0..1)
    floatingPaymentAmount Money (0..1)

The calculationPeriod back-reference is the lineage link. It says: this payment was generated from that specific calculation period. The fixedPaymentAmount and floatingPaymentAmount are the monetary results — the outputs of the calculation chain from the previous article.

Payment and calculation period are not always one-to-one. Monthly calculation periods may be paid quarterly. Multiple periods may compound into one payment. A stub period may produce an irregular first or last payment. PaymentCalculationPeriod preserves the relationship regardless of the mapping.

3. What Actually Moves?

The final question describes the transfer itself.

AssetFlow

A settlement obligation ultimately describes a transfer: what moves, how much, when, and between whom. AssetFlow is that type.

Take the floating leg of our IRS example. For the period ending 31 Dec 2026, the calculation chain produced a floating amount of USD 2,616,889 — Party B pays, Party A receives, on 04 Jan 2027. As an AssetFlow, this becomes:

AssetFlow {
    quantity: NonNegativeQuantity {
        value: 2616889
        unit: Currency { currency: "USD" }
    }
    asset: Asset {
        cash: Cash { currency: "USD" }
    }
    settlementDate: AdjustableOrAdjustedOrRelativeDate {
        adjustableDate: AdjustableDate {
            unadjustedDate: 2027-01-04
        }
    }
    payerReceiver: PayerReceiver {
        payer: Party2           // Party B
        receiver: Party1        // Party A
    }
    paymentDiscounting: PaymentDiscounting {
        discountFactor: 0.9987
        presentValueAmount: Money {
            value: 2613285
            currency: "USD"
        }
    }
    assetFlowType: Known        // the SOFR fixing on 28 Jun has already occurred
}

Every attribute answers one question about the transfer: quantity says how much. asset says what — here, USD cash. settlementDate says when — 04 Jan 2027, the date that flowed from PaymentDates.paymentDaysOffset through to the PaymentCalculationPeriod. payerReceiver says between whom — the same direction declared in Stage 1, now restated at the transfer level. paymentDiscounting says what it is worth today — USD 2,613,285, using a discount factor derived from the relevant curve. assetFlowType says whether the amount is projected, known from a fixing, confirmed for settlement, or already realised — here, Known, because 3M SOFR was observed at 5.12% on 28 Jun 2026.Projected, Confirmed, and Realised

Projected, Confirmed, and Realised

A future floating cashflow based on a forward curve is not the same thing as a cashflow backed by an observed fixing, which is not the same thing as a confirmed payment instruction, which is not the same thing as a settled transfer.

In the CDM, the assetFlowType attribute on AssetFlow uses ScheduledTransferEnum to carry this distinction.

• Projected – The rate has not yet been observed. 
• Known – The fixing has occurred. 
• Confirmed – The payment has been accepted as an operational obligation. 
• Realised – Payment has occurred. 

An AI agent should be able to state whether a cashflow is projected, known, confirmed, or realised — and should never describe a projected amount as if it had already been paid.

The Settlement Chain

Now we covered all the thress groups. Let’s bring them together for the same IRS period used in the Value Determination article — 30 Jun 2026 to 31 Dec 2026, USD 100M notional, Party A pays fixed 4.00% and receives 3M SOFR:

The two AssetFlow instances share the same settlement terms but differ in direction, amount, and status. The fixed leg is projected; the floating leg is known because the rate was fixed on 28 Jun. PrincipalPayments has all three flags set to false — this is a vanilla IRS, no principal moves. The settlementDate on both AssetFlow instances matches the adjustedPaymentDate on the PaymentCalculationPeriod — the settlement date flows from the contractual PaymentDates through to the transfer.

The Full Chain – From Contract to Cashflow

The chain from contract to cashflow is now complete across all four F-PAL stages:

An AI agent tracing this chain can answer: this USD 2,616,889 cashflow belongs to Trade X, was generated from the floating InterestRatePayout, relates to the period ending 31 Dec 2026, uses a notional of USD 100M, a rate of 3M SOFR observed at 5.12% on 28 Jun 2026, an ACT/360 day count, and is due on 04 Jan 2027 with Party B paying Party A.

InterestRatePayout starts as an economic obligation. Contractual Definition turns it into schedules and terms. Value Determination calculates period-level amounts. Settlement / Realisation turns those amounts into cashflows, asset flows, payment obligations, and realised transfers — each with a payer, a receiver, a date, a currency, a status, and a traceable lineage back to the obligation that produced it.

Across four articles, we have traced one concept — an interest-based payment obligation — through the collection of reusable types and four F-PAL stages. The CDM does not model this as a flat record with productType, notional, rate, and maturityDate. It models it as a structured, typed, validated representation of financial meaning, from economic intent to settled cashflow.

That is the foundation for machine-understandable financial data.

• *AI-Native Financial Data Foundation