Forex Trade Journal — R-Multiple, Expectancy, SQN, and MAE/MFE

A trading journal should help explain decisions, rather than simply collect screenshots and results. It needs consistent records of the plan, execution, costs and initial risk to serve that purpose. We show what to record after each trade, how to reconcile the figures with account history and how to calculate R-multiple and other metrics without mixing definitions. The article moves from expectancy and profit factor to drawdown, estimation uncertainty, MAE and MFE. It also explains the limitations of popular indicators and journal tools. Worked examples and a control dataset help you verify calculations before applying them to your own records. The aim is reliable evidence that identifies a problem and supports a decision, rather than a single score that supposedly judges a strategy.

1. Why Without a Journal You Have an Opinion, Not a System

Trading without logging empirical market parameters is an expensive hobby. You do not possess a system; you operate a sequence of arbitrary clicks contaminated by survivorship bias. Under the applicable CFD risk-warning framework discussed in the Polish source, providers publish the percentage of their own retail investor accounts that lose money and update it at least quarterly. This is a jurisdiction-specific disclosure requirement, not a rule assumed to apply to every broker worldwide. The figure from a single broker is not a global market constant, and averaging them is pointless. These figures represent your statistical peers. Without rigorous diagnosis, the vast majority repeat the exact same errors throughout their trading lifespan; experience without measurement is merely repeatable failure.

Three Cognitive Illusions That Destroy Traders Without a Journal

Illusion 1: Selective memory. The human brain prioritizes emotionally charged events (a major windfall, a devastating margin wipeout) while dampening neutral occurrences. After a month, your mind retains perhaps 3 trades out of 50 — typically two spectacular winners and one painful loss. Memory presents these three trades as representative of your entire performance — which they are not. A journal strips away this delusion: black on white, you discover that your "Monday strategy" actually produced 8 wins and 11 losses over the past quarter.

Illusion 2: Post-hoc rationalization. After a losing trade, the brain constructs the convenient narrative: "I knew that setup looked weak." After a winning trade: "I read the market correctly." Both narratives are manufactured after the outcome is known, bearing little resemblance to what you actually knew prior to execution. A journal enforces recording intention before clicking (planned entry, planned SL, setup classification). Comparing pre-trade plans with post-trade execution exposes how many of your "sharp decisions" were genuinely planned versus retroactively invented.

Illusion 3: Aggregate balance instead of distribution. An amateur looks strictly at account equity: "I made 4% in March" — and ceases all analysis. Yet that 4% could be the product of 60 trades with a 55% win rate and +0.3R expectancy (the healthier process in this illustration), or it could stem from 12 trades with a 75% win rate and a single lucky +6R trade masking the fact that the other 11 were unhinged gambling (a fragile process masked by one outlier). Account balance cannot distinguish between these two realities. A journal equipped with proper metrics differentiates them immediately.

The Definition of a Trading System (The One Retail Overlooks)

A trading system is a repeatable process whose results are measurable in standardized units. Three critical criteria define it:

• Repeatable — identical market conditions generate consistent execution decisions. Not "I felt strong bullish momentum," but "conditions A, B, and C were satisfied, triggering rule-based execution."
• Measured — every trade logs 29 fields in the journal; expectancy is calculated per setup, and profit factor is evaluated monthly.
• Standardized units — R-multiple serves as the universal currency of comparison. "I made PLN 200" is completely uninformative (what capital was risked?), whereas "I captured +1.8R" conveys everything.

Without these three pillars, you do not run a system; you engage in disjointed individual gambles lacking a common denominator. You might get lucky (convincing yourself you are skilled) or experience bad variance (concluding the broker manipulated price). Neither conclusion is justified — you simply lack the empirical data required for objective assessment.

Pre-Trade Recording — Eliminating Post-Facto Deception

A second, frequently underestimated function of a journal is operational friction. Logging the execution parameters (planned entry, planned SL, position sizing, setup tier) prior to clicking serves one primary objective: making it harder to deceive yourself after the outcome. If an entry violates your playbook rules, the journal captures it instantly, preventing you from writing "the tape looked bullish." A spreadsheet does not rationalize for you: if you manually dragged your Stop Loss, row 42 logs Error Code 3, regardless of how eloquent an excuse you invent after the session. This is not mere psychology; it is operational friction forcing deliberate reflection before reckless execution occurs.

2. What to Record — 29 Fields of a Professional Trade Journal

An amateur trade journal consists of 5 to 8 basic fields: date, currency pair, direction, entry, SL, TP, outcome, and a brief comment. This represents the absolute bare minimum of a broker account statement, utterly insufficient for systematic diagnostic analysis. A professional trading journal tracks 29 fields organized across 7 functional groups. Every single field answers a distinct analytical question.

Group A: Trade Identification (4 fields)

Foundational metadata — what occurred and exactly when.

1. Trade ID — unique identifier (e.g., T-2026-04-001), enabling cross-referencing in post-trade reviews, scripts, and analytical databases.
2. Open Date and Time — recorded to the minute in a single standardized timezone (UTC recommended, optionally alongside local market time).
3. Currency Pair — EUR/USD, GBP/JPY, etc.
4. Direction — long / short.

Group B: Strategic Context (4 fields)

Your strategic intent, setup structure, and environmental classification.

5. Playbook Setup — specific named setup (e.g., "LON-breakout-A", "NY-mean-revert-B"). Without this field, calculating setup-specific expectancy is mathematically impossible.
6. Setup Tier / Grade — A+, A, B, C. Each tier dictates specific position sizing. Without tier grading, you cannot determine whether you are profitable on A+ setups while leaking capital on B tiers, or vice versa.
7. Market Regime — trending / ranging / high volatility / low volatility — evaluated on D1 or H4 prior to entry.
8. Market Session — Asian / London / New York / London-NY Overlap. Isolates which trading session yields an empirical edge versus which produces consistent losses.

Group C: Order Parameters — Plan vs. Reality (6 fields)

This is where the most unvarnished, brutal truths of retail trade execution emerge.

9. Planned Entry — the exact technical price level where you intended to enter according to pre-trade analysis.
10. Actual Entry Fill — the real fill price executed by the broker (the source uses an illustrative 1–5 pips of slippage on M15; this is an example, not a universal execution benchmark).
11. Planned SL — technical invalidation price where the trade thesis is disproven (dictated by strategy rules).
12. Actual SL Fill — the exact price where the stop order was executed by the liquidity provider (slippage on stop execution can be 2–10× greater than on entry during liquidity vacuums).
13. Planned TP — planned target price or pre-defined R-multiple exit.
14. Actual TP Fill / Manual Exit — actual execution price at target fill or manual discretionary close.

Group D: Friction Costs (4 fields)

Friction costs erode gross theoretical expectancy — exactly how much is revealed solely by your journal, depending on your instrument, broker execution model, and stop width. Without tracking friction, you cannot know whether your edge exists on a net basis.

15. Spread (pips) — live spread at the moment of entry, not the promotional "as low as" spread advertised on broker websites.
16. Entry Slippage (pips) — direction × (actual_entry − planned_entry) / pip_size; a positive value indicates adverse slippage (a worse fill than planned).
17. Exit Slippage (pips) — direction × (planned_exit − actual_exit) / pip_size. Note the mathematical sign inversion: for a long position, adverse entry is a price higher than planned, whereas adverse exit is a price lower than planned. The intended convention is consistent on both sides: adverse slippage is positive and favorable slippage is negative. Reusing the entry subtraction order on exit reverses that meaning for exits.
18. Swap and Commission — denominated in account currency, accounting for overnight financing and ECN turn costs.

Group E: PnL and Performance Metrics (3 fields)

19. Gross PnL — in pips and account currency, calculated from executed price fills excluding financing and commissions.
20. Broker Net PnL — statement PnL after deducting commissions and swap; spread and slippage are already embedded in the fill prices, so do not subtract them a second time.
21. Net R-Multiple — broker_net_pnl / planned_risk (formalized in Section 3).

Group F: Decision Quality Scoring (4 fields)

This group is the most frequently ignored — yet the most diagnostically powerful. Two trades can yield identical financial returns while representing vastly different decision quality.

