界定營運邊界
列出配置必須支援的受監管實體、產品、客戶類型、資產、網路、來源和目的地司法管轄區以及交易對手。在了解周界之前，不要從單一閾值欄位開始。
將要求映射到控制
對於每個走廊，記錄要求來源、生效日期、解釋所有者、閾值處理、資料要求、交易對手條件和保留的證據。
| 決策 | 配置物件 |
|---|---|
| 是否需要資訊交換？ | 適用性和閾值規則 |
| 需要哪一方數據？ | 必填和條件欄位 |
| 對方能收到嗎？ | 能力和協議簡介 |
| 如果資訊無法使用怎麼辦？ | 保留、審查、拒絕或後備路線 |
| 什麼證明該規則已被應用？ | 配置和交易證據 |
測試配置
包括每個閾值處、上方和下方的測試；缺少欄位；管轄權資料相互矛盾；不受支援的交易對手；無託管錢包；重複請求；延遲確認；和配置版本變更。
預期結果應在測試執行之前獲得批准。僅記錄系統發生的操作的測試並不能證明預期的控制。
批准並發布
批准包應包括：
- 要求和解釋參考。
- 配置導出和版本。
- 測試個案、預期結果和實際結果。
- 已知限制和手動控制。
- 生效日期和回滾所有者。
- 受影響的走廊、系統和交易對手。
監控變化
當法規、監管指南、實體範圍、產品、走廊、交易對手、協議或內部風險政策改變時，觸發重新評估。使用知識圖來識別哪些文件、控制項和組態依賴已變更的實體。