Financial product models can feel overwhelming because of the sheer number of attributes involved. There are many product types, many market-specific conventions, and many fields that appear to describe small details. A single product may involve notionals, quantities, currencies, rates, spreads, indices, strikes, effective dates, termination dates, reset dates, fixing dates, payment dates, credit events, exercise terms, delivery terms, settlement terms, and many more.

Each product type also has its own attribute vocabulary. For an interest rate swap, we may talk about notional, fixed rate, floating index, reset dates, payment dates, day count convention, and compounding. For a credit default swap, we may talk about reference entity, reference obligation, credit events, deliverable obligations, recovery, and settlement method. For an option, we may talk about underlier, strike, expiry, exercise style, barrier, observation terms, and settlement. For a commodity contract, we may talk about commodity type, grade, location, delivery period, pricing dates, averaging method, and physical delivery. For a repo, we may talk about security, purchase price, repurchase price, near leg, far leg, haircut, delivery method, and manufactured income.

This creates a real challenge for understanding, analysing, communicating, and abstracting financial product attributes without creating unnecessary cognitive load.

At first glance, these attributes may look like a long and painful field list, but they are not random. They exist because a financial product goes through a complex business process. A product is first economically agreed. Then it needs to be contractually defined. Then its value, payoff, price, return, or cashflow needs to be determined. Finally, the result has to be settled, delivered, exercised, or otherwise realised.

This is the motivation for F-PAL — Financial Product Attribute Lifecycle. F-PAL organises financial product attributes according to the role they play in this lifecycle:

Economic Agreement
        ↓
Contractual Definition
        ↓
Value Determination
        ↓
Settlement / Realisation

The framework does not make financial products simple. They are not simple. But it gives the complexity a structure. It provides a way to present, discuss, and understand product attributes without forcing the reader to stare at an endless list of disconnected fields.

F-PAL: Financial Product Attribute Lifecycle

Stage 1 — Economic Agreement

The first stage is Economic Agreement. This stage captures the irreducible economic core of the transaction. It answers one basic question: what economic exposure has been agreed?

This is where we describe what risk is being transferred, between whom, in what direction, and for how much. Typical questions include: who are the counterparties, who pays and who receives, who buys and who sells, what is the notional or quantity, what is the rate, price, spread, or strike, what is the underlier, asset, commodity, index, or reference entity, and what direction the risk flows.

Typical attributes in this stage include party, counterparty, payer, receiver, buyer, seller, notional, quantity, currency, rate, price, spread, strike, underlier, reference entity, asset, commodity, and trade direction. In business language, this is the stage where someone might say: “5-year IRS, USD 100 million, pay fixed, receive 3M SOFR”, or “buy protection on Company X for USD 100 million”, or “buy a call option on this equity index with strike 100”.

At this stage, the focus is not yet on every detailed schedule, convention, calculation rule, or settlement instruction. The focus is the economic substance of the deal. If one of these attributes changes, we may no longer have the same deal. Changing the notional changes the size of the exposure. Changing the payer and receiver changes the direction of the economics. Changing the rate, spread, strike, underlier, asset, commodity, or reference entity changes the nature of the risk being transferred.

That is why Economic Agreement is the first F-PAL stage. It gives us the commercial core before we move into the detailed mechanics.

Stage 2 — Contractual Definition

The second stage is Contractual Definition. This stage answers: how exactly does the product work?

The economic agreement may be short and intuitive. A trader may describe a trade in a few words, but a system cannot rely on that level of shorthand. A confirmation, term sheet, or product model needs far more precision. It needs to describe when the product starts and ends, how periods are generated, when rates are fixed, when payments are made, what calendars apply, what business day conventions apply, what day count convention applies, what happens if a date falls on a holiday, what triggers the payout, what exercise rights exist, and how irregular periods are handled.

Typical attributes in this stage include effective date, termination date, maturity date, calculation period dates, payment dates, reset dates, fixing dates, observation dates, pricing dates, business day adjustment, day count convention, stub period, compounding method, averaging method, exercise terms, expiry date, credit events, deliverable obligations, and delivery terms.

This is usually the densest stage for schedule-based products. For an interest rate product, this stage may include calculation periods, payment dates, reset dates, fixing rules, day count convention, business day adjustments, compounding, and stub rules. For a credit product, it may include credit events, deliverable obligations, protection period, and settlement terms. For an option, it may include exercise style, expiry, exercise procedure, observation terms, and barrier features. For a commodity product, it may include pricing dates, delivery period, grade, location, averaging method, and delivery terms.

This stage turns a high-level product description into something precise enough to validate, confirm, calculate, and settle. It is where ambiguity is removed. It is also where much of the modelling complexity appears, because real financial products rarely follow perfectly simple patterns. Dates may need adjustment. Periods may be irregular. Rates may need fixing rules. Payments may be delayed. Events may trigger obligations. Exercise rights may depend on detailed contractual conditions.

In F-PAL, these details belong primarily to Contractual Definition. They explain how the product works over its life.

Stage 3 — Value Determination

The third stage is Value Determination. This stage answers: how is the amount, payoff, value, return, price, or cashflow determined?

The wording matters. It may be tempting to call this stage “calculation” or “projection”. That works well for interest rate products, because interest rate payouts often involve projected cashflows generated from schedules, rates, curves, day count conventions, and compounding rules. But not every product determines value in the same way. Some products are curve-projected. Some are observation-driven. Some are event-driven. Some are model-dependent. Some are agreed or fixed directly in the contract. So Value Determination is a better name because it is broader than calculation or projection.

