All
篩選條件:
我該如何將現金存入我的帳戶當中?
我需要帳戶驗證方面的幫助
為甚麼我無法訪問我的帳戶?
提取加密貨幣會產生任何費用嗎?
我需要協助登錄我的帳戶
本文適用於透過我們的模擬環境進行期權交易(透過 API)。

本文檔提供了期權投資組合保證金系統的全面技術概述,描述了其方法、保證金計算和風險管理策略。
投資組合保證金是一種基於風險的保證金計算方法,它根據投資組合的整體風險而非預設策略來確定保證金要求。這種方法旨在使保證金要求與投資組合內合併頭寸的實際風險敞口更緊密地保持一致。
因此,投資組合保證金系統可以抵銷具有相似基礎資產的不同工具之間的風險。與傳統保證金(將個別保證金要求加總)相比,它提高了資本效率。然而,它也增加了保證金計算的複雜性。
保證金要求是根據五個主要風險因素計算的:
非 Delta 市場風險 – 根據 SPAN 方法,在價格和波動性壓力測試下衡量最壞情況的 P&L。
絕對期權 Delta – 考慮清算和市場影響風險。
淨投資組合 Delta – 捕捉清算期間潛在的 Delta 對沖成本。
期貨頭寸保證金 – 確保與多抵押品期貨保證金的一致性。
跨資產淨額結算 – 允許根據資產相關性減少保證金。
此組件計算在多種價格和波動性衝擊情景下最壞情況的投資組合 P&L。該方法遵循 SPAN (Standard Portfolio Analysis of Risk) 模型,但針對期權進行了增強(一個重要區別是我們只考慮 Delta 對沖的投資組合):
23 種不同的市場情景模擬價格變動,例如在 -15% 到 +15% 之間,並在 -45% 和 +45% 處有額外的極端衝擊。
波動性調整基於期權的歷史 IV 行為和前瞻性風險估計。
Theta 衰減影響:對具有負 Theta 的期權(即隨時間損失價值的期權)應用額外風險乘數,方法是衝擊到期時間並將其提前。
Delta 對沖壓力測試:通過假設在當前價格下對價格衝擊進行 Delta 對沖,只考慮殘餘風險(高階 greeks)。
絕對 Delta 衡量投資組合的總方向性敞口。這確保了大型頭寸有足夠的保證金以反映清算/市場影響風險。儘管根據非 Delta 市場風險,投資組合可能具有最小的市場風險,但高 Delta 投資組合將具有清算風險。因此,期權頭寸的 Delta 計算如下:

其中 MaintenanceMarginFactor 在此處提供。係數 2 用作緩衝。
期權 | Delta | 頭寸 | 基礎價格 |
|---|---|---|---|
A | 0.5 | 100 | $50 |
0.5 | -0.3 | 150 | $40 |
計算絕對名義 Delta 敞口:
(0.5 x 100 x 50) + (-0.3 x 150 x 40)=4300
假設維持保證金係數 (mm_factor) 為 0.01:
AbsOptionsDelta = 4300 x0.01 x2 = 86
淨 Delta 代表投資組合的整體方向性偏差,同時考慮期權和期貨頭寸。此指標對於確定清算前的對沖成本至關重要。
方法:
考慮投資組合中的期權和期貨。
計算淨 Delta 敞口,並納入期貨對沖。
使用最小的未對沖敞口以釐定風險。
將 Delta 敞口使用指數價格轉換為名義價值。
應用動態維持保證金因子以計算所需保證金。
工具 | 類型 | Delta | 頭寸 | 指數價格 |
|---|---|---|---|---|
A | 期權 | 100 | 100 | $50 |
B | 期權 | 200 | 200 | $50 |
C | 期貨 | -80 | -80 | $50 |
計算期權 Delta:
options_delta = (0.5 x 100) + (-0.3 x 200) = 50 - 60 = -10
計算期貨 Delta:
underlying_delta= -80
釐定淨 Delta 敞口:
min_net_portfolio_delta=
=minabs(options_delta), abs(options_delta + underlying_delta )=
=min10,abs(-10+(-80))=10
min_net_portfolio_delta 受限於 abs(options_delta),因為我們只想考慮抵銷期權 Delta 的期貨 Delta。
轉換為名義敞口:
min_net_portfolio_delta_notional = 10 x 50 = 500
應用維持保證金因子(例如 mm_factor = 0.01):
Net Portfolio Delta = 500 x0.01 = 5
期貨保證金遵循多抵押品保證金系統,以確保僅交易期貨的客戶的期貨保證金要求保持一致;我們對多抵押品期貨使用現有的保證金系統。

