數位資產衍生性金融商品業務的核心風險，不在於配對引擎的效能，而在於清算系統的可靠性。根據馬來西亞 RMO DAX 框架，衍生性金融商品交易所必須證明其清算機制能在極端市場條件下有效清算高風險部位，以保護交易所、保險基金及零售用戶免於破產損失。 對於服務本地投資者及機構客戶的平台而言，一個經過實戰驗證的平倉引擎，是維持牌照、吸引機構客戶及確保長期營運的先決條件。

然而，一個真正經過工程設計的平倉系統，遠比「當帳戶虧損達到一定比例時強制平倉」來得複雜得多。它必須回答一系列問題：

• 保證金模型應採用隔離式、交叉式還是混合式？初始保證金率與維持保證金率應如何設定，才能在控制平台風險的同時，不影響資本效率？
• 平倉觸發機制應採用固定門檻還是分級觸發？平倉單應發送至公開市場，還是先由做市商承接？應先平倉小額倉位還是大額倉位，抑或反之？
• 若平倉單無法成交並導致破產損失，應由保險基金優先吸收損失，還是應立即觸發 ADL 自動去槓桿機制，讓盈利用戶按比例分擔損失？
• 保險基金應如何籌集、使用及補充？關於平台資本與客戶資金的分隔，證監會（SC）有哪些要求？
• 如何確保清算引擎本身的可用性？若在極端波動期間引擎發生故障，應採取何種降級處理流程？

本文從產品與工程雙重視角，闡述符合馬來西亞監管要求的衍生品平倉風險引擎完整架構，涵蓋保證金模型、觸發機制、平倉執行、ADL、保險基金、追索規則、破產價格計算、監管合規及稽核軌跡。同時也介紹 SoonTech 透過多個東南亞交易所專案所驗證的成熟解決方案。 無論您是正在建構衍生性金融商品交易所的產品團隊、負責風險控制的技術主管，還是申請 RMO DAX 執照的營運人員，您都將獲得一份完整的藍圖，可直接作為設計與審查的參考依據。

1. 產業背景：為何清算風險是 SC 的核心關注點

1.1 RMO DAX 針對衍生性金融商品風險的明確要求

馬來西亞證券委員會在 RMO DAX 指引中明確規定，持牌數位資產交易所必須建立健全的風險管理框架，包括保證金系統、平倉機制、持倉限額及壓力測試。平台必須證明：

• 清算觸發規則清晰、透明，並統一適用於所有用戶；
• 系統能在極端市場條件下完成清算，且不會引發系統性破產；
• 用戶資金與平台資金完全隔離，且保險基金不屬於營運商的財產；
• 所有平倉事件均具備完整的稽核紀錄，且用戶享有申訴與覆核的權利；
• 平台須定期進行壓力測試，模擬單日價格波動超過 20% 時的平倉能力。

這些並非紙上談兵的合規要求——新加坡證監會（SC）將在年度牌照審查及實地查核期間，要求提交清算系統設計文件、歷史清算數據分析及壓力測試報告。

1.2 東南亞衍生品市場的特殊特徵

相較於成熟市場，馬來西亞及東南亞的衍生性金融商品市場具有以下幾項顯著特徵：

• 用戶結構以散戶為主，專業投資者比例偏低，且對保證金、清算及破產風險的理解不足；
• 當地貨幣與主要加密貨幣之間的相關性較高，因此單一貨幣的「黑天鵝事件」容易蔓延至整個市場；
• 當地做市商的深度有限，在極端波動期間流動性可能瞬間消失；
• 散戶用戶習慣使用高槓桿（10x-100x），進一步加劇了平倉壓力。

這意味著馬來西亞交易所無法直接複製幣安（Binance）或 OKX 的平倉參數——必須根據當地市場深度、用戶結構及監管要求進行在地化調整。

1.3 強制平倉事故的先例

全球範圍內，因清算系統故障導致的事故並不少見：

