In the previous article, I discussed the business meaning and product examples of InterestRatePayout. The key idea was that InterestRatePayout is not just a technical object in the ISDA CDM. It represents a common economic pattern across many FICC products: an interest-based payment obligation.

In this article, I move from business meaning to structure. Following the F-PAL framework, I will focus on the first analytical area: Economic Agreement.

Economic Agreement captures what has been commercially agreed: who pays, who receives, what notional applies, and what rate logic determines the obligation.

In other words, Economic Agreement answers the question:

What economic obligation exists between the parties?

Economic Agreement

Economic Agreement is the first layer of the analysis.

For InterestRatePayout, this breaks down into three concerns:

• Who pays and who receives?
• What amount is interest calculated on?
• What rate logic determines the payment amount?

These may sound like simple questions, but they define the core of the payout. If any of them is wrong, everything downstream becomes unreliable: cashflow projection, valuation, risk, settlement, reporting, and AI reasoning.

1. Direction — Who Pays Whom?

Direction sounds trivial. It is not.

In many real-world trade representations, direction is implied by context. A system may use labels such as “fixed leg”, “floating leg”, “pay leg”, or “receive leg”. A trader may understand the convention. A booking system may have its own internal naming logic. A report may rely on positive or negative signs.

That may work inside a specific system, but it is fragile in a canonical model.

Under F-PAL, direction belongs to Economic Agreement because it defines the basic obligation between the parties. Before we discuss schedules, calculation rules, settlement terms, or projected cashflows, the model must answer one question: who is economically required to pay, and who is entitled to receive?

The CDM makes this explicit through PayerReceiver. It is inherited from PayoutBase with cardinality 1..1, meaning every payout must declare both payer and receiver. The two attributes, payer and receiver, are typed as CounterpartyRoleEnum, using trade-level roles such as party1 and party2.

This design choice matters because direction is no longer inferred from labels such as “fixed leg”, “floating leg”, or “pay leg”. It is represented directly in the model.

For example, in a fixed-float interest rate swap, Party1 may pay the fixed payout and receive the floating payout. Party2 does the opposite. The swap cannot be understood correctly unless the direction of each payout is explicit.

For an AI-native financial data foundation, this is exactly what we want. An AI agent should not guess economic direction from naming conventions. It should read it from the structure.

2. Notional — What Amount Is Interest Calculated On?

The second part of Economic Agreement is the notional or quantity basis.

A naive model might store notional as a single field:

notionalAmount = 100,000,000

That works for a very simple vanilla IRS. It breaks down quickly once we move into real FICC products.

Under F-PAL, notional is still part of Economic Agreement because it defines the amount on which the interest obligation is based. The important point is that the agreed amount may not be a single static number. It may be scheduled, resettable, referenced, or derived.

The CDM’s answer is ResolvablePriceQuantity, inherited from PayoutBase. Its name is slightly abstract, but the modelling idea is practical: the model needs a resolvable quantity structure, not just a scalar notional number.

There are several design decisions worth noting.

First, the notional can be schedule-based rather than scalar. The notional lives in quantitySchedule, which can represent a single value or a full step schedule. An amortising swap, an accreting swap, and a more complex notional profile do not require completely separate modelling patterns. The variability is carried by the schedule.

Static Notional

ResolvablePriceQuantity {
    quantitySchedule: NonNegativeQuantitySchedule {
        value: 100000000
        unit: Currency { currency: "USD" }
    }
}

Amortising Schedule

ResolvablePriceQuantity {
    quantitySchedule: NonNegativeQuantitySchedule {
        step: [
            { value: 100000000, effectiveDate: 2026-01-15 },
            { value:  75000000, effectiveDate: 2027-01-15 },
            { value:  50000000, effectiveDate: 2028-01-15 },
            { value:  25000000, effectiveDate: 2029-01-15 }
        ]
        unit: Currency { currency: "USD" }
    }
}

Second, resettable notional is explicit. The reset flag marks whether the notional can change based on external observations. In a cross-currency swap, for example, one side’s notional may be reset based on FX movements. That is economically different from a fixed notional, and downstream processes such as cashflow projection, valuation, and risk need to know this.

FX-Resettable Notional

ResolvablePriceQuantity {
    quantityReference: ResolvablePriceQuantity {
        reference: "usd-anchor-leg-quantity"
    }
    quantityMultiplier: QuantityMultiplier {
        fxLinkedNotionalSchedule: FxLinkedNotionalSchedule {
            initialValue: 0.92
            varyingNotionalCurrency: "EUR"
            constantNotionalCurrency: "USD"
            fxFixingDates: AdjustableDates {
                date: [ 2027-01-15, 2028-01-15, 2029-01-15 ]
            }
        }
    }
    reset: true
}

Third, one payout’s notional can reference another payout’s notional. The quantityReference attribute allows the notional of one payout to point to another payout’s quantity (as shown above in the same FX-Resettable Notional example). This is useful in cross-currency structures, where one side’s notional may be linked to the other side through an FX relationship. The link is structural, not hidden in comment text.

There are also product-specific cases. For example, futureValueNotional can support situations where the notional grows according to an agreed formula. The common case remains simple, but the model can still accommodate special market structures.

ResolvablePriceQuantity {
    quantitySchedule: NonNegativeQuantitySchedule {
        value: 100000000
        unit: Currency { currency: "BRL" }
    }
    futureValueNotional: FutureValueAmount {
        quantity: NonNegativeQuantitySchedule {
            value: 113750000
        }
        currency: "BRL"
        calculationPeriodNumberOfDays: 360
        valueDate: 2027-01-15
    }
}

