Liquidity Confirmation #9

Trả lời ngắn: Liquidity Confirmation là cách kiểm một ảnh chụp thị trường có thể đáp ứng một khối lượng giả định trong giới hạn spread, depth và chi phí đã viết trước hay không. Kết luận phải gắn với đúng venue, symbol, test size và thời điểm; nó không xác nhận hướng giá hoặc bảo đảm khớp lệnh.

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

• Vì sao volume cao chưa đủ chứng minh một giao dịch giả định sẽ khớp gần giá mong muốn.
• Cách tính spread, cumulative depth và giá trung bình ước tính từ order book.
• Khi nào dữ liệu phải trả thin, stale, unavailable hoặc skip.

Lưu ý giáo dục: Toàn bộ order book, khối lượng và giới hạn trong bài là dữ liệu giả. Bài không đề xuất mua, bán, đặt lệnh, TP, SL hay dùng tiền thật.

1. Volume cao chưa chắc khớp êm

a. Ví dụ quầy đổi tiền

Một quầy đổi tiền có giá mua và bán khác nhau. Đổi khoản lớn còn phải hỏi quầy có bao nhiêu tiền ở từng mức. Bảng giá cho 100 USD không bảo đảm đủ cho 10.000 USD.

Liquidity, hay thanh khoản trong bài này, là khả năng xử lý một khối lượng kiểm tra với chi phí và ảnh hưởng giá nằm trong giới hạn đã ghi. Nó không phải nhãn cố định kiểu “mã này luôn thanh khoản”.

Traded volume là lượng đã giao dịch. Displayed depth là lượng lệnh đang hiển thị tại các mức giá và còn có thể đổi. Hai dữ liệu không thay thế nhau.

CME từng cho thấy volume và book depth riêng lẻ có thể dẫn đến hai cách đọc khác nhau; fill quality cần được đặt cùng tốc độ giao dịch và điều kiện thị trường. CME Group — Assessing liquidity

b. Bid, ask và spread

Bid là mức giá cao nhất phía mua đang hiển thị. Ask là mức thấp nhất phía bán đang hiển thị. Spread bằng best ask trừ best bid.

Ví dụ bid 99,9, ask 100,1 thì:

spread = 100,1 − 99,9 = 0,2

Investor.gov cũng mô tả bid, ask và spread theo cách này, đồng thời lưu ý spread là một phần chi phí giao dịch. Investor.gov — ETF Bulletin

Liquidity Confirmation không nói hướng giá. Nó chỉ kiểm điều kiện thực hiện giả định với dữ liệu và size đã khóa.

2. Liquidity Evidence Card bốn ô

Hình 1 — Bốn ô dữ liệu phải cùng hợp lệ trước khi snapshot được phân loại.

a. Ô 1: nguồn, mã và thời gian

Order book, hay sổ lệnh, là danh sách bid và ask chưa khớp đang được venue hiển thị. Venue là sàn hoặc nơi dữ liệu đó được tạo.

Card phải ghi venue, symbol và timestamp. Hai sàn cùng niêm yết vẫn có order book khác nhau. Ảnh lúc 09:00 không đại diện cho 09:05.

Snapshot là ảnh chụp dữ liệu tại một thời điểm. Freshness là độ mới của snapshot so với giới hạn tuổi đã viết trước.

b. Ô 2: bid, ask và spread

Ghi best bid, best ask và phép trừ. Nếu thiếu một bên, không thể tính spread. Không dùng last price thay cho bid hoặc ask, vì giá giao dịch gần nhất có thể không còn là giá đang chào.

c. Ô 3: test size và depth

Test size là khối lượng giả định dùng để đo; nó không phải lệnh thật. Level là một mức giá trong order book. Cumulative depth là tổng quantity hiển thị qua các level đã chọn.

Depth phải đi cùng test size. Bảy đơn vị đủ cho sáu nhưng thiếu cho mười; “depth 7 là sâu” mà không nêu size là vô nghĩa.

d. Ô 4: chi phí trung bình và giới hạn

Estimated average cost là giá trung bình có trọng số nếu test size đi qua các ask level đang hiển thị. CME Liquidity Tool cũng tính cost to trade cho fixed lot size và không tính khi số lệnh không đủ. CME Group — Liquidity Tool Methodology

