Khi một hệ thống giao dịch nhiều vị thế đi vào vùng drawdown, phản ứng nguy hiểm nhất thường là tiếp tục mở lệnh như thể điều kiện thị trường chưa thay đổi. Auto lockdown MinEqui2 trong Python giải quyết đúng bài toán kiểm soát đó: theo dõi equity cấp tài khoản, cân bằng phần lệch khối lượng của từng cụm bằng lệnh LOCKDOWN_ABS, đánh dấu cụm ở trạng thái đóng băng và chỉ cho logic rải lưới hoạt động trở lại khi equity vượt ngưỡng. Trong dự án PyNhiQuaiBot, đây là một lớp phòng thủ vận hành, không phải công thức biến thua lỗ thành lợi nhuận.

Điểm cần nhấn mạnh ngay từ đầu là full hedge không xóa lỗ đã hình thành. Khi Buy và Sell được cân bằng gần như tuyệt đối, độ nhạy tức thời của cụm với biến động giá có thể giảm, nhưng gross exposure, spread, commission, swap, margin và rủi ro thực thi vẫn tồn tại. Lệnh khóa cũng có thể khớp trượt, bị từ chối hoặc không đạt đúng khối lượng mong muốn. Bài viết này phân tích kiến trúc thật của Nhi Quái V6 và bản port Python Bot Auto Trading, qua đó giúp người học hiểu cách xây một cơ chế dừng có trạng thái thay vì coi hedge là nút cứu tài khoản.

1. Vì sao phải quan sát equity thay vì chỉ nhìn balance?

Balance phản ánh số dư sau các giao dịch đã đóng. Equity lấy balance cộng lãi/lỗ thả nổi của các vị thế đang mở. Với chiến lược rải nhiều tầng, balance có thể nhìn vẫn ổn trong khi floating loss đã tăng mạnh. Nếu bộ bảo vệ chỉ đọc balance, bot sẽ phản ứng muộn vì phần rủi ro lớn nhất vẫn chưa được hiện thực hóa.

Có thể diễn đạt đơn giản:

equity = balance + floating_profit_loss

Trong thực tế, broker còn phản ánh swap, commission hoặc cách tính P/L theo đặc điểm sản phẩm. Vì vậy nguồn dữ liệu đúng phải là account_info().equity do terminal MT5 cung cấp, thay vì tự ghép một con số ước lượng từ vài vị thế mà bot đang biết. Equity là chỉ báo sức khỏe cấp tài khoản; còn vị thế theo Magic Number là phạm vi hành động của từng cụm.

Nhi Quái V6 có hai cấu hình riêng:

• buy_min_equi2 cho cụm Magic Buy;
• sell_min_equi2 cho cụm Magic Sell;
• auto_lockdown bật hoặc tắt toàn bộ cơ chế;
• hai Magic Number mặc định tách cụm để truy vết và quản trị.

Một chi tiết đáng chú ý là cả hai cụm đều đọc equity chung của tài khoản. Vì vậy, nếu cùng đặt ngưỡng giống nhau, hai cụm có thể lần lượt kích hoạt khi tài khoản đi xuống. Đây không phải “equity riêng” của mỗi cụm. Người thiết kế phải hiểu rõ phạm vi đo và phạm vi hành động, nếu không sẽ diễn giải dashboard sai.

MinEqui2 là ngưỡng kiểm soát, không phải dự báo

MinEqui2 không dự báo đáy và không nói rằng thị trường sẽ đảo chiều tại đó. Nó chỉ là một ranh giới chính sách: khi equity nhỏ hơn hoặc bằng ngưỡng, bot không còn được phép tiếp tục hành vi bình thường. Giá trị ngưỡng phải xuất phát từ vốn, margin, đặc điểm symbol, stress test và mức tổn thất chấp nhận được; không nên sao chép một con số mặc định sang mọi tài khoản.

Ví dụ minh họa: tài khoản có balance 30.000 USD, equity hiện tại 25.000 USD và MinEqui2 = 25.000. Điều kiện equity <= MinEqui2 đúng. Bot sẽ kiểm tra cụm, tính độ lệch volume và gửi chân đối ứng. Ví dụ này chỉ nhằm giải thích logic, không phải khuyến nghị vốn, lot hay ngưỡng giao dịch.

2. LOCKDOWN_ABS cân bằng cái gì?

