Blotter - DominionFX

What is a trade blotter (simple definition)
– A trade blotter is a chronological record of all trading activity for a defined period (typically one trading day). It can be a paper ledger or — more commonly today — a digital file produced by trading software. The blotter lists each executed order and its key details so traders, operations teams, and regulators can reconstruct what happened and when.

Why blotters matter (key functions)
– Create an audit trail: they show who traded what, when, and for how much.
– Support post-trade review: traders use them to check entries, exits and strategy performance.
– Enable operational control: operations staff use blotters to confirm settlements, match fills, and notice cancellations or failures.
– Support compliance and supervision: compliance teams and regulators sort blotters to find unusual patterns (including possible insider trading or departures from declared investment mandates).

Core elements and definitions (jargon defined on first use)
– Trade date/time: timestamp when the trade executed.
– Buy / Sell / Short: direction of the trade.
– Quantity and unit price: number of shares or contracts and price per unit.
– Security identifier: ticker, CUSIP (unique identifier for U.S. securities), or ISIN.
– Settlement date: the date payment and delivery are due.
– Execution venue / ECN: the venue where the order executed; ECN = electronic communication network, an electronic system that matches buy and sell orders.
– Status: executed, canceled, partially filled, failed, etc.
– Accrued interest: interest that has accumulated on a fixed-income instrument since the last coupon payment (relevant for bond trades).

How trade blotters typically work (step-by-step)
1. Capture trade data in real time from order management systems or market feeds.
2. Record each execution as a new row (the blotter is a “blotter of original entry” — i.e., it records original transaction data).
3. Include key fields that operations and compliance require; make additional optional fields available for traders (notes, strategy tag, client ID).
4. Reconcile blotter entries at day end against clearing/settlement reports; flag mismatches for investigation.
5. Archive blotters for the required retention period so they’re available for audits.

Practical uses (short list)
– Daily performance review and trading-journal replacement for active traders.
– Sorting and querying by security

, counterparty, or client; generating settlement instructions; and feeding P&L and risk systems for intraday monitoring.

Operational and compliance uses (short list)
– End-of-day reconciliation against clearing firm and custodian reports to confirm position, cash, and settlement status.
– Audit trail for trade allocation, client disclosure, and regulatory inspection (shows who entered/approved each row).
– Surveillance for wash trades, layering, insider trading patterns, or exceptions to best-execution policies.
– Evidence for trade amendment history (who changed price/quantity and why).

Key blotter fields (recommended minimum)
– Trade ID (unique), Timestamp (UTC recommended), Trader/user ID.
– Security identifier (ISIN/SEDOL/CUSIP), Symbol, Description.
– Buy/Sell flag; Quantity (signed quantity convention optional); Price.
– Currency, Notional (Quantity × Price), Commission/fees, Net cash.
– Trade date, Settlement date (e.g., T+2), Clearing account/custodian, Counterparty.
– Execution venue, Order ID, Strategy or ticket tag, Compliance flags, Notes/audit trail.

Formulas and worked examples
1) Equity trade net cash (buy):
– Formula: Net Cash = Price × Quantity + Commission + Fees
– Example: Buy 1,000 shares of XYZ at $23.50, commission $12.50, fees $2.50.
– Gross = 23.50 × 1,000 = $23,500.00
– Net Cash = 23,500.00 + 12.50 + 2.50 = $23,515.00 (cash outflow)

2) Realized profit/loss for a closed position:
– Formula: Realized P/L = (Sell Price − Buy Price) × Quantity − Total Commissions
– Example: Bought 1,000 XYZ at $23.50 (commissions $12.50), sold 1,000 XYZ at $24.80 (commissions $12.50).
– Gross P/L = (24.80 − 23.50) × 1,000 = $1,300
– Commissions total = 12.50 + 12.50 = $25.00
– Realized P/L = 1,300 − 25 = $1,275.00

3) Bond trade — accrued interest (AI)
– Definition: Accrued interest is the interest that has accumulated on a bond since the last coupon payment and is paid by the buyer to the seller when the bond is traded between coupon dates.
– Formula (simple day-count): AI = (Coupon Rate / Payments per year) × (Days since last coupon / Days in coupon period) × Par
– Example: 5.00% annual coupon, semiannual payments (2), par $1,000, days since last coupon 60, coupon period 182 days.
– Coupon per period = 0.05 / 2 × 1,000 = $25
– AI = 25 × (60 / 182) ≈ $8.24