This is a good example of why canonical modelling matters.

From a reporting perspective, a notional number may look sufficient. From an economic modelling perspective, it is not. We need to know whether the notional is fixed, scheduled, resettable, referenced, or otherwise derived.

For AI-native financial data, this distinction is important. An AI agent should be able to tell the difference between a fixed USD 100 million notional, an amortising notional schedule, an FX-resettable notional, and a notional derived from another payout. These are not minor technical variations. They change the economic behaviour of the payout.

3. Rate Logic — What Determines the Payment Amount?

The third part of Economic Agreement is rate logic. InterestRatePayout is interest-based, but the rate does not always have the same form. The rate may be fixed, floating, inflation-linked, capped, floored, compounded, averaged, rounded, or subject to fallback rules.

So the key question is not simply: what is the rate?

The better question is: What rate logic determines the payment amount?

This is where the model shows its depth. The rate side of InterestRatePayout is not one type — it is a choice of three (RateSpecification).

The choice — FixedRateSpecification, FloatingRateSpecification, or InflationRateSpecification — means the model knows at the type level whether a payout is fixed, floating, or inflation-linked. You do not need to inspect field values to make this determination. An AI agent reading rateSpecification → FloatingRateSpecification knows the payout is floating before it reads a single rate value.

Fixed Rate. FixedRateSpecification carries a single rateSchedule (RateSchedule), which can be a single rate or a step schedule of rates with dates. A step-up swap that pays 3.50% for years 1–2 and 4.00% thereafter uses the same type as a plain 3.50% fixed swap — the schedule structure absorbs the complexity.

Floating Rate. The four-level inheritance chain — FloatingRateBase → FloatingRate → FloatingRateSpecification → InflationRateSpecification — is a concrete example of the CDM’s modelling philosophy. Each level is a contract: if you have a reference typed at that level, you can rely on those attributes being present. You do not need to know about the levels above you.

FloatingRateBase is the foundation. It answers: what is being referenced, and what boundaries apply? The four fields — rateOption, spreadSchedule, capRateSchedule, floorRateSchedule — are what every floating rate has, regardless of product. Code that only needs to check “does this trade have a cap?” works entirely at this level, and it works for anything that extends FloatingRateBase — a plain swap, an OIS, or an inflation swap.

FloatingRate answers: how is the rate mechanically produced from its observations, and what happens if the normal process fails? It adds the multiplier (for leveraged or inverse floaters), the rate treatment (bank discount to money market yield conversion), the calculation parameters (compounding method, lockout, lookback, observation shift — two nested types shown in lighter orange), and the fallback provisions. A fallback engine works at this level. It needs to know what to do if the index ceases. It does not need to know the initial rate or the rounding precision.

FloatingRateSpecification answers: what did the parties agree about how the rate is finalised for this trade? It adds four trade-level fields: the initial rate if already known, the rounding precision, the averaging method, and the negative rate treatment. A cashflow projector works at this level. It needs the initial rate and rounding rules but does not need inflation-specific attributes.

InflationRateSpecification extends everything above into the inflation domain. It adds nine fields: the lag between payment date and reference period, the index source and publication, the interpolation method, the initial index level, the fallback bond applicability, and the calculation method and style. It inherits all 12 floating-rate fields — an inflation swap has a spread, a cap, a floor, a fallback, and rounding rules, just like any other floating-rate structure.

This layering means each consumer of the model works with exactly the attributes it needs:

Economic Agreement as a Business Object

When direction, notional, and rate logic are combined, we get the Economic Agreement of the InterestRatePayout.

For example:

Party1 pays Party2 interest on USD 100 million at a fixed rate of 3.50%.

Or:

Party2 pays Party1 interest on USD 100 million based on 3M SOFR plus 25 basis points.

These statements are already much richer than saying “fixed leg” or “floating leg”. They make the economic obligation explicit.

However, the Economic Agreement is still not enough.

Interest is always connected to time. A rate applies over a period. The amount accrues over a period. A floating rate may reset on a date. The resulting cash amount is paid on a date. Irregular first or last periods may need special treatment.

This is where the next F-PAL area becomes necessary: Contractual Timing.

What This Means for AI-Native Financial Data

This structure has a practical consequence for AI agents.

An AI agent reading a CDM-style trade should not need to parse product labels, infer direction from leg names, guess whether a notional is static or dynamic, or assume that a fixed payout and a floating payout are identified only by market jargon.

It should be able to read structured attributes directly.

It should read the payer-receiver structure to know who pays and who receives.

It should inspect the quantity structure to understand whether the notional is static, scheduled, resettable, or linked to another payout.

It should inspect the rate specification to determine whether the payout is fixed, floating, or inflation-linked.

Each of these is a structured, typed, constrained attribute. They are not free-text notes. They are not implied by product labels. They are not hidden inside booking conventions. That is the difference between a trade record and a semantic financial data foundation. A trade record may tell us that a trade is an IRS with a fixed leg and a floating leg. A semantic financial data foundation tells us what economic obligations exist and how those obligations can be understood by systems and AI agents.

Final Thought

Economic Agreement is the first layer of understanding InterestRatePayout. It defines the core commercial obligation: who pays, who receives, what notional applies, and what rate logic determines the payout.

This turns InterestRatePayout from a vague interest payment idea into a structured economic component. But the economic agreement is only the starting point. Interest does not exist outside time. It accrues over periods, resets or fixes on dates, and is paid according to contractual payment rules.

In the next article, I will move to Stage 2: Contractual Timing. That is where the model turns the economic agreement into explicit accrual periods, payment dates, reset dates, and stub treatment.

• *AI-Native Financial Data Foundation