Fixed Income Microstructure

Here's a TLDR note based on some data analysis of Fixed Income markets and their microstructure.

Fixed income market structure is very different from equities.

There isn't one central order book.

Instead, there is a collection of venues, protocols, liquidity providers, data feeds, execution mechanisms and post-trade workflows — all overlapping to some degree.

What does the market actually look like when we map the connectivity?

I looked at a set of bond and interest rate swap venues and their supported functionality to understand the shape of the market.

The interesting part isn't just the number of venues.

It's how fragmented the functionality is.

The Fixed Income Market is Fragmented

The bond data contains 48 venues, covering 42 distinct features across government bonds, corporate bonds, munis, agencies, covered bonds and supranationals.

Of the 195 venue/feature relationships:

• 166 are live
• 29 are planned
• 48 distinct venues are represented
• 42 distinct features are represented

There are also 10 IRS venues, with 19 distinct features.

This immediately tells us something about fixed income:

The market is not really a collection of venues. It is a collection of capabilities.

A venue isn't simply "an exchange".

One venue might provide RFQ.

Another might provide axes.

Another might provide streaming prices.

Another might provide market data.

Another might primarily exist for post-trade processing.

And some provide several of these at once.

What Does a Fixed Income Venue Actually Do?

For bonds, the most common capabilities in the dataset are:

Feature	Venues
Post Trade	25
RFQ	17
Static Data	14
Price Contribution	14
Axes	12
Click and Trade	11
Process Trade	10
Non-Contingent List	9
Orders	9
Market Data TOP	8
Market Data AGG	8

The distribution is interesting.

There is a relatively small set of common primitives.

Then there is a very long tail of specialised functionality.

Things like:

• All-to-all trading
• Composite price contribution
• Yield trading
• Spread trading
• Cross trading
• EFP
• TAP facilities
• Market-on-close
• Price-at-close
• Portfolio trading
• Customer pricing

This looks less like a traditional exchange and more like a distributed set of micro-markets.

RFQ is Only One Part of the Market

RFQ is one of the dominant execution mechanisms in the bond data.

There are 17 bond venues supporting RFQ.

But RFQ is surrounded by other mechanisms:

• Axes
• Click and trade
• Non-contingent lists
• Streaming quotes
• RFM
• All-to-all
• Portfolio trading
• Orders

Why does this matter?

Because an execution system can't simply implement "send an RFQ".

The actual decision is closer to:

Given the instrument, liquidity, client, size, market conditions and available counterparties, which execution mechanism should I use?

That becomes a routing problem.

And routing is fundamentally a data problem.

Axes Are Different From Quotes

One of the interesting distinctions in the data is between axes and more traditional pricing.

An axe is effectively an expression of interest.

It tells the market:

I have interest in trading this bond in this direction.

That is different from continuously publishing a firm executable price.

The difference matters.

A trading system therefore has to distinguish between:

• Information
• Indicative liquidity
• Firm liquidity
• Executable liquidity
• Historical liquidity

Treating all of these as "prices" loses important information.

Market Data Is Also Fragmented

There are multiple forms of market data represented in the bond connectivity:

• Top-of-book
• Aggregated market data
• Trade events
• Quotes
• Static data
• Price contributions
• Composite prices
• Streaming prices

This creates an interesting architectural problem.

What is the canonical market state?

If Venue A says the bond is 99.20.

Venue B says 99.18.

Venue C has an indicative axe at 99.25.

And Venue D has a recent trade at 99.17.

These aren't four competing answers.

They are four different pieces of information.

A market data system needs to preserve that distinction.

The Long Tail Is Important

The average venue isn't particularly representative of the market.

For example, the bond venue data contains a small number of highly connected venues alongside a long tail of specialised venues.

Some venues expose more than ten different capabilities.

Others expose only one.

This is important from a technology perspective.

A system designed around the "average" venue will probably be badly designed.

The long tail contains functionality that may only be relevant to a particular asset class, geography, client type or execution workflow.

The architecture therefore needs to support:

common primitives + specialised adapters.

Not:

one universal venue interface.

Venue Connectivity Is an Adapter Problem

A useful way of looking at the market is:

                    Trading System
                          |
              +-----------+-----------+
              |                       |
          Common Model            Strategy
              |
       +------+------+------+------+
       |      |      |      |
     RFQ    Axes   Orders  Market Data
       |      |      |      |
   +---+------+------+-+----+----+
   |   |      |      | |         |
Venue A     Venue B    Venue C   Venue D

The common model should capture the semantics.

The adapter should capture the venue-specific implementation.

This is important because the venue protocols are not identical.

One venue may expose:

RFQ
Click and Trade
Process Trade

Another:

RFM
RFS
Compressions

Another may primarily provide:

Market Data

Trying to force all of these into a single overly generic abstraction can make the system harder to understand rather than easier.

IRS Looks Different

The IRS data is much smaller.

There are 10 venues and 19 features, with the core execution connectivity concentrated around four major venue families:

• Bloomberg IRS
• Tradeweb EU
• Tradeweb US
• Tradeweb Yen

The feature distribution is also more concentrated.

The common functionality includes:

• RFM
• RFS
• RFQ
• Click and trade
• Process trade
• Price contribution
• Post trade
• Compressions
• Composite price contribution

There are also specialised capabilities such as:

• Future spread
• Asset swap
• EFP
• Market agreed coupon
• Market agreed coupon IMM roll

This is a different shape from the bond market.

Compression Is a Good Example

Compression is particularly interesting in IRS.

It isn't simply another execution protocol.

It is a workflow around the existing portfolio.

That means the technology supporting it has to understand more than an individual order.