Best practices checklist for building and using blotters
– Use immutable unique trade IDs and record create/modify audit stamps.
– Capture timestamps in UTC and record the time zone of external systems.
– Standardize identifiers (ISIN/CUSIP) and use controlled reference data.
– Automate feeds from OMS/OMS (order management system) and market data to reduce manual entry errors.
– Reconcile intraday and end-of-day automatically; produce exception reports.
– Retain full change history (who/when/why) for regulatory and audit needs.
– Implement role-based access controls and encrypt stored blotters that include sensitive client data.

Common errors and how to avoid them
– Mismatched settlement dates: enforce

– Mismatched settlement dates: enforce a standardized settlement calendar and validate settlement dates against the trade-date plus the instrument’s required settlement lag (e.g., equities commonly T+2, where T = trade date). Implement a rule that automatically adjusts for weekends and market holidays and flags any trade whose stated settlement date ≠ computed settlement date.

– Incorrect or missing security identifiers: require at least one global identifier (ISIN, CUSIP, SEDOL) and a secondary identifier where useful. Validate identifiers against a reference-data source and reject free-text descriptions. Flag and quarantine any trade with unresolved identifier mapping.

– Duplicate trades: prevent duplicates with an immutable, system-generated unique trade ID plus a secondary dedupe check (hash of core fields: timestamp, instrument ID, side, quantity, price, counterparty). Generate an immediate exception when the same hash appears twice within a configurable time window.

– Wrong side (buy vs sell) or sign errors: enforce sign rules (e.g., buy = positive quantity, sell = negative or a dedicated side field). Add a pre-clearing check that multiplies price × quantity and flags negative notional where not expected.

– Late or missing block allocations: require block trades to carry an “allocation-by” deadline (time or event, e.g., before opening or within X minutes of execution). Auto-notify allocators and lock allocations after the deadline; record who allocated and when.

– Incorrect commissions, fees, or rate types: standardize fee types (per-share, per-trade, percentage) and validate calculations against fee schedules. Flag rounding anomalies and outliers relative to historical benchmarks.

– Wrong counterparty or venue codes: validate counterparty IDs and venue codes against approved lists. Reject or flag trades referencing unknown or deprecated codes.

– Missing regulatory flags or trade modifiers: require specific fields (e.g., short-sale indicator, odd-lot, special settlement, principal vs agency) depending on instrument and jurisdiction. Build rule-based checks that add or require flags before a trade is considered complete.

– Timezone and timestamp inconsistencies: capture all timestamps in UTC and record the original timezone/source. Reject or normalize timestamps that fall outside trading hours for the venue unless a valid crossed-market justification exists.

– Manual overrides without audit trail: disallow blind edits. Every manual change must create a new immutable record of the change including user ID, timestamp, and rationale. Produce a daily report of manual edits for compliance review.

– Misallocated quantities across subaccounts: reconcile block allocation quantities to sum to the block’s executed quantity before settlements are released. Automatically prevent settlement instructions if allocations don’t net correctly.

– Data-format and rounding errors (currency, decimals): enforce numeric formats and currency codes (ISO 4217). Convert and round using documented rules (e.g., to two decimals for USD cents) and log conversions.

Quick troubleshooting checklist (what to run immediately when an exception appears)
1. Identify type: settlement, identifier, duplicate, or calculation error.
2. Pull authoritative source: OMS/EMS record, execution report, counterparty confirmation.
3. Recompute expected values (settlement date, notional = qty × price, commission).
4. Check reference data: identifier mapping, currency exchange rates, settlement calendar.
5. Correct via controlled workflow: if change needed, create a new versioned record noting who/why; if trade is rejected, mark and notify downstream systems.
6. Reconcile to clearing/settlement instructions and confirm with the counterparty if necessary.
7. Log the incident and remedial action for audit and for root-cause analysis.

Worked numeric example — settlement date mismatch
– Scenario: Equity trade executed on 2025-09-01 (Monday). Firm policy: equities settle T+2.
– Computed settlement date = trade date + 2 business days.