Funding Rate ทำลาย Leverage ของคุณ: ทำไม PnL×50x ถึงเป็นแค่ภาพลวงตา
สมมติว่าคุณปรับแต่งกลยุทธ์มาแล้ว Backtest แสดงผล PnL +55%, MaxDD -0.9% คุณคำนวณ MaxLev: แล้วคูณ: สามพันเปอร์เซ็นต์ภายในสองปี คุณเริ่มจินตนาการถึง Lamborghini คันใหม่แล้ว
สามเดือนหลังเปิดใช้งานจริง เงินทุนของคุณต่ำกว่าจุดเริ่มต้น กลยุทธ์ทำงานตรงตาม backtest ทุกอย่าง — จุดเข้าเหมือนเดิม จุดออกเหมือนเดิม drawdown เหมือนเดิม แต่คุณกำลังขาดทุน ทุกวัน อย่างสม่ำเสมอ
สาเหตุ: funding rate ค่าธรรมเนียมที่มองไม่เห็น ซึ่ง backtest ของคุณไม่ได้นำมาคำนวณ — หรือคำนวณอย่างไม่ถูกต้อง
Funding Rate ทำงานอย่างไร
บน cryptocurrency exchanges สัญญา perpetual swap ไม่มีวันหมดอายุ เพื่อให้ราคา futures ยึดโยงกับราคา spot exchanges ใช้กลไก funding — การชำระเงินระหว่าง long และ short เป็นระยะ
กลไกบน Binance/Bybit:
- Funding ชำระ ทุก 8 ชั่วโมง (00:00, 08:00, 16:00 UTC)
- อัตรา funding ถูกกำหนดโดยส่วนต่างระหว่างราคา futures และราคา spot
- หาก funding rate เป็นบวก — ฝั่ง long จ่ายให้ฝั่ง short
- หากเป็นลบ — ฝั่ง short จ่ายให้ฝั่ง long
- อัตราทั่วไป: ต่อ 8 ชั่วโมง (อาจถึง ในสภาวะสุดขีด)
สูตรการชำระครั้งเดียว:
เมื่อมี leverage และเงินทุน :
ทำไม Backtest ถึงโกหกเรื่อง Leverage
เมตริก MaxLev (Maximum Leverage) มาตรฐานคือเพดาน leverage เชิงทฤษฎีที่ drawdown ไม่เกินระดับเป้าหมาย:
สูตรนี้ ไม่ได้คำนวณต้นทุนที่ขึ้นอยู่กับ leverage ที่ leverage 1x อัตรา funding เป็นค่าธรรมเนียมที่ไม่มีนัยสำคัญ ที่ 58x — มันคือหายนะ
ต้นทุนเชิงเส้น vs เชิงกำลังสอง
ค่าคอมมิชชั่นการซื้อขาย (maker/taker fees) เป็นเชิงเส้น — สัดส่วนกับปริมาณการซื้อขายและไม่ขึ้นกับ leverage Funding rate ก็เป็นเชิงเส้นต่อขนาด position แต่เมื่อคำนวณใหม่ ต่อหน่วยเงินทุน จะเติบโตตามสัดส่วนของ leverage:
เมื่อมีระยะเวลาถือครอง วันและ 3 การชำระต่อวัน:
การคำนวณใหม่: ตัวอย่างกลยุทธ์เมื่อรวม Funding
ตัวอย่างเช่น พิจารณากลยุทธ์สมมติสามแบบที่มีโปรไฟล์ความเสี่ยงต่างกัน พารามิเตอร์: perpetual futures ช่วงทดสอบ 25 เดือน อัตรา funding ทั่วไป 0.01% ต่อ 8 ชั่วโมง
ผลลัพธ์เดิม (ไม่รวม Funding)
| กลยุทธ์ | PnL | MaxDD | MaxLev | PnL@ML | จำนวนเทรด | เวลาซื้อขาย |
|---|---|---|---|---|---|---|
| กลยุทธ์ A | +55% | -0.9% | 55x | +3025% | ~500 | ~15% |
| กลยุทธ์ B | +25% | -0.75% | 66x | +1650% | ~40 | ~5% |
| กลยุทธ์ C | +300% | -17% | 3x | +900% | ~400 | ~45% |
การคำนวณต้นทุน Funding
def funding_cost(
leverage: float,
trading_time_pct: float,
test_days: int = 750, # 25 months
funding_rate: float = 0.0001, # 0.01% per 8h
payments_per_day: int = 3,
) -> float:
"""
Calculate cumulative funding costs as % of capital.
Returns:
Funding cost as percentage of initial capital
"""
active_days = test_days * trading_time_pct
daily_cost = funding_rate * payments_per_day * leverage
total_cost = daily_cost * active_days
return total_cost * 100 # in percent
การคำนวณ:
a_funding = funding_cost(55, 0.15, 750)
b_funding = funding_cost(66, 0.05, 750)
c_funding = funding_cost(3, 0.45, 750)
ผลลัพธ์เมื่อรวม Funding
| กลยุทธ์ | PnL@ML (ไม่รวม funding) | ต้นทุน Funding | PnL@ML (รวม funding) | สถานะ |
|---|---|---|---|---|
| กลยุทธ์ A | +3025% | -185.6% | +2839% | กิน ~6% |
| กลยุทธ์ B | +1650% | -74.3% | +1576% | กิน ~4.5% |
| กลยุทธ์ C | +900% | -30.4% | +870% | กิน ~3% |
มองเผินๆ ดูพอรับได้: funding กิน 3-6% ของ PnL@ML สุดท้าย แต่นี่คือ funding rate เฉลี่ย ลองดูว่าเกิดอะไรขึ้นเมื่ออัตราสูงขึ้น
Funding Rate ไม่ใช่ค่าคงที่
อัตรา funding ทั่วไป 0.01% เป็นค่า มัธยฐาน ในความเป็นจริง อัตราผันผวน:
| สภาวะตลาด | อัตรา funding ทั่วไป | ต่อ 8 ชั่วโมงที่ 55x | ต่อวันที่ 55x |
|---|---|---|---|
| ตลาดสงบ | 0.005% | 0.275% | 0.825% |
| ปกติ | 0.01% | 0.55% | 1.65% |
| เทรนด์ขาขึ้น | 0.03% | 1.65% | 4.95% |
| ขาขึ้นสุดขีด | 0.1% | 5.50% | 16.5% |
| Flash pump | 0.5% | 27.5% | — |
ที่ 55x leverage ในช่วงตลาดขาขึ้น (0.03%): หนึ่งวันในฝั่ง long มีต้นทุน 4.95% ของเงินทุน จาก funding อย่างเดียว
PnL ต่อวันที่ Active vs Funding ต่อวัน
นี่คือการคำนวณสำคัญ — ผลตอบแทนกลยุทธ์รายวันเทียบกับต้นทุนรายวัน:
a_pnl_per_day = 55 * 55 / 112.5 # PnL@ML / active days = 26.9%/day
b_pnl_per_day = 25 * 66 / 37.5 # = 44.0%/day
ด้วยตัวเลขแบบนี้ funding ดูเหมือนไม่สำคัญนัก แต่นี่คือ ค่าเฉลี่ย ปัญหาที่แท้จริงอยู่ที่อื่น
ปัญหาที่แท้จริง: Funding ระหว่าง Drawdown

