Trả lời ngắn: Basket Trading trong EA là cách quản lý một nhóm vị thế đã định danh bằng cùng sổ thành viên, đơn vị quy đổi, cổng rủi ro và vòng đời. Nó giúp EA ra quyết định cấp nhóm nhưng không tự tạo đa dạng hóa hay lợi nhuận. Mỗi thành viên vẫn cần bằng chứng thực thi riêng.

Đọc xong, bạn sẽ hiểu: basket khác danh sách vị thế, Grid, Hedging và Portfolio EA; vì sao phải quy đổi; cách xác nhận từng thành viên; và lúc nhóm phải dừng vì phần dư.

Lưu ý giáo dục: B16, ngưỡng và đơn vị là dữ liệu giả để học kiến trúc, không phải công thức tạo nhóm hay lời khuyên giao dịch.

1. Basket là nhóm có hợp đồng, không phải phép cộng tùy ý

a. Món nằm cạnh giỏ chưa chắc thuộc giỏ

Nhóm vị thế có hợp đồng (basket) là tập hữu hạn được quản lý theo một mục tiêu, sổ thành viên và vòng đời. Thành viên (member) là vị thế được sổ nhận diện. Chủ sở hữu (owner) là bộ máy chịu trách nhiệm trạng thái nhóm.

Hình dung giỏ siêu thị. Món trên hóa đơn gắn với mã giỏ; hộp sữa đặt cạnh xe chưa tự thuộc giỏ. Ba vị thế cùng hiện trên màn hình cũng chưa chắc cùng basket.

Sổ thành viên (member registry) cần basketId, phiên bản, chủ, ID vòng đời và mã được phép. POSITION_MAGIC hay POSITION_COMMENT hỗ trợ nhưng chưa đủ chứng minh sở hữu. POSITION_IDENTIFIER ổn định trong vòng đời và liên kết lệnh/lần khớp. MQL5 Position properties

PositionGetTicket() chọn vị thế theo chỉ số; tài liệu khuyên chọn lại trước lúc đọc. Danh sách có thể đổi khi EA xử lý, nên chỉ số không phải ID thành viên. MQL5 PositionGetTicket

b. Basket không phải tên mới của mọi hệ thống nhiều lệnh

  • Danh sách vị thế cho biết tài khoản có gì; basket còn cần điều kiện thành viên và trạng thái.
  • Grid/DCA quy định tạo thêm chân; basket quản nhóm đã định danh.
  • Phòng hộ (hedging) nhắm tới bù phơi nhiễm; basket không nhất thiết bù.
  • Portfolio EA có thể quản nhiều chiến lược và basket.

Gom lệnh thua rồi chờ lệnh thắng “gánh” không tự thành quản trị rủi ro. Basket chỉ điều phối; tín hiệu, giới hạn và khả năng khớp do bộ máy khác chịu trách nhiệm.

2. Basket Controller và demo B16

a. Từ sổ thành viên đến sổ xác nhận

Luồng tối giản:

MEMBER REGISTRY → FRESH SNAPSHOT → NORMALIZE → AGGREGATE → BASKET GUARDS → UNIQUE MEMBER INTENTS → CONFIRMED LEDGER

Ảnh chụp dữ liệu (snapshot) là bộ giá trị tại một mốc. Độ mới (freshness) là tuổi tối đa. SymbolInfoTick() trả giá và lúc cập nhật gần nhất. Mã thiếu giá hoặc quá cũ khiến tổng hợp trả UNKNOWN/HALT. MQL5 SymbolInfoTick

Quy đổi (normalize) đưa đại lượng về cùng đơn vị. Không thể cộng ba quả với hai lít; lot các mã cũng khác nghĩa. OrderCalcProfit() ước tính bằng tiền tài khoản trong môi trường hiện tại, nhưng có thể khác thực tế. MQL5 OrderCalcProfit

Tổng hợp (aggregate) chỉ dùng thành viên hợp lệ, dữ liệu mới, cùng đơn vị. Cổng cấp nhóm (basket guard) kiểm giới hạn, ký quỹ và tài khoản trước khi tạo ý định.

Hình 1 — Basket chỉ đổi trạng thái khi dữ liệu đủ mới và từng thành viên có bằng chứng.

b. Tổng có dấu nhỏ vẫn có thể che chuyển động lớn

Demo B16 dùng ba thành viên A, B, C và đơn vị giả U. Công thức:

basket_pnl = Σ member pnl

absolute_movement = Σ |member pnl|

Snapshot A B C Basket P/L Absolute movement State
S0 +18 U -12 U -5 U +1 U 35 U ACTIVE
S1 +4 U -18 U -7 U -21 U 29 U EXIT_REQUESTED