• 某交易所因分階段平倉邏輯的程式錯誤，在劇烈價格波動期間將本不應被平倉的用戶批量平倉；
• 某平台在保險基金耗盡後觸發自動清算機制（ADL），導致獲利用戶超過 30% 的利潤被收回，引發大量客戶投訴及監管機構介入；
• 某交易所的平倉引擎在高並發狀況下停機 40 分鐘，導致超過 1 億美元的破產損失，最終由股東承擔；
• 某平台因「先平倉、後通知」的設計被監管機構視為資訊披露不充分，遭處以數百萬美元罰款。

對於持有馬來西亞牌照的平台而言，嚴重的清算事故不僅意味著財務損失，更可能導致牌照被暫停或撤銷。

2. 保證金模式：隔離式、跨帳戶式與混合式

2.1 隔離保證金

在隔離模式下，每個合約部位佔用一個獨立的保證金帳戶，盈虧僅在該帳戶內結算，不會與其他部位共享。特點：

• 風險隔離：單一合約遭平倉不會影響其他倉位或帳戶餘額；
• 直觀的使用者體驗：使用者可清楚查看每筆合約所佔用的保證金金額；
• 資本效率較低：用戶必須針對每筆合約分別存入保證金；
• 簡單的平倉邏輯：按合約獨立計算，無交叉影響。

隔離保證金模式適合散戶及初學者，亦是馬來西亞監管機構推薦的預設模式——馬來西亞證監會（SC）在投資者保護指引中明確要求平台必須為散戶提供隔離保證金作為選項。

2.2 跨保證金

在跨合約保證金模式下，帳戶中的所有可用餘額均作為所有倉位的共同保證金，且損益計算涵蓋整個帳戶。特點：

• 資本效率高：一筆保證金存入即可支援多份合約；
• 風險分散：獲利部位的浮動盈利可抵銷虧損部位的浮動虧損；
• 複雜的平倉邏輯：需即時綜合計算整個帳戶的風險敞口；
• 風險傳染：單一合約遭平倉可能耗盡整個帳戶餘額。

跨保證金模式適合專業交易者、做市商及機構客戶。馬來西亞交易平台通常僅向已完成專業投資者認證的客戶開放跨保證金功能，並要求簽署額外的風險披露聲明。

2.3 混合模式與部分隔離保證金

主要平台採用混合模式：用戶可針對每張合約選擇隔離保證金或跨帳戶保證金，且在跨帳戶保證金帳戶內，可設定「隔離部分保證金」子帳戶。SoonTech 在馬來西亞專案中的實作經驗：

• 散戶用戶預設為隔離保證金；跨保證金需手動啟用，並會顯示彈出式警告；
• 專業用戶可自訂「跨合約群組」，將相關合約（例如：BTC 永續合約 + BTC 季度合約）納入同一保證金池；
• 全平台設有「跨帳戶最大槓桿上限」（例如：跨帳戶最高 20 倍，隔離帳戶最高 50 倍）；
• 跨池保證金模式必須即時顯示三項核心指標：當前保證金比率、強制平倉觸發價、預估破產損失。

2.4 初始保證金率與維持保證金率

兩項最核心的參數：

• 初始保證金率（IM）：開倉時所需的最低保證金比率，決定最大槓桿倍數。例如，IM = 1% 對應最大 100 倍槓桿。
• 維持保證金（MM）：持倉期間必須維持的最低保證金比率；當低於此值時將觸發平倉。MM 通常低於 IM，例如 IM = 1%，MM = 0.5%。

馬來西亞監管機構傾向於「低槓桿、低風險」的方針。證監會建議零售用戶的最高槓桿不應超過 20 倍，專業投資者的最高槓桿則不應超過 50 倍。SoonTech 針對本地專案的建議設定：

3. 平倉觸發機制：從固定門檻到分階段平倉

3.1 三種平倉觸發模式

主要交易所採用三種觸發模式：

1. 固定門檻觸發：當保證金比率 ≤ MM 時，立即平倉所有持倉。邏輯簡單但體驗殘酷——微小的價格波動就可能導致全數持倉被平倉。
2. 分階段觸發：當保證金比率從 2% → 1.5% → 1% → 0.8% → 0.5% 逐步下降時，每次僅平倉部分頭寸，為用戶留出補繳保證金的時限。體驗較佳，但實作較為複雜。
3. 增量觸發：即時計算當前價格與平倉價之間的差距，發送預警通知，並在價格每向不利方向波動 10% 時追加通知。

