Two Years of Broker Chat: What the Data Shows

What the first pass through broker chat revealed

Only roughly 35% to 45% of messages that referred to an instrument contained an explicit ISIN in our internal pilot program observations. The remaining messages used desk shorthand such as "French OAT 5yr", "LVMH 2.125s due 2027" or "IGM 10yr". For a human trader who already understands the conversation, that shorthand is often sufficient. For a system attempting to structure the exchange, it is the starting point for the difficult work.

The observation came from early participating rates and credit desks using broker chat across normal price discovery and execution workflows. It does not describe the whole fixed-income market, and it is not a claim about message quality at every firm. It does show why extracting trade data from chat is less like reading a clean order ticket and more like reconstructing a sequence of partial statements.

A message may contain an instrument reference without a direction, a direction without a size, or a price that only makes sense beside the previous message. The practical question is not whether a model can identify the words "5yr" or "bid". It is whether the resulting record preserves enough context for a trader, operations team or compliance reviewer to understand what was actually communicated.

Most chat is price discovery, not confirmation

Quote messages outnumbered fill confirmations by approximately 4:1 on credit desks in the pilot observations, and by closer to 6:1 on rates desks. That distinction matters. A workflow designed only to capture completed trades will miss the majority of the conversation that explains how a price was formed, challenged and revised.

On a credit desk, a sequence might look like this:

• "Bid for 5mm 5yr senior financials"
• "98.42 bid"
• "Can improve to 98.45 for 3mm"
• "Offer 98.50, 5mm"
• "Done 3 at 98.45"

The final line is the fill confirmation. The earlier messages contain the negotiation, the available size and the change in price. They may also be relevant to surveillance, dispute resolution and the trader's later explanation of execution quality.

For rates, the same structure may use yield, price or spread depending on the instrument and desk convention. "Bid 5mm 5yr" could be followed by a yield, a price, or a reference to a benchmark move. A parser that treats every number as a price will create a record that looks complete while being economically wrong.

This is why TwoWay treats the conversation as a connected stream rather than a collection of isolated messages. The objective is to identify quote events, changes in terms and fills while retaining the source wording and the uncertainty around any inferred field.

Direction is often a contextual field

Direction was explicit in approximately 65% of messages observed in the internal pilot program. In the other 35%, determining whether the trader was buying or selling required context, such as the prior message, the counterparty role or the convention used by that desk.

That is a material issue for fixed-income workflows. "At 99.10 for 2mm" is not a complete instruction without knowing whether 99.10 is a bid or an offer. "Take 5" may indicate acceptance of an offer, but its interpretation depends on what preceded it. "Still there?" may refer to a quote, not a trade. A record that fills the direction field with a guess can be more dangerous than a record that marks it for review.

In our structuring workflow, fields such as instrument, direction, size, price or yield, spread, counterparty reference and execution status need to be separated from the confidence attached to each field. An explicit "offer" can be treated differently from a direction inferred from a reply. The distinction is useful operationally because it allows a desk to route ambiguous records for review instead of forcing every message into a definitive trade object.

The context problem also explains why message-level extraction has limits. Consider a rates desk at a mid-size Paris asset manager during a busy morning in a pilot. A trader asks for a five-year OAT in a chat thread, receives several prices, and then switches from yield quoting to price quoting after a benchmark move. The final fill may be clear, but the meaning of an earlier number depends on the quoting convention at that point in the thread. A useful structured feed must preserve the sequence and the change in convention, not simply select the last number it sees.

Different desks leave different data footprints

Broker chat does not have one universal grammar. Credit, rates and repo desks use different shorthand because they are solving different execution problems.

Repo is a useful edge case. In standard general collateral communication, a short message can contain enough meaning for an experienced desk: a tenor, a rate, a size and a settlement instruction may be understood from established convention. The absence of an ISIN does not necessarily mean the message is incomplete. It may indicate that the relevant object is a collateral pool or eligibility set rather than one bond.

Settlement timing can also change the interpretation. A repo instruction for same-day settlement, or T+0, is operationally different from a T+2 cash bond transaction. A structured record therefore needs workflow-specific fields rather than a single bond-trade template applied to every desk.

We also observed variation between ICE Chat, Bloomberg Messenger and Symphony for the same underlying bond on the same day. One channel might carry a spread quote while another used yield. The difference was not necessarily a change in economic intent. It could reflect broker preference, desk convention or the point in the negotiation at which the conversation took place.

What structured chat data is useful for

The immediate use case is a cleaner view of quotes and fills. Fixed-income traders can search a single feed for instrument references, compare successive prices and see which messages led to an execution. Operations teams can receive records that are closer to an order or trade schema, reducing the need to reconstruct every field manually from screenshots and copied chat.

There are also benefits before and after execution. A portfolio manager reviewing a missed opportunity may want to know whether a desk saw a firm offer, an indicative level or only a request for axes. A trader may want to compare the spread quoted by different brokers without manually normalising "+112", "112 over" and an outright price. Compliance teams may need the original communication, the extracted fields and the path between them.

Those uses require careful separation between observed and inferred information. An ISIN resolved from "LVMH 2.125s due 2027" should remain traceable to the original text and, where relevant, to the assumptions used in the resolution. The same applies to a direction inferred from thread context. Structured output is more useful when it exposes provenance instead of presenting interpretation as if it were typed by the trader.

This also matters for governance. MiFID II Article 16 places communication recording and record-keeping within a regulated firm's control framework. GDPR Article 28 is relevant where a service provider processes personal data on behalf of a controller. These references do not prescribe a particular chat parser, and they do not make extracted data correct by default. They do reinforce the need to define retention, access, auditability and processor responsibilities before connecting live communications.

Where the approach falls short

Early pilot data cannot establish a universal message taxonomy or prove that structured chat alone improves execution. The participating desks are a limited sample, and their workflows may be more disciplined than those of other firms. Ratios such as 4:1, 6:1 and 35% to 45% should be treated as observations from an internal beta program, not market benchmarks.

There are also cases where the chat record is intrinsically insufficient. A broker may refer to a bond by an internal nickname that has several possible matches. A trader may confirm a fill by phone and use chat only to discuss the level. A correction may arrive in a second application. A message may be deleted or unavailable under the firm's retention configuration. No structuring layer can recover context that was never captured or that sits outside the connected workflow.

False precision is another risk. If a system resolves an instrument confidently when two bonds fit the description, the tidy output can hide the underlying ambiguity. For this reason, a practical deployment needs review queues, source-message links, configurable confidence thresholds and a way for desk users to correct records. The system should support the desk's controls, not replace them.

Our claim is narrower and more practical: early deployment data can reveal recurring patterns in broker communication, expose which fields are usually explicit and show where desk-specific context is required. It cannot, by itself, demonstrate population-wide behaviour, replace a firm's communication surveillance controls or guarantee straight-through processing for every quote and fill.

The pilot question that matters next

The most useful measure for a prospective deployment is not simply how many messages can be parsed. It is how often the structured record is correct enough for the next workflow without concealing uncertainty. That may mean different thresholds for a trader's search feed, an operations queue and a compliance archive.

For a rates desk, the key test may be whether a change from yield to price remains intelligible through a fast-moving thread. For credit, it may be whether quote history and partial fills stay connected. For repo, it may be whether short GC messages can be classified without inventing a bond identifier.

Our internal pilot observations point to a methodological discipline: measure field coverage by desk and message type, retain the original language, and evaluate inferred fields separately from explicit ones. The next open question is whether those confidence-aware records reduce manual reconstruction in daily workflows without encouraging users to treat an inferred trade field as an unquestioned fact.