Settlement date is often the first field to disappear when a broker quote moves from chat into an OMS workflow. The price may be copied, the notional may be typed into an order ticket, but "T+2," "12 Jan," or a same-day settlement instruction can remain in the message thread rather than becoming a controlled field.
That gap is easy to underestimate. A fixed-income desk may regard the broker conversation as the place where market context lives and the OMS as the place where an order becomes operational. Structuring desks sit between those two environments more often than their system diagrams suggest. They need to determine whether a quote is actionable, comparable with another quote, suitable for a client structure, and complete enough to pass into downstream workflows.
When the handoff is manual, the problem is not only missing text. It is the loss of relationships between fields. A spread may belong to one size, a price to another, and a settlement date to a revised version of the quote. Once those associations are broken, a clean-looking OMS record can still represent an incomplete trade conversation.
Where the handoff breaks
Broker chats contain a mixture of structured facts and conversational shorthand. A dealer might write:
BUY 5mm ACME 3.875 2029 @ 99.42, T+2, firm 30 sec, ICE
In a later message, the same dealer may amend the offer:
99.36 now, 10mm, settle 15 Jan
A human reader can infer that the second message changes price, notional, and settlement date. A basic copy and paste cannot reliably establish that relationship. If the first line is pasted into an OMS and the second remains in ICE Chat, the record may show 5 million at 99.42 with no indication that the quote was superseded. If the second line is pasted instead, direction, security identity, and source platform may be absent.
The ambiguity becomes more difficult when a desk runs several messaging channels. Bloomberg Messenger, ICE Chat, Symphony, and Refinitiv Eikon Messenger each have their own message layouts, participant conventions, and thread behavior. A trader may receive a quote in one platform, ask for an amendment in another, and confirm the final terms by phone. The OMS generally receives only the portion someone chooses to enter.
The fields most exposed to this loss are familiar:
| Field | Typical chat expression | What can be lost at handoff |
|---|---|---|
| Direction | "Offer," "pay," "buy me," or implied by context | Whether the desk is buying or selling, especially after a correction |
| Notional | "5," "5mm," or "up to 10" | Currency, unit, maximum size, or the size linked to a price |
| Price | Clean price, spread, yield, or shorthand such as "99.36 now" | Quote type, revision status, and the security to which it applies |
| Settlement date | "T+2," a calendar date, or "same day" | The actual date, time zone, and whether it changed with the quote |
| Source platform | Visible in the chat interface but absent from copied text | Where the quote originated and which thread contains the supporting context |
An illustrative desk workflow
Consider an illustrative scenario involving a Paris-based credit desk running Bloomberg Messenger alongside ICE Chat. The desk covers a mid-size European asset manager and has a structuring colleague preparing a bond switch for a client portfolio. During a 20-minute window, three brokers quote the same issuer across two channels.
The first quote arrives on Bloomberg Messenger at 10:04:
Sell 3mm, 99.18, settle 14 Jan
At 10:07, a second broker writes on ICE Chat:
Can buy 5mm at 99.11, T+2
At 10:11, the first broker replies in a separate thread:
Can do 5mm, 99.14, but 16 Jan settlement
The structuring desk now has a potentially useful relative-value comparison. The second quote appears better on price, but its direction is opposite to the first quote. The settlement dates are not aligned. The 10:11 amendment changes size and settlement terms, while its security reference may be implicit from the thread rather than repeated in the message.
In an illustrative reconstruction of this workflow, the OMS receives three manually entered rows:
- Issuer and price from the first message
- Notional and direction from the second message
- Settlement date from the third message
The resulting row may not correspond to any executable quote. It combines fields from separate messages that were not intended to form one trade. The error does not require a careless trader. It can arise from a reasonable attempt to consolidate a fast-moving conversation while switching between windows.
TwoWay is being built around this specific gap. The product ingests broker conversations from Bloomberg Messenger, ICE Chat, Symphony, and Refinitiv Eikon Messenger, then structures capital-markets chat into trade-relevant fields. The objective is not to replace the OMS. It is to give the desk a clearer, reviewable representation of what was said before an order or structured trade is entered downstream.
Structuring data is more than entity extraction
Extracting a bond identifier from a message is useful, but it does not solve the handoff by itself. A fixed-income record needs the terms around that identifier and the links between them. A price without direction is not a quote. A notional without currency or price context is not a complete size. A settlement date without the quote version can be misleading.
For that reason, a structuring layer needs to preserve at least four kinds of context:
- Message context: the original wording, timestamp, sender, recipient, and source platform.
- Instrument context: issuer, maturity, coupon, currency, identifier, and any desk-specific alias.
- Quote context: direction, notional, price or spread, validity language, and whether the message is an amendment or a new quote.
- Workflow context: the relationship to a prior message, the review status, and the destination OMS or downstream process.
These categories matter because broker language is often elliptical. "Same line, better at 98.70" depends on a prior security reference. "Offer another 2" depends on the earlier size and currency. "Done, subject" may signal a different level of commitment than "firm for 10." The data model must retain uncertainty and relationships instead of manufacturing precision.
For a structuring desk, the practical output is a set of candidate records that can be checked against the conversation. A record might show the proposed direction, notional, price, settlement date, source platform, and confidence or review state. It should also make the underlying message easy to locate. This is where source platform becomes operationally important rather than merely descriptive. A trader reviewing a discrepancy needs to know whether the evidence sits in Bloomberg Messenger, ICE Chat, Symphony, or Refinitiv Eikon Messenger.
What should remain outside the automated layer
There is a natural temptation to treat structured chat data as an order-ready substitute for human review. That would be the wrong boundary. Automated structuring can identify candidate terms and connect amendments, but it does not decide whether a quote is economically attractive, whether a client mandate permits the trade, or whether a conversation constitutes an execution under a desk's controls.
The safer distinction is between organizing evidence and approving an action. Organizing evidence means surfacing the likely direction, notional, price, settlement date, instrument, and origin of a message. Approving an action means making a trading, compliance, suitability, or allocation decision. Those responsibilities remain with the desk and its existing control framework.
There are other limits. Chat messages can be ambiguous even to experienced traders. A broker may omit the currency because it is understood in the thread. A dealer may use a price convention that differs from the one expected by the OMS. A message can be deleted, edited, or followed by a phone call that never appears in the data. If the source conversation is incomplete, a structuring system should expose the gap rather than fill it with an invented value.
Human review also has a cost, so the useful question is not whether every message should become a fully normalized trade record. It is which conversations deserve attention first. A desk may prioritize quotes that contain a complete instrument reference, a live price, and a meaningful size. It may route records with conflicting settlement dates or unclear direction to an exception queue. That approach makes the structuring layer a triage mechanism as well as a data preparation step.
Connecting the OMS without flattening the conversation
The OMS remains the system where the desk manages orders, allocations, status, and execution workflow. Chat remains a source of market interaction and negotiation. The connection between them should therefore be explicit rather than treated as a one-way copy operation.
One practical pattern is to map structured chat fields to OMS fields while preserving the original message set beside the mapped record. For example:
| Chat-derived value | OMS alignment question |
|---|---|
| Direction | Does "pay," "offer," or "buy" map to the OMS buy and sell convention used by the desk? |
| Notional | Is the amount stated in the correct currency and unit, and is it quoted size or desired size? |
| Price or spread | Is the value a clean price, yield, spread, or dealer indication, and does the OMS expect the same convention? |
| Settlement date | Has "T+2" been resolved using the relevant trade date, calendar, and market convention? |
| Source platform | Can the user return to the originating thread when a field needs verification? |
This alignment is deliberately narrower than a promise to automate the entire trade lifecycle. It addresses the point where information is most likely to be retyped, abbreviated, or separated from its evidence. A structured candidate can then be passed to the desk's established OMS workflow, subject to the same checks that apply to manually entered information.
At TwoWay, this is the working focus of our early-access and pilot program. We are a three-person team in Paris, founded in 2024, building for the specific conditions of fixed-income desks rather than assuming that equity-style order data maps cleanly onto broker chat. Internal pilot work is centered on whether the extracted fields are useful in real review sequences, including cases where a quote changes across messages or platforms.
The useful measure is field continuity
The data loss between an OMS and a structuring desk is rarely a single dramatic failure. More often, it is a series of small omissions: direction inferred but not recorded, notional entered without currency, settlement date left in the thread, or source platform discarded after copy and paste. Each omission makes comparison and review more expensive.
That does not mean every chat message belongs in an OMS, or that structuring software should make a trading decision. It means the fields that influence a desk's next action should remain connected to the message that supplied them. For fixed-income workflows, settlement date, direction, notional, price, and source platform are practical starting points because each can alter whether two quotes are genuinely comparable.
The most useful test for a chat structuring layer is therefore specific: when a trader opens an OMS candidate, can the desk see what each field means, which message supplied it, whether a later message amended it, and what still requires judgment? If the answer is yes, the handoff has preserved enough context for OMS field alignment rather than merely producing another isolated data row.