It needs to understand relationships between trades and positions.

The system therefore starts moving from:

"execute this trade"

towards:

"manage this portfolio transformation."

That is a very different problem.

The Commonality Across Asset Classes

There is nevertheless a common set of concepts.

Both bonds and IRS have:

• Price contribution
• Execution
• Trade processing
• Post trade
• Market data
• Multiple venue connectivity

This suggests that a trading platform should probably have a common core.

But the common core shouldn't attempt to erase the differences between asset classes.

The useful abstraction is probably something closer to:

                    Trading Platform
                           |
             +-------------+-------------+
             |                           |
        Common Trading              Common Data
          Concepts                    Concepts
             |                           |
       +-----+-----+              +------+------+
       |           |              |             |
     Bonds        IRS          Prices        Trades
       |           |              |             |
   Venue Adapters / Protocol Adapters

The abstraction should be around business semantics.

Not around pretending every protocol is the same.

Live vs Planned Connectivity

The datasets also contain an important distinction between LIVE and PLANNING.

For bonds:

• 166 relationships are live
• 29 are planned

For IRS:

• 47 relationships are live
• 4 are planned

This is useful because venue coverage is not static.

A connectivity matrix isn't just documentation.

It is effectively a roadmap.

If a venue has RFQ live but a related market-data capability planned, that tells us something about the evolution of the platform.

It also means that architecture should make adding capabilities cheap.

If every new venue requires changes throughout the trading stack, the cost of market expansion grows quickly.

How Should We Think About Venue Selection?

The obvious question is:

Which venue should I use?

But I don't think this is quite the right question.

A better question is:

Which execution mechanism gives me the best outcome for this particular piece of flow?

That depends on things such as:

• Instrument
• Asset class
• Size
• Direction
• Liquidity
• Client
• Time of day
• Current market conditions
• Available counterparties
• Historical execution quality

The venue is only one dimension.

Execution Quality Is a Distribution

It is tempting to measure a venue using an average execution metric.

But averages hide a lot.

Suppose two venues have the same average execution cost.

One might have a tight distribution.

The other might have occasional very poor outcomes.

Those are very different trading systems.

So we should care about:

• Median execution cost
• Tail execution cost
• Fill probability
• Response time
• Slippage
• Reject rates
• Market impact
• Post-trade processing time

The distribution is usually more interesting than the average.

Technology and Market Structure

This is where fixed income microstructure becomes particularly interesting for technology teams.

Venue fragmentation creates technology fragmentation.

More venues means:

• More protocols
• More data formats
• More connectivity
• More failure modes
• More state to reconcile
• More market-data normalization
• More operational complexity

But the business value isn't necessarily proportional to the number of venues.

A venue that contributes one highly specialised capability may be more important than ten venues providing the same basic RFQ workflow.

So connectivity should be measured by business capability, not just by connection count.

What Should We Measure?

A useful fixed income technology KPI set could look something like:

Market Data

• Feed latency
• Message rate
• Drop rate
• Staleness
• Cross-venue price divergence
• Trade-event latency

Execution

• RFQ response rate
• RFQ response latency
• Fill probability
• Execution cost
• Slippage
• Reject rate

Connectivity

• Venue availability
• Session resets
• Message failures
• Protocol errors
• Reconnect time
• Failover behaviour

Business

• PnL
• Execution quality
• Hit ratio
• Client response quality
• Inventory impact
• Hedge effectiveness

The interesting analysis is then the relationship between these distributions.

Tech KPI Delta

For example:

Does reducing RFQ processing latency actually improve execution quality?

Or:

Does better market-data freshness improve the tail of execution outcomes?

Or:

Does adding another venue improve execution quality, or simply add operational complexity?

These are empirical questions.

They can be answered from the data.

This is where being data driven becomes useful.

Not because we need an ML model.

Because we need to understand the relationship between the technology and the business.

Systemic vs Idiosyncratic Events

The other interesting dimension is market stress.

What happens when liquidity disappears?

A normal trading day might produce:

Market Data
     |
     v
Normalize
     |
     v
Price
     |
     v
RFQ
     |
     v
Execute

A stressed market might produce:

Market Data
     |
     +----> Rate spike
     |
     +----> Message burst
     |
     +----> Venue slowdown
     |
     +----> Stale prices
     |
     +----> RFQ timeout
     |
     v
Bad execution

This is where the co-distribution of technology and business metrics becomes important.

If the worst trading outcomes happen at exactly the same time as the technology is under pressure, the architecture is part of the trading strategy.

The Main Observation

The biggest observation from looking at the venue data is that fixed income isn't one market.

It is a network of overlapping micro-markets.

Bonds have a large and fragmented venue landscape with many specialised capabilities.

IRS has fewer venues and a more concentrated set of core workflows.

Both have a common problem:

turning fragmented connectivity into a coherent trading system.

That requires more than building adapters.

It requires understanding the semantics of the market.

Final Thought

Fixed income market structure is often described as fragmented.

That's true, but it doesn't really describe the problem.

The more interesting observation is that the market is composable.

A venue can contribute:

• A price
• An axe
• A trade
• An RFQ
• A data feed
• A post-trade workflow
• A specialised execution mechanism

The trading system's job is to compose these pieces into a coherent view of the market.

And once you have that view, the interesting questions become measurable:

Which liquidity is actually useful?

Which venue is useful for which type of flow?

Where does technology performance affect execution?

Where do market events expose weaknesses in the architecture?

Which connectivity investments actually improve the business?

That's the interesting part of fixed income microstructure.

Not the number of venues.

The relationship between market structure, technology and execution.