馬來西亞監管機構傾向採用分階段觸發機制，因其能最大程度保障散戶權益。證監會（SC）在投資者保護指引中明確建議，平台應「採用漸進式平倉機制，避免一次性平倉全部持倉」。

3.2 分階段平倉的工程實作

典型的 5 階段平倉流程：

• 警告級別（保證金比率 150% MM）：透過應用程式、電子郵件及 Telegram 推送通知，提醒用戶追加保證金或減持倉位；
• 第 1 級平倉（保證金比率 120% MM）：平倉 20% 部位，發送通知；
• 第二級平倉（保證金比率 110%）：平倉另外 30%（累計 50%），並發送通知；
• 第三級平倉（100% MM）：平倉另外 30%（總計 80%），並發送通知；
• 最終平倉（≤ MM）：平倉剩餘的 20% 倉位。

關鍵設計要點：

• 每個階段結束後，預留 30–60 秒的時段讓用戶追加保證金，之後才繼續執行；
• 若用戶補繳保證金且保證金比率回升至先前水準，則停止後續平倉；
• 若價格走勢有利，亦停止後續平倉；
• 每次平倉操作都必須具備完整的稽核日誌，包含觸發時間、觸發價格、平倉數量、成交價格及實際損益。

3.3 強制平倉優先順序排序

當系統需同時處理大量平倉訂單時，平倉順序將直接影響整體效率與破產風險。常見的排序策略：

• 最低保證金比率優先：優先平倉風險最高的部位，以防止破產風險擴大；
• 先平倉最小倉位：優先平倉小額訂單——快速執行可防止小額訂單累積成巨額破產損失；
• 最大持倉優先：優先平倉大額訂單，以降低整體系統風險敞口；
• 流動性最高者優先：優先平倉訂單簿深度最深的合約，以利執行並降低市場衝擊。

SoonTech 在馬來西亞專案中採用混合策略：首先按保證金比率分級排序，在同一級別內先平倉小額訂單再平倉大額訂單；在市場劇烈波動期間，則暫停大額訂單的平倉，或將其拆分為較小的冰山訂單。

3.4 市場對平倉訂單的處理

清算訂單不應直接發送至公開訂單簿——否則交易機器人將搶先執行，導致更嚴重的滑點及更多破產情況。正確的處理流程如下：

1. 做市商優先接收：首先將平倉訂單發送至白名單中的做市商暗池，給予 50–100 毫秒的優先執行時窗；
2. 內部配對：檢查用戶訂單簿中是否存在反向限價單，以進行內部配對；
3. 公開市場執行：將未成交部分拆分為小筆訂單，並逐步發送至公開市場；
4. ADL 備用機制：若上述所有步驟均失敗，則觸發自動去槓桿。

這種三層架構——暗池優先、內部配對、公開市場備用方案——能將平倉對市場的影響降至最低，並顯著降低破產機率。

4. ADL 自動去槓桿機制設計

4.1 何謂 ADL

ADL（自動去槓桿）是一種安全機制：當清算訂單無法在市場中成交，且保險基金不足以彌補破產損失時，系統會根據獲利百分比的順序，自動削減獲利用戶的持倉，並利用其獲利來填補破產缺口。

對交易所而言，ADL 是最終的安全網——它確保在任何極端市場條件下，平台本身無需動用自有資本作為後盾，單一用戶的破產也不會引發系統性風險。

4.2 ADL 排序規則

ADL 的核心在於「應優先削減哪位用戶的持倉」。常見的排序維度包括：

• 盈利百分比優先級：盈利最高的用戶將優先被去槓桿——他們具備最強的風險承擔能力，理應對極端市場狀況承擔最大責任；
• 槓桿優先級：高槓桿用戶將優先被去槓桿——他們享受了高槓桿帶來的好處，理應承擔相應的風險；
• 持倉時間優先：短期投機者應在長期避險者之前被去槓桿；
• 做市商豁免：為確保市場流動性持續，做市商持倉通常不參與 ADL 排序。

