Building Institutional Trading Systems #29

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ư, tư vấn pháp lý hoặc tín hiệu giao dịch.

Trả lời ngắn: Institutional algorithmic trading system là hệ thống thuật toán có owner rõ, contract dữ liệu có version, risk gate độc lập, evidence truy vết và quyền dừng trước execution. Chữ “institutional” nói về kỷ luật kiến trúc, vận hành; không tự nói hệ thống có nhiều vốn, lợi nhuận cao hay miễn sai sót.

Đọc xong, bạn sẽ hiểu:

• Cách chia một trading system thành 8 lớp có ranh giới và owner rõ.
• Khác biệt giữa data plane xử lý event với control plane quản trị release, policy và quyền dừng.
• Vì sao một lỗi reconciliation đủ chặn release dù các test khác đều pass.

1. Institutional trading system là gì và không phải là gì?

Architecture là cách chia hệ thống thành những phần có nhiệm vụ, đầu vào, đầu ra và ranh giới rõ. Một architecture “institutional” không bắt đầu bằng máy chủ đắt tiền. Nó bắt đầu bằng câu hỏi: ai được tạo thay đổi, ai được duyệt, thành phần nào được từ chối, bằng chứng nằm đâu và khi nào phải dừng.

Hãy hình dung bếp nhà hàng. Người nhận đơn không tự sửa tồn kho. Bếp nấu món nhưng không tự xác nhận khách đã nhận. Người kiểm món có quyền giữ món sai. Thu ngân đối chiếu phiếu, món giao và hóa đơn. Nhà hàng nhỏ vẫn có thể làm việc có kỷ luật; nhà hàng lớn vẫn có thể rối nếu một người vừa nhận đơn, nấu, thu tiền rồi tự xóa sổ.

Trong trading system, cách tách quyền đó gọi là separation of duties: bên đề xuất, bên kiểm risk, bên vận hành release và bên đối soát không nhập nhằng thành một quyền. Nhóm nhỏ vẫn có thể tách vai trò, credential, log và bước phê duyệt.

Hình 1 — Institutional là owner, contract, control và evidence; không phải nhãn cho số vốn lớn.

EA có thể compile, backtest và gửi request đúng API nhưng vẫn thiếu:

• identity của data/model/config đang dùng;
• independent risk gate có quyền chặn;
• release record nối code với config và approval;
• reconciliation nối intent, request, result và position;
• alert có owner và runbook;
• kill path không phụ thuộc chính thành phần đang lỗi.

SEC Rule 15c3-5 áp dụng cho broker-dealer có market access tại Mỹ, không phải mặc định cho mọi người đọc. Dù vậy, nguyên tắc của rule rất đáng học: pre-set threshold, ngăn erroneous order, giới hạn access cho người được phép, nhận post-trade report và review control có tài liệu (SEC — Market Access Rule). Ta dùng đó làm nguồn tư duy kiểm soát, không tuyên bố phạm vi pháp lý.

Institutional không có nghĩa chiến lược chắc thắng, latency luôn thấp, hệ thống không lỗi, mua nhiều service là có architecture hay dashboard đẹp là có audit trail.

Kết luận chắc chắn trong contract bài này: gate FAIL thì release BLOCKED. Kết luận có điều kiện: số layer, công nghệ và quy trình phê duyệt ngoài đời còn tùy broker, asset, luật, đội vận hành và quy mô.

2. Bản đồ 8 lớp và hai luồng control/data

Kiến trúc bài này có 8 lớp. Đây là bản đồ học tập, không phải chuẩn bắt buộc của ngành.