22. Error Classification — categorical taxonomy: 0 = no error (flawless process), 1 = stop loss placed too wide, 2 = stop loss placed too tight, 3 = stop moved against plan, 4 = premature exit, 5 = late exit, 6 = off-playbook entry (FOMO), 7 = oversized position (higher lot size than planned), 8 = revenge trade, 9 = other cognitive/discretionary error, 10 = infrastructure failure (lack of hard server stop, broker platform disconnect, ISP outage — the only error category whose resolution requires operational reconfiguration rather than behavioral change).
23. Psychological State (1–5) — 1 = compromised (fatigued, irritable, distracted), 5 = optimal (focused, rested, clear-headed). Must be recorded prior to order submission, never retroactively.
24. Hours of Sleep — integer/float. Enables computing the Spearman rank correlation between prior night's sleep and realized net R-multiple on your own sample. This is a hypothesis to test on your own data; the source does not supply a public statistic establishing that correlation for retail traders.
25. Decisional Quality (1–5) — scored at the end of the trading day, strictly decoupled from financial outcome. Question: Was this trade executed in 100% compliance with pre-trade rules? 5 = flawless compliance, 1 = ungrounded improvisation.

Group G: Volume, Versioning, and Audit Trail (4 fields)

Four fields without which your journal cannot be reconciled mathematically or evidentially. Without trade volume and pip value, planned monetary risk cannot be reconstructed from price distance alone. Without setup versioning, you cannot identify which rule iteration you are testing. Without an evidence link, you cannot arbitrate discrepancies against your broker statement.

26. Volume (lots) — position size rounded to broker lot step. Combined with stop distance and pip value, it establishes planned monetary risk in account currency; without it, field 21 cannot be reconstructed.
27. Pip Value at Open — in account currency for 1 standard lot (100,000 units of base currency), recorded as a discrete value at trade execution rather than a static global spreadsheet constant (exchange rates fluctuate over time; see Section 3 note).
28. Setup / Playbook Version — card identifier and version tag, e.g., "LON-breakout-A+ v1.2". Performance before and after a rule modification represents two distinct statistical distributions, not a single continuous sample.
29. Evidence Link (evidence_link) — chart screenshot URL, broker ticket number, or path to statement log. The single field that elevates a log from an unverified personal diary to an auditable financial record.

Summary Table — All 29 Fields, Data Types, and Data Sources

Logging these 29 fields requires approximately 60 to 90 seconds per trade once your spreadsheet template is set up. Without these data points, any subsequent performance evaluation is pure guesswork. If you cannot invest 90 seconds to record a trade, you should not be spending 30 seconds to enter it.

CSV / Spreadsheet Mini-Specification

A machine-readable column structure to implement in Excel, Google Sheets, or a PostgreSQL/SQLite database. Left column — technical field name; right column — operational source and mathematical derivation:

While there are 29 logical fields, the technical spreadsheet encompasses more physical columns — several parameters exist in paired "planned vs. actual" formats (entry, stop, target, slippage) spanning distinct columns. The structural columns in your spreadsheet should mirror this specification directly. Currency-specific column names in the Polish template have been generalized here to account-currency names; the worked PLN examples retain their original currency and amounts.

The error_code taxonomy contains exactly eleven distinct integer values applied consistently throughout this guide: 0 = no error, 1–9 = cognitive and discretionary trading errors from field 22, and 10 = infrastructure failure (absence of server-side hard stop, platform freeze, ISP disconnection). Error code 10 must never be lumped with discretionary errors, because resolving it requires architectural reconfiguration rather than psychological modification. If a position has no server-side stop during an outage, the missing execution history may be impossible to reconstruct from local logs. Recording an error code does not replace repairing that infrastructure.

The Orders and Fills Layer — One Decision, Multiple Executions

The primary trade table answers the strategic question: "What was the decision?" The granular history of orders and fills answers the technical question: "How was it executed?" These represent two distinct database layers linked by the relational key trade_id. Conflating them is the single most common reason trading journals diverge from real account balances:

• orders — an individual order request: order_id, trade_id, order type (market / limit / stop / modify SL / modify TP), submitted price, submission timestamp, execution status (filled / rejected / canceled). Rejections and stop adjustments are logged here, not in the primary trade summary table.
• fills — an individual trade execution: fill_id, order_id, trade_id, executed fill price, fill volume, fill commission, timestamp. A partial scale-out represents multiple execution rows sharing an identical trade_id.

Four ironclad aggregation rules preserve metric comparability:

• Calculate initial risk R0 exactly once, established from the pre-trade plan prior to initial entry fill, and keep it strictly immutable across partial closes or stop adjustments. Closing 50% of a position at +1R does not retroactively construct a new risk denominator for the runner.
• Sum net PnL and friction costs across all execution fills, dividing only the aggregate sum by R0. Never average the discrete R-multiples of separate partial tranches — because tranches frequently possess differing volume weights.
• One strategic decision equals one trade in statistical performance. Calculating win rate across separate partial tranches artificially inflates win rate (since initial scale-outs are typically winners) — the oldest trick in retail marketing to manufacture a cosmetically flattering journal without altering true profitability.
• Specify your measurement convention for MAE/MFE — define whether you track the raw price trajectory from the initial fill or the account-currency equity excursion of a position whose size decreases through partial closes. These are two completely different metrics and cannot coexist in a single column.

Import, Statement Reconciliation, Deduplication, and Audit Adjustments

A trading journal that has never been reconciled against an official broker statement is merely an unverified personal diary. Conduct this minimal reconciliation routine once weekly:

1. Import — export trade history from your platform (MetaTrader, cTrader, FIX log) into CSV for the closed period, maintaining an identical date boundary and server timezone (e.g., standard calendar week, server time explicitly noted in filename).
2. Deduplication — establish primary key trade_id from the broker's unique position ticket ID. When importing overlapping date ranges, prioritize the record with the later close timestamp, not simply the file downloaded later. Because partial executions and order modifications share a primary ticket, manage granular executions via order_id and fill_id within the relational layer rather than overwriting every fill or modification under the same trade_id.
3. Reconciliation — the total number of trades, aggregate net PnL, and sum of commissions/swaps must reconcile against the official broker statement down to the exact cent. Any discrepancy represents an operational error requiring investigation, not an acceptable rounding variance.
4. Audit Adjustments — log any post-trade correction as a new version with an amendment timestamp and justification; never delete the historical entry. Without version preservation, you cannot differentiate between an erroneous log entry and a genuine broker execution dispute.

Diagnostic Audit: Why do reports from two different platforms show conflicting figures for identical trades? Six verifiable operational causes:

• Conflicting server timezones — a position closed at 23:30 server time falls on Monday in one platform and Tuesday in another. Weekly totals diverge, even if annual totals align when the shift does not also cross the year boundary.
• Accounting for financing and commissions — one platform embeds swap and commissions into closed position PnL, whereas another books them as separate balance transactions.
• Netting vs. Hedging accounts — simultaneous opposite positions on the same pair are merged into a single net exposure on a netting account, while appearing as two discrete trades on a hedging account.
• Partial close execution — one platform logs a scaled-out position as a single trade with multiple execution legs, while another splits it into separate independent trade tickets, altering total trade count, win rate, and average R.
• Post-trade broker adjustments — cancellations of erroneous off-market pricing spikes, swap recalculations, or balance adjustments executed days after closure.
• Rounding and exchange-rate conversion mechanics — converting profit to base account currency at the exact timestamp of trade closure versus applying an end-of-day official fixing rate.

If unexplained discrepancies persist after auditing these six factors, your journal is not ready for performance metric computation. Metrics calculated on unreconciled statements reflect data corruption rather than strategy edge.

Regulatory Boundary: A trading journal is an operational performance tool, not a statutory tax ledger. Fiscal capital gains calculations are handled in Section 14 — your journal supplies supporting documentation (broker statements, order tickets, evidence links), not statutory tax liability calculations. Taxes never enter the calculation of r_net in either the numerator or denominator: fiscal levies are not execution transaction costs.

3. R-Multiple — The Fundamental Metric Retail Traders Often Do Not Calculate

R-multiple lets you compare trades with different risk profiles on one scale. Without it, a PLN 200 profit on an M5 scalp and a PLN 200 profit on a D1 swing trade look identical, although the first might have risked PLN 50 (+4R), and the second PLN 600 (+0.33R, a much smaller return on the initial risk). These are the Polish-currency examples from the source. Van K. Tharp introduced R-multiple^[1], and it is a foundation of trading-system analysis.