Trong mỗi cụm, PyNhiQuaiBot cộng tổng volume Buy và tổng volume Sell:

d = buy_volume - sell_volume

Nếu d > 0, cụm đang thừa Buy nên bot gửi Sell với volume abs(d). Nếu d < 0, cụm đang thừa Sell nên bot gửi Buy với volume abs(d). Comment của order là LOCKDOWN_ABS, nhờ đó hệ thống nhận diện chân khóa khi quét lại position.

Ví dụ cụm Magic 6111 đang có tổng Buy 0,35 lot và tổng Sell 0,20 lot. Bias volume là 0,15. Khi lockdown kích hoạt, bot muốn gửi Sell 0,15 lot. Sau khi khớp đủ, tổng Buy và Sell đều xấp xỉ 0,35 lot, net volume gần bằng 0. Trường hợp ngược lại, Buy 0,10 và Sell 0,28 sẽ tạo lệnh Buy khóa 0,18 lot.

Từ ABS trong LOCKDOWN_ABS nhấn mạnh việc dùng độ lớn tuyệt đối của chênh lệch. Tuy nhiên, bình đẳng về lot chưa chắc đồng nghĩa bình đẳng hoàn toàn về rủi ro:

• các position có giá vào khác nhau và chi phí khác nhau;
• contract size hoặc tick value có thể thay đổi theo symbol;
• lệnh khóa có thể chỉ khớp một phần;
• volume step của broker có thể buộc làm tròn;
• tài khoản netting có hành vi khác tài khoản hedging;
• giá Bid/Ask khiến hai phía không triệt tiêu chi phí;
• swap của Buy và Sell có thể bất đối xứng.

Do đó, “full hedge” trong mã nên được hiểu là cân bằng volume theo mô hình của bot, không phải bảo đảm P/L đứng yên tuyệt đối.

Vì sao phải gắn comment riêng?

Comment tạo dấu vết nghiệp vụ. Khi khởi động lại, bot có thể hỏi: cụm hiện có position nào mang comment LOCKDOWN_ABS hay không? Nếu có, nó tránh gửi thêm chân khóa chỉ vì tick kế tiếp vẫn thỏa điều kiện equity. Không có dấu định danh, mỗi vòng lặp có thể thấy bias cũ trong thời gian order chưa được đồng bộ và tạo nhiều lệnh đối ứng.

Comment không nên là lớp nhận diện duy nhất. Kiến trúc vững hơn còn lọc theo symbol, Magic Number, ticket và trạng thái lưu bền. Trong PyNhiQuaiBot, positions(magic) đã giới hạn theo symbol đang chạy và Magic; comment bổ sung ý nghĩa cho position trong phạm vi đó.

3. Chu trình trạng thái của auto lockdown

Cơ chế này dễ hiểu nhất khi mô hình hóa thành bốn trạng thái:

1. Sẵn sàng: auto lockdown bật, equity ở trên ngưỡng, cụm hoạt động bình thường.
2. Kích hoạt: equity chạm hoặc xuống dưới MinEqui2; bot tính chênh lệch và gửi LOCKDOWN_ABS.
3. Đóng băng: cờ _LOCKED bằng 1; bot dừng TP và dừng xử lý rải cụm.
4. Mở khóa logic: equity vượt MinEqui2; bot xóa cờ _LOCKED nhưng giữ position LOCKDOWN_ABS, sau đó logic lưới được chạy lại.

Trình tự trên có một lựa chọn thiết kế rất quan trọng: mở khóa trạng thái không tự đóng lệnh hedge. Trong cả MQ5 và bản Python, nhánh equity hồi phục chỉ xóa key _LOCKED. Chân LOCKDOWN_ABS vẫn nằm trong tài khoản và tiếp tục được tính vào volume cụm.

Điều này tránh hành động đóng hedge ngay tại một tick vừa vượt ngưỡng, vốn có thể tạo rung lắc đóng/mở liên tục quanh MinEqui2. Nhưng nó cũng làm thay đổi cấu trúc cụm sau mở khóa. Logic rải lưới phải nhìn position thực tế, tính bias mới và tôn trọng bộ lọc max_allowed_bias.

Điều kiện biên được viết có chủ đích

Kích hoạt dùng:

equity <= MinEqui2

Mở khóa dùng:

equity > MinEqui2

