Project Record

Bloomberg Trade Message Parser

Hedge fund trade-capture parser that converts semi-structured Bloomberg IB messages into normalized trade events across multiple asset classes.

Domains

Hedge FundExecutionPost Trade

Capability

Market Data Engineering

Methods

Regex ExtractionClassificationNormalizationTrade Capture

Executive Summary

In many hedge fund workflows, the first record of a trade is not a clean database row. Traders and operations teams communicate executed trades through Bloomberg IB messages, using semi-structured templates that vary by desk, trader, asset class, and instrument type. Those messages contain the economic intent of the trade, but they must be interpreted before they can support controls or downstream reconciliation.

I worked on a parser that converted raw Bloomberg trade messages into normalized trade events. The system treated each incoming message as a text stream, classified the likely instrument type, and extracted the fields needed to compare trader communication with booking-system records.

The parser covered multiple asset classes, including bonds, CDS, CDX indices, equities, and other products. It used a waterfall-style rule engine: specific and complex instrument patterns were evaluated before simpler generic rules, reducing false matches when different instruments shared similar wording or abbreviations.

This created a structured trade-event layer from front-office communication. It demonstrates financial text parsing, instrument-aware classification, regex extraction, and operational data normalization for hedge fund trade capture.

Problem

Bloomberg IB messages are semi-structured rather than schema-enforced. A message may include trader names, execution time, instrument description, settlement convention, side, price, and quantity, but the order and wording of those fields varies across desks and products.

The parser must solve two linked tasks:

Classify the likely instrument family represented by a raw message string.
Extract the instrument-specific trade parameters into a normalized schema.

A flat parser is fragile because several products share overlapping terminology. For example, a bond message and a CDS message may both contain issuer names, maturities, spreads, currencies, and settlement references, while a CDX index trade may resemble a credit derivative message but require different fields.

Waterfall Classification

Let $m$ be the raw Bloomberg message and let $\mathcal{R} = (r_1, r_2, \ldots, r_n)$ be an ordered list of parsing rules. Each rule $r_i$ has:

r_i = (\text{instrument}_i,\; \text{predicate}_i,\; \text{extractor}_i)

where $\text{predicate}_i(m)$ tests whether the message fits an instrument pattern and $\text{extractor}_i(m)$ returns the structured fields for that product.

The rules are ordered from the most specific to the most generic:

\hat{r}(m) = \min_{r_i \in \mathcal{R}} \{ i : \text{predicate}_i(m) = 1 \}

This waterfall structure matters because generic rules can otherwise capture messages that should be handled by a more precise instrument parser. The system first tests complex credit and fixed-income templates, then falls back to broader patterns only when no specific rule matches.

Extraction Schema

The normalized output is a trade-event record:

t = (\text{source},\; \text{trader},\; \text{timestamp},\; \text{instrument},\; \text{side},\; \text{quantity},\; \text{price},\; \text{settlement},\; \text{attributes})

Core fields were shared across products, while attributes held instrument-specific details such as coupon, maturity, reference entity, index series, tenor, currency, or security description.

The parser used product-specific regex templates and rule-based normalization:

Bonds: issuer, coupon, maturity, currency, quantity, price, settlement date, and security identifiers where present.
CDS: reference entity, tenor, spread or upfront, currency, direction, and settlement convention.
CDX indices: index family, series, version, tenor, notional, spread, and roll details.
Equities: ticker or issuer, side, quantity, price, exchange or settlement cues.

Implementation

Input: raw Bloomberg IB message strings, including trader communication and template-style trade confirmations.
Classification: ordered instrument rules, starting with the highest-ambiguity products and ending with simpler fallback patterns.
Extraction: regex-driven field recovery with product-specific normalization of dates, prices, quantities, and settlement conventions.
Validation: missing or contradictory fields were flagged rather than silently coerced.
Output: normalized trade-event records suitable for comparison with booking-system records and reconciliation pipelines.

Trade-offs

Rule-based parsing is transparent and fast to tune when message templates are known. That transparency is valuable in trade-capture controls, where operations teams need to understand why a message was classified in a certain way.

The cost is maintenance. New trader templates, desk conventions, or instrument variants can break assumptions. The waterfall design reduces false positives, but it also means rule order becomes part of the system logic and must be tested carefully when adding new products.

The parser is therefore best understood as an operational extraction layer: it turns messy communication into a structured view of trader intent, while keeping uncertain cases visible for review.