The R-Multiple Formula

The safest operational definition is:

R_net = actual_broker_net_pnl / planned_risk

Actual net PnL is the result after actual fills, commission, swap, and all costs shown in the broker statement. Slippage and spread are already embedded in the fills: the broker calculates profit from actual transaction prices, not planned prices. Record slippage and spread separately for diagnosis, but do not subtract them again when they are already included in actual PnL.

The denominator is planned risk, not realized risk. If the stop slips 10 pips beyond the planned 30-pip distance, the denominator does not increase: the loss is then −40 / 30 = −1.33R, plus commission, rather than −1R. A result worse than −1R is possible and is precisely what this convention should reveal: the actual cost of failed execution. Set the denominator before submitting the order, and do not change it after moving the stop, taking a partial exit, or learning the outcome.

Execution Drag — Diagnosing Execution Alongside Performance

Spread, slippage, and commissions are operating costs, but in the accounting of results they are already included in actual PnL. To diagnose execution quality, calculate separately:

execution_drag_R = [direction × (planned_exit_price_of_same_type − planned_entry) / pip_size × lots × pip_value_per_standard_lot − actual_net_pnl] / planned_risk

The crucial phrase is “planned exit price of the same type.” If the trade stopped out, compare it with the planned SL. If it reached its target, compare it with the planned TP. For a manual or time-based exit without a planned exit price, define the diagnostic as entry slippage, commission, and swap expressed in R. Comparing every trade with its planned TP is tempting because TP is recorded, but produces an absurd result: a clean stop-out filled exactly as planned would show about 3R of “execution cost” despite zero slippage. Execution drag measures execution quality, not the distance from the ideal profitable outcome. Direction (+1 long, −1 short) and volume must be included so short and long trades are treated consistently. Do not add spread separately when it is already reflected in fill prices.

Operational rule: keep performance accounting separate from execution diagnosis. If r_net uses actual broker PnL, costs are already in the result and are analyzed separately through execution drag. If the calculation starts from planned prices, deduct the costs manually. Use one method or the other, never both simultaneously.

A Complete Worked Calculation

Consider a EUR/USD long of 0.5 lot (50,000 EUR) on a PLN-denominated account, with an illustrative USD/PLN rate of approximately 4.40. One pip on a standard EUR/USD lot is USD 10, approximately PLN 44; on 0.5 lot it is approximately PLN 22 per pip.

• Planned entry: 1.0850
• Actual entry: 1.0852 (2 pips of slippage)
• Planned SL: 1.0820 (30 pips of risk)
• Planned TP: 1.0910 (60 pips = 2R)
• Actual exit: 1.0908 (2 pips of slippage at TP)
• Spread at entry: 0.8 pip
• ECN commission: PLN 4 per round turn
• Swap: 0 (position closed the same day)

Calculating R_net from actual broker fills:

• PnL from actual fills: (1.0908 − 1.0852) / 0.0001 = 56 pips; in PLN: 56 × 22 = PLN 1,232. Entry and exit slippage are already included because the calculation uses actual prices.
• ECN commission: PLN 4. Swap: 0.
• Actual net PnL: 1,232 − 4 = PLN 1,228.
• Planned risk: |1.0850 − 1.0820| / 0.0001 = 30 pips; 30 × 22 = PLN 660.
• R_net = 1,228 / 660 ≈ +1.86R.

Calculating execution drag as a separate diagnostic:

• Planned gross PnL with ideal fills and no costs: (1.0910 − 1.0850) / 0.0001 × 22 = 60 × 22 = PLN 1,320.
• Actual net PnL: PLN 1,228.
• Difference: 1,320 − 1,228 = PLN 92.
• execution_drag_R = 92 / 660 ≈ 0.14R. The trade exited at its target, so the planned exit benchmark is TP; execution costs consumed about 14% of planned risk.

For a stop-out, calculate drag against the planned SL. If both entry and stop fill exactly at their planned prices and the commission is PLN 4, drag is 4 / 660 ≈ 0.01R, not the approximately 3R produced by benchmarking against TP. If the earlier 2-pip entry slippage is retained, the cost is instead PLN 44 + PLN 4, or 48 / 660 ≈ 0.07R. Extrapolation requires a separate, explicit assumption: “after 100 trades, drag is approximately 14R, or roughly 14% of capital per year at 1% risk per trade” applies only to a scenario with 100 target exits and the same slippage on each. In a real journal, calculate drag across closed trades and examine stop exits and target exits separately: they are different distributions, and pooling them obscures the diagnosis. Costs are not a rounding detail; they inform choices about broker, pair, and timeframe. Keep r_net for performance accounting and execution_drag_R for improving execution; do not combine both deductions in one formula.

Why R-Multiple Instead of Percentages or PLN?

R-multiple provides a common risk-based unit for comparing scalps with swings, EUR/USD with GBP/JPY, and small with large positions. After a year and 200 journaled trades, a trader can say precisely: “My A+ setup averages +0.84R, B +0.21R, and C −0.13R.” That is where the journal's contribution ends. Whether to disable C depends on the intervals around those numbers and the criteria in Article 15.10, not simply on the sign of the mean.

The R-Multiple Distribution — Reading 220 Trades

Three observations follow from this distribution:

• Low win rate, but a positive result in this sample: 44.5% of trades are positive (98 of 220 above 0R), while the right tail — 17 trades at +2R or more, including one +5R trade — accounts for all positive expectancy. Remove those seventeen and total R becomes negative.
• Median 0R, mean +0.13R: the difference shows that profits come from the tail. Half the trades finish at zero or below. This is characteristic of trend-following and explains why the median and mean should be shown together rather than used interchangeably.
• Mean-reversion can show the opposite shape: the source's illustration has a high win rate of 60–70%, a small average winner of +0.5R, and a long left tail with rare −2R or −3R losses when mean-reversion fails. These describe an example pattern, not guaranteed strategy characteristics.

The same distribution is used later for Sharpe and Sortino in Section 6 and SQN in Section 4: the mean is +0.130R and standard deviation 1.182R, giving a per-trade Sharpe of 0.11, SQN of 1.10 with N capped at 100, and correctly calculated Sortino of 0.21. Remember these numbers: a seemingly “healthy” distribution with a profit factor of 1.31 looks weak in popular threshold tables. That alone does not invalidate the distribution; thresholds may assume different definitions or trade counts.

4. Net Expectancy — What Separates a Profitable System from Marketing

Expectancy answers one fundamental question: how much do I expect to earn (or lose) on each trade, expressed in units of R? Without this metric, you cannot know whether your trading strategy possesses mathematical viability. With it, you can estimate the mean result over N trades under the model assumptions; the estimate is not a guarantee of the next sample or of capital returns.

The Canonical Expectancy Formula

The standard structural formulation (used in backtesting and pre-trade theoretical modeling):

Expectancy = (WR × avg_win_R) − ((1 − WR) × avg_loss_R) − costs_per_trade_R

One essential statistical caveat: the term (1 − WR) lumps trades that closed at exactly 0.00R into the losing category. If your distribution contains breakeven trades, partition the sample into three discrete populations — E = pw × avgWin − pl × |avgLoss|, where pw + pl + p0 = 1 — which is the exact implementation used in the Python script below and the synthetic ledger in Section 5.

Where:

• WR — win rate, expressed as a decimal fraction (e.g., 0.55 = 55%).
• avg_win_R — average R-multiple of winning trades (e.g., +1.80R).
• avg_loss_R — absolute value of the average R-multiple of losing trades (e.g., 1.00R with strict stop discipline).
• costs_per_trade_R — aggregate friction (spread + slippage + swap + commission) normalized as a percentage of planned risk R (e.g., 0.10R).

Three Working Expectancy Benchmarks

The thresholds in this table represent illustrative working assumptions for scenario planning, not universal market mandates. They must only be applied alongside their corresponding confidence intervals: if the confidence interval spans across a threshold boundary, any strategic decision must be deferred. Position sizing by setup tier is established in Article 15.2, while formal decommissioning criteria reside in Article 15.10.

Minimum Sample Size for Expectancy Validation