Hai điều kiện không để khoảng trống logic. Tại đúng giá trị ngưỡng, cụm vẫn thuộc trạng thái bảo vệ. Chỉ khi vượt lên mới xóa cờ frozen. Dù vậy, đây chưa phải hysteresis thực sự, vì chênh lệch chỉ có thể là một đơn vị rất nhỏ. Một thiết kế sản xuất có thể bổ sung UnlockEquity = MinEqui2 + buffer, yêu cầu equity duy trì trên ngưỡng trong một khoảng thời gian, hoặc xác nhận bằng nhiều snapshot liên tiếp.

4. Từ hàm handle_lockdown đến vòng lặp on_tick

Trong bản Python, handle_lockdown(magic) thực hiện chuỗi kiểm tra:

• thoát ngay nếu auto_lockdown tắt;
• đọc mt5.account_info();
• chọn MinEqui2 theo Magic;
• kiểm tra cờ frozen trong GVStore;
• kiểm tra có position comment LOCKDOWN_ABS;
• nếu frozen và equity đã vượt ngưỡng, xóa cờ;
• nếu equity thấp, chưa có hedge, tính volume lệch và gửi order;
• đặt _LOCKED = 1.

Sau đó on_tick() gọi hàm này cho cụm Buy và Sell. Chỉ khi is_full_hedge_frozen(magic) trả về false, bot mới gọi tp_logic() và process_cluster(). Trật tự này bảo đảm lớp phòng thủ được đánh giá trước các hành động thu hoạch hoặc mở mới.

Đây là quy tắc kiến trúc đáng học khi xây Python Bot Auto Trading: guard phải nằm trước action. Nếu bot mở thêm một lệnh rồi mới phát hiện equity đã vượt giới hạn, thứ tự kiểm soát bị đảo. Với vòng lặp nhanh, một tick sai thứ tự có thể tạo position mà chính sách rủi ro không cho phép.

“Đóng băng” thực sự dừng những gì?

Trong PyNhiQuaiBot, frozen ngăn hai nhóm hành động chính:

• không chạy logic TP theo X và trailing plow;
• không chạy core grid để mở hoặc bổ sung lệnh tại Step.

Dashboard vẫn được vẽ, trạng thái vẫn được lưu JSON, và hàm lockdown vẫn tiếp tục kiểm tra equity. Hệ thống không “ngủ” hoàn toàn; nó chuyển sang chế độ giám sát. Đây là khác biệt giữa pause nghiệp vụ và dừng process.

Nếu process bị tắt, bot không thể tự thấy equity phục hồi hoặc báo lỗi. Nếu chỉ pause action nhưng vẫn heartbeat, log và reconcile, người vận hành còn quan sát được hệ thống.

5. Vì sao mở khóa nhưng giữ LOCKDOWN_ABS?

Giữ chân hedge sau khi equity hồi phục có thể khiến người mới ngạc nhiên. Lý do đầu tiên là equity hồi một chút không chứng minh nguyên nhân rủi ro đã biến mất. Nếu đóng hedge ngay, cụm lập tức phơi lại net exposure đúng lúc thị trường có thể quay đầu lần nữa.

Lý do thứ hai là tách quyền hoạt động khỏi cấu trúc position. Cờ _LOCKED trả lời “core logic có được chạy không?”. Position LOCKDOWN_ABS trả lời “tài khoản đang có chân đối ứng nào?”. Hai sự thật không nên bị gộp thành một boolean.

Lý do thứ ba là tránh một thao tác đóng hàng loạt khó hoàn nguyên. Khi xóa cờ, bot có thể tiếp tục rải theo bias và trạng thái thực. Việc đóng chân khóa nên thuộc một quy trình recovery riêng, có điều kiện, giới hạn tốc độ và log rõ ràng.

Tuy nhiên, lựa chọn này không tự động đúng với mọi chiến lược. Nếu bot không có kế hoạch xử lý hedge tồn tại, chi phí giữ hai phía có thể tích lũy. Người phát triển cần định nghĩa một trong các chính sách:

• giữ khóa cho đến khi reset cả cụm;
• tháo khóa theo từng phần khi equity và margin hồi phục;
• chỉ đóng LOCKDOWN_ABS khi net exposure mục tiêu cho phép;
• chuyển chân khóa vào module recovery;
• yêu cầu xác nhận thủ công;
• đặt giới hạn thời gian rồi cảnh báo, không tự ý đóng.

6. Cờ _LOCKED và tính bền vững của trạng thái

