Lệnh đòn bẩy 22,72× làm mất 44% tổng lỗ của quỹ — và nó nằm trên symbol tôi chưa bao giờ kiểm định

Lệnh rơi vào lỗ trần đòn bẩy

Ngày 02 tháng 9, một lệnh BUY trên US30/YM1! mở với 3,99 lot (khoảng 4 lot YM future). Notional đạt 211.993 EUR, đòn bẩy thực 22,72×. Trần quy định là 10×. Lệnh này gấp 2,27 lần trần.

Nó lỗ 296,40 EUR.

Tổng lỗ của tài khoản trong kỳ này là 670,30 EUR. Lệnh này chiếm 44% (296,40 / 670,30 = 44,2%). Một lệnh duy nhất, một ngày, mất gần nửa tất cả.

Lệnh đó inh 3,18% equity (mẫu số: 9.329,70 EUR, tài khoản selffunded tính đến 23/09/2026 22:15). Luật H&V viết "rủi ro 1% trên lệnh". Lệnh này gấp 3,18 lần luật.

Nó nằm trên symbol US30 (chỉ số Dow Jones). Tôi chưa bao giờ viết file kiểm định nào cho symbol này — không có *_VERDICT.csv, không có cấu hình giao dịch nào được kiểm định trước.

Lệnh sát nút thứ hai, ngày 10 tháng 9, US500, 12 lot, đòn bẩy 9,74×. Chỉ dưới trần đúng 0,26× nhưng vẫn lỗ 189,60 EUR = 2,03% equity. Hai lệnh liên tiếp đều phá luật 1%.

Vì sao bản báo cáo trước SAI — và sai bằng cách nguy hiểm nhất

Bản báo cáo ngày 24/09 lúc 14:49 kết luận: "Cả 7 dòng vượt trần đều là lệnh TEST". Sai.

Sai vì MÙ, không phải vì tính nhầm. Đây là điểm quan trọng nhất.

Adapter ctrader_journal đọc journal từ broker cTrader và ghi ra CSV. Nó không ghi cột qty — số lượng hợp đồng. Mà không qty thì không thể tính notional. Không notional, công cụ kiểm soi không thể tính đòn bẩy. Kết quả: 5 lệnh thật từ broker rơi khỏi bảng đòn bẩy trong im lặng.

Bản kiểm soi đúng phần không cần soi (lệnh test, lệnh E2E verify). Bản để sơ hở cái quan trọng (lệnh thật nhưng không có qty).

Tôi đã suy lại qty từ các con số sẵn có trong sổ:

risk_1R = |pnl| / |R|            (R đọc từ ghi chú: "SL R=-1.01")
qty     = risk_1R / |entry - sl|

Rồi kiểm chứng độc lập bằng script khác — apply_leverage_cap.sh — script viết trước, chạy trên dữ liệu khác (trading_journal.csv), không biết gì về phương pháp suy này:

4/4 khớp. Một phép suy chỉ đáng tin khi nó đã được xác nhận từ nguồn thứ hai độc lập. Đây là trường hợp đó.

13 dòng vượt trần: 1 thật, 12 test

Bảng đầy đủ tất cả 13 lệnh vượt trần 10×:

12 dòng test (hầu hết với notional siêu to — 188×, 165× — là dấu hiệu test). Nhưng 2 dòng thật: US30 ngày 02/09 (22,72×) và US500 ngày 10/09 (9,74×).

Lệnh 12 test với notional 1.758.691 EUR (188,50× đòn bẩy) là chứng cứ code không chặn. Không phải lỗi nhỏ có thể bỏ qua.

Tầng ba: siết trần không phải lời giải pháp

Hệ thống có MAX_LEVERAGE = 10× từ trước. Tôi đã siết xuống còn 2,25× từ 24/09 lúc 04:18 (trong accounts.py:70, xác nhận bằng launchctl getenv MAX_LEVERAGE → 2.25).

Nhưng nhìn vào bảng dry-run (chạy lịch sử qua cấu hình mới, không sửa gì thực tế):

Vì sao "code-hiện-tại" ở trần 2,25× vẫn để lọt lệnh −296,4 €?

Lý do kỹ thuật: cap = int(equity * lev / notional). Với notional 211.993 EUR, equity 9.329,70 EUR, lev 2,25:

cap = int(9329.70 * 2.25 / 211993) = int(0.0993) = 0 lot

0 < MIN_LOT (tối thiểu 1 lot). Nên nhánh cap bị bỏ qua sạch. Như chưa có cấu hình nào cả.

Chỉ cấu hình kết-hợp (MAX_LEVERAGE 2,25 + RISK_CAP_PCT 0,01 = 1% equity tối đa) mới ĐẠT: lỗ lớn nhất còn −74,1 € = −0,73%, mà không phải bỏ lệnh nào. Đó là sự kết hợp hai cơ chế: trần notional + ngân sách rủi ro.

Một tham số cấu hình trông như đã sửa vấn đề nhưng trên thực tế chưa. Mà giám sát báo "sạch" dù vẫn rò rỉ, còn nguy hiểm hơn không có giám sát, vì nó cấp cho bạn sự yên tâm sai.

Phản biện đã sẵn sàng

"Size đó tính cho FTMO 100.000 EUR, không phải ví 9.329,70"

Lấy nền 100.000 EUR:

• Notional 1.758.691 / 100.000 = 17,59×. Vẫn vượt trần 10×.
• Dòng THẬT 02/09: 211.993 / 100.000 = 2,12×. Dưới trần, không sao.

Nhưng lỗ 296,40 EUR là tiền thật đã mất trên ví 9.329,70 EUR có thật, không phải trên ví 100.000 EUR không tồn tại.

"Qty là suy ra, không phải sao kê broker"

Suy ra và đã đối chiếu 4/4 với script độc lập. Muốn bác thì bác bằng sao kê broker hoặc output API từ cTrader, không bác bằng chữ "ước".

Bài học

Một cộng chặn lệnh (leverage cap, risk cap, vv) chỉ thật sự tồn tại khi bạn đã chạy lại lịch sử qua nó (backtesting, dry-run, paper-trade) và thấy nó bắt đúng cái nó phải bắt. Cấu hình không phải là sự thực thi. Code không biết cấu hình là bao, chỉ biết logic nó đang chạy.

Một hệ thống báo cáo chỉ "sạch" vì nó mù ở đúng chỗ còn nguy hiểm hơn không có báo cáo. Đó là sai tệ hơn tính nhầm, vì tính nhầm còn tạo ra thông báo lỗi, nhưng mù thì không.

Tự kiểm chứng

Người đọc có thể chạy lại:

python3 ~/Documents/trading/ES-NQ/wr_monitor.py

Xem bảng đòn bẩy đầy đủ:

awk -F, 'NR==1 || $20==1' ~/Documents/trading/ES-NQ/leverage_replay.csv | column -s, -t

Chạy dry-run cấu hình mới (không sửa gì trên thực tế):

./apply_leverage_cap.sh

Cảnh báo rủi ro

Nội dung bài này là phân tích giáo dục về giám sát rủi ro và lỗ hổng công cụ, không phải lời khuyên đầu tư. Hiệu suất quá khứ không bảo đảm kết quả tương lai. Giao dịch đòn bẩy (margin/futures) mang rủi ro mất vốn toàn bộ. Tôi sử dụng tài khoản demo (demo.ctrader.5885753), nhưng cấu trúc rủi ro áp dụng tương tự tài khoản thực. Bài học về cơ chế cap, về cách kiểm chứng, về nguy hiểm của giám sát "sạch" không phụ thuộc vào demo hay thật.