就PM的角色來說，其實不需要了解安控的技術細節，但是至少要能解釋規格書上的東西。
以我之前在做API規劃的時候需要符合前一版的電子安控基準。
企業付款API屬於高風險的交易，需要符合ex.不可否認性等，針對不可否認性在做技術上的定義。這一版新版的則是比較直接針對每種交易類別去定義其需要符合的技術。
API設計架構會符合下列:

1. 身份驗證與授權機制 (Authentication & Authorization)
   等級對應機制：依據 API 處理的業務類型（如：查詢類、變更類、交易扣款類）實施不同安全等級的驗證機制（安控基準第七條）。
   標準協定採用：
   OAuth 2.0 / OIDC (OpenID Connect)：做為第三方服務機構 (TSP) 或企業用戶存取 API 的標準授權與認證框架。
   mTLS (Mutual TLS)：在傳輸層建立雙向憑證驗證，確保 API 呼叫端與提供端雙方的合法身份。
2. 傳輸加密與防竄改 (Transport Security & Integrity)
   加密等級：傳輸層強制要求使用 TLS 1.2 或 TLS 1.3 以上版本，停用存在安全漏洞的加密套件（Cipher Suite）。
   訊息簽章 (Message Signing)：針對高風險或高金額的交易類 API，需要求採用數位簽章（如 JWS / RSA-SHA256）以達到不可否認性（Non-repudiation）與防竄改。
3. API 存取控制與防護 (Access Control & Threat Protection)
   流量限制 (Rate Limiting & Throttling)：針對不同 Client 或 API Key 設定存取次數與頻率上限，防範 DDoS 攻擊與暴力破解。
   輸入校驗與過濾 (Input Validation)：實施嚴格的 Request Body / Header / Parameter 驗證，防止 SQL Injection、XSS 及 JSON 注入攻擊。
   API Gateway 整合：透過 API Gateway 統一進行 IP 白名單過濾、憑證校驗與路由控管。(現行大部分銀行會有一個APIM系統作控管)
4. 稽核軌跡與監控 (Audit Logging & Monitoring)
   完整軌跡記錄：每一筆 API 呼叫需記錄 Timestamp、Correlation ID、Client IP、呼叫者身份驗證結果及 HTTP 狀態碼。
   敏感資料遮蔽：Log 記錄時須注意個資法與安控規範，嚴禁將用戶密碼、Token、完整信用卡號或金鑰明文寫入日誌。
   異常預警機制：建立 Real-time 監控，當發生短時間大量失敗、異常 IP 存取或權限逾越時自動觸發告警。