關於 Organizations

最後更新: 2026年8月17日
註:

如果您的 Organization 是在 Beta 存取模型下建立的(即權限逐一授予每位 Member),請參閱 從 Beta 遷移。該文章涵蓋變更內容,以及事前需完成的 API 整合工作。

Organizations 概覽

Organizations 讓機構客戶得以在多個隔離帳戶上部署交易者、操作員及審批人團隊,並以審批工作流程保護資金流動、每項行政變更及治理規則本身。

建立 Organization 後,您可以:

  • 管理多個帳戶的獨立餘額、訂單及歷史紀錄
  • 邀請團隊成員,並透過可重複使用的角色與設定檔指派存取權限
  • 針對提款、轉帳及行政變更要求多方審批
  • 透過組織內部轉帳進行帳戶再平衡,與其他資金流動一樣須經審核與審批
  • 建立 API 金鑰,支援自動化交易(包括現貨市場的 FIX 連線)及報告功能,每個金鑰的權限範圍限定於所操作的帳戶
  • 查閱 Organization 內所有操作的安全事件記錄

Organization 是頂層容器,整合您所管理的帳戶、操作人員及其登入憑證,以及凌駕兩者之上的治理規則。

Organization Owner —— 建立該 Organization 的帳戶持有者。Owner 初始即擁有所有工作流程及帳戶的完整存取權限,並負責建立團隊及其治理架構。本系統不設共同擁有者角色。

Member —— 受邀加入 Organization 的人員。Member 以各自的 Kraken 登入憑證登入,須遵守 Organization 的登入雙重認證政策,並持有唯一一個 Workflow Profile 及任意數量的 Account Roles。

Accounts —— Organization 內的隔離帳戶單位,各自擁有獨立的餘額、未成交訂單及歷史紀錄。Organization 建立時設有一個主帳戶,並可持有多個帳戶;存取某一帳戶的權限不會延伸至其他帳戶。請參閱 帳戶

API key —— 供交易系統及自動化程式使用的程式化存取憑證。API 金鑰擁有獨立的權限模型,與 Member 分開管理。請參閱 API 金鑰

成員在組織內的所有操作均屬以下兩類之一。掌握此區分後,其餘運作模式便一目了然。

直接操作即時生效。查看餘額、交易,以及將資金配置至 Earn 產品,均屬直接操作:成員只要持有該帳戶的相應權限,操作即時生效。直接操作不會產生審批請求。

受管操作以審批請求形式執行。提款、帳戶間轉帳,以及所有管理變更(包括管理團隊存取權限、API 金鑰、帳戶、地址及政策)均屬受管操作。發起受管操作後,系統將建立一項請求,由工作流程的政策決定該請求是即時完成,還是等待其他成員審批。

直接操作

受管操作

範例

查看餘額、交易、Earn 配置及取消配置

提領、轉帳、邀請成員、建立 API 金鑰、變更政策

管控方式

帳戶權限,透過帳戶角色逐帳戶授予

工作流程配置檔案的級別,加上工作流程的審批政策

完成方式

立即

即時完成,或依據政策設定於審批後完成

受管操作按工作流程分類管理。每個工作流程均有其專屬審批政策,並在每位成員的工作流程配置檔案中設有「查看 / 發起 / 審批 / 執行」各級別。

工作流程

管控範圍

提款請求

提款至已加入白名單的外部地址

轉帳請求

組織各帳戶之間的資金劃轉

管理團隊及存取權限

成員邀請、啟用、帳戶角色及工作流程配置檔

管理 API 金鑰

建立、編輯及撤銷 API 金鑰

管理帳戶

帳戶生命週期管理,包括新增、編輯、停用及刪除

管理地址

提款目的地白名單

管理政策

管轄所有其他工作流程的審批規則

Organization——將成員、帳戶及治理整合於同一架構下的頂層容器。

Account——獨立的運營單元,各自擁有獨立餘額、未成交訂單及歷史紀錄。各帳戶的存取權限互不相通。

Main account(主帳戶)——Organization 建立時既有的帳戶。主帳戶支援成員進行現貨交易及孖展交易;其他帳戶目前僅支援現貨交易。請參閱 適用範圍與限制

Account permission(帳戶權限)——授權成員在特定帳戶執行特定操作的權限項目:Read(查看)、Trade(交易)、Earn Allocate(理財配置)、Earn Deallocate(理財取消配置)、Withdraw(提領)或 Transfer(轉帳)。

Account Role(帳戶角色)——可重複使用的帳戶權限組合,適用於指定的一組帳戶。成員可持有多個 Account Role,各角色的權限將累加合併。

Workflow(工作流程)——共用同一審批政策的一組相關受管轄操作:Withdrawal Request(提款請求)、Transfer Request(轉帳請求)、Manage Team & Access(管理團隊及存取權限)、Manage API Keys(管理 API 金鑰)、Manage Accounts(管理帳戶)、Manage Addresses(管理地址)及 Manage Policies(管理政策)。

Workflow Profile(工作流程設定檔)——每位成員持有的唯一設定檔,定義其在各工作流程中的權限級別(View、Initiate、Approve、Execute)。Workflow Profile 的權限級別適用於整個 Organization。

Policy(政策)——單一工作流程的審批配置:定義請求所需的審批數量,以及是否每項請求均須經審批。每個工作流程各設一套政策,對整個 Organization 統一生效。

Request(請求)——成員或 API 金鑰發起受管轄操作時所建立的工作單元。請求可在政策允許時即時完成,或進入審批佇列等候處理。

Security event(安全事件)——記錄 Organization 內各項操作的日誌,涵蓋執行者、來源位置、所涉帳戶及操作結果。請參閱 安全事件

Separation of duties(職責分離)——規定成員不得審批自己發起的請求。此規則由系統強制執行,不可變更。

  • 成員在任何工作流程或配置下,均不得批准自己提交的請求。
  • 權限採用累加機制。成員初始不具備任何權限,僅能獲得其 Workflow Profile 及 Account Roles 所授予的存取權限。
  • 受治理操作是否即時完成或需等待審批,取決於成員的 Workflow Profile 及工作流程的政策設定,而非操作本身的性質。
  • 更改或解鎖已鎖定的政策,須由 Workflow Profile 具備 Manage Policies 審批權限的成員進行獨立審批後方可生效。任何人(包括 Owner)均不得單獨更改已鎖定的政策。
  • 所有成員均須啟用 Organization Sign-in 2FA。該政策於創建時設定,適用於所有現有及未來成員。
  • 閒置工作階段將自動過期,須重新完成身分驗證。
  • 每次登入、權限變更、資金移動及政策變更,均會記錄為安全事件。
  • 請先在 Kraken Pro 上擁有已完成企業驗證的 Kraken 帳戶,方可創建 Organization。Standard 帳戶及入門帳戶均不符合資格。
  • 僅完成企業驗證的帳戶持有者方可創建 Organization。創建完成後,該人士將成為 Organization Owner。
  • Owner 的電子郵件地址可日後透過一般的電子郵件變更流程進行修改。此過程可能需要完成身分驗證,並可能須接受人工審核。
  • 撤銷 Organization 須聯絡客服協助處理,過程需時,且僅在滿足所需條件後方可執行。
註:

部分功能仍在陸續推出中。請參閱 適用範圍與限制,了解目前已開放的功能。

請先閱讀 創建 Organization,再依序參閱 角色、配置檔案與權限政策、審批與治理推行治理。如需管理 Organization 的特定部分,請參閱相關文章。

需要更多幫助?