Ở MQ5, trạng thái được lưu bằng GlobalVariableSet. Bản Python dùng GVStore, một dictionary được serialize ra JSON. Key có prefix gồm tên storage, symbol, login và Magic Number, sau đó nối _LOCKED. Thiết kế namespace này giảm nguy cơ bot BTCUSD đọc nhầm cờ của XAUUSD hoặc tài khoản khác.

Ví dụ hình thức key:

NHỊ QUÁI V6_BTCUSD_123456_6111_LOCKED

Nếu chỉ đặt tên LOCKED, nhiều instance chạy song song sẽ tranh cùng một biến. Prefix là phần thiết yếu của tính cô lập, không phải chi tiết trang trí.

GVStore được lưu ở cuối mỗi vòng on_tick() và khi reset. Nhờ vậy, restart process vẫn có thể khôi phục cờ. Tuy nhiên, JSON local không phải cơ sở dữ liệu giao dịch hoàn hảo. Việc ghi đè trực tiếp có thể gặp:

• process chết giữa lúc ghi;
• hai instance cùng sửa một file;
• file hỏng khiến _load() trả về dictionary rỗng;
• quyền thư mục hoặc ổ đĩa đầy;
• clock hoặc login thay đổi làm prefix khác;
• trạng thái JSON lệch với position thật trên terminal.

Vì position broker mới là nguồn sự thật cuối cùng, quá trình khởi động phải reconcile. Nếu có LOCKDOWN_ABS nhưng key _LOCKED mất, bot cần chính sách rõ: tái lập frozen, cảnh báo, hoặc chuyển sang recovery. Mã hiện tại dùng has_manual_lockdown() để tránh đặt thêm hedge, nhưng cờ frozen vẫn quyết định việc dừng core. Đây là điểm cần kiểm thử kỹ trước khi dùng ngoài demo.

7. Những kịch bản lỗi không thể bỏ qua

Order khóa bị từ chối

Hàm có thể tính d = 0,15, gọi order_send, nhưng broker từ chối vì thiếu margin, volume không hợp lệ, thị trường đóng hoặc filling mode sai. Nếu vẫn đặt _LOCKED = 1, bot ngừng rải nhưng cụm chưa được cân bằng. Về mặt fail-safe, dừng mở mới là hợp lý; về mặt quan sát, dashboard và log phải nói rõ “frozen nhưng hedge chưa xác nhận”.

Thiết kế tốt hơn nên lưu trạng thái chi tiết: LOCK_REQUESTED, LOCK_CONFIRMED, LOCK_PARTIAL, LOCK_FAILED. Boolean duy nhất không đủ diễn tả execution.

Partial fill hoặc volume làm tròn

MT5 package trả kết quả gửi lệnh, nhưng môi trường thực có thể tạo khối lượng khác dự kiến. Bot nên đọc lại positions, tính residual bias và chỉ đánh dấu hoàn tất khi residual nằm trong tolerance. Không nên tin tuyệt đối volume request.

Tolerance phải dựa trên volume_step của symbol. So sánh cứng abs(d) >= 0.01 chỉ phù hợp khi bước volume tương ứng. Một broker có minimum 0,1 hoặc step 0,001 sẽ cần quy tắc khác.

Equity rung quanh ngưỡng

Nếu equity 24.999,9 rồi 25.000,1 liên tục, cờ có thể bị xóa và đặt lại. Vì lệnh LOCKDOWN_ABS được giữ, bot không gửi thêm hedge, nhưng core logic có thể được bật ngắn hạn giữa các tick. Buffer mở khóa, debounce thời gian và yêu cầu nhiều lần xác nhận giúp giảm flapping.

Người dùng đóng tay chân LOCKDOWN_ABS

Nếu cờ _LOCKED còn 1 nhưng người dùng đóng position khóa, bot vẫn frozen. Ở tick sau, điều kiện equity thấp và has_hedge false có thể gửi lại chân khóa. Đây có thể là hành vi mong muốn, nhưng phải được tài liệu hóa. Nếu người vận hành muốn tháo khóa thủ công, họ cần đồng thời thay đổi chế độ hoặc dừng bot, nếu không automation sẽ tái lập trạng thái.

Tài khoản netting