馬來西亞監管機構傾向採用「獲利百分比優先＋做市商豁免」的組合，因為此方案最符合「報酬與風險匹配」原則，並能防止做市商因 ADL 風險而退出市場。

4.3 ADL 執行與通知

ADL 的執行流程必須具備透明度且可稽核：

1. 系統偵測到清算訂單無法成交，且保險基金餘額不足以彌補破產損失；
2. 計算所需的總缺口金額；
3. 依 ADL 優先順序由高至低削減持倉，直至填補缺口為止；
4. 每次減持操作均須即時通知受影響用戶，並說明減持數量、減持價格及相應的虧損彌補情況；
5. 所有 ADL 事件必須在平台公告頁面上公開披露，並揭露總減持金額、受影響用戶人數以及已彌補的破產損失總額；
6. 用戶可在 7 天內對 ADL 結果提出申訴，平台必須於 3 個工作天內予以回覆。

SC 特別強調，ADL 規則必須在用戶開倉前明確披露，且每次觸發 ADL 後，必須主動通知所有受影響用戶——嚴禁進行「靜默」去槓桿。

4.4 ADL 上限與斷路器機制

為防止濫用 ADL，必須建立斷路器機制：

• 單一用戶每日 ADL 上限：每位用戶每日持倉削減幅度不得超過 50%；
• 全平台每日 ADL 上限：不得超過平台總未平倉合約量的 5%；若超出，則暫停交易並觸發熔斷機制；
• ADL 間隔限制：同一用戶在 24 小時內最多可被強制減持兩次；
• 極端熔斷機制：若每日 ADL 超過閾值，平台可暫時降低全市場的槓桿上限，以防止風險進一步擴散。

5. 保險基金的設計與管理

5.1 保險基金來源

保險基金是專門用於彌補破產損失的資本池。其來源通常包括：

• 平台初始注資：平台上線時注入的初始資本，通常不低於 100 萬美元；
• 清算盈餘：當清算訂單以優於破產價格的價格執行時，盈餘的 100% 將撥入保險基金；
• 手續費分配：每筆交易手續費的 5%–10% 會自動注入保險基金；
• ADL 盈餘：若 ADL 產生的利潤超出缺口，該部分將注入保險基金；
• 罰款收入：來自違規用戶的罰款及對做市商的處罰。

馬來西亞監管機構明確規定：保險基金必須與平台自有資金及客戶資金完全隔離，存放於獨立託管帳戶中，且平台不得將其用於任何其他用途（包括營運開支、市場造市、投資等）。

5.2 保險基金使用規則

保險基金的使用必須有明確的優先順序及審批流程：

1. 清算盈餘優先：每次清算所產生的破產損失，應優先由該次清算的盈餘彌補；
2. 合約層級資金次之：每個合約可設有獨立的保險基金子帳戶，優先使用對應合約的資金；
3. 全球保險基金作為備用：若合約層級資金不足，則動用全球保險基金；
4. 最後觸發 ADL：僅當全球保險基金亦不足時，方觸發 ADL。

關鍵規則：保險基金不得用於彌補因平台漏洞或系統故障所造成的損失——此類損失必須由平台股東的自有資本承擔，且不得動用由用戶繳納費用所形成的保險基金。

5.3 保險基金的透明度與審計

SC 要求保險基金具備高度透明度：

• 即時公開披露保險基金餘額、歷史注資及支出紀錄；
• 每月發布保險基金報告，披露當月破產損失、清算盈餘注資、費用注資及 ADL 觸發情況；
• 由獨立審計機構對保險基金進行年度特別審計，並發布審計報告；
• 當保險基金餘額低於安全門檻（例如：30 天平均破產損失的 5 倍）時，平台必須發布公開警告並啟動注資機制。

SoonTech 已為馬來西亞客戶建置「保險基金透明度儀表板」，讓任何人都能查閱即時餘額及歷史明細——這也是 SC 現場查核時的重點關注事項。

