Paper Trading và Live Trading khác Backtest ở độ trễ, lỗi hệ thống và tâm lý thực thi thế nào?

Một strategy có Sharpe 1.5 trong backtest chưa có nghĩa khi chạy thật sẽ giữ được Sharpe 1.5. Khoảng cách giữa backtest và live trading thường không đến từ một nguyên nhân duy nhất mà tích lũy qua cả chuỗi thực thi: dữ liệu đến chậm hơn, tín hiệu được tính sau vài mili giây hoặc vài giây, lệnh gửi đi có độ trễ, giá đã thay đổi khi lệnh tới sàn, một phần lệnh không khớp, hệ thống có thể mất kết nối, broker trả lỗi, và cuối cùng người vận hành có thể can thiệp vì sợ hãi hoặc kỳ vọng. Paper trading nằm giữa hai thế giới này: nó sử dụng dữ liệu gần real-time và có thể kiểm tra phần lớn pipeline vận hành, nhưng vẫn chưa tái hiện đầy đủ áp lực của tiền thật.

1. Backtest giả định một thế giới quá sạch, còn Paper Trading bắt đầu đưa strategy vào thời gian thực

Backtest thường chạy trên dữ liệu lịch sử đã hoàn chỉnh. Một strategy breakout có thể được viết rất gọn:

high_20 = close.shift(1).rolling(20).max()
entries = close > high_20
exits = close < close.rolling(10).mean()

Sau đó engine giả định rằng khi entries=True, lệnh được thực hiện theo một quy tắc xác định trước như giá Close, Open phiên sau hoặc một mức giá mô phỏng. Với dữ liệu daily, toàn bộ quá trình từ “nhận dữ liệu → tính signal → gửi order → broker nhận lệnh → exchange khớp” thường bị rút gọn thành một dòng code. Điều này rất tiện để nghiên cứu strategy, nhưng execution ngoài thị trường không diễn ra tức thì.

Trong live trading, chuỗi thực tế gần hơn với:

Market Data
→ Data Feed
→ Strategy Engine
→ Risk Check
→ Order Manager
→ Broker API
→ Exchange
→ Fill
→ Portfolio Update

Mỗi bước đều tạo ra latency. Giả sử strategy phát hiện breakout tại giá 100.00. Trong backtest, giá entry có thể được ghi đúng 100.00. Nhưng live system mất 150 ms để nhận tick, 20 ms xử lý signal, 80 ms qua risk engine và network, sau đó broker và exchange mất thêm thời gian để xử lý. Khi lệnh tới order book, best ask đã thành 100.15. Chênh 0.15% nghe nhỏ, nhưng nếu expected edge trung bình mỗi trade chỉ khoảng 0.5–1%, execution cost đã ăn mất một phần đáng kể alpha.

Paper trading hữu ích vì bắt đầu chạy strategy trên clock thật. Data feed đến lúc nào thì system xử lý lúc đó; API có timeout thì strategy phải đối diện với timeout; scheduler chạy sai giờ thì signal có thể bị bỏ lỡ. Nhưng paper trading vẫn thường giả lập fill theo cách thuận lợi hơn thị trường thật. Một market order có thể được đánh dấu “filled” ở best ask mà không xét market impact. Một limit order có thể được coi là khớp khi giá chạm mức limit, dù thực tế phía trước còn hàng nghìn cổ phiếu đang xếp hàng.

Đây là lý do kết quả thường có cấu trúc:

Backtest Return > Paper Return > Live Return

không phải lúc nào cũng đúng tuyệt đối, nhưng là điều rất thường gặp khi execution assumptions của backtest quá lạc quan.

Một cách tốt hơn là cố tình làm backtest “xấu” hơn. Ví dụ thay vì:

fees = 0.001
slippage = 0

có thể stress test:

fees = 0.001
slippage = 0.001

rồi tiếp tục thử:

Slippage = 0.05%
Slippage = 0.10%
Slippage = 0.20%
Slippage = 0.30%

Nếu Sharpe giảm từ 1.5 xuống 1.3, 1.1, 0.8 rồi 0.4 chỉ sau vài thay đổi nhỏ về execution cost, strategy đang phụ thuộc rất mạnh vào giả định khớp lệnh.

Latency cũng có thể được stress bằng cách delay signal:

entries_t0 = signal
entries_t1 = signal.shift(1)
entries_t2 = signal.shift(2)

