A pre-trade checklist is the last verification layer between a prepared plan and a live order. It should not invent a setup or talk you into a trade. It should verify seven things that must already be defined: setup, invalidation, size, payoff, timing, event/account constraints, and execution readiness.
Run it against visible evidence. If an item cannot be verified, the result is not “close enough”; it is not ready. That can mean skip the trade, correct the order, reduce risk, or return the idea to research.
The 7-point protocol: (1) named setup and version, (2) entry/invalidation/order defined, (3) account risk and size calculated, (4) target and net expectancy plausible, (5) timing/liquidity permitted, (6) scheduled events and account rules checked, and (7) execution state clear. Verify each item; do not replace a failed rule with conviction.
What an Execution Checklist Can—and Cannot—Do
A checklist is a forcing function for critical, repeatable checks. FAA human-factors research distinguishes a “do-list,” which directs a sequence, from challenge–verification–response, which verifies that actions already performed are correct. A pre-trade protocol is strongest in the second role: the plan creates the trade; the checklist verifies it. See the FAA-hosted flight-deck checklist research.
It cannot prove that a setup has edge, make an event outcome predictable, guarantee a stop fill, diagnose a mental-health condition, or rescue undefined rules. Build the underlying decision system first with a written trading plan.
The 7-Point Pre-Trade Checklist
| Gate | Evidence required | Fail action |
|---|---|---|
| 1. Setup | Named setup, rule version, market and direction | Send an unclassified idea to research |
| 2. Order | Entry condition, invalidation, order type, exit instructions | Define them before exposure |
| 3. Risk | Account state, risk budget, per-unit risk, quantity, portfolio overlap | Resize or skip |
| 4. Payoff | Target logic, net reward/risk, costs, strategy expectancy context | Reject a late or cost-eroded entry |
| 5. Timing | Permitted session, liquidity, spread and data state | Wait for an allowed condition |
| 6. Events and rules | Scheduled events plus exact broker/prop/account restrictions | Apply the written event or account response |
| 7. Readiness | No loss-chasing, urgency override, platform ambiguity, or unresolved order | Pause, reconcile, or end the session |
1. Verify the Setup, Not the Story
Name the saved setup and its version. Confirm each required condition from observable data. “Looks like a breakout” is not enough if the setup requires a close, retest, volume condition, or specific session. Record the market and direction so the decision can later be reconstructed.
A new pattern can be interesting without being live-ready. Capture it as a hypothesis. The checklist should keep curiosity from becoming an untested position.
2. Define Entry, Invalidation and the Actual Order
Write the entry trigger and the price or condition that invalidates the trade. Then choose the order instructions that express those rules on this venue. A stop price is not always a guaranteed fill price, and a limit price controls price but may not fill. Order behavior and names can differ by broker and venue.
The SEC’s current order-types bulletin explains those trade-offs for securities. For futures, forex, crypto, options, and a specific platform, verify the venue’s own documentation rather than assuming identical behavior.
Also confirm there is no unresolved order from a previous attempt. If a cancel or replace is uncertain, reconcile platform state before sending another instruction.
3. Calculate Risk and Position Size
Start from the account’s permitted risk budget, not desired profit. Estimate risk per unit from entry-to-invalidation distance, tick or point value, commissions, fees, and a defensible allowance for slippage or gaps. Then calculate:
quantity = floor(permitted account risk ÷ estimated risk per unit)Check minimum lot or contract size, leverage, margin, currency conversion, and correlated exposure. If one unit already exceeds the budget, the valid quantity is zero. The risk-per-trade guide connects this calculation to daily and account-level limits.
The checklist verifies the inputs; it does not choose a universal risk percentage. If the stop or cost model is missing, the size is not known.
4. Check Payoff in the Strategy’s Own Context
Confirm the target or exit logic and calculate net reward relative to the estimated risk. Do not use a universal reward-to-risk threshold detached from win probability, exit distribution, costs, partials, and market state. Breakeven arithmetic is a floor, not proof of positive expectancy.
This gate is particularly useful after price has moved away from the planned entry. Recalculate with the actual achievable entry and current costs. If the trade no longer matches the tested rule, a beautiful chart does not restore it.
5. Verify Timing, Liquidity and Market State
Check that the market is open for the intended product, the strategy permits this session, data are current, and spread or depth has not invalidated the execution model. A personal time filter should come from a defined strategy or adequately tagged journal evidence—not a generic claim that one session is best.
For swing trades, this gate also covers overnight risk, earnings or contract events, and whether the order duration matches the plan. It is not a separate swing-trading strategy or stock recommendation.
6. Check Scheduled Events and Exact Account Rules
Consult authoritative calendars or notices for the events your plan covers. Do not hardcode a universal “no trading within 30 minutes” rule: some strategies exclude events, some trade them, and the relevant window varies. The decision must be written before the release. The economic-calendar guide shows how to convert an event into a rule rather than a prediction.
On a funded or restricted account, verify the exact program, phase, region, account size, daily/max-loss calculation, consistency or concentration rule, holding restrictions, platform limits, and any prohibited practice. A generic prop-firm rule is not evidence for the account in front of you.
7. Confirm Execution Readiness
Use observable questions rather than asking only whether you “feel calm.” Are you increasing size to recover a loss? Re-entering without a new setup? Racing a countdown that the strategy never defined? Trading after a daily stop? Unsure whether the last order filled? Deviating because someone else posted a call?
Any yes answer activates the prewritten response: pause, reduce, reconcile, or stop. The revenge-trading protocol provides a stricter branch for loss-driven re-entry. A checklist is a process control, not medical assessment.
Use Challenge–Verify–Respond, Not Box-Ticking
- Challenge: read the gate exactly as written.
- Verify: inspect the chart, account state, calculator, calendar, platform, or plan field that answers it.
- Respond: record pass, fail, or not verified. Do not answer from memory when current state is available.
- Act: execute only the action attached to that response.
A fixed ten-second pause is optional, not a scientific constant. The useful delay is long enough to finish verification and short enough to fit the strategy. If the setup cannot survive that latency, move the checks earlier or automate them; do not pretend they were performed.
Design an Override Policy Before the Exception
Some checklist items are hard account or risk limits and cannot be overridden. Others may have a documented exception path. Mark the distinction in advance. A valid exception names the authorizing rule, evidence, owner, and expiry; “this one looks unusually good” is not an exception.
Log every failed gate and every attempted override, including skipped trades. Do not score hypothetical P&L as though it were an executable fill. Review which gates fire, which are ambiguous, and whether the checklist is catching known errors or merely adding ritual.
Implement the Checklist Where the Order Happens
- Physical card: useful while the wording is being tested; mark the evidence, not just the answer.
- Digital form: faster to revise and timestamp, but should not default every item to pass.
- Journal-integrated protocol: preserves setup version, inputs, result, and later review in one evidence chain.
- Automated preflight: appropriate for systematic orders, with logs for data health, limits, order state, and kill-switch behavior.
Start with the shortest list that covers critical failures. Add an item only when it maps to a real decision and a defined fail action. Remove duplicated or decorative checks.
Worked Example: A Valid Setup That Still Fails Preflight
Assume a trader sees a saved pullback setup on a permitted market. The setup conditions are visible and match version 4 of the rule. That passes Gate 1, but it does not authorize the trade by itself.
- Setup: the market, direction, structure, and trigger match the saved definition. Pass.
- Order: the entry and invalidation are defined, but the platform is configured with a stop-limit instruction while the tested strategy assumes a stop that becomes a market order. The execution behavior differs from the evidence model. Fail until corrected or explicitly tested.
- Risk: after using the intended order behavior, the entry-to-stop distance and estimated costs make the smallest tradable unit larger than the remaining daily risk budget. Fail; valid quantity is zero.
- Payoff: not evaluated as permission because Gate 3 already failed. A large target does not repair an oversized minimum unit.
- Timing: the session is permitted and data are current. Pass.
- Events and rules: no relevant scheduled exclusion applies, but the exact account daily-loss state still blocks new exposure. Fail.
- Readiness: the trader notices an urge to reduce the stop distance solely to manufacture a permissible quantity. That would change the setup. The predefined response is to record the failed opportunity and stand down.
The important lesson is that “valid setup” and “valid order now” are separate claims. The checklist prevented an execution-model mismatch, a risk-budget breach, and an unlogged rule change. It did not establish what the skipped trade would have earned or lost.
Make Every Answer Auditable
A yes/no result without its source is fragile. The useful record stores the answer beside the evidence used at decision time. For Gate 1 that may be a setup ID and chart timestamp. For Gate 3 it is the account-risk snapshot and size calculation. For Gate 6 it is the calendar or rule snapshot with its timezone and verification time.
| Record field | Minimum content | Review question |
|---|---|---|
| Protocol version | ID and effective date | Which checklist governed the order? |
| Gate response | Pass, fail, not verified, or documented exception | Was ambiguity hidden as a pass? |
| Evidence pointer | Rule, calculation, snapshot, notice, or current platform state | Can another reviewer reconstruct the answer? |
| Fail action | Skip, wait, resize, reconcile, stop, or research | Was the prescribed action followed? |
| Override record | Authorizing rule, reason, owner, expiry | Was this a real exception or post-hoc permission? |
| Order confirmation | Submitted instruction, fill or rejection, fees, final protective state | Did live execution match the intended order? |
Do not prefill the response as “pass.” Defaults should require a current selection, and critical values should be copied from the calculator or account state where the platform safely supports it. For manual workflows, keep the record short enough to complete honestly.
Calibrate the Protocol From Failures, Not From One Outcome
Review the checklist on a fixed cadence and after material errors. Count missing responses, failed gates, overrides, duplicate orders, size corrections, event-rule blocks, and cases where the submitted order did not match the intended instruction. Keep outcome metrics beside these process measures, not in place of them.
A gate deserves revision when its wording is ambiguous, its evidence cannot be retrieved in time, it duplicates another control, or it repeatedly passes while the underlying failure still occurs. A gate does not deserve deletion merely because a skipped trade later looked profitable. That is outcome knowledge unavailable at the decision time.
When the strategy, venue, account program, platform, or order type changes, version the protocol. Do not compare old and new trades as if the same checks governed both. For automated systems, replace manual questions with preflight assertions and retain logs for data freshness, exposure, account limits, open orders, connectivity, and kill-switch state.
Keep both failed and passed records. If only completed trades enter the journal, the review cannot tell whether a gate is protecting the process or simply never being used. A short reason code for every blocked opportunity makes the checklist itself testable without pretending that hypothetical fills are real trades.
How TSB Makes the Protocol Reviewable
Trader’s Second Brain can attach the seven responses to the trade record with account, setup/version, entry, stop, target, risk, session, notes, and imported execution fields when present. The weekly review can then compare passed, failed, missing, and overridden gates against rule adherence and outcomes.
Coach can summarize selected evidence and surface recurring missing gates or override tags. That is a strong use of Coach: it turns a long journal into inspectable questions. It should qualify or refuse a verdict when the checklist was not recorded, the selected cohort is too thin, or the user asks it to infer psychology or causality that the data do not contain.
TSB recognizes 328 exact import profiles and has normalized 600K+ imported trades. These figures mean import coverage and imported trade volume—not users, checklist compliance, the sample for this article, or evidence of performance improvement.
TSB is our product. We disclose that ownership because this guide recommends its journal and Coach workflow.
Methodology Note
- Checklist evidence: the verification model is bounded to FAA-hosted human-factors research; aviation outcomes are not presented as trading outcomes.
- Order facts: price and fill caveats use current SEC investor guidance and explicitly require venue-specific verification.
- Removed claims: fixed cognitive timings, universal event windows, compliance/P&L percentages, trader-population frequencies, deterministic override cascades, and experience cutoffs were not retained.
- Product facts: TSB journal fields, Coach evidence boundaries, and canonical import markers were checked against current server code.
For our evidence and correction process, see the editorial methodology.
Final Verdict: Seven Verified Gates Before Exposure
A checklist works when every item has evidence and a fail action. Verify setup, order, risk, payoff, timing, events/account rules, and readiness. Keep hard limits hard. Route new ideas to research. Recalculate from current market and account state.
The goal is not perfect discipline or guaranteed profit. It is a timestamped decision that can be reconstructed, audited, and improved after the trade.