6. 破產價格計算與追索權

6.1 破產價的定義

破產價是指當用戶的持倉以該價格平倉時，用戶的保證金將精確歸零——平台既不獲利也不虧損的價格。這是清算系統中最核心的計算公式之一。

對於多頭倉位，簡化計算公式為：破產價 = 進場價 × (1 − 初始保證金率)。 以 100 USDT 開倉的 10 倍多單（初始保證金率 10%）為例，破產價約為 90 USDT。一旦標價跌破該水平，該倉位的保證金將無法覆蓋虧損，剩餘缺口必須由保險基金彌補。

在實際系統設計中，還需考慮以下因素：

• 資金費率的累積影響；
• 已實現與未實現損益；
• 手續費成本；
• 平倉執行成本（滑點估算）。

若最終清算執行價格優於破產價格，剩餘資金將撥入保險基金；若較差，其差額則為由保險基金或 ADL 承擔的破產損失。

6.2 標價與公允價格

清算不能以最新成交價作為觸發依據——否則將容易受到虛假報單（spoofing）和蠟燭桿攻擊（wick attacks）的操縱。業界標準是採用「標價」作為觸發依據：

• 標價 = 多個主要交易所中同一合約價格的中位數或加權平均值；
• 或 標價 = 現貨指數價格 + 資金費率基差（公平價格）；
• 標價採用 5–15 分鐘的 TWAP（時間加權平均價）來過濾瞬時波動。

馬來西亞監管機構明確要求，標價的計算方法必須公開且透明，數據來源必須獨立於平台自身的交易價格，以防止平台操縱標價來惡意強制平倉用戶。

6.3 特殊追索情境

除 ADL 之外，尚有數種特殊的破產追索情境：

• 系統故障導致的破產：由配對引擎、清算引擎或 RPC 節點故障所造成的破產損失，須由平台自有資本承擔——不得動用保險基金或 ADL；
• 價格操縱導致的破產：因惡意操縱標價而引發的異常清算，平台須回滾交易並補償用戶損失；
• 跨合約鏈破產：在極端波動期間，若多個合約同時破產，可能耗盡保險基金。在此情況下，將觸發「全局破產追索」機制，所有獲利用戶須按比例分擔虧損，且平台必須注入自有資本以彌補至少 20% 的總缺口。

7. 清算引擎工程架構

7.1 三層架構：計算、決策、執行

生產級的平倉引擎通常分為三個層級：

1. 計算層：擷取即時價格、用戶持倉、保證金餘額，並針對每個持倉計算當前保證金比率、平倉價及破產價。典型效能要求：100,000 筆持倉的完整計算時間需小於 100 毫秒。
2. 決策層：根據計算結果決定是否觸發平倉、觸發哪個級別、平倉數量以及使用哪個執行通道。需支援狀態機及降級切換機制。
3. 執行層：負責將平倉訂單發送至做市商暗池、內部配對引擎或公開市場，監控執行狀態，並處理部分成交及取消-替換（C&R）流程。

解耦分層的優勢：計算層可透過水平擴展提升效能；決策層邏輯變更不會影響執行層；若執行層發生問題，可進行手動接管。

7.2 高可用性與容錯設計

清算引擎是交易所中可用性要求最高的組件之一——即使在極端波動、全市場熔斷機制觸發以及基礎設施故障的情況下，仍必須正常運作。關鍵設計：

• 多活躍部署：在至少三個可用區域中獨立部署——任何單一區域的故障都不會影響整體運作；
• 本地快取備援：每個引擎節點皆在本地端快取價格與持倉資料，即使資料庫離線仍可持續運作；
• 降級開關：可在極端情況下關閉分階段清算、停用暗池優先權，或暫時降低槓桿上限；
• 手動干預通道：風險控制團隊可暫停平倉、調整參數，並從後端手動接管特定倉位的平倉作業；
• 定期壓力測試：每日進行全面壓力測試，模擬歷史最高清算壓力的 10 倍。

7.3 稽核與可觀察性

清算引擎的每項操作都必須留下不可篡改的稽核軌跡：