S0 còn +1 U theo dấu nhưng ba chân dịch chuyển 35 U tuyệt đối. +1 cho thấy chúng đang bù nhau, không chứng minh rủi ro thấp.

S1 là -21 U, vi phạm ngưỡng giả -20 U, nên chuyển ACTIVE → EXIT_REQUESTED. Đây không phải ngưỡng ngoài đời.

Hình 2 — Tổng gần zero vẫn có thể che chuyển động trái dấu lớn giữa ba thành viên.

c. Yêu cầu đóng cả nhóm chưa phải nhóm đã đóng

Mỗi thành viên có khóa riêng: B16:X:A:v1, B16:X:B:v1, B16:X:C:v1. Ý định (intent) là đề nghị nội bộ; yêu cầu (request) là thao tác đã gửi; xác nhận (confirmed) cần bằng chứng máy chủ.

OrderSend() trả true chỉ cho biết kiểm tra cấu trúc và chấp nhận xử lý thành công, không chứng minh giao dịch hoàn tất. EA phải đọc mã trả về và sự kiện. MQL5 OrderSend

B16 có A/B đã đóng; C timeout, vẫn tồn tại. Basket phải vào RESIDUAL_HALT. Quét vé cả nhóm chưa chứng minh mọi người đã qua cổng.

Hình 3 — Hai thành viên đóng xong chưa đủ để gọi cả basket là CLOSED.

3. Chín lỗi và giới hạn phải giữ

a. Lỗi nhận diện và kế toán

  1. Quét toàn tài khoản: kéo cả lệnh tay hoặc EA khác vào basket.
  2. Một nhãn là đủ: coi mã nhận diện magic hay ghi chú là ID quan hệ hoàn chỉnh.
  3. Cộng lot khác mã: bỏ qua quy mô hợp đồng, đồng tiền và hướng.
  4. Ảnh chụp lệch nhịp: A dùng giá mới, C dùng giá cũ.
  5. Tổng dương = ít rủi ro: bỏ chuyển động trái dấu, ký quỹ và tương quan.
  6. Yêu cầu = xác nhận: đổi trạng thái trước bằng chứng.
  7. Thử lại mù: cùng nhịp xử lý tạo nhiều ý định đóng.
  8. Bỏ thay đổi ngoài luồng: không phát hiện đóng tay, đóng một phần hoặc mã vị thế đổi.
  9. Còn phần dư vẫn CLOSED: mất quyền quản lý chân cuối.

Thoát một phần (partial exit) nghĩa mới đóng vài thành viên. Phần dư (residual) còn chủ sau thoát. Chân mồ côi (orphan) mất bằng chứng sở hữu, nên phải dừng.

b. Những gì phép cộng P/L không nói được

P/L trong tiền tài khoản không thay thế phơi nhiễm, tương quan, thanh khoản hay ký quỹ. Hai vị thế đang ngược nhau vẫn có thể cùng giảm; các mã cũng không đóng cùng lúc.

Đóng nhiều thành viên không nguyên khối (non-atomic): không bảo đảm tất cả cùng thành công hoặc cùng giữ nguyên. Một yêu cầu có thể sinh nhiều sự kiện và thứ tự OnTradeTransaction không được đảm bảo. Phải ghi bằng chứng rồi đối chiếu vị thế/lịch sử. MQL5 OnTradeTransaction

AccountInfoDouble() cung cấp vốn, ký quỹ đã dùng và ký quỹ tự do. OrderCalcMargin() ước tính mà không tính lệnh chờ/vị thế mở hiện tại. Một số riêng lẻ không bảo đảm ký quỹ sau cả basket. MQL5 AccountInfoDouble, MQL5 OrderCalcMargin

4. Hợp đồng basket trước khi viết code

a. Mười tám câu hỏi

  1. basketId và phiên bản nào?
  2. Bộ máy nào sở hữu nhóm?
  3. Nguồn sổ thành viên ở đâu?
  4. Dùng ID vòng đời nào?
  5. Những mã nào được phép?
  6. Đơn vị quy đổi là gì?
  7. Báo giá được cũ tối đa bao lâu?
  8. Ảnh chụp hoàn tất khi nào?
  9. Trường nào được tổng hợp?
  10. Trần P/L, rủi ro và ký quỹ nào?
  11. Giới hạn thành viên/yêu cầu bao nhiêu?
  12. Khóa chống lặp gồm gì?
  13. Khi nào kết thúc build?
  14. Điều kiện thoát thuộc bộ máy nào?
  15. Thứ tự thoát được quy định ra sao?
  16. Đóng một phần, thử lại và timeout xử lý thế nào?
  17. Phần dư/chân mồ côi do ai phục hồi?
  18. Nguồn đối chiếu và công tắc dừng ở đâu?

