pre-trade-compliance

What this skill does

# Pre-Trade Compliance

## Purpose
Guide the design and implementation of automated pre-trade compliance systems that validate orders against regulatory rules, firm policies, and client-specific restrictions before execution. Covers compliance rule engines, restricted and watch lists, concentration limits, position limits, hard and soft block configurations, regulatory constraints, and compliance override workflows. Enables building systems that prevent compliance violations while minimizing false blocks that impede legitimate trading.

## Layer
11 — Trading Operations (Order Lifecycle & Execution)

## Direction
prospective

## When to Use
- Designing a pre-trade compliance rule engine for an RIA, broker-dealer, or multi-custodian advisory firm
- Configuring hard blocks and soft blocks for different categories of compliance violations
- Building or maintaining restricted and watch lists, including MNPI-driven restrictions and personal trading lists
- Setting concentration limits at the security, sector, asset class, or issuer level across accounts or households
- Implementing position limits, notional exposure caps, or short selling controls
- Enforcing regulatory rules such as wash sale detection, free-riding prevention, or pattern day trader identification
- Applying client-specific investment restrictions including ESG screens, legal constraints, and frozen account handling
- Designing compliance override workflows with proper authorization, documentation, and escalation
- Adding, modifying, or backtesting compliance rules and tuning false positive rates
- Evaluating the latency impact of compliance checks on order routing and execution speed

## Core Concepts

### Pre-Trade Compliance Architecture
The pre-trade compliance system intercepts orders after generation by the portfolio management system or order entry interface and before routing to custodians or execution venues. The system evaluates each order against a set of rules and either permits the order to proceed, blocks it entirely (hard block), or flags it for review (soft block).

**Rule engine design — sequential vs. parallel evaluation:**

- **Sequential evaluation:** Rules are evaluated in a defined order, and processing stops at the first failure. This approach is efficient when early rules are likely to catch the majority of violations (e.g., checking whether the account is frozen before evaluating concentration limits). Sequential evaluation reduces latency for orders that fail early but provides incomplete diagnostic information — the trader sees only the first violation, not all violations.
- **Parallel evaluation:** All rules are evaluated simultaneously, and the system returns the complete set of results. This approach provides comprehensive diagnostic output — the trader sees every rule that the order violates in a single pass. Parallel evaluation is preferred for advisory workflows where orders are reviewed before submission and the compliance team benefits from seeing the full picture. The tradeoff is higher computational cost per order, though for typical advisory order volumes this is negligible.
- **Hybrid approach:** Critical rules (account status, restricted list) are evaluated first as a fast-fail gate. If the order passes these, the remaining rules are evaluated in parallel. This balances latency with diagnostic completeness.

**Order interception points:**

- **Pre-routing:** The compliance check occurs before the order is transmitted to the custodian or execution venue. This is the primary interception point and catches violations before any market interaction. The order exists only within the firm's systems at this stage.
- **Pre-execution:** For firms with direct market access or algorithmic execution capabilities, a second compliance check may occur after routing but before the order is released for execution. This catches issues that arise from market conditions between routing and execution (e.g., a rapidly changing position that now breaches a limit).
- **Post-aggregation, pre-routing:** For block trades, compliance checks should be applied both at the individual account level (does this account violate its concentration limit?) and at the aggregate block level (does the total block size exceed the security's average daily volume threshold?).

**Hard blocks vs. soft blocks:**

- **Hard blocks** prevent the order from proceeding under any circumstances without first resolving the underlying condition. The order cannot be overridden — it must be modified, canceled, or the blocking condition must be removed (e.g., removing a security from the restricted list, unfreezing an account). Hard blocks are reserved for regulatory requirements and firm policies where no exception is permissible: restricted list violations, trading in frozen or suspended accounts, exceeding regulatory position limits, and trading in securities subject to a legal hold.
- **Soft blocks** generate a warning that requires acknowledgment and documented justification before the order can proceed. Soft blocks are appropriate for guidelines where professional judgment may justify an exception: internal concentration guidelines (as opposed to regulatory limits), watch list matches, minor deviations from model allocation, and trades that trigger an advisory alert (e.g., approaching but not exceeding a limit). Every soft block override must be logged with the identity of the authorizer, the timestamp, and the stated justification.

**Compliance check latency requirements:**

Pre-trade compliance checks must complete within a timeframe that does not materially impair execution quality. For equity and ETF orders where market prices are moving, compliance latency directly affects execution price risk. Target latency benchmarks: single-order compliance check should complete in under 100 milliseconds for real-time trading workflows; batch compliance checks for model-driven trades (hundreds or thousands of orders) should complete within seconds, not minutes. Rule engines that require real-time database lookups (e.g., checking a restricted list stored in an external system) must use caching strategies to meet latency targets. Caching strategies include: loading restricted lists and concentration thresholds into memory at system startup with incremental refresh on change events, pre-computing portfolio metrics (sector weights, issuer exposures) and updating them incrementally as positions change rather than recalculating from scratch for each compliance check, and maintaining in-memory snapshots of account-level compliance state that are updated after each trade rather than queried from the database on every check.

**Rule priority and ordering:**

Rules should be organized by priority to ensure that the most critical checks are evaluated first and that rule interactions are handled correctly. A typical priority ordering is: (1) account status checks (frozen, suspended, closed), (2) restricted list screening, (3) regulatory position limits, (4) regulatory compliance rules (wash sale, free-riding), (5) client-specific restrictions, (6) firm-level concentration limits, (7) model and guideline compliance. When multiple rules fire on the same order, the most restrictive outcome governs — a hard block from any rule overrides soft blocks from other rules.

### Restricted and Watch Lists
Restricted and watch lists are central compliance tools that control trading in securities where the firm or its personnel have conflicts, information advantages, or regulatory obligations.

**Firm restricted list (MNPI-driven):**

The firm restricted list contains securities in which the firm or its affiliates possess material non-public information (MNPI). For broker-dealers with investment banking affiliates, the restricted list is populated when the firm is engaged in an advisory assignment (M&A, underwriting, restructuring) involving a public company. Trading in restricted list securities is prohibited across all firm accoun