The most dangerous trap in retail trading is calculating expectancy on 30 to 50 trades and treating the resulting decimal as an immutable truth. Probability theory demonstrates otherwise:

• 50 trades — 95% confidence interval for win rate spans approximately ±14 percentage points (Wald interval at p = 0.55, assuming independent trials; clustering and exposure to shared events can make the interval wider). An observed win rate of 55% could easily represent a true population parameter of 41% or 69%.
• 100 trades — interval spans approximately ±10 pp — still too broad to justify abandoning an established setup.
• 200 trades — interval narrows to approximately ±7 pp.
• 500 trades — interval narrows to approximately ±4 pp. A narrower estimate, but still bounded by probabilistic uncertainty.

The operational rule is not "never make decisions under 100 trades," but rather: decide based on the confidence interval, never the point estimate. If the 95% confidence interval for a setup's expectancy encompasses your operational decision threshold, decision-making is deferred until the next audit cycle — whether you have logged 40 trades or 400. Sample size enters the calculation through the width of the confidence interval; a count is neither a universal minimum nor validation by itself. Note that halting trading due to operational risk (exceeded drawdown limits, broker execution failures) is always permissible and never waits for statistical significance.

The Friction Cost Trap: Backtests vs. Live Execution Drag

Retail traders routinely evaluate gross theoretical expectancy, neglecting spread, slippage, commissions, and rollover financing. An idealized backtest yielding +0.50R gross frequently deteriorates to +0.20R net under live conditions. Over a year, account balance stagnates — because the trader realizes +0.20R, not +0.50R, across 200 trades.

Methodological Imperative: If r_net is derived from net statement PnL (Section 3), costs are already internalized — spread, slippage, and fees are tracked separately as execution drag, never subtracted twice. If calculating expectancy from idealized candle charts, friction must be deducted explicitly. Do not mix the two methods. The following hypothetical examples calculate execution drag, not a second deduction from net PnL:

Concrete examples of costs per trade in R, retaining the original PLN account and illustrative exchange rates:

• Pair: EUR/USD; ECN broker; spread 0.2 pip; commission USD 7 per standard lot round turn; average slippage 0.3 pip on each side.
• Typical setup: SL 30 pips, size 0.3 lot, illustrative USD/PLN ≈ 4.40; pip value for 0.3 lot ≈ PLN 13.20.
• Planned risk: 30 × 13.20 = PLN 396.
• Costs: spread 0.2 × 13.20 = PLN 2.64; slippage 0.6 pip for entry and exit × 13.20 = PLN 7.92; commission USD 7 × 0.3 lot = USD 2.10 ≈ PLN 9.24. Total: approximately PLN 19.80.
• Costs in R: 19.80 / 396 = 0.05R, or 5% of planned risk.

Another example — a more expensive pair and a tighter stop:

• Pair: GBP/JPY; market-maker broker; spread 2.5 pips; no commission; slippage 1 pip on each side.
• Pip value for 0.1 lot at illustrative USD/JPY ≈ 150 and USD/PLN ≈ 4.40: one standard lot produces JPY 1,000 per pip; 1,000 / 150 ≈ USD 6.67, or PLN 29.33 at 4.40. For 0.1 lot, approximately PLN 2.93 per pip.
• Tight setup: SL 25 pips, size 0.1 lot; risk 25 × 2.93 = PLN 73.25, or approximately PLN 73.
• Position costs: spread 2.5 × 2.93 ≈ PLN 7.33; entry slippage 1 × 2.93 = PLN 2.93; exit slippage 1 × 2.93 = PLN 2.93; total PLN 13.19 with the displayed rounding.
• Costs in R: 13.19 / 73.25 ≈ 0.18R, or about 18% of planned risk consumed by costs from the outset.

This shows the proportional-cost trap: the same slippage in pips consumes much more R with a tighter stop. A 25-pip stop on a pair with a 2.5-pip spread is therefore difficult to justify on costs alone. The working assumption here is an illustrative scenario threshold, not a market standard: costs above 5–8% of planned risk start to materially affect the result, prompting a review of broker, pair, or timeframe with a wider technical stop. The relevant test comes from your own journal: divide average costs in R by gross expectancy and examine how much expectancy remains.

Van Tharp's System Quality Number (SQN) — Formula, N-Cap, and Scale

The method author's interpretive scale is presented in full here. Other articles in the section should refer here rather than reproduce different variants: three inconsistent 'Tharp scales' in three articles would undermine the course's consistency.

Three vital caveats prevent misinterpretation: First, this scale represents the author's heuristic, not a market standard. Second, SQN expands with the square root of N up to 100 trades; comparisons are valid only between metrics calculated at identical N — the 220-trade baseline from Section 3 produces 1.10 at N = 100, yet would reach 1.63 if n = 220 were naively plugged in without the cap. Third, SQN is a signal-to-noise metric, not a position-sizing directive; it does not replace the confidence interval for net expectancy.

Sample Segmentation — Avoiding Selection Bias

A structured journal allows you to segment your trading dataset by setup, session, market regime, and playbook version. Maintain strict statistical vigilance: the more sub-segments you compare, the higher the probability that the top-performing bucket is an artifact of random noise. Selecting the best performer among twelve discrete setups represents data selection rather than true parameter estimation. The formal architecture for in-sample calibration versus out-of-sample validation is detailed in Article 15.4, while keep/modify/disable decisions belong to Article 15.10. The journal must supply the observation count and interval for every subset, not merely a ranking.

Bootstrap Confidence Intervals — Why +0.22R Is a Hypothesis, Not an Edge

An observed net expectancy of +0.22R across 42 trades does not constitute a proven edge — it represents an untested empirical hypothesis. Non-parametric bootstrapping exposes this directly: draw 10,000 resamples with replacement from those 42 trades, compute the mean of each resample, and plot the distribution of means to establish empirical confidence bounds. Document the finding in one sentence with the same three components every time: n, method, and assumption:

“For n = 42 trades, a 95% interval for expectancy is (−0.17R; +0.61R) at std(R) = 1.3R. These displayed endpoints are a check using the normal approximation, ±1.96 × std / √n; they are not a calculated bootstrap result. The intended bootstrap uses 10,000 resamples with replacement, can be asymmetric for a skewed R distribution, and its actual output is what should be recorded. Both approaches here assume independent observations; clustering and shared events can widen the interval. Since the interval includes zero, the setup decision is deferred until the next review.”

Sample size alone settles nothing; the width of the confidence interval relative to your decision boundary governs all conclusions. For low-frequency setups (generating only a handful of signals per month), bootstrap verification is non-negotiable: without it, 50 trades gathered across a full year appear solid, yet represent statistical noise dispersed over twelve months.

Python Script: Computing Performance Metrics from CSV

The following script calculates net expectancy, profit factor, per-trade Sharpe, Sortino, SQN, MAE/MFE, and equity drawdown directly from a standardized 29-field journal CSV:

import pandas as pd
import numpy as np

# Load trade journal from CSV (29 fields as specified in Section 2)
df = pd.read_csv('journal.csv')

# Restrict to closed positions with computed net R-multiples
df = df.dropna(subset=['r_net'])

# Enforce strict chronological ordering. Without this, equity curve
# and drawdown metrics reflect export sorting rather than account history.
df['close_time_utc'] = pd.to_datetime(df['close_time_utc'], utc=True)
df = df.sort_values('close_time_utc').reset_index(drop=True)

total = len(df)
if total == 0:
    raise SystemExit('No closed trades found — metrics undefined, not zero.')

r = df['r_net']

# Three distinct populations: wins, losses, and exact breakevens.
wins   = r[r > 0]
losses = r[r < 0]
zeros  = r[r == 0]

wr       = len(wins) / total
p_loss   = len(losses) / total
avg_win  = wins.mean()        if len(wins)   else float('nan')
avg_loss = abs(losses.mean()) if len(losses) else float('nan')

# Net expectancy equals the arithmetic mean of r_net (costs internalized)
expectancy = r.mean()
# Structural cross-check: must match the arithmetic mean exactly
structural_check = ((wr * avg_win if len(wins) else 0.0)
                    - (p_loss * avg_loss if len(losses) else 0.0))

