joellewis/finance_skills/pre-trade-compliance
Claude Code and agent skill by joellewis/finance_skills
- community
Checking that the SKILL.md file is still in the repository.
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.
Install
npx vskill@latest install joellewis/finance_skills/pre-trade-complianceSKILL.md
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):
When a security is added to the restricted list, the restriction must propagate to related securities. If the parent company is restricted, all subsidiaries, affiliates, and related entities should also be restricted. This requires maintaining an issuer hierarchy that maps corporate relationships. The propagation should cover: common stock, preferred stock, convertible securities, options, warrants, debt securities, and any other instruments issued by or linked to the restricted issuer. Failure to propagate restrictions across the corporate family is a common compliance gap that regulators specifically test for.
Watch list vs. restricted list (different actions):
The watch list contains securities that are under heightened surveillance but not subject to an outright trading prohibition. Watch list securities may be traded, but trades generate alerts for compliance review. The watch list is used when the firm has reason to monitor trading in a security but the information or situation does not rise to the level requiring a full restriction — for example, when the firm is in early-stage discussions about a potential engagement, when rumors are circulating about a company the firm covers, or when an employee has reported a potential conflict. Watch list matches produce soft blocks; restricted list matches produce hard blocks.
Gray list (additional surveillance tier):
Some firms maintain a gray list in addition to the restricted and watch lists. The gray list is used for securities where the firm may soon receive MNPI but has not yet — for example, when an investment banking pitch is in progress but no engagement letter has been signed. Gray list securities are not restricted from trading, but all trades are flagged for post-trade review by the compliance surveillance team. The gray list provides an early warning mechanism and helps establish that the firm had surveillance procedures in place before MNPI was received, which can be important in defending against insider trading allegations.
List maintenance and updates:
Restricted and watch lists must be updated promptly as circumstances change. Stale lists create two risks: (1) securities that should be restricted are not, exposing the firm to insider trading liability, and (2) securities that should have been removed remain restricted, unnecessarily blocking legitimate trading. Best practices include: real-time or daily list updates, automated feeds from deal management systems (for investment banking-driven restrictions), regular review cycles to confirm that all entries remain valid, and audit trails documenting every addition, removal, and modification with the reason and authorizing person.
Concentration Limits
Concentration limits prevent excessive exposure to a single security, issuer, sector, or asset class. These limits serve both risk management and regulatory compliance purposes.
Security-level concentration:
The most common concentration limit restricts the maximum percentage of a portfolio that may be invested in a single security. Typical thresholds range from 5% to 10% of account value for a single equity position. The compliance system must calculate the post-trade position value (current holding plus the proposed order) as a percentage of the account's total value and compare it against the limit. For buy orders, the check is straightforward: will this purchase cause the position to exceed X% of the portfolio? For sell orders in other securities, the check must consider whether the sale changes the denominator (total portfolio value) such that remaining positions now exceed their concentration limits.
Sector and industry limits:
This is the start of the file. Read the full SKILL.md on GitHub.
Security
- Security scanPassed, 95 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingplugins/trading-operations/skills/pre-trade-compliance/SKILL.md
Popularity
- Repository stars
- 161
- Repository forks
- 33
- 7-day trend score
- 25
Stars and forks are for the whole GitHub repository, not this skill alone. Refreshed 2 Aug 2026, 3 months ago.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/joellewis/finance_skills/pre-trade-compliance)