ต้นทุน funding สะสม อย่างต่อเนื่อง ตราบใดที่ position เปิดอยู่ — รวมถึงในช่วง drawdown ตัวอย่างเช่น: drawdown สูงสุด 0.9% (กลยุทธ์ A) ที่ 55x leverage กลายเป็น:
นี่อยู่แค่ขอบของการ liquidation แล้ว ลองเพิ่ม funding:
หาก drawdown ใช้เวลา 3 วันที่อัตรา funding 0.01%:
รวมแล้ว: — liquidation ที่ maintenance margin มาตรฐาน 50%
สูตร Leverage ที่ปลอดภัยเมื่อรวม Funding
โดย Funding buffer คือ funding ที่คาดว่าจะเกิดขึ้นตลอดระยะเวลา drawdown ทั่วไป:
นี่เป็นสมการแบบ recursive (funding buffer ขึ้นอยู่กับ ) วิธีแก้:
def safe_leverage(
max_dd_pct: float,
target_dd_pct: float = 50.0,
funding_rate: float = 0.0001,
dd_duration_days: float = 3.0,
) -> float:
"""
Safe leverage accounting for funding costs during drawdown.
"""
denominator = max_dd_pct / 100 + funding_rate * 3 * dd_duration_days
return target_dd_pct / 100 / denominator
a_safe = safe_leverage(0.9, 50.0, 0.0001, 3.0)
a_safe_high = safe_leverage(0.9, 50.0, 0.0003, 3.0)
สรุป: ที่อัตรา funding ทั่วไป leverage ที่ปลอดภัยสำหรับกลยุทธ์ A คือ 50x ไม่ใช่ 55x ที่ funding สูง — 42x ส่วนต่างใน PnL@ML:
- แบบไม่คิดผล:
- รวม funding (0.01%):
- รวม funding (0.03%):
การรวม Funding เข้า Backtest อย่างปฏิบัติได้จริง
การคำนวณ funding rate ใน backtest ไม่ใช่ตัวเลือก — มันคือความจำเป็น นี่คือ implementation ขั้นต่ำ:
import pandas as pd
import numpy as np
def load_funding_rates(symbol: str) -> pd.DataFrame:
"""Load historical funding rates from warehouse."""
path = f"warehouse/data/{symbol}/funding/"
return df # columns: [timestamp, rate]
def apply_funding_to_trades(trades, funding_rates, leverage: int = 1):
"""
Subtract real funding costs from each trade's PnL.
"""
for trade in trades:
mask = (
(funding_rates.index >= trade.entry_time) &
(funding_rates.index <= trade.exit_time)
)
payments = funding_rates.loc[mask, 'rate']
direction = 1 if trade.side == 'long' else -1
total_funding = payments.sum() * direction * leverage
trade.pnl_pct -= total_funding * 100
return trades
ใน backtesting engine ที่สร้างมาอย่างดี funding rate จะถูกโหลดและนำไปใช้กับแต่ละเทรดโดยอัตโนมัติ ซึ่งให้ภาพที่เป็นจริง — และมักจะสวยงามน้อยกว่าที่ต้องการ
ช่วง Leverage ที่สมจริง