# Profit Factor. Zero losses = undefined, not "infinite perfection"
sum_wins   = wins.sum()
sum_losses = abs(losses.sum())
profit_factor = sum_wins / sum_losses if sum_losses > 0 else float('nan')

# Per-trade R statistic and SQN with the chosen N = min(n, 100) convention
sd     = r.std(ddof=0)
sharpe = expectancy / sd if sd > 0 else float('nan')
sqn    = sharpe * np.sqrt(min(total, 100))

# Sortino Ratio: downside deviation across ENTIRE population, MAR = 0
mar     = 0.0
dside   = np.sqrt((np.minimum(r - mar, 0) ** 2).mean())
sortino = (expectancy - mar) / dside if dside > 0 else float('nan')

# Analytical 95% confidence interval for expectancy (assuming i.i.d.)
se = r.std(ddof=1) / np.sqrt(total)
ci = (expectancy - 1.96 * se, expectancy + 1.96 * se)

# Drawdown evaluation on equity curve with fixed fractional risk f per trade.
# Initial capital (1.0) MUST be prefixed to the rolling peak array;
# otherwise, a journal starting with a loss reports a misleading 0% drawdown.
f       = 0.01                      # working scenario parameter, not universal
equity  = pd.concat([pd.Series([1.0]), (1 + r * f).cumprod()], ignore_index=True)
run_max = equity.cummax()
max_dd  = ((equity - run_max) / run_max).min()

# MAE / MFE analysis computed across populated rows
mae_win = mae_loss = mfe_win = float('nan')
if {'mae_r', 'mfe_r'}.issubset(df.columns):
    m = df.dropna(subset=['mae_r', 'mfe_r'])
    if len(m):
        mae_win  = m.loc[m['r_net'] > 0, 'mae_r'].mean()
        mae_loss = m.loc[m['r_net'] < 0, 'mae_r'].mean()
        mfe_win  = m.loc[m['r_net'] > 0, 'mfe_r'].mean()

# Segmented breakdown per setup and playbook version
print(df.groupby(['setup', 'strategy_version']).agg({
    'r_net': ['count', 'mean', 'sum', 'std']
}))

print(f"Sample Size (n): {total} (Wins: {len(wins)}, Losses: {len(losses)}, Breakeven: {len(zeros)})")
print(f"Win Rate: {wr:.1%}")
print(f"Net Expectancy: {expectancy:+.2f}R (Structural check: {structural_check:+.2f}R)")
print(f"95% CI for Expectancy: ({ci[0]:+.2f}R; {ci[1]:+.2f}R)")
print(f"Profit Factor: {profit_factor:.2f}")
print(f"Per-Trade Sharpe: {sharpe:.2f} | SQN (capped N=100): {sqn:.2f}")
print(f"Sortino Ratio (full downside dev, MAR=0): {sortino:.2f}")
print(f"Max Equity Drawdown (at f={f:.0%}): {max_dd:.1%}")
print(f"Avg MAE Wins: {mae_win:.2f}R | Avg MAE Losses: {mae_loss:.2f}R | Avg MFE Wins: {mfe_win:.2f}R")

The script assumes the CSV structure from Section 2 and requires four populated columns: r_net, close_time_utc (chronology is essential for equity and drawdown), and setup plus strategy_version for segmentation. mae_r and mfe_r are optional; missing or empty data leave their metrics undefined, not zero. Before relying on the results, validate the script against a verified benchmark — such as the 6-trade synthetic ledger in Section 5 — confirming that its output matches manual calculations exactly. Test a secondary synthetic file that commences with a losing trade: this isolates whether your script properly includes initial equity in rolling maximums (a buggy script will display 0% drawdown on an initial loss). A diagnostic script that has not been benchmarked against known edge cases is merely another source of unwarranted confidence.

5. Profit Factor and Recovery Factor — Different Questions, Different Answers

Net expectancy quantifies "how much I expect to make per trade on average." Profit Factor and Recovery Factor address entirely different structural questions; ignoring them conceals vital dimensions of system health.

Profit Factor — Ratio of Total Profits to Total Losses

The benchmarks in both tables of this section represent illustrative working assumptions (not market standards) and carry statistical meaning solely when coupled with sample size. Profit Factor calculated from net R-multiples provides an unvarnished net assessment; an absence of losses in a sample yields an undefined PF, never an "infinite, perfect system."

Profit Factor (PF) = sum_of_all_wins / abs(sum_of_all_losses)

The core question it resolves: Does my trading system generate more cumulative profit than cumulative loss, and by what exact multiple?

Profit Factor offers immediate intuitive clarity for traders without a formal statistical background — "for every PLN 1 lost, the strategy generates PLN 1.80 in profit." However, it possesses a notable limitation: it ignores underlying distribution. A system delivering a PF of 1.80 across 200 trades is structurally incomparable to a system boasting a PF of 1.80 over 20 trades. Always evaluate Profit Factor in direct conjunction with trade count and net expectancy.

Recovery Factor — Cumulative Net Gain Relative to Maximum Drawdown

Recovery Factor (RF) = total_net_profit / max_drawdown

The core question it resolves: How many times does total net return surpass the deepest historical drawdown? Stated differently — how many times could the strategy have traversed its worst historical slump while preserving overall capital gains?

For example: an annual return of +35% achieved alongside a maximum drawdown during the year of −12% yields RF = 35 / 12 = 2.92. Both figures must stem from the exact same equity curve over identical timeframes — period profit divided by period drawdown. Placing multi-year CAGR in the numerator against a single-year drawdown in the denominator manufactures an unscientific metric comparing incompatible parameters.

Recovery Factor is an invaluable psychological gauge: if generating a 30% annual return required enduring a grueling 25% peak-to-trough drawdown (RF = 1.20), you must question whether the psychological anguish was justified by the yield. The source frames the trade-off as preferring RF above 2 with a lower CAGR over higher returns accompanied by a deep drawdown; this is a preference to assess, not an established statistic about professional traders.

Win Rate vs. Profit Factor — The Classical Retail Fallacy

Retail traders routinely conflate win rate with system quality: "I have a 75% win rate, so the strategy must be profitable." That conclusion is mathematically invalid. A 75% win rate coupled with an average win of +0.50R and an average loss of −2.50R results in:

• Net Expectancy: 0.75 × 0.50 − 0.25 × 2.50 = 0.375 − 0.625 = −0.25R per trade (an unambiguously losing system).
• Profit Factor: (0.75 × 0.50) / (0.25 × 2.50) = 0.375 / 0.625 = 0.60 — for every PLN 1 lost, the system earns only PLN 0.60 in profits.

A high win rate unaccompanied by rigorous control of the win/loss payout ratio is the hallmark of reckless mean-reversion strategies lacking stop discipline. A single outsized loss erases the result of many winning trades. Profit Factor exposes this reality instantly — a 75% win rate with a 0.60 Profit Factor is a losing result despite the high win rate.

Synthetic Journal Audit Ledger — Six Trades and Reconciled Metrics

Illustrative scenario based on synthetic data, not historical account performance. The six rows below are not taken from any account and do not demonstrate the effectiveness of any strategy. They retain the source's PLN denomination and are synthetic data designed to illustrate the full mathematical reconciliation from initial risk R0 to maximum drawdown on a sample compact enough to verify by hand. The standard convention holds throughout: R0 represents planned initial risk locked prior to execution; r_net represents official broker statement net PnL (after fees and financing) divided by R0.

Step-by-step arithmetic derived exclusively from the r_net column:

• Win Rate = 3 / 6 = 50.0%. Trade T-004 with +0.03R qualifies as a win because it is strictly net positive; had it closed at exactly 0.00R, it would belong to the third, breakeven population rather than to losses. This is precisely what the shortcut (1 − WR) × avgLoss mishandles.
• Cumulative R = 1.80 − 1.03 − 1.00 + 0.03 + 1.25 − 1.02 = +0.03R.
• Net Expectancy = +0.03 / 6 = +0.005R per trade. Structural cross-check: average win = +1.027R, average loss = −1.017R; therefore, (0.50 × 1.027) − (0.50 × 1.017) = +0.005R — confirmed.
• Profit Factor = (1.80 + 0.03 + 1.25) / (1.03 + 1.00 + 1.02) = 3.08 / 3.05 = 1.01.
• Maximum Drawdown evaluated on cumulative R (sampled after each trade; this is drawdown in R, not a percentage of account capital, and must be labeled accordingly): 0.00 → +1.80 → +0.77 → −0.23 → −0.20 → +1.05 → +0.03R. Rolling peak is +1.80R; subsequent trough reaches −0.23R; hence, max DD = 1.80 − (−0.23) = 2.03R. By the end of the sample (+0.03R vs. peak +1.80R), the drawdown remains unrecovered; recovery duration is explicitly documented as undefined rather than omitted.
• Confidence Interval: std(R) = 1.257, standard error = 1.257 / √6 = 0.513; 95% normal-approximation confidence interval for expectancy, assuming independent observations, spans (−1.00R; +1.01R).

