Pre Trade Compliance

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 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 accounts — proprietary, advisory, and personal. The restricted list is maintained by the compliance department, typically with input from the legal department and information barriers (Chinese walls) group. Additions and removals are time-sensitive: a security must be added before MNPI is disseminated within the firm and may only be removed after the information becomes public or the engagement terminates.

Personal trading restricted list:

Access persons — employees with access to non-public information about client trades, portfolio holdings, or investment recommendations — are subject to personal trading restrictions. The personal trading restricted list may include securities that the firm is actively trading for clients (to prevent front-running), securities under active research coverage, and IPO and limited offering securities (which require pre-clearance under SEC Rule 204A-1). Personal trading restrictions operate independently of the firm restricted list and may be more or less restrictive depending on the employee's role.

Client-specific restricted securities:

Individual client accounts may have their own restricted securities lists arising from legal constraints (insider status in a company, divorce decree prohibiting sale of certain holdings), contractual obligations (lock-up agreements), or client preferences (client instructs the firm not to purchase securities of a specific company). These restrictions are maintained at the account level and checked during pre-trade compliance for that specific account.

Issuer restriction propagation (parent/subsidiary):