Chiến lược dựa trên nhiều Buy/Sell đồng thời và comment theo position cần tài khoản hedging. Trên netting, một lệnh đối ứng có thể giảm position hiện hữu thay vì tạo chân khóa riêng. Khi đó has_manual_lockdown() theo comment có thể không phản ánh đúng. Kiểm tra account mode phải là điều kiện khởi tạo bắt buộc.

8. Cách kiểm thử auto lockdown có hệ thống

Không nên kiểm thử bằng cách chờ tài khoản thật drawdown. Hãy tạo adapter hoặc mock cho account_info, positions_get và order_send, sau đó chạy bảng kịch bản.

Kiểm thử ngưỡng

Với MinEqui2 = 25.000, cần ít nhất ba ca:

• equity 25.000,01: không kích hoạt;
• equity 25.000,00: kích hoạt;
• equity 24.999,99: kích hoạt.

Khi frozen, kiểm tra equity 25.000,01 phải xóa cờ; đúng 25.000 vẫn giữ cờ.

Kiểm thử hướng hedge

Tạo snapshot:

• Buy 0,30; Sell 0,10 → request Sell 0,20;
• Buy 0,10; Sell 0,30 → request Buy 0,20;
• Buy 0,20; Sell 0,20 → không gửi order nhưng vẫn chuyển chế độ bảo vệ;
• không có position → không gửi order, cần xác định có frozen hay không theo chính sách.

Ngoài direction và volume, phải kiểm tra Magic, symbol, comment và filling mode.

Kiểm thử idempotency

Gọi handle_lockdown() nhiều lần với cùng snapshot. Kết quả chỉ có một yêu cầu LOCKDOWN_ABS. Sau restart, load JSON và positions giả lập, hệ thống vẫn không gửi lệnh trùng.

Thử tình huống timeout: order thực tế đã tạo ở broker nhưng response về client bị mất. Lần chạy kế tiếp phải reconcile positions trước khi retry. Đây là ca đặc biệt quan trọng đối với mọi Python Bot Auto Trading.

Kiểm thử mở khóa

Khởi tạo _LOCKED = 1 và một position LOCKDOWN_ABS. Khi equity tăng, xác minh:

• key _LOCKED bị xóa;
• position khóa không bị đóng;
• process_cluster() được phép chạy ở tick phù hợp;
• bias mới bao gồm volume của chân khóa;
• log ghi rõ mở khóa logic và giữ hedge.

Kiểm thử lỗi lưu trữ

Tạo file JSON hỏng, file chỉ đọc và hai process cạnh tranh. Bot phải fail-safe: dừng action, phát cảnh báo và không mặc định “không có cờ nghĩa là an toàn”. Trong mã học tập hiện tại, lỗi load được chuyển thành state rỗng; khi nâng cấp vận hành, nên coi đây là sự kiện nghiêm trọng.

9. Hysteresis, cooldown và state machine nâng cao

Một phiên bản trưởng thành có thể tách ngưỡng khóa và ngưỡng mở:

lock_when   = equity <= 25.000
unlock_when = equity >= 26.000 trong 60 giây

Khoảng 1.000 chỉ là ví dụ. Mục đích là tạo hysteresis để hệ thống không đổi mode vì nhiễu nhỏ. Ngoài equity, điều kiện mở khóa có thể yêu cầu:

• margin level trên mức tối thiểu;
• spread đã bình thường;
• không có order pending chưa xác nhận;
• residual bias nằm trong tolerance;
• terminal và feed ổn định;
• người vận hành đã xác nhận kế hoạch recovery.

State machine có thể gồm:

NORMAL
  -> LOCK_PENDING
  -> LOCKED_CONFIRMED
  -> RECOVERY_READY
  -> RECOVERING
  -> NORMAL

Mỗi chuyển trạng thái phải có guard, timestamp, reason code và log. Nếu process restart ở LOCK_PENDING, bot đọc broker snapshot để quyết định đã khớp hay cần retry. Cách nghĩ này biến lockdown từ một câu if thành quy trình có khả năng phục hồi.

10. Quan sát và cảnh báo: phần không thể tách khỏi lockdown

Dashboard Nhi Quái V6 hiển thị equity, balance, trạng thái FullHed, P0, floating P/L, volume Buy/Sell và bias của từng cụm. Đây là nền tảng tốt, nhưng triển khai thực tế nên bổ sung:

