Project Record

Compliance Tool for Bond Trade Labeling

Open in an AI assistant with a suggested prompt

Preview prompt

Summarize the Ionitsa project record titled "Compliance Tool for Bond Trade Labeling" for a technical reader.
Cover the problem or research question, implementation or method, evidence or results, and limitations.
Separate facts stated on the page from your own assessment, note anything unclear or unverified, and avoid promotional language.

Primary source: https://ionitsa.com/projects/compliance-bond-trade-labeling.md
Canonical page: https://ionitsa.com/projects/compliance-bond-trade-labeling/

Hedge fund compliance system for labeling bond execution quality across Bloomberg, Markit, dealer quote, and trade-print benchmarks.

Domains

Hedge FundCreditCompliance

Capability

Controls & Reconciliation

Methods

ScoringExecution AnalysisControlsMarket Data NormalizationBenchmark Selection

Executive Summary

Compliance teams reviewing bond executions need a consistent way to judge whether a trade was done well relative to market. For liquid equities this is often straightforward, but corporate and sovereign bonds trade over the counter, with price evidence spread across evaluated marks, composite quotes, RFQs, dealer axes, and recent trade prints. A single mid-price can be useful, but it is rarely the whole market.

I built a labeling system that normalized multiple fixed-income pricing sources, including Bloomberg-style evaluated and composite prices, Markit/S&P evaluated bond prices, dealer quotes, RFQ data, and recent execution prints. The system selected an appropriate benchmark for each trade, computed side-aware slippage in basis points, and mapped the result to favorable, fair, unfavorable, or review-needed labels.

The output fed dashboards, regulatory reports, and exception queues. Compliance users could see not only the final label, but also the benchmark source, price timestamp, bid/mid/ask context, and reason a trade was escalated.

This demonstrates fixed-income execution analysis, market-data normalization, benchmark selection, compliance controls design, and basis-point scoring for bond operations.

Problem

Raw execution data does not indicate whether a bond trade was done well. A trade record may contain instrument, side, size, price, trader, counterparty, and timestamp, but the compliance question depends on the price evidence available at the time of execution.

We need a rule that (1) normalizes competing market-data sources, (2) selects a benchmark appropriate for the bond and execution context, (3) computes side-aware cost in bps, and (4) maps the result to a small set of labels for reporting and escalation.

The core difficulty is that the benchmark is itself a model choice. Bloomberg and Markit marks can disagree; dealer quotes can be stale or one-sided; prints may be real but small or off-market; and illiquid bonds may require curve or spread-implied estimates rather than direct executable prices.

Market Data Benchmarks

For each bond execution, the system collected candidate reference prices from the sources available for that instrument and time window:

Bloomberg evaluated prices: BVAL-style bid, mid, and ask marks where coverage exists.
Bloomberg composite or dealer quote views: composite bid/ask indications and dealer-contributed quote context when available.
Markit/S&P evaluated bond pricing: independent evaluated prices and multi-source reference marks used for cross-checking.
Trade prints and recent executions: observed market trades, especially useful for liquid bonds when size and recency are comparable.
RFQ and dealer runs: timestamped quotes, axes, or RFQ responses when attributable and close enough to execution time.
Curve, spread, or matrix-implied marks: fallback estimates for stale, illiquid, or sparsely quoted bonds.
Secondary execution benchmarks: VWAP, arrival price, or a time-window mid for larger orders or multi-fill execution review.

Each benchmark type has a different evidentiary meaning. An evaluated price is broad and stable, but may lag the market. A dealer quote may be closer to executable liquidity, but can be one-sided or stale. A recent trade print is real, but may be too small, too old, or from a different liquidity context.

Benchmark Selection

Each candidate price is normalized into a common tuple:

b_i = (\text{source}_i,\; P^{bid}_i,\; P^{mid}_i,\; P^{ask}_i,\; t_i,\; q_i,\; s_i)

where $\text{source}_i$ is the vendor or evidence type, $P^{bid}_i$ , $P^{mid}_i$ , and $P^{ask}_i$ are available price levels, $t_i$ is the price timestamp, $q_i$ is a confidence or quality score, and $s_i$ is a staleness measure.