Giới hạn phải được viết trước: tuổi tối đa, spread tối đa, depth tối thiểu và giá trung bình tối đa. Các mốc trong bài chỉ thuộc demo.

Card trả một trong năm trạng thái:

• usable: snapshot đủ dữ liệu và qua toàn bộ giới hạn demo;
• thin: dữ liệu đủ nhưng spread, depth hoặc cost vượt giới hạn;
• stale: snapshot quá tuổi;
• unavailable: thiếu dữ liệu bắt buộc để tính;
• skip: chưa khóa venue, symbol, test size hoặc rule.

Usable không có nghĩa an toàn hay chắc chắn khớp. Nó chỉ nói card vừa qua bài kiểm đã viết.

3. Ví dụ LIQ Demo Book A/B

a. Book A

Book A dùng cùng một venue và symbol giả, snapshot age 1s:

Spread là 100,1 − 99,9 = 0,2. Test size bằng 6. Tổng ask depth ở hai level là 4 + 3 = 7, đủ để mô phỏng sáu đơn vị.

Bốn đơn vị đầu dùng giá 100,1; hai đơn vị còn lại dùng 100,2:

estimated average = (4×100,1 + 2×100,2) / 6

= 600,8 / 6 = 100,133

Demo đã khóa giới hạn: age ≤2s, spread ≤0,2, depth hai level ≥6, average ≤100,15. Book A qua cả bốn nên trả usable snapshot.

Hình 2 — Test size sáu buộc phép tính dùng bốn đơn vị ở L1 và hai đơn vị ở L2.

b. Book B

Book B cũng age 1s, cùng venue, symbol và test size:

Depth hai level vẫn là 2 + 5 = 7. Nhưng spread bằng 100,3 − 99,7 = 0,6.

Giá trung bình cho sáu đơn vị:

(2×100,3 + 4×100,6) / 6 = 603 / 6 = 100,5

Book B đủ displayed depth nhưng spread 0,6 và average 100,5 đều vượt rule demo. Output là thin.

Đây là điểm quan trọng: cùng depth 7 không đồng nghĩa cùng chất lượng thực hiện. Vị trí của quantity trên các mức giá quyết định chi phí mô phỏng.

c. Nhánh đóng an toàn

Nếu snapshot quá 2s, output là stale. Nếu thiếu bid, ask, timestamp hoặc không có đủ level để mô phỏng test size, output là unavailable. Chưa khóa venue, symbol, size và rule thì skip.

Không tự điền số thiếu bằng zero. Không đổi giới hạn sau khi thấy Book B fail.

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

Đoán chắc: “Depth đủ nên sáu đơn vị sẽ khớp ở 100,133.” Đúng hơn: “Snapshot hiện tại ước tính 100,133; quote còn có thể đổi trước khi thực hiện.”

a. Đồng nhất volume với liquidity

Volume cao nói nhiều giao dịch đã xảy ra. Nó không cho biết spread, depth và cost cho test size ở giây hiện tại. Ngược lại, depth thấp cũng chưa đủ kết luận thanh khoản tổng thể, vì quote có thể được bổ sung nhanh.

b. Nhìn một “tường lệnh”

Một quantity lớn có thể bị sửa hoặc hủy. Không gọi nó là “cá voi bảo vệ giá” vì displayed order không chứng minh danh tính hay ý định.

Hình 3 — Displayed quote là dữ liệu có thể đổi, không phải kho hàng được giữ riêng cho mình.

c. Dùng last price làm execution price

Last price là giao dịch gần nhất, không phải lời hứa cho giao dịch tiếp theo. Investor.gov lưu ý market order thường thực hiện nhanh nhưng execution price không được bảo đảm; lệnh lớn có thể khớp ở nhiều giá. Investor.gov — Understanding Order Types

Market order yêu cầu thực hiện ở giá tốt nhất đang có. Limit order đặt giới hạn giá nhưng có thể không khớp. Partial fill là khi chỉ một phần quantity được thực hiện. Bài chỉ giải thích rủi ro, không chọn loại lệnh.

d. Bỏ size, venue hoặc thời gian

“Spread nhỏ” phải nói nhỏ ở venue nào, lúc nào. “Depth đủ” phải nói đủ cho size bao nhiêu. Thiếu một trong ba thì kết luận không tái lập được.

