MiFID II Article 16 puts the chat record inside the control framework
MiFID II Article 16 requires investment firms to record telephone conversations and electronic communications that relate to the reception, transmission, and execution of client orders, or to the conclusion of transactions on own account. On a bond desk, that can include an RFQ response, a price revision, a counteroffer, or an execution confirmation exchanged through Bloomberg Messenger, ICE Chat, or Symphony.
The operational gap is easy to describe. The regulation requires a retrievable record. The record is often a chat thread. The chat thread is unstructured, distributed across several applications, and full of shorthand. The desk may still rely on manual parsing to identify the instrument, side, price, quantity, and execution terms. In many firms, the communication-recording workflow and the trade-data workflow have not been formally joined.
Article 16 is an organisational requirement, not simply an archiving preference. Firms need arrangements that allow relevant communications to be recorded, retained, and made available to regulators. ESMA's guidelines on the recording of telephone conversations and electronic communications under MiFID II address the scope of trading-related communications, including communications conducted through messaging platforms used for business purposes.
That scope matters for fixed-income desks because the commercial negotiation may not resemble a conventional order ticket. A broker message saying "5mm 27s at 98.42?" may be followed by "offer 98.38," "done," and a later correction to settlement details. Each message contributes to the communication trail. A record containing only the final booking does not necessarily preserve how the transaction came about.
What the electronic communication record needs to preserve
MiFID II Article 16 does not prescribe a single data model for chat records. It does, however, require firms to be able to evidence the relevant communications and preserve them in a form that can be reproduced or copied, with safeguards against alteration or deletion. The control objective is broader than retaining screenshots or a final export from a messaging application.
For a bond transaction, the relevant record may include:
- the original RFQ or client instruction;
- the instrument reference, usually an ISIN or another identifier that can be resolved to the relevant instrument;
- the side, nominal amount, currency, price, yield, spread, or other quoted terms;
- revisions, counteroffers, and clarifications exchanged before execution;
- the identities or identifiers of the participants and the relevant client or account;
- the execution confirmation, timestamp, and any subsequent correction or cancellation communication.
The communication trail should also preserve sequencing. A quote received at 10:14:03, revised at 10:14:38, and accepted at 10:15:01 has a different evidentiary meaning from three messages presented without reliable timestamps or ordering. Time zones, message identifiers, attachments, edits, deleted messages, and system-generated delivery markers can all affect reconstruction.
This is where the language of "record" becomes operationally important. A firm may retain the raw messages but still struggle to demonstrate which conversation relates to which order, whether a later message superseded an earlier price, or whether two similarly named securities were involved. The existence of data is not the same as the ability to retrieve the relevant record promptly and accurately.
MiFIR Article 25 adds a transaction-reporting view
MiFIR Article 25 requires investment firms that execute transactions in financial instruments to report transaction details to the relevant National Competent Authority, or NCA. The report must identify the transaction in sufficient detail for the authority to monitor market activity and investigate possible market abuse. In practice, the reporting framework requires fields such as the instrument identifier, price, quantity, execution time, trading venue or relevant execution context, and client data, together with other details required by the applicable reporting rules.
For bonds, the instrument identifier is commonly an ISIN. FIRDS, the Financial Instruments Reference Data System maintained by ESMA, links financial instrument reference data to the identifiers and characteristics used in reporting. A chat message may contain a short name, a maturity shorthand, or a broker's internal label rather than a clean ISIN. The reporting process still needs the correct instrument and the correct reportable attributes.
The same communication trail can therefore support several control processes without being identical to any one of them. Article 16 concerns the recording and retention of relevant communications. Article 25 concerns transaction reporting to an NCA. Post-trade transparency concerns public or regulatory publication of trade details, subject to the applicable rules for the instrument, liquidity, and available deferrals. Pre-trade transparency is more limited in bond markets than in equities and can involve the publication of bid and ask quotes by systematic internalisers, or SIs, within the relevant scope.
An SI is an investment firm that executes client orders on its own account systematically, frequently, and substantially. Its transparency and reporting obligations differ from those of other execution arrangements. For operations teams, the practical point is that the chat record may be needed to explain not only what was reported, but how the desk classified the transaction, identified the instrument, determined the execution time, and applied the relevant venue or client attributes.
When an NCA such as the AMF in France, BaFin in Germany, or another competent authority requests supporting information, a transaction report alone may not answer the question. The authority may also need the order book or communication trail: the sequence of quotes, RFQ responses, revisions, counteroffers, and execution confirmations that explains the transaction.
The chat trail rarely arrives as a regulatory record
Broker chat is written for speed. Traders use abbreviations, incomplete sentences, copied identifiers, implied currencies, and terms whose meaning depends on the preceding messages. A dealer may write "same 5 at 98," assuming that the bond, side, and settlement convention are obvious from context. A later message may refer to "the other line" or "make it 3," requiring a reviewer to look backward through the thread.
The raw content also arrives in different shapes. One platform may expose a conversation identifier and message timestamp. Another may provide an export organised by user or date. Attachments, quoted text, edits, reactions, and system notices may be represented differently or omitted from a standard export. Retention and retrieval policies can vary by platform, business unit, and local implementation.
That creates several points of failure:
- an instrument name in the chat does not resolve automatically to the correct ISIN;
- the quantity may be expressed in nominal, par, or shorthand units;
- price, yield, spread, and clean or dirty price may be mentioned without an explicit label;
- a message may contain a correction without clearly identifying which prior term it replaces;
- the relationship between the communication and the booked trade may remain implicit.
MiFID II does not require a structured data feed. It requires a retrievable record. The gap is between those two things. A firm can retain the original messages and still face a substantial reconstruction task before it can present a coherent, ordered account of the transaction.
One negotiation can span two platforms
Illustrative scenario: A bond desk receives an RFQ response from a broker on ICE Chat for a specified nominal amount of a corporate bond. The trader asks for a revised price in the same thread. The broker responds later through a follow-up conversation on Bloomberg Messenger, where the terms are adjusted and the trader accepts. The trade is then executed and booked.
The communications relate to one transaction, but the trail is split across two platforms. The platforms may use different timestamps, participant identifiers, message references, and retention processes. Neither thread alone shows the complete sequence. The ICE Chat exchange contains the original RFQ and first response. The Bloomberg Messenger exchange contains the revision and acceptance.
If an NCA asks for all communications related to the execution, the desk may have to search both applications, identify the relevant broker and instrument, compare timestamps, interpret shorthand, and manually place the messages into a single order of events. It may also need to establish that the two conversations concern the same trade rather than two separate inquiries in the same security.
This channel diversity is not limited to ICE Chat and Bloomberg Messenger. Fixed-income participants may also use Symphony or Refinitiv Eikon Messenger, depending on the counterparties and the desk's operating model. A single trader can move between applications without experiencing the boundaries that later matter to compliance. The conversation feels continuous to the trader even when the retained evidence is fragmented.
That fragmentation can affect routine surveillance as well as formal inquiries. A reviewer looking only at one platform may see an apparently incomplete RFQ, an unexplained price change, or an execution without the preceding client instruction. The missing context may exist elsewhere, but the control process needs a way to find and associate it.
Raw retention is permitted, but reconstruction still has to work
There is an important nuance here. The regulatory record obligation does not specify that firms must store every communication in a particular structured format. A firm can retain raw chat logs and reconstruct the relevant context manually. That approach may be proportionate for a small number of transactions or a limited set of channels.
The practical test is whether the reconstruction is reliable enough to withstand an inquiry, and whether the firm discovers failures before or after one arrives. A process that depends on an experienced trader remembering which platform carried the second half of a negotiation is difficult to evidence. A process that produces a message export without instrument, client, or execution linkage may leave reviewers with the same problem in a different file format.
Structured extraction does not replace the source record. The original messages remain important evidence, particularly where meaning depends on context or where a reviewer needs to verify a parsed field. The structured layer provides an index and a working representation of the order book or communication trail. It can connect a message to a candidate instrument, trade, participant, timestamp, and execution event while preserving the path back to the underlying communication.
For compliance and operations teams, useful controls include exception queues for unresolved instruments, explicit handling of revised terms, confidence indicators for extracted fields, and audit logs showing when a record was created or amended. Cross-platform association should be reviewable rather than silently inferred. A system should also distinguish a broker quote from a client order, an indicative price from a firm quote, and a post-trade correction from a new instruction.
Build a compliance-ready retrieval path from the chat record
At TwoWay, we are a three-person, bootstrapped team in Paris building an early-access product for fixed-income trading desks. TwoWay structures broker chat from Bloomberg Messenger, ICE Chat, Symphony, and Refinitiv Eikon Messenger into trade data that participating desks can review and connect to their existing workflows.
The objective is practical: when a compliance or operations team needs the record behind a transaction, it should not begin with an unbounded search across messaging applications. It should be able to start with the trade, instrument, broker, client, or time window, inspect the extracted terms, and return to the source messages that support them.
MiFID II Article 16 and MiFIR Article 25 address different obligations, but both depend on the firm being able to establish what happened, when it happened, and which financial instrument and parties were involved. A structured chat record gives the compliance workflow an ordered communication trail, traceable fields, and a defined place for unresolved terms to be reviewed. That is the operational difference between retaining messages and retrieving the record of an execution.