• thời điểm lockdown bắt đầu;
• equity kích hoạt và equity hiện tại;
• volume yêu cầu, volume đã xác nhận, residual;
• ticket của LOCKDOWN_ABS;
• gross exposure và margin level;
• tổng swap/commission từ lúc khóa;
• số lần retry và mã lỗi gần nhất;
• trạng thái JSON persistence;
• lý do chưa được mở khóa.

Cảnh báo nên gửi khi chuyển trạng thái, không spam mỗi tick. Một event mẫu có thể mang account, symbol, magic, previous_state, new_state, equity, threshold, bias_before, hedge_ticket và correlation_id. Dữ liệu có cấu trúc giúp điều tra tốt hơn một chuỗi log tự do.

Đồng thời cần heartbeat. Nếu bot bị chết sau khi mở hedge, không có log mới không có nghĩa tài khoản an toàn. Hệ thống giám sát bên ngoài phải phát hiện heartbeat mất và thông báo cho người vận hành.

11. Nguyên tắc cấu hình MinEqui2 có trách nhiệm

Không tồn tại ngưỡng “chuẩn” cho mọi người. Quy trình cấu hình nên bắt đầu bằng câu hỏi:

1. Mức tổn thất tối đa theo chính sách là bao nhiêu?
2. Margin còn lại khi equity chạm ngưỡng có đủ để đặt hedge không?
3. Trong stress test gap và spread tăng, order khóa có thể trượt bao nhiêu?
4. Hai cụm có thể cùng kích hoạt không?
5. Chi phí giữ gross exposure trong một ngày, một tuần là bao nhiêu?
6. Nếu hedge thất bại, hành động dự phòng là gì?
7. Ai có quyền mở khóa và theo điều kiện nào?

Backtest giá đóng cửa không đủ trả lời. Cần mô phỏng tick, Bid/Ask, phí, latency, reject, partial fill và restart. Sau đó chạy demo hoặc tài khoản nhỏ trong thời gian đủ dài để quan sát trạng thái bất thường.

Không đặt MinEqui2 quá gần equity bình thường đến mức bot liên tục flapping. Cũng không đặt quá thấp khiến margin không còn đủ cho chân đối ứng. Ngưỡng phải liên kết với giới hạn lot, max positions, spread guard và kill switch tổng thể.

12. Các cải tiến nên cân nhắc cho PyNhiQuaiBot

Từ bản Python hiện tại, một lộ trình nâng cấp hợp lý gồm:

Xác nhận order trước khi coi đã khóa

Sau order_send, kiểm tra retcode, đọc lại position, tính residual và ghi ticket. Nếu thất bại, frozen vẫn có thể bật để dừng core nhưng state phải là LOCK_FAILED, kèm cảnh báo ưu tiên cao.

Ghi JSON theo cách atomic

Ghi vào file tạm, flush, fsync rồi rename atomically. Thêm schema version, checksum và backup gần nhất. Dùng file lock hoặc tách file theo instance để tránh ghi đồng thời.

Reconcile khi khởi động

Đọc positions từ MT5 trước, sau đó đối chiếu JSON. Nếu position LOCKDOWN_ABS tồn tại, không được xem cụm là NORMAL chỉ vì key thiếu. Nếu key còn nhưng position không có, đánh dấu inconsistency.

Bổ sung unlock buffer

Tách min_equi2 và unlock_equi, thêm unlock_hold_seconds. Khi equity vượt ngưỡng mở, bắt đầu timer; nếu rơi xuống trước khi hết thời gian, hủy quá trình mở.

Recovery có giới hạn

Không đóng toàn bộ hedge trong một lệnh mặc định. Có thể lập kế hoạch giảm từng phần theo residual bias, margin và trạng thái thị trường. Mọi hành động recovery phải idempotent, có max volume và cooldown.

Metrics và audit

Xuất số lần khóa, thời gian frozen, chi phí trong lúc khóa, residual bias, lỗi execution và số lần mở lại. Audit trail cần đủ để tái dựng tại sao bot hành động.

13. Full hedge không thay thế quản trị rủi ro nền tảng

Lockdown chỉ là một lớp. Trước nó vẫn cần:

• giới hạn lot và gross exposure;
• giới hạn số position;
• spread và market-hours guard;
• kiểm tra free margin;
• chống lệnh trùng bằng FSM/idempotency;
• timeout và retry có đối soát;
• giới hạn drawdown theo ngày;
• kill switch độc lập;
• backup, dashboard và cảnh báo;
• quy trình can thiệp thủ công.