Danh sách làm rõ quyền, dữ liệu và trạng thái cho phép.

b. Trình tự đóng khi bằng chứng thiếu

Trình tự: sổ thành viên → chọn lại vị thế → tick mới → quy đổi → tổng hợp → cổng tài khoản → khóa ý định → yêu cầu → sự kiện → đối chiếu vị thế/lịch sử → sổ.

Đối chiếu (reconciliation) so yêu cầu, sự kiện, vị thế và lịch sử. Thành viên mơ hồ, giá cũ, thiếu tỷ giá, xung đột chủ, hổng lịch sử hoặc phần dư đều trả UNKNOWN/HALT.

Khi có can thiệp tay, EA ghi thay đổi, đóng băng quyết định mới và đối chiếu; không nhận vị thế lạ chỉ vì trùng mã hoặc hướng.

5. Bảng Basket Ledger 15 phút

a. Cách làm

Dùng giấy hoặc Google Sheets; chưa mở MT5, kết nối tài khoản hay dùng tiền thật. Chép B16, tính S0/S1, đánh dấu ngưỡng giả -20 U, rồi điền ba khóa thoát.

b. Mẫu đối chiếu

Snapshot A B C Basket P/L Absolute movement State
S0 +18 U -12 U -5 U +1 U 35 U ACTIVE
S1 +4 U -18 U -7 U -21 U 29 U EXIT_REQUESTED
Member Unique key Request Evidence Result
A B16:X:A:v1 accepted close confirmed CLOSED
B B16:X:B:v1 accepted close confirmed CLOSED
C B16:X:C:v1 timeout position remains RESIDUAL

Kết quả là RESIDUAL_HALT. Gọi lại khóa C không tạo ý định thừa. Chỉ khi C có bằng chứng phù hợp và sổ hết member mở, basket mới được xét CLOSED.

6. Tổng kết: quản nhóm nhưng xác nhận từng chân

a. Năm ý chính

  • Basket là nhóm hữu hạn có sổ thành viên, chủ sở hữu và vòng đời.
  • Dữ liệu phải mới và được quy đổi trước khi tổng hợp.
  • P/L dương không chứng minh rủi ro thấp.
  • Yêu cầu đóng nhóm chưa chứng minh từng thành viên đã đóng.
  • Còn phần dư, chân mồ côi hoặc lịch sử mơ hồ thì UNKNOWN/HALT.

Bài trước là Hedging System trong EA. Bài tiếp theo là Recovery System trong EA #17.

b. Câu hỏi tự kiểm tra

  • Vì sao quét toàn bộ vị thế không tạo thành một basket hợp lệ?
  • B16 S0 có P/L nhóm và tổng chuyển động tuyệt đối bao nhiêu?
  • Vì sao A/B đóng rồi mà trạng thái vẫn là RESIDUAL_HALT?
  • OrderSend=true đã đủ xác nhận vị thế đóng chưa?

c. Gợi ý đáp án

Xem gợi ý câu 1

Basket cần sổ, chủ sở hữu và bằng chứng thành viên; tài khoản có thể chứa vị thế ngoài nhóm. → xem mục 1.

Xem gợi ý câu 2

S0 có tổng có dấu +1 U và tổng trị tuyệt đối 35 U. → xem mục 2.

Xem gợi ý câu 3

C timeout và vẫn mở, nên basket còn phần dư có chủ. → xem mục 2 và 5.

Xem gợi ý câu 4

Chưa; true không phải execution proof, cần retcode, transaction và đối chiếu trạng thái. → xem mục 2.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Basket Nhóm vị thế có hợp đồng quản lý chung.
Sổ thành viên Danh sách định danh thành viên hợp lệ của nhóm.
Snapshot Ảnh dữ liệu tại một mốc.
Quy đổi Đưa đại lượng về cùng đơn vị trước khi cộng.
Tổng hợp Cộng trường hợp lệ của các thành viên đã xác nhận.
Khóa duy nhất Khóa ngăn tạo lại cùng một ý định.
Phần dư Thành viên có chủ còn tồn tại sau quy trình thoát.
Chân mồ côi Vị thế tồn tại nhưng mất quan hệ sở hữu xác minh được.
Đối chiếu Dựng trạng thái từ yêu cầu, sự kiện, vị thế và lịch sử.

e. Nguồn tham khảo

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Basket Trading không thể loại bỏ rủi ro thị trường, tương quan, thanh khoản, ký quỹ hoặc lỗi thực thi.