The central lesson of this ledger: six trades demonstrate arithmetic reconciliation, but prove zero statistical edge. The confidence interval spans across zero, covers the +0.15R viability threshold, and extends into catastrophic loss territory — a single additional trade swings expectancy more than the purported edge itself. This ledger answers only: "Do my formulas reconcile cleanly?" It cannot determine whether the strategy is viable. Evaluating that same ledger across 600 trades provides statistical substance — yet the underlying mathematical formulas remain identical; only the confidence interval narrows.

6. Sharpe and Sortino — When They Make Sense for Retail

The Sharpe Ratio and Sortino Ratio serve as institutional gold standards in hedge fund performance attribution — yet they frequently mislead when uncritically applied to retail trading. However, when adapted to a "per-trade" framework (rather than annual portfolio volatility), they supply vital diagnostic information that neither net expectancy nor Profit Factor can reveal.

The Per-Trade Sharpe Ratio — Return per Unit of Outcome Volatility

Sharpe = (mean_R − risk_free_rate) / std_R

For the per-trade diagnostic used here, we set the benchmark to zero and measure outcomes in R. This is a convention, not a claim that normalization makes the economic risk-free rate zero. It gives:

Sharpe ≈ mean(R) / std(R)

What it communicates: how much return the system generates per unit of dispersion in trade outcomes. A higher value indicates a larger mean relative to outcome dispersion; it does not guarantee a smooth or predictable sequence. A low Sharpe signifies widely dispersed outcomes, even if net expectancy remains nominally positive.

The interpretive ranges in the table below reflect illustrative working assumptions and must only be evaluated alongside the exact sample size from which they were calculated.

Institutional annualized Sharpe cannot be translated 1:1 to a per-trade metric. Annualization scales via Sharpe_per-trade × √N, where N represents the number of trades executed annually. Consequently, an identical 0.30 per-trade Sharpe produces an annualized score of 1.50 at 25 trades/year, 2.00 at 44 trades, 4.20 at 200 trades, and 7.30 at 600 trades. One single per-trade score yields four drastically divergent "annualized Sharpe ratios." Furthermore, this mathematical scaling assumes strict independence between trades — an assumption that can fail for trades on the same pair or under the same regime. Positive dependence can inflate this annualized result. Always report per-trade Sharpe alongside total trade count; an annualized figure devoid of trade frequency is statistically meaningless.

The Fatal Flaw of the Sharpe Ratio — Penalizing Upside Volatility

The classical Sharpe ratio treats all dispersion around the mean as undesirable risk. When your strategy captures an outsized trend run producing massive tail winners (+5.0R, +8.0R), the sample standard deviation expands substantially — and the Sharpe formula penalizes your score. From an economic perspective, this is absurd: a trader should never be penalized for positive outlier gains running in their favor.

To resolve this distortion, Dr. Frank A. Sortino developed the alternative formulation^[2]: measuring strictly downside variance.

The Sortino Ratio — Return per Unit of Downside Risk

Sortino = (mean(R) − MAR) / DD, where DD = √( Σ min(Ri − MAR, 0)² / n ), and MAR = 0

The crucial mathematical element is the sample size n in the denominator: downside deviation must be evaluated across the entire population of trades, inserting zero for every trade that performed at or above the Minimum Acceptable Return (MAR) — rather than calculating the standard deviation of losing trades alone. This distinction is profound. The "standard deviation of losses only" variant fails to penalize the frequency of losing trades: a sample of 99 winners and 1 loss would yield zero loss dispersion and an undefined or astronomically inflated Sortino score. On the 220-trade baseline from Section 3, proper downside deviation is 0.631, yielding Sortino = 0.21; the flawed "losses only" variant produces 0.205 and an artificially inflated "Sortino" of 0.63 — a threefold distortion. Before comparing your Sortino ratio to external benchmarks, verify which mathematical definition was utilized.

Sortino penalizes strictly downside volatility. Large winning trades expand the numerator without expanding downside deviation in the denominator. Consequently, for right-skewed trend systems, Sortino reliably exceeds Sharpe.

These illustrative ranges are calibrated to this definition — downside deviation across the whole population — and are not market standards. They are not comparable with threshold tables based on the standard deviation of losses alone, which inflates the result roughly threefold in Section 3. The multiplier is not constant: it depends on the loss distribution and frequency, and can become arbitrarily large when the loss-only denominator approaches zero. The Section 3 distribution has profit factor 1.31 and Sortino 0.21, classified as “solid” on this scale.

A working rule: for many retail strategies with asymmetric outcomes, Sortino can reveal more than Sharpe, but both become uncertain with only a few dozen trades. Standard deviation itself then has a wide estimation interval, and metrics built on it inherit that uncertainty. Sharpe describes all fluctuations; Sortino focuses on outcomes below the target. Choose according to the style, frequency, and outcome distribution of your particular system.

When Sharpe and Sortino Break Down for Retail Traders

• Small sample sizes — with only a few dozen trades, outcome variance is unstable; always state sample size n alongside the metric.
• Highly asymmetric event-driven strategies (e.g., non-farm payroll breakouts) — where wins form a long tail and standard deviation may not represent what the trader considers typical volatility.
• Ultra-low trade frequency (e.g., 5 swing trades per month) — the source warns that estimating annualized Sharpe reliably from only 60 annual observations is difficult; the relevant issue is estimator uncertainty and dependence, not a universal numerical minimum.

For typical retail traders executing 200 to 600 trades annually across trend-following and mean-reversion strategies: Sortino serves as a dependable navigational compass, while per-trade Sharpe supplies secondary contextual validation.

7. MAE/MFE — What It Reveals About Entry and Exit Quality

Maximum Adverse Excursion (MAE) and Maximum Favorable Excursion (MFE) are two diagnostic metrics that uncover how far price traveled against your position and how far it traveled in your favor throughout the active lifespan of a trade. Retail traders rarely track them — forfeiting their most potent empirical tool for optimizing Stop Loss and Take Profit placement.

Definitions of MAE and MFE

• MAE (Maximum Adverse Excursion) — the deepest price excursion against the position while active, measured in units of R from entry. For example: bought EUR/USD at 1.0850 with planned SL at 1.0820 (30 pips initial risk). Before closing, price dipped to 1.0825 → MAE = [(1.0850 − 1.0825) / 0.0001] / 30 = 25 / 30 = 0.83R.
• MFE (Maximum Favorable Excursion) — the highest price excursion in favor of the position while active, measured in units of R from entry. Bought at 1.0850; price peaked at 1.0920 before pulling back → MFE = [(1.0920 − 1.0850) / 0.0001] / 30 = 70 / 30 = 2.33R.
• Both are running maximums evaluated strictly on the closed interval entry → exit and cannot decrease. MFE cannot "decay" when price pulls back — a retracement diminishes realized PnL, not the peak excursion reached. Once closed, MFE measurement terminates: subsequent price action belongs to a hypothetical alternate universe ("what if I had held longer?") and must be logged in a distinct research column. Conflating the two can wrongly attribute movement after a full TP exit to the closed trade. The source's TP comparison assumes the entire position actually closes at that target; a planned target alone is not a universal upper bound when execution differs or part of the position remains open.

What MAE and MFE Diagnose