• 每次清算觸發：記錄時間、標記價格、用戶 ID、合約、持倉規模、保證金比率、觸發水準；
• 每次清算執行：記錄訂單 ID、發送通道、執行價格、成交數量、滑點、破產／盈餘金額；
• 每次 ADL 觸發：記錄價差金額、排序規則、去槓桿用戶清單、每次減持的數量與價格；
• 每次保險基金變動：記錄注資／支出金額、來源／去向、對應的事件 ID。

所有稽核日誌必須寫入不可變的日誌系統，保存至少 7 年，並供監管機構隨時查閱。

8. SoonTech 在馬來西亞的實施

8.1 清算引擎模組概述

SoonTech 為符合馬來西亞法規的交易所提供的清算引擎包含：

• 保證金計算服務：支援隔離／跨賬戶／混合模式，並針對所有持倉進行即時保證金比率及平倉價計算；
• 分階段平倉決策引擎：5 級觸發邏輯，各級平倉比率與時間窗口皆可自訂；
• 三層執行路由器：做市商暗池 → 內部配對 → 公開市場，可配置滑點保護；
• ADL 自動去槓桿模組：可配置排序規則、斷路器閾值、通知及稽核功能；
• 保險基金管理系統：多帳戶隔離、自動注資、透明度儀表板、月度報告生成；
• 監管合規套件：所有 SC 要求的報告、稽核日誌、壓力測試工具；
• 用戶通知中心：多管道（App 推播、電子郵件、Telegram、簡訊）平倉警告及 ADL 通知。

8.2 典型效能指標

在馬來西亞某領先交易所的生產環境中，SoonTech 的平倉引擎實際達成了以下成果：

• 單一可用區域即可支援超過 500,000 筆倉位的即時計算，延遲低於 50 毫秒；
• 在極端市場條件下（單日比特幣波動超過 15%），平倉成功率達 99.7%，破產率低於 0.05%；
• 平均平倉訂單滑點低於 0.2%，遠低於 0.5%–1% 的業界平均水準；
• ADL 觸發頻率：約每 2–3 個月一次，平均用戶持倉減少幅度 < 5%；
• 保險基金充足率始終維持在 10 倍以上（基金餘額 / 30 天平均破產損失）。

8.3 符合新加坡監管要求

SoonTech 解決方案與馬來西亞監管要求的主要對應點：

• 零售用戶保護：預設採用隔離保證金機制、20倍槓桿上限、分階段平倉、多管道警示機制；
• 資金隔離：保險基金由獨立機構託管，與平台自有資金實體隔離；
• 透明度：公開清算規則、即時保險基金儀表板、公開披露異常交易事件（ADL）；
• 審計要求：7 年不可篡改的審計日誌、可匯出符合監管規範格式的報告、壓力測試工具；
• 申訴機制：內建清算申訴單系統，支援用戶申訴審查及平台回應。

9. 企業實施建議

9.1 上線前準備

• 壓力測試：模擬歷史最高交易量與波動率 5 倍的情境，以驗證清算引擎的吞吐量與成功率；
• 做市商協議：與至少 2 至 3 家領先做市商簽署清算承接協議，明確定義極端情況下的承接義務與費用；
• 用戶教育：於上線前至少 2 週開始針對強制平倉、ADL 及保險基金進行用戶教育；
• 監管溝通：向證監會提交清算系統設計文件、參數配置及壓力測試報告以供預審；
• 災難演練：模擬清算引擎停機、資料庫故障及價格資料來源異常等情境，以驗證效能降級處理流程。

9.2 上線後持續優化

• 參數迭代：每季依據實際交易數據檢視清算參數（保證金率、階段比率、滑點閾值），並根據市場變化進行調整；
• 自動清算觸發（ADL）檢討：每次 ADL 觸發後進行全面事後分析，評估排序規則是否合理及是否需要調整；
• 保險基金動態：根據歷史破產損失數據動態調整費用注入比率，確保基金充足性始終維持在安全範圍內；
• 用戶反饋迴圈：收集用戶對清算體驗的反饋，持續優化警示時機、通知管道及清算透明度。