Nếu strategy daily vẫn tốt khi entry chậm một phiên, edge thường bền hơn strategy chỉ hoạt động khi mua chính xác tại một thời điểm mà thực tế khó khớp. Với intraday system, logic tương tự có thể áp dụng trên tick, second hoặc minute bars.

Backtest vì vậy chủ yếu trả lời: logic này có edge trên dữ liệu lịch sử không? Paper trading bắt đầu trả lời câu khác: hệ thống có thể tạo signal và gửi order đúng thời điểm trong môi trường đang chạy thật không?

2. Live Trading thêm một loại rủi ro mà backtest gần như không thấy: lỗi hệ thống và execution failure

Một strategy có thể đúng hoàn toàn về mặt thống kê nhưng vẫn mất tiền nếu infrastructure sai. Live trading không chỉ có market risk mà còn có operational risk.

Giả sử strategy dự kiến mua 10.000 cổ phiếu. Code gửi:

broker.place_order(
    ticker="ABC",
    side="BUY",
    quantity=10_000,
    price=25_000
)

Trong notebook, đây chỉ là một function call. Trong production có rất nhiều trạng thái cần xử lý:

NEW
SENT
ACKNOWLEDGED
PARTIALLY_FILLED
FILLED
REJECTED
CANCEL_PENDING
CANCELLED
UNKNOWN

Nếu API timeout sau khi gửi lệnh, system không thể đơn giản gửi lại vì lệnh đầu tiên có thể đã tới broker. Gửi lần hai có thể tạo duplicate order. Nếu system tưởng lệnh chưa khớp nhưng thực tế đã khớp, portfolio nội bộ sẽ lệch khỏi tài khoản thật. Nếu WebSocket mất kết nối vài giây, strategy có thể bỏ lỡ market data. Nếu dữ liệu bất thường trả về giá bằng 0 hoặc volume null mà không có validation, signal engine có thể tạo lệnh sai.

Một live system tối thiểu vì vậy cần nhiều lớp kiểm tra hơn backtest:

if data_is_stale:
    block_trading()

if position > position_limit:
    block_order()

if order_value > max_order_value:
    reject_order()

if broker_position != internal_position:
    trigger_reconciliation()

Một phần quan trọng khác là reconciliation. Sau mỗi phiên hoặc thậm chí trong phiên, position mà strategy nghĩ mình đang giữ phải được đối chiếu với position tại broker:

internal = get_internal_positions()
broker = get_broker_positions()

diff = broker - internal

Nếu diff != 0, system không nên tiếp tục giao dịch như chưa có chuyện gì xảy ra.

Paper trading có thể kiểm tra phần lớn logic này, nhưng nhiều môi trường paper vẫn “hiền” hơn live. Broker có thể không mô phỏng đầy đủ order reject, partial fill, queue priority, disconnect hoặc biến động mạnh. Vì vậy sau paper trading nên có một giai đoạn live với quy mô vốn rất nhỏ thay vì chuyển thẳng từ simulation sang full size.

Có thể coi quá trình triển khai strategy thành:

Research Backtest
→ Robustness Test
→ Paper Trading
→ Small Live
→ Normal Live
→ Scale Up

Mỗi bước kiểm tra một loại rủi ro khác nhau. Backtest kiểm tra statistical edge. Paper kiểm tra pipeline. Small live kiểm tra execution assumptions. Scale-up mới kiểm tra capacity và market impact.

Một strategy có thể vượt qua ba bước đầu nhưng thất bại khi scale vốn. Ví dụ với 100 triệu đồng, lệnh gần như không tác động giá. Với 10 tỷ, strategy bắt đầu chiếm tỷ lệ đáng kể volume tại một số mã. Giá entry trở nên xấu hơn, thời gian fill dài hơn và khả năng exit trong phiên biến động mạnh giảm xuống. Capacity vì vậy là một phần của live trading mà paper rất khó mô phỏng chính xác.

3. Tâm lý thực thi là khoảng cách lớn nhất giữa Paper và Live Trading

Paper trading có thể mô phỏng data feed, signal, order và thậm chí slippage khá tốt. Thứ nó gần như không thể mô phỏng hoàn chỉnh là phản ứng của con người khi P&L trở thành tiền thật.