MAE answers: How far did price retrace against the trade prior to conclusion? An average MAE on winning trades of 0.40R represents an empirical hypothesis that your stop loss contains excess buffer the market rarely challenges — not definitive proof that you should immediately tighten your stop. An average alone settles nothing for three reasons: First, it is evaluated strictly on surviving trades: trades stopped out are excluded by definition, meaning you only inspect survivors. Second, the average conceals the tail — several winning trades registering MAE of 0.90R would be stopped out under a narrower stop, and those specific trades frequently generate your right-tail gains. Third, MAE reflects where market price traded, not whether an execution could have occurred at that exact level (use the candle boundaries and the executable side appropriate to direction: a long exits at Bid, not at an undifferentiated mid-price). Only a full distribution analysis plus out-of-sample simulation ("how many winners would be stopped out at 0.8× SL?") provides actionable confirmation. The inverse observation is far more definitive: an average MAE of 0.90R on winning trades signals that stop buffers are fully utilized and any increase in broker slippage will convert winners into outright losses.

MFE answers: Am I leaving excessive profit on the table? The fundamental analytical constraint: both metrics must stem from the exact same population. Comparing average MFE across all closed trades against average profit of winning trades introduces severe distortion by commingling losing positions. If winning trades generate an average MFE of +2.50R while delivering an average realized profit of +1.20R, the +1.30R gap indicates that Take Profit orders are placed too conservatively or trailing stops are triggering prematurely. This is an analytical lead, not a conclusion: MFE represents peak historical excursion, not a price at which an exit was necessarily available: an order would have needed to be in place at that peak and execute on the correct side of the spread.

Four Practical MAE/MFE Diagnostic Scenarios

MAE/MFE on Losing Trades — Evaluating Stop Integrity

Evaluated exclusively across losing positions:

• Average MAE on losses ≈ 1.00R (planned SL) — stop discipline is maintained flawlessly; loss sizing is strictly normalized. If realized net outcome averages −1.10R to −1.20R, the discrepancy isolates broker execution slippage and commissions.
• Average MAE on losses > 1.20R — stops are being manually widened against plan, catastrophic slippage is occurring, or positions are being held into price gaps. Each root cause requires immediate operational intervention.

Extracting MAE/MFE from Trading Platforms

Most retail brokers do not export granular MAE/MFE in standard CSV reports. Reports may supply entry, exit, and sometimes the price range over the trade, without a ready MAE/MFE measure. Four operational approaches follow: select one and maintain it for three months before assessing whether the data changed your decisions.

• MetaTrader (MT4/MT5) Without Tick History — upon trade closure, open an M5/M15 chart covering the active trade duration. Use the candle range to estimate the greatest adverse and favorable moves, converting them to R (MAE_pips / SL_pips, MFE_pips / SL_pips). Time required: 30–60 seconds per trade.
• cTrader / TradingView Automated Scripting — export candle data across the open_time to close_time window and calculate extrema algorithmically via Python. Ready-made per-trade MAE/MFE may be restricted to the strategy tester rather than manually executed trades. Verify the platform, account state, and workflow on your own account before relying on it; candle-based and tick-based extrema are not interchangeable.
• Dedicated Journal Software (Edgewonk) — automatically computes MAE/MFE following trade statement imports; verify the actual mechanism and coverage in the vendor documentation — ticks, candles, or broker API — before building a workflow around it.
• Analytics Aggregators (FX Blue / Myfxbook) — the scope of MAE/MFE analysis and plan availability can change. Check current vendor documentation instead of assuming the function is absent.

For most retail traders, manual chart inspection upon trade closure is the most dependable approach — the source budgets about 30 seconds for a careful manual record, without API integration or software costs.

The Sweeney MAE/MFE Scatter Plot — Deciphering the Four Clusters

The Sweeney chart^[4] arranges MAE on the horizontal axis and MFE on the vertical axis, with each point representing a discrete trade. Winning trades appear green; losing trades appear red. Four analytical quadrants diagnose execution health:

• Bottom-Left Quadrant (Low MAE, Low MFE) — swift winning trades with minimal adverse excursion; an optimal execution experience, yet frequently indicative of targets placed prematurely close.
• Top-Right Quadrant (High MAE, High MFE) — trades that suffered severe drawdown, narrowly escaping stop invalidation before rallying to large gains. A critical warning: minor slippage spikes would have transformed these into full losses.
• Top-Left Quadrant (Low MAE, High MFE) — flawless entry timing followed by massive directional trend extension. The elite setup profile your trading process seeks to systematically replicate.
• Bottom-Right Quadrant (High MAE, Low MFE) — immediate adverse price movement with little favorable follow-through. Avoid these patterns and diagnose the setups in this cluster; the chart alone is not a decision to disable them.

8. Drawdown — Historical, Current, and Expected

Drawdown measures the percentage decline in capital from the preceding peak. Systematic drawdown analysis operates across three complementary analytical dimensions:

Historical Maximum Drawdown

The interpretive thresholds below reflect working scenario assumptions, not universal market mandates — an identical trading strategy executed at 2% risk per trade produces approximately double the drawdown depth of a 1% risk allocation. Stating "max DD is 20%" without specifying position sizing conveys zero structural information about the strategy.

Maximum Drawdown measures the single deepest peak-to-trough decline observed across account history — the ultimate metric for evaluating psychological stress tolerance.

Ht = max(Eu : u ≤ t) — the running high-water mark of equity, with initial capital explicitly included; Dt = (Ht − Et) / Ht; max DD = max(Dt). This must be evaluated continuously along the equity curve, not as a simplistic comparison of the global maximum to the global minimum: for the sequence 100 → 80 → 120 → 110, the true maximum drawdown is 20.0%, not 33.3%.

Before quoting any drawdown metric, two foundational parameters must be explicitly declared: whether the trajectory reflects floating equity (incorporating open trade fluctuations) or closed account balance, and the exact sampling frequency (tick, trade-by-trade close, or daily end-of-day). Deposits and withdrawals must be mathematically neutralized — injecting fresh capital during a drawdown cosmetically disguises drawdown depth rather than reducing risk. Drawdown evaluated on cumulative R rather than equity currency must be explicitly designated as "Max DD in R, sampled per trade" and never labeled as an account percentage.

Average Drawdown

The arithmetic mean of all distinct peak-to-trough drawdown cycles across account history. It reflects the routine operational "pain" of the system, distinct from worst-case tail scenarios.

A practical diagnostic heuristic (an illustrative scenario assumption, not a market standard): if Maximum Drawdown exceeds 3× Average Drawdown, the return distribution exhibits severe fat tails — typically indicating exposure to extreme external market shocks or a sequence of positions larger than the plan allowed. The 3× multiple is an illustrative rule of thumb; the structural root cause in your data is what demands investigation.

Drawdown Duration — The Recovery Horizon

Frequently far more psychologically debilitating than drawdown depth: how much time is required to recover to a fresh high-water mark?

• A 10% drawdown resolved within 2 weeks is easily absorbed psychologically.
• A 10% drawdown grinding on for 8 months dismantles trader conviction, leading the majority to abandon viable strategies during the drawdown.

A system characterized by moderate drawdown depth but protracted recovery durations can be far more psychologically grueling than a strategy with sharp drawdowns and rapid V-shaped recoveries. This dynamic can be synthesized into the product of average depth and average recovery duration — termed here the pain product (an analytical diagnostic metric specific to this framework). Do not conflate it with the Pain Index (average drawdown over time) or the Ulcer Index (square root of the mean squared drawdown) — three distinct formulations sharing similar nomenclature. A drawdown unrecovered at the end of the sample must remain labeled unrecovered: do not enter an invented recovery duration into the average; report it separately alongside the average of completed recoveries. The pain product is specific to this article, not an industry standard.

Expected Drawdown — Preparing Empirical Data for Simulation

Your trade journal supplies one fundamental asset to Monte Carlo simulations: the empirical vector of r_net values, standardized to an immutable R0 denominator with friction reconciled against official broker statements. The simulation methodology itself — what is resampled (order, blocks, or paths), random seed, simulation horizon, and capital model — is codified in Article 15.4. Two operational caveats apply: First, simulated drawdown percentages depend directly on assigned position sizing — arguing that "because the 95th percentile max DD is 18%, 1% risk is safe" is circular reasoning. Simulation reveals what drawdowns a specific R distribution produces at a specified sizing. Second, reshuffling historical trades cannot generate individual losses larger than the worst historical outlier in the sample. Novel tail risks must be stressed via structural scenario modeling, not random permutations.

The Performance Metrics Control Card — Definitions, Denominators, and Limitations