e. Dùng threshold chung

Mốc 2s, 0,2, 6 và 100,15 là demo. Tick size, cấu trúc thị trường, tốc độ cập nhật và độ biến động khác nhau giữa sản phẩm. Không mang rule này sang tài sản thật.

Order book còn không hiển thị toàn bộ thanh khoản có thể xuất hiện sau đó; queue priority cũng ảnh hưởng ai được khớp trước. Vì vậy Card chỉ là ước tính snapshot, không phải mô hình execution đầy đủ.

5. Checklist áp dụng

1. Venue/source và symbol có khớp trên toàn bộ dữ liệu không?
2. Timestamp là gì và snapshot còn trong giới hạn tuổi không?
3. Đang mô phỏng phía ask hay bid?
4. Test size đã khóa trước khi xem book chưa?
5. Best bid và best ask có đủ để tính spread không?
6. Các level dùng để cộng depth đã ghi rõ chưa?
7. Cumulative depth có đủ cho test size không?
8. Estimated average được tính bằng weighted average nào?
9. Age, spread, depth và average có qua đúng rule viết trước không?
10. Output là usable, thin, stale, unavailable hay skip?

Snapshot stale thì chụp lại, không kéo dài tuổi bằng cảm tính. Thiếu một side hoặc level thì unavailable. Rule chưa khóa thì skip. Card qua rule vẫn phải giữ câu “không bảo đảm fill”.

6. Bài tập 15 phút

Mở Google Sheets, LibreOffice Calc hoặc máy tính miễn phí. Không kết nối broker và không gửi order.

Trong 10–15 phút:

1. Nhập Book A và B từ bài.
2. Tính ask − bid.
3. Cộng quantity hai ask level.
4. Tính weighted average cho test size 6.
5. So với rule demo, rồi ghi output.
6. Thử xóa best bid và đổi age thành 3s để xem fail-closed branch.

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

Kết quả đạt là người khác tính lại đúng và hiểu vì sao hai book cùng depth khác output. Không dùng tiền thật.

7. Tổng kết: thanh khoản phải gắn với size và thời điểm

a. Năm ý chính

• Liquidity Confirmation kiểm điều kiện thực hiện giả định, không xác nhận hướng giá.
• Volume đã giao dịch khác displayed depth đang chào.
• Spread, depth và estimated cost phải gắn với cùng venue, symbol, timestamp và test size.
• Cùng depth vẫn có thể cho chi phí khác vì quantity nằm ở các level khác nhau.
• Usable chỉ là snapshot qua rule; stale, thiếu dữ liệu hoặc chưa khóa rule phải fail closed.

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

• Vì sao volume cao chưa đủ gọi một snapshot là usable?
• Book A dùng quantity nào ở 100,1 và 100,2?
• Vì sao Book B thin dù cumulative depth cũng bằng 7?
• Khi thiếu best bid, Card trả trạng thái nào?

c. Gợi ý đáp án

Xem gợi ý câu 1

Volume kể lượng đã giao dịch, không cho đủ spread, depth và cost cho test size hiện tại. → Xem mục 1.

Xem gợi ý câu 2

Dùng `4` ở `100,1` và `2` ở `100,2` để đủ test size `6`. → Xem mục 3.

Xem gợi ý câu 3

Spread `0,6` và average `100,5` vượt giới hạn demo, dù tổng depth đạt `7`. → Xem mục 3.

Xem gợi ý câu 4

Không tính được spread nên output là `unavailable`, không tự điền zero. → Xem mục 2–3.

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

e. Nguồn tham khảo

• CME Group — Liquidity Tool Methodology
• CME Group — Assessing liquidity
• Investor.gov — Understanding Order Types
• Investor.gov — ETF Bulletin

f. Bài tiếp theo

Quay lại Multi-Timeframe Confirmation #8 để ôn data ownership và snapshot freshness. Tiếp tục với Invalid Setup: Khi nào phải bỏ kèo? #10 để biến các điều kiện fail thành quyết định đứng ngoài rõ ràng.

Nhắc lại: Nội dung này chỉ phục vụ giáo dục. Snapshot usable không bảo đảm giá khớp, không xóa rủi ro mất vốn và không thay thế hiểu sản phẩm hoặc quy tắc của venue.