The selected benchmark is the highest-quality usable candidate after applying source hierarchy, recency, liquidity, and side-aware availability checks:

\hat{b} = \arg\max_{b_i \in B} \; w_{src}(b_i) + w_q q_i - w_s s_i - w_o o_i

where $w_{src}$ encodes source preference, $w_q$ rewards confidence, $w_s$ penalizes stale prices, and $w_o o_i$ penalizes outliers relative to the available price cluster.

The side-aware reference price is:

P_{ref} = \begin{cases} P^{ask}_{\hat{b}}, & \text{buy trade and ask available} \\ P^{bid}_{\hat{b}}, & \text{sell trade and bid available} \\ P^{mid}_{\hat{b}}, & \text{otherwise} \end{cases}

This keeps the rule conservative for compliance review. A buy should generally be compared against the ask-side liquidity that was available, while a sell should be compared against bid-side liquidity. Mid-price remains a useful fallback, but it is not treated as the only truth.

Labels

The system computes side-adjusted execution cost in bps:

\text{cost}_{bps} = \begin{cases} \frac{P_{exec} - P_{ref}}{P_{ref}} \cdot 10^4, & \text{buy} \\ \frac{P_{ref} - P_{exec}}{P_{ref}} \cdot 10^4, & \text{sell} \end{cases}

Positive cost means worse execution after accounting for side: a buy paid above the reference level, or a sell traded below it. Negative cost means favorable execution relative to the selected benchmark.

Trades are mapped to a controlled label set:

Favorable: execution improves on the side-aware benchmark beyond the favorable threshold.
Fair: execution falls inside the configured tolerance band.
Unfavorable: execution breaches the tolerance band in the costly direction.
Review-needed: the benchmark is stale, contradictory, missing, or based on weak evidence.

Thresholds are configurable by market, desk, liquidity bucket, rating bucket, or instrument type. For example, a liquid investment-grade bond can use a tighter tolerance than a distressed or thinly quoted high-yield bond.

Implementation

Inputs: execution records with instrument, side, size, price, trader, counterparty, and execution time; Bloomberg pricing snapshots; Markit/S&P evaluated prices; optional RFQ, dealer quote, and trade-print data.
Normalization: mapped each source into a common bid/mid/ask schema with source, timestamp, confidence, and stale-price indicators.
Time alignment: joined execution records to the nearest usable benchmark inside configured windows, with stricter windows for liquid bonds and wider review bands for illiquid names.
Quality checks: flagged stale marks, crossed or inverted bid/ask levels, vendor disagreements, outlier prices, missing side-specific prices, and benchmarks that moved materially after execution.
Benchmark selection: chose the strongest available benchmark according to source hierarchy, recency, liquidity, confidence, and side-aware price availability.
Scoring: computed bps cost against the selected benchmark, applied desk or liquidity thresholds, and assigned favorable, fair, unfavorable, or review-needed labels.
Outputs: labeled trades for compliance dashboards, regulatory reports, and exception queues, with the chosen benchmark and supporting price evidence retained for audit.

Trade-offs

No single price source is always authoritative for bonds. Bloomberg and Markit can differ because they use different coverage, evaluated-pricing methodology, timing, contributor depth, and liquidity assumptions. That difference is useful rather than merely inconvenient: when two independent marks agree, the label is stronger; when they diverge, the trade is often worth reviewing.

Mid-price is clean and easy to explain, but it can hide liquidity cost. A trade at mid may be excellent in a wide market, while a trade a few bps away from mid may be poor for a liquid issue with tight executable quotes. Bid/ask context is therefore more informative for compliance than mid alone.

Trade prints and RFQs add market realism, but they also introduce comparability problems. Size, timestamp, counterparty, venue, and quote firmness all matter. I treated these sources as high-value evidence when they were fresh and comparable, and as review context when they were not.

The safest operational design is conservative: automatically label clear cases, retain the benchmark evidence, and route ambiguous or illiquid cases to review. The goal is not to pretend that every bond has a precise executable fair value; it is to make execution review consistent, explainable, and auditable.