Giả sử backtest cho thấy strategy có Max Drawdown -18%. Khi nhìn chart lịch sử, -18% chỉ là một đoạn đi xuống trên equity curve. Nhưng live trading không cho biết trước drawdown sẽ dừng ở -18%. Khi tài khoản đang -8%, rồi -12%, rồi -15%, người vận hành không biết đó là drawdown bình thường hay edge đã biến mất.

Đây là lúc hành vi bắt đầu thay đổi.

Strategy quy định:

Position Size = 10%
Stop Loss = -7%
Hold tối đa = 20 phiên

Nhưng sau ba lệnh thua liên tiếp, trader giảm size xuống 3%. Lệnh tiếp theo lại thắng lớn. Sau vài lệnh thắng, trader tăng size lên 15% đúng lúc strategy bước vào chuỗi thua. Hoặc system phát tín hiệu mua nhưng thị trường vừa giảm mạnh nên người vận hành bỏ qua vì “cảm giác chưa an toàn”. Những can thiệp như vậy khiến live track record không còn là track record của strategy ban đầu.

Một hiện tượng khác là profit interference. Backtest nói giữ lệnh 15 ngày, nhưng khi live trade đang lãi 6% sau ba ngày, việc nhìn thấy tiền thật khiến người vận hành muốn chốt. Ngược lại với lệnh lỗ, trader có thể trì hoãn stop vì hy vọng giá quay lại. Strategy trên code có payoff distribution A, nhưng human intervention biến nó thành payoff distribution B.

Vì vậy nên log cả những lệnh không được thực hiện:

timestamp
ticker
signal
expected_order
actual_order
difference
reason

Ví dụ:

09:45  ABC  BUY   10,000   0      Manual override
10:20  XYZ  SELL   5,000   5,000  Executed
13:30  DEF  BUY    8,000   3,000  Reduced size

Sau vài tháng có thể tính:

Model P&L
Actual P&L
Execution Gap = Actual P&L - Model P&L

Nếu Model P&L +12% nhưng Actual P&L +5%, cần phân rã 7% chênh lệch đó thành:

Slippage
Fees
Missed Trades
Partial Fills
System Errors
Manual Overrides
Position Sizing Differences

Khi đó “live kém backtest” không còn là một nhận xét chung chung mà trở thành một bài toán đo được.

Một metric khá hữu ích có thể tự xây là Implementation Shortfall. Với một order:

Implementation Shortfall
= Giá thực thi thực tế - Giá tại thời điểm quyết định

Với lệnh mua, số càng dương thì execution càng xấu. Với toàn strategy, có thể tổng hợp theo trade, ticker, thời gian trong ngày hoặc market regime để biết alpha bị mất nhiều nhất ở đâu.

Ví dụ:

Backtest expected edge/trade     +0.85%
Slippage                         -0.14%
Fees                             -0.12%
Missed/partial fills             -0.09%
Manual intervention              -0.18%
---------------------------------------
Live realized edge               +0.32%

Strategy vẫn có edge, nhưng gần 60% edge ban đầu bị mất trong quá trình implementation.

Đây cũng là lý do Paper Trading không nên được đánh giá chỉ bằng việc “paper có lãi hay không”. Giá trị lớn nhất của paper là kiểm tra xem toàn bộ pipeline có vận hành đúng trước khi tiền thật tham gia: data có đến đúng, feature có tính đúng, signal có xuất hiện đúng, order mapping có đúng, position có reconcile được và system có phục hồi sau disconnect hay không.

Một workflow thực tế có thể là:

Backtest
↓
Có statistical edge?
↓
Paper Trading
↓
Pipeline có chạy ổn?
↓
Small Live
↓
Slippage / Fill / Error có chấp nhận được?
↓
Normal Live
↓
Execution Gap có ổn định?
↓
Scale Capital

Backtest, Paper Trading và Live Trading vì vậy không phải ba phiên bản của cùng một bài test. Chúng trả lời ba câu hỏi khác nhau. Backtest kiểm tra ý tưởng. Paper Trading kiểm tra hệ thống. Live Trading kiểm tra khả năng biến ý tưởng thành P&L thật.

Một strategy có Sharpe 1.5 trong backtest nhưng chỉ còn 0.8 khi live không nhất thiết đồng nghĩa model sai. Phần Sharpe biến mất có thể nằm trong latency, slippage, fees, partial fills, infrastructure hoặc chính hành vi của người vận hành. Quant Research tốt không dừng ở việc tối ưu signal; phần khó hơn là đo được alpha đã mất ở đâu trên đường từ signal → order → fill → position → P&L.