1. Market Data Ingest nhận tick, bar, quote và trạng thái nguồn.
2. Normalize + Reference Data chuẩn hóa symbol, timezone, session, precision và mapping. Reference data là dữ liệu mô tả thị trường, không phải giá chạy từng tick.
3. Research + Replay lưu dataset, feature spec, test fixture và tái hiện decision trong môi trường tách production.
4. Strategy Proposal tạo intent có schema; proposal chưa phải order.
5. Independent Risk kiểm account, exposure, limit, freshness và kill state. “Independent” nghĩa gate có quyền từ chối và không dùng kết quả do strategy tự duyệt.
6. OMS + Execution Adapter quản lý vòng đời request rồi dịch request hợp lệ sang API broker. OMS là Order Management System; OMS không tự đồng nghĩa broker đã nhận hoặc đã fill.
7. Ledger + Reconciliation ghi intent, request, acknowledgement, fill, position và delta.
8. Observability + Governance quản lý metric, alert, incident, release, approval, audit và owner.

Hai luồng chạy xuyên qua 8 lớp:

• Data plane xử lý snapshot, proposal, risk decision, order request, result và ledger của từng event.
• Control plane quản lý identity, policy, release, config, approval, quyền truy cập và kill state.

Ví dụ bếp: phiếu món đi qua bếp là data plane. Menu, quyền nhân viên, danh sách món cấm, lịch ca và nút đóng bếp là control plane. Nếu policy đang ở version không xác định, data plane không được tự chọn policy “gần đúng”.

NIST Zero Trust nói không cấp implicit trust chỉ vì user, device hoặc service ở trong mạng nội bộ; authentication và authorization cần gắn với resource, identity và policy (NIST SP 800-207). Áp vào trading architecture: service nội bộ vẫn phải có identity, least privilege và quyền đúng nhiệm vụ. Strategy service không cần credential để sửa audit log. Dashboard đọc position không cần quyền gửi order.

Contract giữa hai lớp tối thiểu có schema/version, source identity, timestamp/expiry/sequence, idempotency key, allowed states, reject reason, owner và escalation path.

Hình 2 — Mỗi decision đi qua contract và để lại trail; control plane không bị giấu trong strategy code.

Ranh giới quan trọng nhất nằm giữa proposal và independent risk. Strategy có thể nói “tôi muốn làm X”. Risk service trả ALLOW, REDUCE, REJECT hoặc HALT theo policy đã khóa. OMS chỉ nhận decision hợp lệ, đúng release và còn hạn.

Tôi từng nghĩ tách nhiều server là đủ; sai ở chỗ server tách mà quyền và evidence vẫn nhập nhằng. Hai service chạy trên hai máy nhưng dùng chung admin credential, chung mutable file và chung log xóa được thì blast radius vẫn lớn.

3. Một decision đi từ dữ liệu đến bằng chứng như thế nào?

Giả sử một snapshot hợp lệ đi vào strategy:

snapshot → proposal → risk decision → OMS request → broker adapter → result → ledger → reconciliation

Mỗi bước thêm identity, không xóa identity trước. Snapshot có snapshot_id; proposal có proposal_id; risk decision trỏ lại proposal và policy hash; OMS request có idempotency key — khóa nhận diện để cùng request không bị xử lý lặp; result trỏ lại request; reconciliation nối tất cả với position thực tế.

Release artifact là bộ code, config, schema, policy và dependency được định danh như một đơn vị. Chỉ ghi “version 29” chưa đủ. Hai deploy cùng code nhưng khác config hash là hai release khác nhau vì behavior có thể khác.

Release record nên có:

FINRA Regulatory Notice 15-09 là guidance cho member firms Mỹ. Notice đề cập code development, independent QA, test control, data/workflow validation, test record, remediation và significant testing trong môi trường tách production. Notice cũng nhấn mạnh monitoring, alert và reconciliation sau khi algorithm đi vào production (FINRA — Regulatory Notice 15-09).

Test ladder gồm static/schema, unit/integration, recorded replay, rejection tests, reconciliation drill, approval gate, rồi mới shadow/canary có exposure và stop rule rõ.

AWS Well-Architected gom kiến trúc vận hành vào các trụ như operational excellence, security và reliability; reliability bao gồm khả năng phục hồi khỏi disruption, còn operational excellence nhấn mạnh quan sát, phản ứng sự kiện và cải tiến (AWS Well-Architected). Đây là hướng dẫn kiến trúc chung, không phải regulation giao dịch.