A comprehensive master reference for all metrics established across this guide. The final column is the most critical: it separates rigorous quantitative measurement from promotional hyperbole and is the most frequently ignored by retail traders.

9. Tools: Edgewonk, Myfxbook, FX Blue, Custom Excel/Notion

A software tool does not create a successful trade journal. An Excel workbook maintained with unwavering discipline will outperform an expensive commercial platform abandoned after two weeks. Nevertheless, your software stack matters — an inappropriate tool either creates excessive friction that erodes consistency or fails to surface the diagnostic metrics you require.

Comparative Analysis of Primary Journaling Tools

What Mainstream Journaling Tools Fail to Track

The vast majority of commercial tools omit critical decision quality parameters — psychological state, hours of sleep, and end-of-day rule compliance. These must either be engineered via custom tags or tracked in a parallel spreadsheet. Without qualitative logging, you cannot determine whether physical fatigue or emotional agitation correlates with strategy underperformance — an empirical question that only you can resolve on your personal dataset; the source supplies no public statistic establishing that correlation across retail journals. Broker fill logs alone cannot capture this reality.

When Custom Excel Outperforms Commercial Software

• Bespoke metrics derived from external macro data — for example, conditional rules such as "setup valid if VIX < 18 and CBOE put/call ratio > 1.1." While the vendor lists custom tag categories and full customization (information checked: 2026-09-07, edgewonk.com/pricing), compiling dynamic formulas incorporating third-party macroeconomic feeds is handled far more effectively in a spreadsheet.
• Multi-asset strategy architectures — verify cross-market support with software vendors prior to selection: commercial pricing lists multi-market compatibility (information checked: 2026-09-07, edgewonk.com/pricing). The primary argument for a custom workbook remains uncompromised ownership of every formula definition and denominator.
• Complex R-multiple adjustments — such as portfolio correlation or A+/B/C classification under a proprietary methodology — where spreadsheet formulas provide total modeling flexibility.

The Optimal Implementation Sequence

The implementation path is universal regardless of capital size: establish the manual logging habit in a spreadsheet first; automate the execution layer second (broker statement CSV imports); and invest in dedicated analytical software last. Upgrading software before building the behavioral habit achieves nothing — tools do not generate discipline; they merely magnify existing habits. Aligning your analytical workflow with your personal schedule (morning preparation, post-session review, weekend audit) is detailed in Article 15.5; for trade journaling, the non-negotiable rule is logging the 29 fields on the day of execution and reconciling them weekly against official broker statements.

10. Journal-Analysis Workflow — Daily, Weekly, Monthly, Quarterly

A trade journal maintained without a systematic review cadence is merely a dormant database. The review architecture operates across four distinct operational tiers — daily, weekly, monthly, and quarterly — with the first three belonging to the journaling process. The fourth, quarterly review, constitutes a formal strategy audit governed by Article 15.10: the journal supplies empirical data, while strategic decisions regarding setup decommissioning occur there. Each tier answers specific operational questions within a designated time budget.

Daily Cadence — 5 Minutes Post-Session

Objective: capture unvarnished raw data while operational memory is immediate.

• Record all executed trades across all 29 fields (from broker statements plus qualitative metrics).
• Assign error classification (Category 0–10).
• Score decisional quality (1–5) — evaluated rigorously, strictly decoupled from financial PnL.
• Record hours of sleep if omitted during morning routine — this is an objective pre-session parameter easily recalled in the evening. Psychological state is the critical exception: log it prior to order execution or leave the field blank. If a mental-state score is entered in the evening after the outcome is known, explicitly label it retrospective. Otherwise the supposed state/result correlation measures memory of the result, not the state before entry.
• Record one concise contextual sentence: "London a little quieter than usual; NFP was yesterday."

Same-day logging is an operational prerequisite for data integrity. After 72 hours, you cannot accurately reconstruct your emotional discipline during entry; after a week, memory will rationalize improvised gambles into "sound technical setups" to justify the known outcome. That is the exact cognitive illusion this guide aims to eliminate — and logging late transforms that illusion into corrupted data.

Weekly Cadence — 30 Minutes on Sunday Evening

Objective: short-term behavioral diagnosis — verify strategy compliance throughout the preceding week.

• Count trades per setup and per tier (A+, A, B, C).
• Compute weekly net R-multiple sum (cumulative weekly R).
• Tally execution errors by category — did a specific mistake dominate the week?
• Calculate average decisional quality — has it dipped below 3.5? (an immediate warning signal).
• Evaluate behavioral correlations: on days where psychological state scored < 3, what were the realized returns?
• Write one structured reflection paragraph: what this week revealed about execution discipline and market regime alignment.

The weekly review catches behavioral drift early: "On Wednesday, I took four trades, all outside my A-tier playbook — pure FOMO following a poor Monday." Identifying behavioral patterns weekly allows you to correct course before bad habits solidify into permanent capital destruction.

Monthly Cadence — 60 Minutes on the First Weekend

Objective: compute complete quantitative metrics and assess whether monthly performance aligns with long-term system baselines.

• Execute full metric calculations: win rate, net expectancy, profit factor, Sortino ratio, maximum drawdown, and Recovery Factor.
• Compile segmented performance table per setup: trade count, average R, and net expectancy.
• Plot monthly equity curve — benchmark against expected trajectories from Monte Carlo simulations.
• Inspect MAE/MFE scatter — was entry timing sharp, or was excessive profit surrendered via premature trailing?
• Audit error taxonomy — isolate the top 3 error categories for the month, drafting targeted behavioral safeguards.
• Analyze correlations: sleep deprivation vs. net R; mental state below 3 vs. results.
• Draft a concise one-page monthly executive audit for yourself.

Conducting this quantitative review once monthly — regardless of whether the month was profitable or unprofitable — provides the sole objective verification of whether you are improving as a trader or merely enjoying favorable variance. A monthly review strips away excuses: you see clearly whether losses stemmed from setup invalidation, session timing, currency pair, poor sizing, or deliberate execution breaches.

Quarterly Cadence — Supplying Empirical Data for Strategy Audits

The quarter is an operational decision tier, not merely a measurement interval. The formal audit architecture — multi-stage decision gates, retention criteria, tier degradation, and playbook revision — is codified in Article 15.10. Your trade journal supplies four specific assets to that audit: a reconciled statement of all trades, segmented tables per setup and version (sample size n, mean R, confidence intervals), the proportion of trades carrying nonzero error codes, and total friction drag in R. If any of these four elements is missing, the audit cannot proceed — the only legitimate conclusion from an incomplete journal is that performance data is unverified.

Summary Table — The Journal Review Workflow Across Four Frequencies

Adapting the Workflow to Your Trading Lifestyle

The timeframes above are calibrated in dedicated minutes rather than rigid hours of the day. Integrating this routine alongside full-time employment, dedicated full-time trading, or swing trading with only a few trades per month — along with the weekly calendar and daily tool choices — is developed in Article 15.5. For journaling, one rule remains non-negotiable: qualitative fields must be logged on the day of execution, with psychological state recorded before entry as specified above and decision quality and error classification at their designated review times. Reconstructing them days later yields unscientific retrospective rationalization rather than objective diagnostic data.

Journal Signals vs. System Decommissioning Decisions

The single most destructive blunder following a losing quarter is replacing your trading strategy instead of eliminating execution errors — or conversely, stubbornly clinging to a broken setup after market regimes have structurally shifted. Deciding whether to repair the system or repair your execution is the domain of Article 15.10. The journal's role is foundational: disaggregating performance into distinct layers. Financial outcome separately; rule compliance separately (error codes, decisional quality); execution friction separately (slippage, drag); and playbook versions separately. A losing quarter where 50% of trades carried nonzero error codes reveals nothing about strategy edge — it proves execution failure. Evaluate this hierarchy first: that is the complete, indispensable contribution of your journal to decisions it does not make alone.

An individual trade's R definition does not turn it into a periodic portfolio return. Mean(R)/std(R) multiplied by the square root of the trade count is a mechanical scaling of an R statistic, not automatically an annual account Sharpe. Fund comparisons require consistent capital-return periods, benchmarks, risk and dependence assumptions. The FX Blue Publisher EA guide describes CalculateMAEandMFE and price-history limitations; check results using a control dataset.