PDT Rule Compliance for Automated Trading

An automated trading bot complies with the Pattern Day Trader (PDT) rule by maintaining a real-time count of day trades within a rolling five-business-day window. This count is checked and enforced as a hard gate before any order is submitted to the broker. If submitting the order would result in a PDT violation (four or more day trades in five rolling business days in a margin account under $25,000 equity), the order is blocked and never sent.

What went wrong

Our initial implementation of PDT rule compliance was reactive. We relied on the broker to flag and reject trades that violated the PDT rule. This meant that a violating trade was sent to the broker, only to be rejected. While the broker's rejection prevented the trade from executing, it still represented a failed attempt. For an automated system, this is unacceptable. A failed order attempt can trigger downstream logic errors, create confusion in our internal state tracking, and, most importantly, it means the system is not operating as intended. The cost was not financial loss from trades, but the operational overhead of debugging and correcting these unexpected rejections, and the erosion of confidence in the system's reliability.

Why it happens

The PDT rule is fundamentally a counting problem with a specific, rolling window. The rule flags an account as a pattern day trader at four or more day trades — a buy and sell of the same security on the same day — within five rolling business days in a margin account under the $25,000 equity threshold. The complexity arises from the "rolling" nature of the window. It's not a fixed calendar week; it's five business days that continuously shift. This means the count needs to be recomputed on every potential day trade, not just reset on a fixed schedule. Furthermore, a user can have multiple accounts across different brokers. The PDT rule applies per broker account, not per user. Therefore, the count must be tracked per resolved broker account. Finally, account equity fluctuates. An account can cross the $25,000 threshold in either direction between trading sessions. This means the equity level must be read from the broker at the precise moment the PDT check is performed.

What we changed

We shifted PDT rule enforcement from a post-trade rejection to a pre-trade, hard gate within our system's risk layer. This means the PDT check runs before an order is submitted to the broker. The process involves several key components:

1. Per-Broker Account Tracking: We maintain a separate PDT trade count for each unique, resolved broker account. This ensures compliance is enforced at the correct level.
2. Rolling Window Calculation: For each potential day trade, we query our historical trade data for that specific broker account. We count the number of completed day trades (buy and sell of the same security on the same day) within the last five rolling business days. This requires careful handling of business days versus calendar days.
3. Equity Check: At the time of the PDT check, we fetch the current equity for the relevant broker account. If the equity is below the $25,000 threshold, the PDT rule is active.
4. Pre-Trade Gate: If the trade is a day trade, and the count within the rolling window is already three or more, and the account equity is below $25,000, the system blocks the order. This prevents a fourth day trade from being sent, thus avoiding a PDT violation.
5. Unified Risk Layer: This PDT gate sits alongside our other pre-trade risk checks, such as position limits, sector exclusions, daily loss limits, and circuit breakers. All these checks operate within the same risk layer, meaning a single rejection path handles all pre-trade violations. This simplifies our architecture and error handling.
6. Auditable Rejections: Every rejected trade, including those blocked by the PDT rule, is logged with a specific reason. This audit trail is crucial for debugging and understanding why a trade was not sent, making silent blocking issues debuggable.

How to check your own system

To ensure your automated trading system complies with the PDT rule, perform the following checks:

• Pre-Trade Enforcement: Verify that your system checks for PDT rule violations before sending any order to the broker. A rejected order by the broker is a sign of a potential gap in your pre-trade logic.
• Per-Broker Account Logic: Confirm that your PDT trade counts are tracked and enforced on a per-broker account basis, not globally per user.
• Rolling Window Implementation: Test your system's ability to correctly calculate day trades within a rolling five-business-day window. Ensure it handles weekends and holidays appropriately.
• Dynamic Equity Check: Validate that your system reads the account's current equity from the broker at the time of the trade check, not relying on stale data from previous sessions.
• Audit Logging: Ensure that all blocked trades, with clear reasons for the block, are logged for later analysis and debugging.

By implementing these checks proactively, you can prevent costly operational issues and ensure your automated trading systems operate within regulatory requirements.

Disclaimer

This article describes engineering decisions in a trading system. It is not investment advice. Trading involves substantial risk of loss and is not suitable for all investors. Past performance does not guarantee future results. Always do your own research and consider your financial situation before trading.