9.3 組織與流程

• 成立專責的衍生性金融商品風險控制團隊，針對清算引擎提供 7x24 全天候待命服務；
• 針對極端市場狀況制定應急計畫，明確界定誰有權觸發降級措施以及誰有權暫停交易；
• 定期（至少每季一次）向監督委員會提交衍生性金融商品風險報告，內容包含清算數據、破產分析、保險基金變動及 ADL 觸發條件；
• 設立獨立審計職位，定期根據實際執行結果審查清算引擎的程式邏輯。

常見問題

Q1：馬來西亞法規對衍生性金融商品是否有明確的槓桿上限？

A：證監會（SC）的 RMO DAX 框架並未明確規定具體的槓桿倍數，但在投資者保護指引中「建議」零售用戶的槓桿不應超過 20 倍，專業投資者的槓桿不應超過 50 倍。 實際上，若平台向零售用戶提供 100 倍槓桿，在現場檢查時很可能被要求進行整改。

Q2：保險基金屬於平台還是用戶？

A：保險基金是所有平台用戶的共同風險儲備，並非平台股東的財產，亦不得用於派發股息、支付營運開支或進行投資。平台僅作為管理該基金的受託人，必須遵循預設的使用規則，並接受獨立審計。

Q3：自動強制平倉（ADL）觸發後，用戶能否拒絕減持？

A：不可以。自動減持機制（ADL）規則是用戶開倉時簽署的服務協議的一部分，一旦觸發即自動執行。但用戶可以提出申訴——若平台確認自動減持機制是因系統錯誤或價格操縱而觸發，則可提供補償。

Q4：為何不將所有平倉單直接發送至公開市場？

A：平倉單是市場上最「有利可圖」的訂單——所有交易機器人都會對其進行搶先交易和夾擊。若直接發送至公開市場，將導致嚴重的滑點，實際上反而會增加破產風險。暗池優先處理與內部配對是業界標準做法。

Q5：標價應採用多少個數據來源？

A：建議至少使用 3 個獨立資料來源，並採用中位數或 TWAP 計算。資料來源應包含至少 2 家海外主要交易所及 1 家本地主要交易所，以避免單一資料來源的異常情況導致全平台批量清算。

Q6：若連 ADL 都無法彌補破產損失該如何處理？

A：這屬於極其罕見的極端情況——歷史上僅有FTX崩盤級別的事件才會導致此狀況。此時，平台有兩種選擇：股東注入自有資本作為後盾，或啟動「全球破產追索權」，由所有獲利用戶按比例分擔虧損。馬來西亞監管機構傾向優先採用股東後盾機制，因為此舉能保護散戶用戶的權益。

結論

衍生性金融商品業務的本質在於風險管理，而清算引擎則是風險管理中的最後一道防線。在馬來西亞 RMO DAX 框架下，清算系統不再是僅需「能運作」的邊緣模組——它已成為監管審查的核心對象、機構客戶入駐的先決條件，更是決定平台存續的關鍵基礎設施。

設計完善的清算引擎應能在極端市場條件下無聲無息地完成清算，讓大多數用戶甚至察覺不到其存在；而設計不良的清算引擎，則可能在單一「黑天鵝事件」中拖垮整個平台。

SoonTech 在中心化交易所（CEX）衍生品平倉及東南亞在地化方面擁有多年的工程技術積累，已為馬來西亞、印尼和泰國的多個持牌交易所專案交付了經生產環境驗證的平倉引擎。若您的團隊正規劃或優化衍生品業務，歡迎與我們聯繫。 我們可根據您的用戶結構、做市商深度及監管要求，提供從保證金模型到自動清算機制（ADL）、從保險基金管理到監管合規的端到端解決方案。

可控風險、透明清算、值得信賴的平台——這才是衍生品業務長期營運的唯一正確道路。

🌐 與 SoonTech 攜手打造安全且可擴展的 Web3 平台。

探索我們針對白標加密貨幣交易所、預測市場、MPC 錢包、撮合引擎、流動性整合及合規的解決方案。