Reconciliation là đối chiếu nhiều nguồn để tìm thiếu, thừa hoặc lệch state. Ví dụ: strategy ledger có ba intent, OMS có ba request, broker result có hai acknowledgement và position snapshot chỉ có hai position. Delta bằng một không được “lấp” bằng giả định request còn lại thất bại. Trạng thái chưa phân loại phải dừng và điều tra.

4. Case INST29: release bị chặn bởi reconciliation

Case giả lập dùng contract INST29:RELEASE:V1:

• release REL-2901;
• build B29-F3;
• fixture MD29-20260726;
• config CFG-29A.

Các số dưới đây là quy ước bài học, không phải threshold chuẩn ngành.

Approval ledger:

Hình 3 — Bốn nhóm test pass không bù được một reconciliation delta chưa phân loại.

Ops giữ approval vì expected positions 3, actual positions 2. Delta:

delta = expected - actual = 3 - 2 = 1

Ta biết chắc delta bằng một trong case. Ta chưa biết chắc nguyên nhân là request mất, result đến muộn, mapping sai hay ledger ghi trùng. Vì vậy verdict:

BLOCKED · FIX RECONCILIATION · RE-RUN ALL GATES

Canary requests 0; production orders 0.

Không sửa reconcile rồi mở release bằng test cũ. Fix có thể đổi contract, state transition hoặc timing; phải tạo revision có hash mới và chạy lại gate.

Dev chứng minh build, Risk chứng minh reject cases, Ops chứng minh deploy và reconciliation. Dev không ký thay Ops chỉ vì deadline.

5. Sai lầm, giới hạn và rủi ro

Sai lầm 1: monolith không có contract nội bộ. Một file lớn chưa chắc xấu, nhưng nếu data, strategy, risk, execution và log dùng chung mutable state thì không thể chỉ ra decision boundary.

Sai lầm 2: strategy tự tính rồi tự duyệt risk. Strategy có thể tính candidate size; independent risk phải đọc policy/account state từ nguồn được kiểm soát và có quyền reject.

Sai lầm 3: log nhiều nhưng không correlate. Một triệu dòng log không giúp nếu thiếu release ID, proposal ID, request ID và result ID.

Sai lầm 4: retry mọi timeout. Timeout không nói bên kia chưa xử lý. Thiếu idempotency và reconciliation, retry có thể tạo duplicate.

Sai lầm 5: dashboard xanh nghĩa là an toàn. Metric không có owner, threshold, runbook và alert delivery chỉ là hình trang trí.

Sai lầm 6: dùng last-known-good cho unknown control state. Last-known-good có thể hợp lệ cho read-only display, nhưng không nên tự mở new execution khi policy, permission hoặc kill state chưa xác minh.

Blast radius là phạm vi thiệt hại tối đa khi một component, account, release hoặc credential lỗi. Giảm blast radius bằng account isolation, least privilege, per-strategy cap, staged rollout và independent global stop. Nếu tất cả worker cùng credential và cùng config mutable, nhiều worker không tạo containment thật.

Hình 4 — Người tạo thay đổi không tự duyệt, tự chạy rồi tự xóa bằng chứng của cùng release.

Giới hạn cần nói thẳng: tám lớp không tạo trading edge; thêm service tăng latency, chi phí và failure modes; reconciliation phát hiện lệch nhưng không tự suy ra nguyên nhân. Regulation tùy thị trường, pháp nhân và quyền market access. High availability không thay data correctness; disaster recovery không thay independent risk.

Fail closed trong bài nghĩa là missing, stale, conflicting hoặc unknown control state chặn new execution. Fail closed không nhất thiết tắt monitoring, reconciliation hay thao tác giảm rủi ro đã được định nghĩa trước. Stop behavior phải được thiết kế và test, không viết mơ hồ “an toàn thì dừng”.

6. Checklist kiến trúc và bài tập 15 phút

Checklist trước khi gọi một trading system là vận hành được:

1. Liệt kê 8 lớp và owner của từng lớp.
2. Ghi input/output schema, version và source identity.
3. Tách data plane khỏi control plane trên sơ đồ.
4. Strategy chỉ tạo proposal; independent risk giữ reject authority.
5. OMS có state machine và idempotency key.
6. Broker result không được suy ra từ request success.
7. Ledger nối release, snapshot, proposal, decision, request và result.
8. Reconciliation có expected, actual, delta và reason state.
9. Credential theo least privilege; audit store không cho strategy xóa.
10. Release artifact khóa code/config/schema/policy/dependency.
11. QA/replay/rejection/reconciliation chạy trong môi trường phù hợp.
12. Approval gắn với đúng artifact và đúng evidence.
13. Alert có owner, severity, delivery test và runbook — hướng dẫn xử lý có thứ tự.
14. Kill path độc lập với component cần dừng.
15. Unknown state → block; không tự dùng stale fallback.
16. Chỉ cân nhắc shadow/canary sau khi local/replay gate pass.

a. Bắt đầu từ đâu

Dùng Google Sheets, LibreOffice Calc hoặc giấy. Chưa kết nối broker, chưa nhập credential, chưa dùng tiền thật.

Trong 15 phút, tạo 8 hàng ứng với 8 lớp và năm cột: Owner, Input, Output, Fail action, Evidence. Điền mẫu:

b. Mẫu đối chiếu đã điền

Sau đó điền REL-2901. Kết quả đúng: schema PASS, 184/184 PASS, 12/12 PASS, 7/7 PASS, reconcile 3 vs 2 FAIL, Ops WITHHELD, verdict BLOCKED, requests 0, production orders 0.

Hình 5 — Mỗi layer cần owner, contract, fail action và evidence trước khi nói đến deploy.

Nếu sheet của bạn vẫn cho release pass, approval logic đang đếm số gate pass thay vì yêu cầu tất cả mandatory gate pass. Sửa thành ALL mandatory gates = PASS; không dùng majority vote.

7. Tổng kết

a. Năm ý chính

• Institutional nói về ownership, control và evidence; không đồng nghĩa vốn lớn hay lợi nhuận.
• Tám lớp tách data, research, proposal, risk, execution, reconciliation và governance.
• Data plane xử lý từng decision; control plane quản lý identity, policy, release, approval và kill.
• Independent risk, idempotency và reconciliation ngăn strategy tự duyệt hoặc retry mù.
• REL-2901 bị BLOCKED vì reconcile delta 1; bốn nhóm test pass không bù gate FAIL.

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

• Vì sao nhiều server chưa chắc tạo separation of duties?
• Data plane và control plane khác nhau ở đâu?
• Vì sao request success không chứng minh broker đã fill?
• Tại sao REL-2901 phải chạy lại gate sau khi sửa reconciliation?

c. Gợi ý đáp án

Xem gợi ý câu 1

Server tách nhưng credential, quyền duyệt và evidence còn dùng chung thì blast radius vẫn lớn. Xem mục 1 và 2.

Xem gợi ý câu 2

Data plane xử lý event/decision; control plane quản trị identity, policy, config, release, approval và kill. Xem mục 2.

Xem gợi ý câu 3

Request có thể timeout, bị reject hoặc chưa có result; phải nối acknowledgement/fill/position bằng ledger và reconciliation. Xem mục 3.

Xem gợi ý câu 4

Fix có thể đổi contract, transition hoặc timing; evidence cũ không tự chứng minh artifact mới. Xem mục 4.

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

e. Nguồn tham khảo

• SEC — Risk Management Controls for Brokers or Dealers With Market Access
• FINRA — Regulatory Notice 15-09
• NIST — Zero Trust Architecture SP 800-207
• AWS — Well-Architected Framework pillars

f. Học tiếp

Bài trước, AI + EA Integration #28, khóa typed proposal và deterministic gates. Bài tiếp theo, AI79 Professional EA Framework #30, sẽ gom toàn bộ series thành một framework release và vận hành cuối khóa.

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ư, tư vấn pháp lý hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.