ตัวอย่างเช่น — อัตรา funding กระทบ leverage ที่ปลอดภัยอย่างไรที่ระดับ MaxDD ต่างๆ:
| ระบอบ Funding | อัตราเฉลี่ย | MaxLev ที่ DD=0.9% | MaxLev ที่ DD=17% |
|---|---|---|---|
| ต่ำ (0.005%) | 0.005% | 53x | 3x |
| ทั่วไป (0.01%) | 0.01% | 50x | 3x |
| สูงขึ้น (0.03%) | 0.03% | 42x | 3x |
| สูง (0.05%) | 0.05% | 36x | 2x |
ข้อสังเกตสำคัญ: สำหรับกลยุทธ์ที่มี drawdown ต่ำ (กลยุทธ์ A, B) funding ลด effective leverage อย่างมีนัยสำคัญ สำหรับกลยุทธ์ที่มี drawdown สูง (กลยุทธ์ C) ผลกระทบของ funding น้อยมาก — เพราะ leverage ถูกจำกัดอยู่ที่ 3x อยู่แล้ว
กลยุทธ์การลดผลกระทบจาก Funding
1. Hedge-Neutral Positions
อัตรา funding ถูกกำหนดโดยส่วนต่างระหว่างราคา futures และราคา spot หากกลยุทธ์ของคุณอนุญาตให้ hedge ผ่าน spot — funding จะถูก neutralize:
- Long futures + short spot = 0 net exposure ต่อ funding
- แต่: การ short spot ใน crypto มีข้อจำกัด (ต้องใช้ margin account หรือการยืม)
2. ย้ายไป Exchanges ที่มี Funding ต่ำกว่า
Exchanges ต่างๆ มีอัตรา funding ต่างกันสำหรับ asset เดียวกัน การติดตาม funding arbitrage เป็นกลยุทธ์แยกต่างหาก อธิบายรายละเอียดในบทความ Funding Rate Arbitrage ข้ามตลาด
3. การเลือกเวลาเข้า Position
Funding ชำระในเวลาที่กำหนด (00:00, 08:00, 16:00 UTC) หากเทรดปิดหนึ่งนาทีก่อนการชำระ — funding จะไม่ถูกเรียกเก็บ นี่คือ micro-optimization แต่ที่ 58x leverage การประหยัด 0.58% จากการข้ามการชำระหนึ่งครั้งมีความสำคัญ
4. Dynamic Leverage
แทนที่จะใช้ leverage คงที่ ให้ใช้ leverage แบบปรับตัวได้:
เมื่อ funding สูงขึ้น leverage จะลดลงโดยอัตโนมัติ จำกัดต้นทุน
คำแนะนำในการรวม Funding เข้า Pipeline
Funding rate ต้องเป็นส่วนบังคับของ backtesting pipeline:
- โหลด historical funding rate สำหรับแต่ละ symbol
- ปรับแต่ละเทรดตาม funding จริงตลอดระยะเวลาถือครอง
- คำนวณ MaxLev โดยใช้สูตรที่มี funding buffer
- ในรายงาน แสดงทั้งสองตัวเลข: PnL@ML ไม่รวม funding และรวม funding
กฎในทางปฏิบัติ: หากกลยุทธ์หยุดทำกำไรที่อัตรา funding 0.03% (ซึ่งเกิดขึ้น 20-30% ของเวลาในช่วง bull market) — มันยังไม่พร้อมสำหรับ production ที่ leverage สูง ลด leverage ลงสู่ระดับที่กลยุทธ์ยังทำกำไรได้แม้ในสถานการณ์ funding เลวร้ายที่สุด
บทสรุป
Funding rate คือภาษีบน leverage เช่นเดียวกับภาษีจริง มันไม่เป็นที่สังเกตในจำนวนน้อย และร้ายแรงในจำนวนมาก
สามกฎ:
-
คำนวณ PnL@ML รวม funding เสมอ สูตรที่ไม่มี funding คือการตลาด ไม่ใช่การเทรด โหลด historical funding rate และหักต้นทุนจริงออกจากแต่ละเทรด
-
ใช้สูตร leverage ที่ปลอดภัย:
- ทดสอบที่ 3x funding หากกลยุทธ์ทำกำไรที่ funding 0.03% (ไม่ใช่แค่ 0.01%) — มันมีความแข็งแกร่ง หากไม่ใช่ — ลด leverage
ตัวเลข PnL ที่สวยงามที่ leverage 50-60x เป็นภาพลวงตาที่น่าพึงพอใจ Funding rate คือความเป็นจริงที่เย็นชา ระหว่างสองสิ่งนี้คือความแตกต่างระหว่าง backtest กับบัญชีเทรดจริง
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับคณิตศาสตร์ของ drawdown และ volatility drag ที่ leverage สูง — ดูบทความของเรา ความไม่สมมาตรของขาดทุน-กำไร สำหรับวิธีรับช่วงความเชื่อมั่นสำหรับผลลัพธ์ที่ปรับ funding — Monte Carlo Bootstrap สำหรับ Backtest
ลิงก์ที่เป็นประโยชน์
- Binance — ประวัติอัตรา Funding
- Binance — แนะนำ Funding Rate บน Binance Futures
- Bybit — ทำความเข้าใจ Funding Rate
- Deribit Insights — ต้นทุนที่ซ่อนอยู่ของ Perpetual Swaps
- Lopez de Prado — Advances in Financial Machine Learning, บทที่ 14: Backtest Statistics
- Kevin Davey — Building Winning Algorithmic Trading Systems: Transaction Costs
อ้างอิง
@article{soloviov2026fundingratesleverage,
author = {Soloviov, Eugen},
title = {Funding Rates Kill Your Leverage: Why PnL×50x Is a Fiction},
year = {2026},
url = {https://marketmaker.cc/ru/blog/post/funding-rates-kill-leverage},
version = {0.1.0},
description = {How funding rates on Binance/Bybit turn beautiful high-leverage backtest results into guaranteed losses. Formulas, recalculation of real strategies, and the maximum leverage at which funding does not eat into profits.}
}
ผู้เขียน
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.