“Giao dịch thuật toán” có thể mang nghĩa từ một bảng tính kiểm tra một quy tắc cho đến phần mềm định tuyến lệnh và đối soát khớp lệnh. Nhãn này không cho bạn biết loại nào đang chạy. Trước khi đánh giá một bot hay dựng một nguyên mẫu, hãy lần theo những gì xảy ra giữa một quan sát thị trường và một vị thế đã được xác nhận.
Tách nghiên cứu khỏi việc thực thi lệnh
Hãy bắt đầu với đặc tả nghiên cứu: thị trường và công cụ, nguồn dữ liệu, khung thời gian, các đầu vào có sẵn tại mỗi quyết định, điều kiện vào và ra, quy tắc quy mô vị thế, giả định chi phí, chuẩn so sánh và một điều kiện khiến bài kiểm thử không thể kết luận. Hãy đánh phiên bản cho đặc tả và bộ dữ liệu. Một backtest (kiểm thử lịch sử) nên để lại một sổ ghi mà người khác có thể kiểm tra, bao gồm cả những tín hiệu không trở thành khớp lệnh theo mô hình.
Sau đó, hãy phân biệt rõ ba trạng thái vận hành:
| Trạng thái | Điều có thể xác lập | Điều không thể xác lập |
|---|---|---|
| Mô phỏng lịch sử | Cách các quy tắc đã nêu vận hành trên dữ liệu lịch sử và giả định khớp lệnh đã chọn | Rằng dữ liệu là đầy đủ hay kết quả tương lai sẽ giống mẫu |
| Quan sát mô phỏng | Cách một quy trình ghi lại các quyết định giả định trong kỳ quan sát | Rằng lệnh có thể đến được sàn hay nhận được khớp lệnh như mô hình |
| Luồng gửi lệnh thực tế | Những gì các xác nhận đã xác thực từ sàn, khớp lệnh, phí và bản ghi tài khoản cho thấy | Rằng một chiến lược có lợi thế bền vững hay phù hợp với một người cụ thể |
Một bài kiểm thử phần mềm thành công chỉ bao trùm đúng hành vi mà nó đã chạy thử. Nó không xác minh một tài khoản sàn, một quyền API, một kho bí mật (secret store) trên môi trường production hay một lệnh thực tế.
Thiết kế ranh giới kiểm soát trước chiến lược
Nếu một hệ thống có thể gửi lệnh thật, hãy coi luồng vận hành của nó là một bài toán kỹ thuật riêng. Kiểm tra độ mới của dữ liệu và danh tính công cụ trước khi dùng một tín hiệu. Áp dụng giới hạn tối đa cho lệnh, phơi nhiễm và thua lỗ trước khi gửi yêu cầu. Lưu lại một mã quyết định duy nhất và mã tham chiếu lệnh phía khách hàng trước khi truyền đi, ở nơi sàn hỗ trợ. Mã tham chiếu đó giúp truy vấn và đối soát một yêu cầu chưa chắc chắn; nó không làm cho việc gửi trùng trở nên an toàn trên mọi sàn. Sau khi có phản hồi, hãy đối soát trạng thái lệnh và vị thế với bản ghi của sàn; một yêu cầu HTTP thành công không đồng nghĩa với một lần khớp lệnh.
Hãy định nghĩa hệ thống làm gì khi bất kỳ phần nào chưa chắc chắn. Một giá cũ, một khối lượng sai định dạng, một lệnh bị từ chối, một lần khớp lệnh một phần, mất kết nối hay một vị thế không rõ nên dừng mọi việc gia tăng rủi ro mới cho đến khi trạng thái được kiểm tra lại. Một công tắc dừng khẩn (kill switch) nên có tác dụng đã được kiểm thử rõ ràng, một người chịu trách nhiệm và một quy trình khôi phục. Bản thân một lệnh stop không đảm bảo giá thực thi hay ngăn được thanh lý theo quy tắc của sàn.
Hướng dẫn Rule 15c3-5 của SEC mô tả các kiểm soát rủi ro tiếp cận thị trường cho các công ty môi giới – tự doanh (broker-dealer) thuộc phạm vi điều chỉnh trên thị trường chứng khoán Hoa Kỳ, bao gồm các ngưỡng trước khi đặt lệnh và việc rà soát định kỳ. Quy tắc đó không phải là một danh mục kiểm tra chung áp đặt cho mọi script crypto bán lẻ, và cũng không phải là phát biểu về luật crypto ở mọi khu vực pháp lý. Phạm vi hẹp của nó là một ví dụ hữu ích về cách các kiểm soát tiếp cận thị trường có thể được phân công và ghi nhận; bất kỳ ai xây dựng hay vận hành một hệ thống đều phải tự xác định riêng những quy tắc thực sự áp dụng cho mình.
Đi qua một tình huống thất bại, không chỉ đường đi thuận lợi
Hãy hình dung một quy trình chiến lược gửi một lệnh và mạng bị quá thời gian chờ trước khi phản hồi đến. Yêu cầu có thể đã đến được matching engine ngay cả khi phía khách hàng không thấy câu trả lời nào. Tài liệu Spot REST của Binance ghi rõ một lỗi quá thời gian chờ (timeout) và một số lỗi máy chủ là trạng thái thực thi không xác định, và khuyên kiểm tra user stream hoặc truy vấn trạng thái lệnh. Hyperliquid có tài liệu về mã lệnh phía khách hàng (client order ID) và truy vấn trạng thái lệnh theo mã lệnh (order ID) hoặc mã client (client ID). Đây là những công cụ riêng của từng sàn, không phải một bảo đảm exactly-once (xử lý đúng một lần) phổ quát; hãy dùng hợp đồng hiện hành của sàn và đừng gửi lệnh thứ hai chỉ vì phản hồi đầu tiên bị mất. Xem hướng dẫn Binance Spot REST API, endpoint exchange của Hyperliquid và truy vấn trạng thái lệnh của Hyperliquid.
Hãy dùng một giao thức đối soát nhỏ và ghi lại bằng chứng đằng sau mỗi lần thay đổi trạng thái:
| Tình huống | Kiểm tra dựa trên bằng chứng của sàn | Quyết định vận hành |
|---|---|---|
| Yêu cầu quá thời gian chờ hoặc trả về lỗi máy chủ mơ hồ | Truy vấn bằng client ID gốc ở nơi được hỗ trợ; kiểm tra trạng thái lệnh và các lần khớp lệnh | Giữ quyết định ở trạng thái chưa giải quyết; không thử lại như một lệnh mới khi phơi nhiễm còn chưa rõ |
| Lệnh được khớp một phần hoặc một lệnh hủy đang chờ xử lý | Cộng từng lần khớp lệnh, phí và khối lượng còn mở; sau đó kiểm tra lại sau khi hủy | Định cỡ hành động tiếp theo từ phơi nhiễm đã đối soát, không phải từ khối lượng đã yêu cầu |
| Quy trình hoặc private stream kết nối lại | Làm mới lệnh mở, vị thế và các lần khớp lệnh gần đây; chỉ tiếp tục xử lý sự kiện sau khi trạng thái khớp nhau | Tạm dừng rủi ro mới nếu không thể đối soát một khoảng trống |
| Sàn trả về phản hồi giới hạn tần suất | Tuân theo hướng dẫn backoff của sàn đó và kiểm tra trạng thái lệnh/tài khoản hiện tại | Dừng việc thử lại liên tục; các yêu cầu lặp lại có thể kéo dài sự cố gián đoạn |
Ví dụ, hướng dẫn Spot REST của Binance nói rằng phản hồi 429 của họ nghĩa là đã vượt giới hạn tần suất, yêu cầu phía khách hàng phải backoff, và cảnh báo rằng vi phạm tiếp diễn có thể dẫn đến chặn IP. Đây là hành vi của Binance Spot, không phải lời hứa rằng một API khác dùng cùng các mã đó. Tài liệu exchange của Hyperliquid định nghĩa các lựa chọn time-in-force riêng: ALO hủy thay vì lấy thanh khoản ngay lập tức, còn IOC hủy phần còn lại chưa khớp. Những quy tắc đó ảnh hưởng đến kết quả lệnh, nên cùng một ý định chiến lược có thể để lại trạng thái vị thế khác nhau dưới các chỉ dẫn sàn khác nhau. Hãy ghi lại chính xác sàn, sản phẩm, phiên bản API và các cờ lệnh được dùng trong một buổi diễn tập.
Trước khi coi một bộ điều khiển thực thi là sẵn sàng cho bất kỳ triển khai nào, hãy chủ động chạy thử các tình huống thất bại đó trong một môi trường không phải môi trường thực. Hãy giả lập một báo giá cũ, một phản hồi bị mất sau khi được chấp nhận, một lần thực thi một phần trong lúc hủy, một lần ngắt kết nối private stream và một phản hồi giới hạn tần suất. Với mỗi tình huống, hãy xác minh rằng hệ thống không gia tăng phơi nhiễm từ một trạng thái không rõ và không mất dấu khối lượng còn lại, đồng thời một người vận hành có thể dừng, kiểm tra và tiếp tục nó từ bằng chứng đã ghi lại. Chỉ một phiên giao dịch mô phỏng theo đường thuận lợi thì không kiểm thử được việc khôi phục.
Với một công cụ hợp đồng tương lai hoặc có đòn bẩy, ranh giới kiểm soát còn gặp rủi ro tài khoản: khuyến nghị của CFTC về hợp đồng tương lai tiền mã hóa lưu ý rằng đòn bẩy có thể khuếch đại thua lỗ và dẫn đến yêu cầu ký quỹ bổ sung hoặc đóng vị thế trong bối cảnh hợp đồng tương lai mà nó đề cập.
Ranh giới thực tế của SuperQuant
SuperQuant cung cấp một công cụ nghiên cứu lịch sử chạy cục bộ và một quy trình luyện tập mô phỏng thủ công dùng các chuỗi lịch sử tổng hợp đi kèm. Sản phẩm không gửi lệnh lên sàn và không kết nối với tài khoản giao dịch của người dùng. Không nên mô tả nó như một bot tự động giao dịch. Để tìm hiểu phía nghiên cứu, hãy bắt đầu với ví dụ theo xu hướng, làm theo quy trình backtest, và so sánh giao dịch tùy ý và giao dịch hệ thống. Đây là hướng dẫn về kiến trúc, không phải lời khuyên về thực thi lệnh thật hay khuyến nghị chiến lược.