FpML can represent an interest rate swap with explicit fields for notional, fixed rate, day-count fraction, payment frequency, and business-day convention, while a dealer may agree the same transaction in ten words of chat. The gap is not primarily vocabulary. It is the difference between what a parser can assert from the conversation and what must remain a candidate value until the parties, a confirmation, or a governing convention provides evidence.
That distinction matters when a fixed-income desk wants to move from chat capture to structured trade data. A message can contain enough information to identify a likely instrument and enough economics to support a trader's decision, yet still fall short of a valid FpML representation. Treating every inferred value as confirmed creates a clean-looking message with an unreliable evidentiary basis.
What FpML expresses in a chat-to-structure workflow
ISDA FpML, or Financial Products Markup Language, is an XML-based standard published by the International Swaps and Derivatives Association for representing OTC derivatives and other financial instruments. Its product taxonomy covers interest rate swaps, including fixedFloat, basisSwap, and OIS structures, as well as credit default swaps, FX, equity, and repo products.
For an interest rate swap, FpML separates the economic components into structures such as fixedLeg and floatingLeg. Within those legs, a representation can carry the notional, currency, fixed rate, floating-rate index, accrual conventions, payment frequency, date-adjustment rules, and notional exchange terms. A floating leg may identify an index such as EURIBOR or SOFR, along with the conventions that determine how the index is observed and applied.
This precision is useful because a swap confirmation is more than a textual record of what traders remember agreeing. It is the physical or electronic document that records the agreed terms after execution. A downstream system needs explicit values to calculate cash flows, generate confirmations, reconcile positions, and compare the trade with settlement or risk records.
Chat sits earlier in that sequence. It is a stream of short messages, corrections, abbreviations, quoted levels, and implied context. A broker may know that "5y EUR swap, 2.71, pay fixed" refers to a familiar market convention. An XML consumer cannot safely assume every convention that a human on the desk would supply from context. FpML provides a target for precise representation, but it does not remove the need to establish what the conversation actually supports.
The FpML fields that shorthand tends to omit
Consider the fields that determine whether a swap can be priced and settled consistently. Dealers often state the headline economics and leave convention details implicit because the counterparties operate within a known market practice. Those omitted details are precisely where a mapping process needs to slow down.
- dayCountFraction: The accrual calculation may use 30/360, Act/360, Act/365, or Act/Act. "Five-year EUR swap" does not identify the day-count convention for either leg.
- businessDayConvention: A payment or calculation date may use Modified Following, Following, or another adjustment rule. A phrase such as "quarterly payments" gives a frequency, not the calendar treatment.
- paymentFrequency: "5y" generally describes tenor, not the interval at which each leg pays. The fixed leg and floating leg can also have different schedules.
- notionalExchange: A standard interest rate swap usually does not exchange principal at inception or maturity, but that cannot be assumed for every structure. The presence or absence of notional exchange needs to be represented explicitly where relevant.
- floatingRateIndex: "EUR swap" does not by itself establish EURIBOR tenor, an overnight index, a compounding method, or a fallback treatment. "SOFR" still leaves questions about observation shift, lookback, lockout, and payment lag in some structures.
- currency and notional: "Pay 2.71 in five years" is not enough to establish whether the notional is EUR 10 million, USD 10 million, or a different amount, nor whether the currency applies to both legs.
- effective and termination dates: Spot-starting is common, but a forward-starting trade, a broken-date swap, or a trade with a stated start date cannot be represented safely from tenor alone.
The ISDA 2006 Definitions provide a governing fallback layer for terms such as day-count fraction and business-day convention when those terms are not fully specified in a confirmation. That fallback is important, but it is not a license to insert an unmarked value into a chat-derived record. A mapping system should distinguish between a term stated in the message, a term supplied by an applicable definition or market rule, and a term that remains unresolved.
Computable fields and attested fields
A useful working distinction is between computable fields and attested fields.
A computable field can be calculated once its inputs and governing convention are known. If a trade has an explicit effective date, a termination date, a Modified Following convention, and a quarterly payment frequency, a system can generate a payment schedule. It can adjust dates against a holiday calendar, count accrual days under Act/360, and determine the number of periods. The arithmetic is mechanical after the assumptions are fixed.
An attested field requires evidence from the parties, the source document, or an explicitly applicable rule. The notional, agreed fixed rate, selected index, and decision to exchange principal are examples. A parser can identify a likely notional from "10m," but it should still preserve the source text and currency context. It cannot derive the agreed notional from the tenor or calculate whether the parties intended notional exchange from the existence of a swap.
Some fields have both aspects. A termination date can be computed from an effective date and a stated five-year term, but only if the start convention and date treatment are established. A day-count fraction can be selected from a standard market template in a tightly controlled workflow, but the selection remains a rule-based attribution, not something inferred from the coupon rate.
This is why confidence should attach to individual fields rather than only to the whole trade. A chat record may support high confidence for instrument type, direction, currency, and quoted rate, while leaving payment frequency and business-day convention unresolved. A single label such as "parsed" hides those differences.
Illustrative scenario: a fixedFloat swap in dealer chat
The following exchange is illustrative and does not represent a real customer or transaction.
Dealer: "Pay fixed EUR 50m 5y at 2.71, spot start."
Trader: "Done, 2.71."
A structuring layer can reasonably extract several candidate values: an interest rate swap, EUR currency, EUR 50 million notional, a five-year tenor, pay-fixed direction, a fixed rate of 2.71 percent, and a spot-starting convention. Depending on the desk's controlled vocabulary, the likely product classification could be an FpML fixedFloat interest rate swap.
That exchange does not, by itself, fully establish the FpML content. It does not state the floating-rate index, the fixed-leg day-count fraction, the floating-leg day-count fraction, payment frequencies, business-day convention, holiday calendars, payment lags, stub treatment, or notional exchange. "Spot start" also needs an operational definition. Does the trade start on the standard spot date for the relevant market, or was that phrase used informally to mean the next business day?
An output that fills every blank with a familiar EUR market convention may be useful as a provisional trade ticket, but it should not be presented as though each value was attested by the chat. The structured record can instead carry separate states such as stated, derived, supplied by rule, and unresolved. The candidate FpML representation may then be generated with validation warnings where required data is absent.
For example, the record might preserve:
| Field | Chat evidence | Evidence status |
|---|---|---|
| Product | "Pay fixed EUR ... 5y" | Stated or strongly classified |
| Notional | "EUR 50m" | Stated |
| Fixed rate | "2.71" and "Done, 2.71" | Stated and accepted |
| Floating-rate index | No explicit index | Unresolved |
| Payment frequency | No explicit frequency | Unresolved |
| Day-count fraction | No explicit convention | Requires source or applicable rule |
The value of this approach is operational. A trader or operations analyst can see why the message is not yet confirmation-ready and can request only the missing terms. The system does not discard the useful structure merely because the record is incomplete, and it does not disguise uncertainty behind a fully populated schema.
Mapping is evidence gathering, not just translation
Mapping chat to FpML is an evidence-gathering exercise. The FpML output should carry the evidence status alongside the values, especially when the source is a conversation rather than a signed confirmation.
That evidence can come from several places. A later message may clarify "quarterly versus semiannual," a broker recap may state the index and conventions, or a swap confirmation may provide the authoritative terms. Internal desk configuration can supply a default for a tightly governed workflow, but the record should identify that source and the version of the rule used.
There is also a difference between a missing value and a value that is intentionally inapplicable. For a plain fixedFloat swap, notional exchange may be set to false because the trade terms specify no principal exchange. For another product, the element may need to express an exchange at inception, maturity, or both. "Not mentioned" should not automatically become "false." The mapping layer needs a state for unknown or not yet evidenced.
The same principle applies to dates. A five-year tenor can support a candidate termination date only after the effective date, calendar, and business-day treatment are known. If those inputs are absent, the system can retain "five years" as a stated tenor without manufacturing a calendar date.
FpML is a target, not always the final destination
FpML is not the only target schema for a fixed-income desk. Some firms use full FpML for OTC derivative workflows. Others use an FpML-lite subset, an internal trade object, an OMS format, or an ISDA confirmation template. A desk may need a compact signal record for pricing and surveillance before it needs a complete confirmation message.
The right target depends on the handoff. An internal schema may store a normalized product type, side, notional, rate, tenor, and evidence status. An OMS may require instrument identifiers and execution fields. A confirmation workflow may require the fuller set of schedules, conventions, elections, and legal terms that FpML can express. A single chat event can therefore produce several representations without pretending that they have the same level of completeness.
For bond conversations, the same evidence discipline applies even though the field inventory differs. A message may contain an ISIN, CUSIP, or SEDOL, a price, a yield, a nominal amount, and a settlement indication, while omitting accrued interest treatment, settlement date, or whether the quote is clean or dirty. The target might be an OMS format rather than FpML. The general workflow remains: identify what was stated, resolve identifiers, preserve ambiguity, and only calculate values when the inputs and conventions are available.
Where a structuring layer fits
At TwoWay, our focus is the first part of this workflow: turning broker and dealer chat into structured fixed-income trade data that a desk can review. The relevant sources can include Bloomberg Messenger, ICE Chat, Symphony, and Refinitiv Eikon Messenger. A parser can identify candidate instruments and terms across those conversations, while a structuring layer keeps the original message, extracted fields, and unresolved questions connected.
That separation is important for a pilot workflow. A desk may want a searchable feed of quotes and fills without treating every record as a completed confirmation. It may also want to route only records with sufficient evidence into an OMS or a downstream FpML process. The practical objective is not to force every chat message into a complete XML document. It is to make the path from shorthand to validated representation visible and reviewable.
For teams working with FpML, the most reliable implementation starts with a field inventory for each product type, followed by explicit evidence states and validation rules. Map stated terms first, calculate dates only after conventions are known, consult the ISDA 2006 Definitions where they govern, and preserve unresolved elements rather than filling them silently. That workflow lets a chat-derived record become an FpML-compatible candidate without confusing a plausible convention with an agreed term.