Normalizing Fixed-Income Market Data Across Venues

Normalizing Fixed-Income Market Data Across Venues

On ICE Chat, a broker might write: "XS0123456789 bid 5mm at 98.25."

On Bloomberg Messenger, the same bond might appear as: "offer French OAT 5yr at +12bp OAS," while a Symphony message says: "vs btd 5yr at 12 over."

These messages may describe related trading interest, but they do not arrive with the same instrument reference, side, size, price basis, or benchmark definition. For a fixed-income desk, normalizing them is not simply a matter of moving text into columns. It is an exercise in interpreting market language without removing the evidence needed to understand what was actually communicated.

One quote, several market languages

The example above contains several layers of ambiguity.

• Instrument: the first message identifies an ISIN, while the others refer to an issuer, maturity bucket, or relative-value description.
• Side: "bid" and "offer" are explicit in one message, but "btd," meaning bid to, may depend on desk convention and surrounding context.
• Quantity: "5mm" gives a notional amount, but the currency and whether the amount is firm or indicative may still need to be inferred.
• Price convention: 98.25 is a clean price, while "12bp OAS" and "12 over" are spread expressions rather than outright prices.
• Benchmark: "over" could refer to a government benchmark, an interpolated swap rate, or another reference understood by the participants.

A useful normalized record might therefore contain an instrument identifier, issuer, maturity, direction, notional, value, price type, benchmark, spread, currency, settlement terms, timestamp, venue, sender, and confidence or interpretation status. Yet the record should also retain the original message and its surrounding conversation.

The objective is not to pretend that all three messages are equivalent. It is to make their comparable elements visible while marking the fields that remain uncertain.

Price conventions cannot be flattened safely

Fixed-income prices are not expressed in one universal unit. A bond may be quoted as a clean price, a dirty price that includes accrued interest, a yield, or a spread against a reference instrument. A floating-rate note may be discussed using discount margin, or DM. An option-embedded bond may be discussed using option-adjusted spread, or OAS. A credit analyst may compare a bond using its G-spread over a government bond or its I-spread over an interpolated swap rate.

Those values are not interchangeable. A normalized schema that stores every quote in a generic "price" field can create false comparability. "98.25" may be usable for an outright price comparison, but it does not carry the same meaning as "12bp OAS." Converting the spread into an estimated price may be useful for a particular analytical workflow, but the conversion depends on assumptions such as the curve, cash flows, volatility treatment, accrued interest, and market convention at the time of the quote.

Normalization should therefore separate the observed value from any derived value. For example:

• Observed value: 98.25
• Observed value type: clean price
• Observed spread: 12 basis points
• Spread type: OAS
• Benchmark: not stated or awaiting resolution
• Derived mid or comparable price: calculated separately, with methodology and timestamp

This distinction matters for trading and for review. A quant analyst may want a common numerical representation for screening. Compliance may need to know whether the original communication contained a firm bid, an indicative offer, or a relative-value opinion. The same data model must support both uses without presenting an estimate as if it had been stated by the broker.

Instrument and settlement fields need their own logic

Instrument references are another source of mismatch. One venue may carry a full ISIN. Another may use an issuer short name and tenor. A third may refer to a bond by coupon, maturity, or an internal desk nickname. Even when the security can be resolved, similar instruments can remain economically distinct because of currency, seniority, coupon structure, call features, or issue size.

A normalization process can map the available reference to a canonical security identifier, but the mapping should retain how that identifier was reached. An exact ISIN match is different from a match inferred from issuer, maturity, and coupon. An unresolved reference should remain unresolved rather than being forced into the nearest security.

Settlement fields create a similar problem. A message may specify a value date, use a relative convention, or omit settlement entirely because the participants rely on a venue default. Corporate bonds commonly use T+2 settlement, while some European government securities can use T+1 or T+0 arrangements as settlement timelines accelerate in the EU post-CSDR environment. A normalized record should store the stated settlement term, the interpreted value date, the calendar used, and the source of that interpretation.

This is particularly important when comparing opportunities across instruments or venues. A price difference may disappear once accrued interest, settlement date, funding, or failed-settlement risk is included. Treating settlement as a secondary text field makes those differences difficult to identify downstream.

Preserving context is part of normalization

Normalization has a boundary. It should preserve the information needed to compare, route, search, and monitor a message. It may discard presentation differences such as capitalization, repeated salutations, or a venue's formatting markers. It should not discard the source wording, sender identity, timestamp, venue, conversation thread, or the uncertainty behind an interpretation.

For a buy-side data operations team, that means a normalized event should have at least two layers:

• Canonical fields: instrument, side, quantity, price or spread, currency, settlement, status, and timestamps.
• Source context: original text, venue, participants, thread, message sequence, attachments or references, and the rules used to interpret the message.

The source layer is not just an archive. It allows an analyst to inspect why a record was classified as a quote, indication, axes message, or execution. It also helps identify when a broker corrected a price, changed the size, or clarified that a message was "runs," "subject," or "workable." Those terms can affect the practical meaning of a message without fitting neatly into a single status field.

For MiFID II controls, recordkeeping and communication review require more than a clean table of extracted fields. MiFID II Article 16 places organizational and recordkeeping obligations on investment firms, and the relevant review may depend on the original communication as well as the structured interpretation. A normalized record that cannot be traced back to its source is difficult to challenge, explain, or correct.

Where a single schema creates risk

The case for normalization is strong, but forcing every message into one schema introduces its own risk. A schema often reflects the assumptions of the team that designed it. If the model has only one "price" field, it may force yield, clean price, DM, G-spread, I-spread, and OAS into the same category. If it has only one "side" field, it may turn "looking for," "offering," "axes," and "bid wanted" into equivalent labels.

That loss of nuance can affect compliance review. A broker's statement that a bond is "offered around" is not necessarily a firm offer. "Subject" can signal that a quote requires confirmation. "For information" may indicate that the message was not executable. A downstream process that converts all of these into an "offer" event may make the dataset easier to query while making the audit trail less accurate.

The answer is not to avoid structure. It is to make ambiguity explicit. Fields can include controlled values such as "stated," "inferred," "derived," and "unresolved." A record can carry multiple price representations without treating them as substitutes. Schema versions can document changes in interpretation rules. Human review can focus on low-confidence records rather than requiring an operator to inspect every message.

At TwoWay, our focus is the point where broker chat becomes structured trade and market data for fixed-income workflows. The practical test is whether a trader can find a comparable signal quickly while a data or compliance reviewer can still reconstruct the original communication. That requires a model designed around both use cases, not a parser that produces tidy values at any cost.

The useful record is both normalized and traceable

Cross-venue normalization works best when it treats structured data as an interpretation with provenance. The canonical record can make an ISIN searchable, distinguish a clean price from an OAS, identify a stated T+2 term, and flag a missing benchmark. It can also connect related messages from ICE Chat, Bloomberg Messenger, Symphony, and other channels without suggesting that their shorthand carries identical meaning.

For trading systems, that structure supports comparison and downstream calculation. For data operations, it provides consistent fields and explicit exception states. For compliance, it preserves the path from the normalized value back to the message that produced it.

The tradeoff remains irreducible: a more uniform schema is easier to query, but a normalized record that loses the original spread convention may be useful for trading and problematic for a MiFID II communication review.