期貨的保證金要求與期權的保證金要求合計。
注意:多抵押品保證金系統與單一抵押品合約的系統略有不同。對於單一抵押品,保證金要求基於標記價格而非平均入場價格。選擇這種多抵押品合約的方法是因為它被認為更容易讓客戶理解,因為初始保證金對於給定規模和平均入場價格是固定的。
跨資產淨額結算是一種保證金減免機制,允許投資組合保證金系統識別不同工具之間的相關風險抵銷。系統不會將所有頭寸視為獨立,而是在資產歷史上存在抵銷風險時,應用相關係數來降低整體保證金要求。
系統在兩個值之間進行插值:
所有期權在每個情景中合計損失的最差情況。
所有情景中每個資產最差損失的總和(較嚴格者)。
系統在這些方法之間進行插值,以平衡風險準確性和資本效率。這個插值將被視為投資組合的非 Delta 市場風險。參數本身將由管理員設定,並介於 0 和 1 之間。
注意:這個數字僅表示 BTC 和 ETH 之間的相關性,因為這些是已上市期權的標的資產,預計會持續一段時間。如果增加更多期權,則需要重新審視該方法以處理 3 個或更多不同的標的資產。
情景 | BTC 虧損 ($) | ETH 虧損 ($) |
|---|---|---|
1 | -1,000 | -2,000 |
2 | -500 | -2,500 |
3 | -1,500 | -1,500 |
4 | -2,500 | -500 |
每個情景的虧損是各資產虧損總和的結果。這假設每個情景中的所有虧損都是可加的,意味著 BTC 和 ETH 的虧損會同時完全實現。
情景 | 總虧損 |
|---|---|
1 | -3,000 |
2 | -3,000 |
3 | -3,000 |
4 | -3,000 |
所有情景中最差的總計為 -3000。
在這裡,我們查看每個單一工具在所有情景中的最差虧損:
BTC 在所有情景中的最差虧損:-2500 (情景 4)
ETH 在所有情景中的最差虧損:-2500 (情景 2)
總保證金要求為 -2500 + (-2500) = -5000
然而,這並不假設 BTC 和 ETH 在同一情景中達到最差虧損。
在計算個別頭寸的上述風險因素後,最終保證金要求在投資組合層面通過以結構化方式整合這些組成部分來確定:
OptionsMaintenanceMargin = max(CrossAssetNettedMarketRisk, AbsOptionsDelta)+ NetPortfolioDelta
我們取上述兩者的最大值,以便在仔細對沖的投資組合情況下,我們仍然受清算風險的約束。
OptionsInitialMargin = OptionsMaintenance x MarginOptionsIMarginFactor
PortfolioMaintenanceMargin = OptionsMaintenanceMargin + FuturesMaintenanceMargin
PortfolioInitialMargin = OptionsInitialMargin + FuturesInitialMargin
OptionsIMarginFactor 由管理員定義。
在僅限多頭期權投資組合的情況下,期權的初始保證金和維持保證金不能超過標記價格,因為這是最大虧損。
引擎會計算初始保證金,同時考慮未平倉訂單並假設它們已執行,以防止客戶發送在執行後會使所需保證金超過初始保證金的訂單。
該機制確保可能增加風險的訂單在執行前有足夠的保證金。對於有活躍未平倉訂單的投資組合,系統會模擬所有未平倉訂單已成交的保證金影響,並加上任何負的盈虧和費用。因此,每個期權的訂單所需保證金為:
marginForBids = marginImpactAllBidsFilled+min(pnlBidsFilled,0) + bidsFilledFee
marginForAsks = marginImpactAllAsksFilled + min(pnlAsksFilled,0) + asksFilledFee
marginRequiredForOrders = max(marginForBids, MarginForAsks)
我們採取保守做法,因此需要最高的保證金。買入、賣出訂單不能同時成交。
未平倉訂單保證金計算詳情如下:
1. 計算每份期權訂單的初始保證金
對於每份期權 opt,會計算買入和賣出訂單的初始保證金影響,並考慮:
成交後的影響

未實現虧損(僅限負數盈虧)

與訂單相關的費用

因此,未平倉訂單的初始保證金為:
IM[orders,opt] = max(max[of bid&ask orders](IM[impact](orders) + min(PNL[impact](orders),0) + Fees[impact](orders)),0)
請注意:買入和賣出訂單不能同時成交。這就是為什麼會取兩者中的最大值。
2. 除非客戶是做市商,否則將所有期權訂單的保證金加總,做市商則只加總 N 筆影響保證金最大的訂單。

3. 所有訂單的總初始保證金是上述計算(期權)和期貨的總和。

當用戶下達訂單時,會假設訂單已下達來計算未平倉訂單的總保證金。如果此值與下達訂單前的值 (IM[orders, total]) 之間的差額小於或等於可用保證金,則可以下達訂單。
檢查如果訂單執行,未平倉訂單的總初始保證金是否會增加。如果不會增加,則下達訂單。
保證金影響的計算方式為:
max(mm_impact_all_bids_filled, mm_impact_all_asks_filled)
如果上述計算產生負保證金影響,則表示該訂單會降低風險,系統允許消耗保證金緩衝:
usableMargin = margin_equity - current_mm,其中 margin_equity 是抵押品價值(包括折價)+ 未實現盈虧。
如果上述計算產生正保證金影響,則表示該訂單會增加風險,系統會使用:usableMargin = availableMargin
如果用戶的可用保證金跌至零以下,並且他們有增加風險的訂單,系統將開始取消訂單,以嘗試將其可用保證金恢復到零以上。
如果該工具是期貨且有非平倉訂單(即不平倉/增加風險敞口的訂單),則該工具的所有訂單都會被取消。
與期貨不同,由於期權的非線性,執行訂單可能會透過平倉(平倉訂單)來降低投資組合的總風險。因此,如果一組買入/賣出訂單會降低風險,則會取消這些買入/賣出訂單,否則不會。
迭代所有工具:每個工具可以是期貨或期權。
處理期貨:取消所有非平倉訂單
如果該工具是期貨且有非平倉訂單(即增加風險敞口的訂單),則該工具的所有訂單都會被取消。
處理期權:選擇性訂單取消
將所有買入和賣出訂單分為兩組(賣出和買入),然後計算每組是否會減少保證金。如果保證金沒有減少,則取消該組的所有訂單(即使是那些會減少保證金的訂單)。
請注意:請記住,未平倉訂單在仍未平倉時不會增加保證金。我們取消所有那些如果執行可能會增加所需保證金的訂單,是因為我們不希望客戶持有需要保證金的倉位。