Typical questions in this stage include: what amount is due, what the projected cashflow is, what the present value is, what market data is required, which curve, fixing, price, or observation is used, whether the value is schedule-projected, observation-driven, event-driven, model-dependent, or agreed directly in the contract.

Typical attributes include observed rate, fixing rate, market price, commodity price, average price, calculated amount, fixed amount, floating amount, payoff amount, recovery value, auction price, intrinsic value, present value, forecast cashflow, realised cashflow, valuation date, pricing model, volatility, curve, discount factor, and calculation method.

Different products show different value-determination patterns. For interest rate products, the pattern is often curve / schedule-projected:

schedule + notional + rate + day count + curve
        ↓
projected cashflows

For commodity products, the pattern is often observation-driven:

pricing dates + observed market prices + averaging method
        ↓
settlement price or amount

For credit default products, the pattern is often event-driven:

credit event + recovery / auction outcome
        ↓
protection payment

For options, the pattern may be exercise-driven and model-dependent:

underlier price + strike + expiry + volatility + exercise terms
        ↓
option value or payoff

For fixed-price products, forwards, or some repo economics, the value may be largely agreed or fixed:

fixed price × quantity

This stage is often the most revealing part of the framework. It shows that products differ not only by what they are called, but by how their value, payoff, return, price, or cashflow is determined. An interest rate swap needs schedules, curves, fixings, and projected cashflows. A commodity swap may need price observations over a pricing period. A CDS may need a credit event and a recovery or auction outcome. An option may need an exercise event and a valuation model. A repo may embed the financing return in the difference between purchase and repurchase terms.

These are structurally different behaviours. F-PAL makes that difference easier to see.

Stage 4 — Settlement / Realisation

The fourth stage is Settlement / Realisation. This stage answers: how does the result become an actual payment, delivery, exercise, or transfer?

The result of value determination does not remain as an abstract number. It has to become real. It may become a cash payment, a physical delivery, an exercise event, a principal exchange, a securities transfer, or a credit settlement.

Typical questions in this stage include: whether the product is cash settled or physically settled, who pays whom, what amount is paid, what currency is used, what the settlement date is, whether settlement is delivery-versus-payment or free-of-payment, whether there is netting, whether there is principal exchange, whether there is asset delivery, what asset is delivered, what grade, location, or load profile applies, and whether settlement has completed.

Typical attributes include settlement type, settlement currency, settlement date, settlement amount, settlement method, payment amount, payment currency, payment instruction, cash settlement terms, physical settlement terms, delivery method, delivery location, delivery-versus-payment, free-of-payment, netting terms, principal exchange, asset transfer, security delivery, commodity delivery, exercise settlement, credit event settlement, and settlement status.

For an interest rate swap, this may be a cash payment on each payment date. For a cross-currency swap, it may also include principal exchanges. For a credit default swap, it may involve cash settlement or physical delivery after a credit event. For an option, it may involve cash settlement or delivery of the underlier after exercise. For a commodity contract, settlement may involve physical delivery with location, grade, delivery period, and load profile. For a repo, settlement is central to the product because the exchange of cash and securities is the transaction itself.

This is why settlement should not be treated as a minor back-office detail. Settlement is the realisation of the economic obligation. It is the point where agreed and determined obligations become actual payments, deliveries, exercises, or transfers.

F-PAL as Business Views

Another way to read F-PAL is as four business views of the same product.

This view is useful because it explains why attributes are so massive. They are not created by one single function. Front office needs attributes to express the trade. Legal, documentation, and middle office teams need attributes to define the contract. Risk, valuation, quant, finance, and product control teams need attributes to determine value, risk, PnL, and cashflows. Operations, treasury, custodians, clearing brokers, and settlement systems need attributes to realise the result through payment or delivery.

The same product moves across different business views, and each view cares about different attributes. F-PAL connects these views into one structure. This makes the framework useful not only for modelling, but also for communication. It gives people a shared language for discussing where an attribute belongs and what role it plays.

F-PAL Is Directional, but Not Strictly Sequential

F-PAL should not be read as a rigid step-by-step workflow. The lifecycle is directional, but not strictly sequential. A product generally moves from economic agreement to contractual definition, from contractual definition to value determination, and from value determination to settlement or realisation. However, the stages can overlap.

Some attributes naturally connect more than one stage. For example, notional is part of the economic agreement, but it is also used in value determination. A day count convention is part of the contractual definition, but it directly affects cashflow calculation. A credit event is contractually defined, but once it occurs, it drives value determination and settlement. A settlement currency may be defined in the contract, but it is realised operationally at settlement.

So F-PAL is best understood as a semantic lifecycle, not a rigid workflow. It helps identify the primary business role of an attribute, while recognising that the same attribute may also support other lifecycle stages. This is important because financial products are not clean textbook objects. They are business arrangements that move across trading, documentation, valuation, risk, operations, and settlement. The framework should help us navigate this complexity, not pretend that the complexity does not exist.

Conclusion

Financial product attributes are massive because the underlying business lifecycle is massive. F-PAL is my attempt to organise that complexity by asking four simple questions: what economic exposure has been agreed, how exactly the product works, how value is determined, and how the result is settled or realised.

These questions help move the discussion from field names to business meaning. They make large product attribute sets easier to present, communicate, and reason about. For AI-native financial data foundations, that is the direction I want to go.

• *AI-Native Financial Data Foundation