Hedge cũng không bảo vệ khỏi mọi rủi ro phi tuyến. Gap, requote, stop-out, thay đổi contract, mất kết nối hoặc broker đóng một phía có thể phá giả định cân bằng. Với crypto CFD hoặc vàng, spread và swap trong thời điểm biến động mạnh có thể khác xa dữ liệu bình thường.

14. Checklist triển khai auto lockdown

Trước khi chạy, hãy xác nhận:

• tài khoản MT5 là hedging nếu chiến lược cần hai phía;
• symbol, contract size, tick value và volume step đã đọc đúng;
• Magic Buy/Sell khác nhau;
• MinEqui2 phù hợp từng tài khoản, không dùng mù giá trị mẫu;
• LOCKDOWN_ABS được nhận diện bằng symbol, Magic và comment;
• order result được kiểm tra và reconcile;
• frozen chặn mọi đường mở lệnh, không chỉ core loop chính;
• mở khóa không âm thầm đóng hedge;
• có hysteresis hoặc quy trình chống flapping;
• JSON có namespace, atomic write và cảnh báo lỗi;
• restart phục hồi đúng state;
• dashboard hiển thị residual bias và margin;
• đã kiểm thử reject, partial fill, timeout, restart và manual close;
• có người chịu trách nhiệm cho recovery;
• toàn bộ thử nghiệm bắt đầu ở môi trường demo.

Checklist không bảo đảm bot không thua. Nó giúp giảm lỗi phần mềm và lỗi vận hành có thể phòng tránh.

15. Bài học kiến trúc cho Python Bot Auto Trading

Auto lockdown của Nhi Quái V6 minh họa bốn bài học quan trọng. Thứ nhất, dữ liệu rủi ro cấp tài khoản phải được đọc trước hành động chiến thuật. Thứ hai, trạng thái “được phép chạy” phải tách khỏi position thật. Thứ ba, hành động gửi lệnh và kết quả khớp là hai sự kiện khác nhau. Thứ tư, persistence local luôn phải đối soát với nguồn sự thật tại broker.

PyNhiQuaiBot hữu ích như một dự án học tập vì người học nhìn thấy mối liên hệ giữa thuật toán, API và vận hành. Một dòng equity <= min_eq chỉ là điểm bắt đầu. Để biến nó thành module an toàn cần state machine, idempotency, persistence, observability, kiểm thử lỗi và quy trình recovery.

Nếu bạn đang học Python Bot Auto Trading, hãy thử tự viết test trước khi chỉnh tham số. Hãy buộc hệ thống trả lời được: điều gì xảy ra nếu order khóa bị reject, process chết, JSON hỏng, equity rung quanh ngưỡng hoặc người dùng đóng tay hedge? Khi các câu hỏi đó có đáp án kiểm chứng được, module mới tiến gần chất lượng vận hành.

Kết luận

Auto lockdown MinEqui2 trong PyNhiQuaiBot là cơ chế phòng thủ theo equity: đo chênh lệch Buy/Sell của từng Magic, tạo chân LOCKDOWN_ABS, đặt cờ frozen và dừng logic rải. Khi equity vượt ngưỡng, bot xóa cờ để hoạt động trở lại nhưng giữ chân hedge. Cách tách state và position này có giá trị kiến trúc, đồng thời đòi hỏi kế hoạch recovery rõ ràng.

Không nên diễn giải full hedge là khóa chắc thua lỗ hay bảo toàn tài khoản. Nó vẫn chịu phí, margin, execution và rủi ro hệ thống. Hãy kiểm thử trên demo, giới hạn vốn, giám sát liên tục và coi mọi tham số mặc định là dữ liệu minh họa.

Muốn học cách chuyển các luật phòng thủ như MinEqui2, FSM, Basket TP, trailing plow và lưu trạng thái thành một hệ thống Python có thể kiểm thử, bạn có thể xem lộ trình Lập trình Python nâng cao Hedging tự động hóa của Hướng Nghiệp Dữ Liệu. Nội dung tập trung vào tư duy xây bot, quản trị trạng thái và kiểm soát rủi ro; không cung cấp cam kết lợi nhuận hay tín hiệu đầu tư.

---

📌 Khóa Lập trình Python nâng cao Hedging (PyNhiQuaiBot)
Xem lộ trình & đăng ký · Zalo 0934.145.100 · Hướng Nghiệp Dữ Liệu