/pre-trade-compliance

name: pre-trade-compliance
description: "Guide the design and implementation of automated pre-trade compliance systems that validate orders before execution. Use when building a compliance rule engine for an RIA or broker-dealer, configuring hard blocks and soft blocks, maintaining restricted and watch lists including MNPI-driven restrictions, setting concentration limits at security/sector/issuer level, implementing position limits or short selling controls, enforcing wash sale detection or free-riding prevention or pattern day trader identification, applying client-specific ESG screens or legal constraints, designing compliance override workflows with authorization and documentation, backtesting compliance rules, or evaluating compliance check latency impact on execution quality."

Pre-Trade Compliance

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 ha