Well-Architected Framework：金融服務業 (FSI) 觀點

這份Google Cloud Well-Architected Framework 文件說明相關原則和建議，協助您在 Google Cloud 設計、建構及管理金融服務業 (FSI) 應用程式，以達成營運、安全性、可靠性、成本和效能目標。

本文件的目標對象包括決策者、架構師、管理員、開發人員和營運人員，他們負責在 Google Cloud中設計、建構、部署及維護 FSI 工作負載。可從本指南獲益的金融服務機構包括銀行、支付基礎架構業者、保險供應商和資本市場營運商。

金融服務機構有特別的考量，尤其是架構和復原能力。這些考量因素主要是受到法規、風險和效能要求的影響。本文提供高階指引，內容根據我們在全球各地 FSI 客戶的設計考量而來。無論工作負載完全位於雲端，還是要轉換為混合雲或多雲端部署作業，本文的指引都有助於您在 Google Cloud 上設計工作負載，以滿足法規要求和各種風險觀點。這些指引可能無法解決每個機構的獨特挑戰。可滿足金融服務機構的許多主要法規要求。

設計雲端工作負載時，主要挑戰在於如何讓雲端部署作業與地端環境保持一致，特別是當您希望在安全性、可靠性和韌性方面採取一致的做法時。雲端服務可提供機會，讓您從根本上重新思考架構，進而減少管理負擔、最佳化成本、提升安全性，並提高可靠性和復原能力。

以下頁面說明針對 Well-Architected Framework 各大支柱的 FSI 工作負載，所適用的原則和建議：

貢獻者

作者：

其他貢獻者：

金融服務業觀點：卓越的營運成果

這份Google Cloud Well-Architected Framework 的金融服務業觀點文件，概述了在 Google Cloud中建構、部署及運作穩健金融服務業 (FSI) 工作負載的原則和建議。這些建議可協助您設定觀測能力、自動化和擴充性等基本要素。本文中的建議符合 Well-Architected Framework 的卓越營運支柱。

由於金融服務業工作負載受到嚴格監管，且性質敏感，因此卓越營運至關重要。 Google Cloud 卓越營運可確保雲端解決方案能因應不斷變化的需求，並滿足您對價值、效能、安全性和可靠性的要求。如果這些領域發生問題，可能會導致重大財務損失、監管處罰和聲譽受損。

卓越營運可為金融服務機構工作負載帶來以下優勢：

  • 維護信任和聲譽：金融機構非常依賴顧客的信任。營運中斷或發生安全漏洞可能會嚴重破壞這份信任，導致客戶流失。卓越營運有助於盡量降低這些風險。

  • 符合嚴格的法規遵循要求：金融服務產業須遵守許多複雜的法規，例如：

    完善的作業程序、監控和事件管理機制，是證明符合法規要求及避免處罰的必要條件。

  • 確保業務持續運作和復原能力：金融市場和服務通常會持續運作。因此，高可用性和有效的災難復原至關重要。優質營運原則可做為設計和實作彈性系統的指引。如需這方面的更多指引，請參閱可靠性支柱。

  • 保護機密資料：金融機構會處理大量高度機密的客戶和財務資料。為防範資料外洩及維護隱私權，必須採取嚴格的作業控管措施、進行安全監控，並快速應變事件。如需這方面的更多指引，請參閱安全性支柱。

  • 提升重要應用程式的效能：許多金融應用程式 (例如交易平台和即時分析) 都需要高效能和低延遲。如要符合這些效能需求，您需要經過高度最佳化的運算、網路和儲存空間設計。如需這方面的更多指引，請參閱成效最佳化支柱。

  • 有效管理成本：除了安全性和可靠性，金融機構也重視成本效益。卓越營運包括最佳化資源使用率和管理雲端支出的做法。如需這方面的更多指引，請參閱成本最佳化支柱。

本文中的優質營運建議會對應至下列核心原則：

定義服務水準協議，以及相應的服務等級目標和服務水準指標

在許多金融服務機構中，應用程式的可用性通常是根據復原時間目標 (RTO) 和復原點目標 (RPO) 指標分類。如果是為外部客戶提供服務的業務關鍵應用程式，可能也會定義服務水準協議 (SLA)。

服務等級協議需要指標架構，從使用者滿意度的角度呈現系統行為。網站穩定性工程 (SRE) 做法可協助您達到所需的系統穩定性。建立指標架構時，需要定義及監控重要的數值指標，從使用者的角度瞭解系統健康狀態。舉例來說，延遲時間和錯誤率等指標可量化服務的效能。這些指標稱為服務水準指標 (SLI)。開發有效的 SLI 至關重要，因為這是客觀評估可靠性所需的原始資料。

如要定義有意義的服務水準協議、SLI 和 SLO，請參考下列建議：

  • 為每項重要服務開發及定義服務水準指標。設定目標值，定義可接受的效能等級。
  • 根據服務水準指標 (SLI) 開發及定義服務等級目標 (SLO)。舉例來說，服務等級目標可能會規定 99.9% 的要求延遲時間必須少於 200 毫秒。
  • 如果服務未達到 SLO，請找出必須採取的內部補救措施。舉例來說，為提升平台韌性，您可能需要將開發資源集中用於修正問題。
  • 驗證各項服務的服務水準協議需求，並將服務水準協議視為與服務使用者的正式合約。

服務等級範例

下表列出付款平台服務等級指標、服務等級目標和服務等級協議的範例：

業務指標 SLI SLO 服務水準協議
付款交易成功

這項指標會以百分比的形式，顯示成功處理及確認的付款交易占所有發起交易的比例。

範例：(成功交易次數 ÷ 有效交易總次數) × 100，以 5 分鐘的滾動時間範圍計算。

內部目標：在特定期間內，維持高比例的付款交易成功率。

示例：在 30 天的滾動週期內，維持 99.98% 的付款交易成功率，並排除無效要求和預定維護作業。

合約保證付款交易處理的成功率和速度。

範例：服務供應商保證，客戶發起的付款交易中，有 99.0% 會在一秒內成功處理並確認。
付款處理延遲

從客戶發起付款交易到最終確認，處理交易的平均時間。

範例：交易確認的平均回應時間 (以毫秒為單位)，以 5 分鐘的滾動時間範圍為測量依據。

處理付款交易的速度內部目標。

示例：確保在 30 天的滾動期間內，有 99.5% 的付款交易在 400 毫秒內處理完畢。

合約承諾在指定時間範圍內解決重大付款處理問題。

示例：如果發生重大付款處理問題 (定義為影響超過 1% 交易的中斷)，服務供應商承諾在問題回報或偵測到後兩小時內解決。
平台適用情形

核心付款處理 API 和使用者介面可供用戶端運作和存取的時間百分比。

範例：(總運作時間 − 停機時間) ÷ 總運作時間 × 100，以分鐘為單位計算。

核心付款平台的運作時間內部目標。

範例：在每個曆月內，平台可用性達到 99.995%，不含排定的維護期間。

對客戶做出正式且具法律約束力的承諾，保證支付平台最低正常運作時間，包括未達標的後果。

示例：平台在每個曆月至少會維持 99.9% 的可用性，但預定維護時段除外。如果可用性低於最低等級，每下降 0.1%，客戶就能獲得每月服務費 5% 的服務抵免額。

使用 SLI 資料監控系統是否符合定義的 SLO，並確保符合 SLA。工程師和開發人員可使用一組定義完善的 SLI，在下列層級監控 FSI 應用程式：

  • 直接在應用程式部署的服務中，例如 GKE 或 Cloud Run。
  • 使用基礎架構元件 (例如負載平衡器) 提供的記錄。

OpenTelemetry 提供開放原始碼標準和技術組合，可擷取所有類型的遙測資料，包括指標、追蹤記錄和記錄檔。Google Cloud Managed Service for Prometheus 提供全代管、高度可擴充的指標後端，以及大規模運作 Prometheus 的功能。

如要進一步瞭解 SLI、SLO 和錯誤預算，請參閱 SRE 手冊。

如要開發有效的快訊和監控資訊主頁與機制，請搭配使用 Google Cloud Observability 工具和Google Cloud 監控。如要瞭解安全性專屬的監控和偵測功能，請參閱安全性支柱。

定義及測試事件管理程序

定義完善且定期測試的事件管理程序，可直接提升 Google Cloud中 FSI 工作負載的價值、效能、安全性和可靠性。這些程序可協助金融機構滿足嚴格的法規要求、保護私密/機密資料、維持業務連續性，並贏得客戶信任。

定期測試事件管理流程可帶來下列好處：

  • 在負載量達到高峰時維持效能：定期進行效能和負載測試，有助於金融機構確保雲端應用程式和基礎架構能應付交易量高峰、市場波動和其他高需求情境，且效能不會下降。這項功能對於維持流暢的使用者體驗，以及滿足金融市場的需求至關重要。
  • 找出潛在瓶頸和限制：壓力測試會將系統推向極限，讓金融機構在潛在瓶頸和效能限制影響重要作業前，找出這些問題。這種主動式做法可讓金融機構調整基礎架構和應用程式，以獲得最佳效能和擴充性。
  • 驗證可靠性和韌性：定期測試 (包括混亂工程或模擬故障) 有助於驗證金融系統的可靠性和韌性。這項測試可確保系統能從故障中順利復原，並維持高可用性，這對業務持續性至關重要。
  • 有效規劃容量： 效能測試可提供不同負載條件下的資源用量相關寶貴資料，有助於準確規劃容量。 金融機構可運用這項資料，主動預測未來的容量需求，避免因資源限制而導致效能問題。
  • 順利部署新功能和程式碼變更：將自動化測試整合至 CI/CD 管道，有助於確保變更和新部署項目在發布至正式環境前，都經過徹底驗證。這種做法可大幅降低錯誤和回歸的風險，避免作業中斷。
  • 符合系統穩定性的法規要求：金融法規通常會要求機構採用完善的測試做法，確保重要系統的穩定性和可靠性。定期測試有助於證明您符合這些規定。

如要定義及測試事件管理程序，請參考下列建議。

建立明確的事件應變程序

一套完善的事件應變程序包含下列要素：

  • 為事件指揮官、調查人員、溝通人員和技術專家定義角色和職責，確保有效且協調一致的應變措施。
  • 定義通訊協定和向上呈報路徑，確保在事件期間及時有效地分享資訊。
  • 手冊或劇本中記錄的程序，概述通報、分類、調查和解決問題的步驟。
  • 定期訓練和準備，讓團隊具備有效應對的知識和技能。

定期執行效能和負載測試

定期進行效能和負載測試，有助於確保雲端應用程式和基礎架構能處理尖峰負載，並維持最佳效能。負載測試會模擬實際的流量模式。壓力測試會將系統推向極限，找出潛在瓶頸和效能限制。您可以運用 Cloud Load Balancing 和負載測試服務等產品，模擬實際流量。您可以根據測試結果調整雲端基礎架構和應用程式，以獲得最佳效能和擴充性。舉例來說，您可以調整資源分配或微調應用程式設定。

在持續整合/持續推送軟體更新管道中自動執行測試

在 CI/CD 管道中加入自動化測試，有助於在部署前驗證變更，確保雲端應用程式的品質和可靠性。這種做法可大幅降低錯誤和回歸的風險，並協助您建構更穩定可靠的軟體系統。您可以在 CI/CD 管道中納入不同類型的測試，包括單元測試、整合測試和端對端測試。使用 Cloud Build 和 Cloud Deploy 等產品，建立及管理 CI/CD 管道。

持續改良和創新

對於雲端中的金融服務工作負載，遷移至雲端只是第一步。持續強化和創新至關重要，原因如下：

  • 加速創新：運用 AI 等新技術改善服務。
  • 降低成本：消除效率不彰的情況，並最佳化資源用量。
  • 提升靈活度：快速因應市場和法規變化。
  • 改善決策品質：使用 BigQuery 和 Looker 等資料分析產品，做出明智的選擇。

為確保持續改善和創新，請考慮下列建議。

定期進行回顧

回顧對於持續改善事件應變程序至關重要，且有助於根據定期效能和負載測試的結果，調整測試策略。為確保回顧會議有效，請採取下列做法：

  • 讓團隊有機會反思自己的體驗、找出表現良好的部分，並找出待改善的地方。
  • 在專案里程碑、重大事件或重要測試週期後，進行回顧。團隊可以從成功和失敗中學習，並持續改善流程和做法。
  • 請使用「開始、停止、繼續」等結構化方法，確保回顧會議能有效率地進行，並產生可執行的步驟。
  • 透過回顧檢討，找出可進一步強化變更管理自動化的領域，以提高可靠性並降低風險。

培養學習文化

學習文化有助於安全探索新技術，例如運用 AI 和機器學習功能強化詐欺偵測和個人化財務建議等服務。Google Cloud如要推廣學習文化，請執行下列操作：

  • 鼓勵團隊進行實驗、分享知識，並持續學習。
  • 建立不究責的文化，將失敗視為成長和改善的機會。
  • 建立心理安全環境，讓團隊敢於冒險並考慮創新解決方案。團隊會從成功和失敗中學習，進而打造更具韌性和適應力的機構。
  • 培養分享知識的文化，讓員工能從事件管理程序和測試演練中學習。

掌握雲端技術的最新動態

持續學習有助於瞭解及導入新的安全措施、運用進階資料分析取得更深入的洞察資料，以及採用與金融業相關的創新解決方案。

  • 隨時掌握最新進展、功能和最佳做法，充分發揮 Google Cloud 服務的潛力。
  • 推出新 Google Cloud 功能和服務時，請找出進一步自動化程序、提升安全性，以及改善應用程式效能和擴充性的機會。
  • 參加相關研討會、網路研討會和訓練課程，拓展知識並瞭解新功能。
  • 鼓勵團隊成員取得Google Cloud 認證，確保機構具備在雲端環境中獲得成功的必要技能。

金融服務業觀點：安全性、隱私權和法規遵循

這份文件位於Google Cloud 架構完善的架構：金融服務業觀點 ，提供原則和建議總覽，協助您在 Google Cloud中處理金融服務業 (FSI) 工作負載的安全、隱私權和法規遵循需求。這些建議可協助您建構符合法規的彈性基礎架構、保護機密資料、維護客戶信任、因應複雜的法規要求，以及有效管理網路威脅。本文中的建議與 Well-Architected Framework 的安全性支柱一致。

雲端運算安全是金融服務機構 (FSI) 的重大疑慮，因為這類機構管理大量敏感資料 (包括客戶詳細資料和財務記錄)，因此對網路犯罪者極具吸引力。安全漏洞的後果非常嚴重，包括巨額財務損失、長期信譽受損和巨額監管罰款。因此，金融服務業工作負載需要嚴格的安全控管機制。

為確保全面安全和法規遵循，您需要瞭解您 (金融服務機構) 與 Google Cloud之間的共同責任。 Google Cloud 負責保護基礎架構，包括實體安全和網路安全。您有責任保護資料和應用程式、設定存取權控管機制，以及設定和管理安全服務。為協助您提升安全性，Google Cloud 合作夥伴生態系統提供安全整合和管理服務。

本文中的安全性建議對應至下列核心原則：

採用融入安全考量的設計

付款卡產業資料安全標準 (PCI DSS)、美國的葛萊姆-里奇-布萊利法案 (GLBA)，以及各國的金融資料保護法等金融法規，都規定系統必須從一開始就整合安全性。「設計即安全」原則強調在整個開發生命週期中整合安全性，從一開始就盡量減少安全漏洞。

如要在Google Cloud中為 FSI 工作負載套用「設計即安全」原則，請參考下列建議：

  • 透過 Identity and Access Management (IAM) 中的精細角色型存取權控管 (RBAC)，套用最低權限原則，確保只授予必要權限。許多金融法規都規定必須使用 RBAC。
  • 使用 VPC Service Controls，在 Google Cloud 內對機密服務和資料強制執行安全防護範圍。安全防護範圍有助於區隔及保護機密資料和資源，並根據法規要求，防止資料外洩和未經授權的存取行為。
  • 使用基礎架構即程式碼 (IaC) 工具 (如 Terraform)，以程式碼形式定義安全性設定。這種做法會在初始部署階段嵌入安全控制項，有助於確保一致性和可稽核性。
  • 整合靜態應用程式安全測試 (SAST)，透過 Cloud Build 掃描 CI/CD 管道中的應用程式碼。建立自動安全閘道，防止部署不符規定的程式碼。
  • 使用 Security Command Center 提供安全性深入分析的統一介面。使用 Security Command Center 可持續監控並及早偵測設定錯誤或威脅，避免違反法規。如要符合 ISO 27001 和 NIST 800-53 等標準的規定，可以使用安全狀態管理範本。
  • 追蹤正式版部署作業中發現的安全漏洞減少情形，以及符合安全最佳做法的 IaC 部署作業百分比。您可以使用 Security Command Center 偵測及查看安全漏洞，以及有關安全標準法規遵循情形的資訊。詳情請參閱「安全漏洞發現結果」。

導入零信任機制

現代金融法規日益強調嚴格存取控管和持續驗證的重要性。這些要求反映了零信任原則，旨在保護工作負載免受內部和外部威脅及惡意行為者的侵擾。零信任原則主張持續驗證每位使用者和裝置，藉此消除隱含信任，並降低橫向移動的風險。

如要實作零信任，請考慮下列建議：

  • 結合 IAM 控制項和 Chrome Enterprise Premium，根據使用者身分、裝置安全性、位置和其他因素啟用情境感知存取權。確保系統在授予財務資料和系統的存取權前，會持續進行驗證。
  • 設定 Identity Platform (或使用員工身分聯盟時的外部身分提供者)，提供安全且可擴充的身分和存取權管理服務。設定多重驗證 (MFA) 和其他控管措施，這些措施對於實作零信任和確保法規遵循至關重要。
  • 為所有使用者帳戶導入 MFA，尤其是可存取機密資料或系統的帳戶。
  • 全面記錄及監控使用者存取權和網路活動，支援與法規遵循相關的稽核和調查。
  • 使用 Private Service Connect，在Google Cloud 和內部部署環境中啟用服務間的私密安全通訊，不必將流量暴露在公開網際網路上。
  • 使用 Identity-Aware Proxy (IAP) 實行精細的身分控管機制，並在應用程式層級授權存取權，而不必依賴 VPN 通道等網路型安全機制。這個方法有助於減少環境內的橫向移動。

導入「優先確保安全」機制

金融監管機構鼓勵採取主動式安全防護措施。在開發生命週期早期找出並解決安全漏洞，有助於降低安全事件風險，以及因違規而遭處罰的可能性。「提早測試」的安全性原則提倡早期安全性測試和整合，有助於降低修復成本和複雜度。

如要實作「左移」安全防護，請考慮下列建議：

  • 將容器安全漏洞掃描和靜態程式碼分析等安全性掃描工具整合至 CI/CD pipeline，並搭配 Cloud Build，確保在開發過程初期進行自動安全性檢查。

  • 使用 Artifact Registry 提供安全的集中式存放區，儲存軟體套件和容器映像檔，並整合安全漏洞掃描功能，確保只部署安全的構件。使用虛擬存放區，優先處理私人構件而非遠端存放區，藉此防範依附元件混淆攻擊。

  • 將 Web Security Scanner (Security Command Center 的一部分) 整合至開發管道，自動掃描網頁應用程式中的常見安全漏洞。

  • 使用軟體構件供應鏈級別 (SLSA) 架構，針對原始碼、建構程序和程式碼出處實作安全性檢查。使用二進位授權等解決方案，強制執行環境中執行工作負載的來源。使用 Assured Open Source，確保工作負載只使用經過驗證的開放原始碼軟體程式庫。

  • 追蹤開發生命週期中發現及修復的安全漏洞數量、通過安全掃描的程式碼部署百分比，以及軟體安全漏洞導致的安全事件減少量。 Google Cloud 提供相關工具，協助追蹤不同類型的工作負載。舉例來說，如果是容器化工作負載，請使用 Artifact Registry 的容器掃描功能。

預先防範網路威脅

金融機構是網路攻擊高手的首要目標。 法規通常要求組織具備強大的威脅情報和主動防禦機制。先發制人的網路防禦措施著重於主動偵測威脅，並運用進階分析和自動化功能做出回應。

請參考下列建議：

安全且負責任地使用 AI，並運用 AI 強化安全防護

AI 和 ML 越來越常應用於金融服務，例如偵測詐欺和演算法交易。法規要求以合乎道德、公開透明且安全的方式使用這些技術。AI 也能協助提升安全防護能力。使用 AI 時，請參考下列建議：

  • 使用 Vertex AI 在安全且受控的環境中開發及部署機器學習模型。模型可解釋性和公平性指標等功能，有助於解決負責任的 AI 相關疑慮。
  • 善用 Google Security Operations 的安全分析和營運功能，運用 AI 和機器學習技術分析大量安全資料、偵測異常狀況，並自動應對威脅。這些功能有助於提升整體安全防護機制，並監控法規遵循狀況。
  • 為 AI 和機器學習的開發與部署程序制定明確的治理政策，包括安全性和倫理相關考量。
  • 遵循安全 AI 架構 (SAIF) 的要素，這個架構提供實用做法，可解決 AI 系統的安全性和風險疑慮。
  • 追蹤 AI 輔助詐欺偵測系統的準確度和效力、安全警示誤判次數的減少量，以及 AI 輔助安全自動化帶來的效率提升。

滿足法規遵循和隱私權需求

金融服務須遵守各種法規，包括資料落地要求、特定稽核追蹤記錄和資料保護標準。為確保機密資料獲得妥善識別、保護及管理，金融服務機構需要健全的資料治理政策和資料分類架構。請參考下列建議，確保符合法規規定：

  • 在 Google Cloud 中使用 Assured Workloads，為機密和受監管的工作負載設定資料邊界。這有助於您符合政府和產業專屬的法規遵循要求，例如 FedRAMP 和 CJIS。
  • 導入 Cloud Data Loss Prevention (Cloud DLP)，識別、分類及保護機密資料，包括財務資訊。這樣做有助於您遵守《一般資料保護規則》(GDPR) 和《加州消費者隱私法》(CCPA) 等資料隱私權法規。
  • 使用 Cloud 稽核記錄追蹤管理活動和資源存取權的詳細資料。這些記錄對於滿足許多金融法規規定的稽核要求至關重要。
  • 為工作負載和資料選擇Google Cloud 區域時，請考量與資料落地相關的當地法規。 Google Cloud 全球基礎架構可讓您選擇區域，協助您符合資料落地要求。
  • 使用 Cloud Key Management Service 管理用於加密靜態和傳輸中機密財務資料的金鑰。許多安全和隱私權法規都規定必須採用這類加密技術。
  • 實作必要控管機制，以符合法規要求。確認控管機制是否正常運作。請外部稽核人員再次驗證控制項，向監管機構證明您的工作負載符合法規。

優先推動安全措施

由於安全需求範圍廣泛，金融機構必須根據風險評估和法規授權，優先推動相關措施。建議您採取下列分階段做法：

  1. 建立穩固的安全基礎：著重於安全性的核心領域，包括身分和存取權管理、網路安全和資料保護。這項重點有助於建立強大的安全防護措施，確保全面防禦不斷演變的威脅。
  2. 遵守重要法規：優先遵守 PCI DSS、GDPR 和相關國家/地區法律等重要法規。這麼做有助於確保資料受到保護、降低法律風險，並贏得顧客信任。
  3. 導入進階安全防護措施：逐步採用進階安全防護措施，例如零信任、AI 輔助安全防護解決方案，以及主動式威脅搜尋。

金融服務業觀點：可靠性

這份Google Cloud Well-Architected Framework：金融服務業觀點文件概述了在Google Cloud中設計、部署及運作可靠金融服務業 (FSI) 工作負載的原則和建議。這份文件探討如何將進階可靠性做法和可觀測性整合到架構藍圖中。本文件中的建議符合 Well-Architected Framework 的可靠性支柱。

對金融機構而言，穩定且具彈性的基礎架構不僅是業務需求，也是法規要求。為確保金融服務業工作負載的可靠性，您必須瞭解並降低潛在故障點、部署備援資源，以及規劃復原作業。Google Cloud 營運韌性是可靠性的結果。韌性是指吸收、適應及從中斷中復原的能力。作業彈性可協助金融服務機構組織滿足嚴格的法規要求。並避免對消費者造成無法容忍的傷害。

可靠性的主要建構區塊 Google Cloud 是區域、可用區，以及雲端資源的各種位置範圍：可用區、區域、多區域和全球。您可以運用受管理服務、分配資源、導入高可用性模式，以及自動化處理程序，進一步提升可用性。

法規要求

金融服務機構須遵守監管機構的嚴格可靠性規定，例如美國的聯邦準備系統、歐盟的歐洲銀行業管理局，以及英國的審慎監理局。全球監管機構都強調營運韌性，這對金融穩定和消費者保護至關重要。營運韌性是指承受中斷、有效復原及維持重要服務的能力。因此，管理技術風險和對第三方依賴關係時，必須採取一致的做法。

大多數司法管轄區的法規要求都有以下共同主題：

  • 網路安全和技術韌性：加強防禦網路威脅，確保 IT 系統的韌性。
  • 第三方風險管理：管理與外包服務相關的風險，這些服務是外包給資訊及通訊科技 (ICT) 供應商。
  • 營運持續性和事件應變：完善的計畫，可在中斷期間維持重要營運，並有效復原。
  • 維護金融穩定：確保整體金融系統的健全和穩定。

本文中的可靠性建議對應至下列核心原則：

優先部署多區域和多地區網路

對於重要的金融服務應用程式，建議您使用多區域拓撲，並將應用程式分散到至少兩個區域，以及每個區域內的三個可用區。這種做法對於防範可用區和區域服務中斷至關重要。法規通常會規定採用這種做法，因為如果某個可用區或區域發生故障，大多數管轄區會認為第二個可用區嚴重中斷是可能發生的後果。理由是當一個位置發生故障時，另一個位置可能會收到異常大量的額外流量。

建議您參考下列做法，防範可用區和區域中斷：

  • 盡量選擇涵蓋範圍較廣的資源。盡可能使用區域資源，而非可用區資源；使用多區域或全域資源，而非區域資源。這種方法有助於避免使用備份還原作業。
  • 在每個區域中，請使用三個可用區，而非兩個。如要處理容錯移轉，請將容量佈建量設為預估值的 1.33 倍。
  • 實作主動-主動部署 (如以下範例)，盡量減少手動復原步驟：
    • Spanner 等分散式資料庫提供內建的備援機制，並可在不同地區之間同步處理。
    • Cloud SQL 的高可用性功能提供近乎主動-主動的拓撲，並在各個可用區中提供讀取副本。可提供接近 0 的區域間復原點目標 (RPO)。
  • 使用 Cloud DNS 將使用者流量分配至各區域，並在每個區域中部署區域負載平衡器。您也可以視需求和重要性，考慮使用全球負載平衡器。詳情請參閱「多區域部署的全域負載平衡優點和風險」。
  • 如要儲存資料，請使用多區域服務，例如 Spanner 和 Cloud Storage。

排除單點故障

將資源分配到不同位置，並使用備援資源，避免單一故障點 (SPOF) 影響整個應用程式堆疊。

請參考下列建議，避免出現單點故障：

詳情請參閱「為 Google Cloud中的工作負載設計可靠的基礎架構」。

瞭解及管理匯總供應情形

請注意，系統的整體或匯總可用性會受到系統各層級或元件可用性的影響。應用程式堆疊中的層級數量與堆疊的整體可用性成反比。如要管理匯總供應情形，請參考下列建議：

  • 使用公式 tier1_availability × tier2_availability × tierN_availability，計算多層堆疊的總可用性。

    下圖顯示由四項服務組成的多層級系統，其匯總可用性計算方式如下：

    具有四項服務的多層級服務的匯總可用性公式。

    在上圖中，每個層級的服務可用性為 99.9%，但系統的總可用性較低，為 99.6% (0.999 × 0.999 × 0.999 × 0.999)。一般來說，多層堆疊的整體可用性會低於可用性最低的層。

  • 如有可能，請選擇「平行化」而非「串鏈」。平行化服務的端對端可用性高於個別服務的可用性。

    下圖顯示使用鏈結和平行化方法部署的兩個服務 A 和 B：

    鏈結服務與平行化服務的匯總可用性公式。

    在上述範例中，兩項服務的服務水準協議都是 99%，因此根據實作方法，匯總可用性如下：

    • 串聯服務的整體可用性僅為 98% (.99 × .99)。
    • 平行化服務可提供 99.99% 的更高總可用性，因為每項服務都是獨立運作，個別服務不會受到其他服務可用性的影響。匯總平行服務的公式為 1 − (1 − A) × (1 − B)。

  • 選擇 Google Cloud 提供正常運作時間服務水準協議的服務，協助應用程式堆疊達到整體正常運作時間的必要等級。

  • 設計架構時，請權衡可用性、作業複雜度、延遲時間和成本。可用性每增加一個 9，通常成本就會提高，但這樣做有助於您符合法規要求。

    舉例來說，99.9% 的可用性 (三個 9) 代表一天 24 小時內，可能會有 86 秒的停機時間。相較之下，99% (兩個 9) 代表在同一段時間內停機 864 秒，停機時間是可用性為三個 9 的 10 倍。

    對於重要金融服務，架構選項可能有限。不過，找出供應情形需求並準確計算供應情形至關重要。進行這類評估有助於您評估設計決策對架構和預算的影響。

導入完善的 DR 策略

針對不同災害情境 (包括區域和區域性服務中斷) 制定明確的計畫。明確的災難復原 (DR) 策略可協助您從中斷事件中復原，並在影響最小的情況下恢復正常運作。

災難復原和高可用性 (HA) 是不同的概念。在雲端部署中，一般而言，DR 適用於多區域部署，HA 則適用於區域部署。這些部署原型支援不同的複製機制。

  • HA：許多代管服務預設會在單一區域內的可用區之間提供同步複製功能。這類服務支援零或接近零的復原時間目標 (RTO) 和復原點目標 (RPO)。這項支援功能可讓您建立沒有 SPOF 的主動/主動部署拓撲。
  • DR：如果工作負載部署在兩個以上的區域，且您未使用多區域或全球服務，則必須定義複製策略。複製策略通常為非同步。 請仔細評估這類複製作業對重要應用程式的 RTO 和 RPO 有何影響。找出容錯移轉所需的半自動或手動作業。

對於金融機構，您選擇的容錯移轉區域可能受到資料主權和資料落地相關法規的限制。如果您需要在兩個區域之間使用「作用中-作用中」拓撲，建議您選擇受管理的多區域服務，例如 Spanner 和 Cloud Storage，尤其是在資料複製至關重要時。

請參考下列建議：

  • 使用代管的多地區儲存服務儲存資料。
  • 為永久磁碟中的資料建立快照，並將快照儲存在多區域位置。
  • 使用區域或地區資源時，請設定資料複製到其他地區。
  • 定期測試 DR 方案，確保方案有效。
  • 請注意，RTO 和 RPO 與您所在管轄區金融法規規定的影響容許度相關。

詳情請參閱「為雲端基礎架構中斷情況設計災難復原機制」。

運用代管服務

請盡可能使用代管服務，充分運用備份、高可用性和擴充性的內建功能。使用代管服務時，請參考下列建議：

  • 在 Google Cloud中使用代管服務。提供有服務水準協議保障的高可用性。同時也提供內建備份機制和復原功能。
  • 如要管理資料，不妨考慮使用 Cloud SQL、Cloud Storage 和 Spanner 等服務。
  • 如要代管運算和應用程式，請考慮使用 Compute Engine 代管執行個體群組 (MIG) 和 Google Kubernetes Engine (GKE) 叢集。地區性 MIG 和 GKE 地區叢集可抵禦可用區中斷。
  • 如要提高區域中斷的復原能力，請使用代管多區域服務。
  • 針對具有獨特特徵的服務，找出退場計畫的需求，並定義必要計畫。FCA、PRA 和 EBA 等金融監管機構要求企業制定資料擷取和營運持續策略與應變計畫，以防與雲端供應商的關係終止。公司必須先評估退出可行性，再簽訂雲端合約，且必須維持更換供應商的能力，避免作業中斷。
  • 確認所選服務支援將資料匯出為開放格式，例如 CSV、Parquet 和 Avro。確認服務是否以開放技術為基礎，例如 GKE 支援開放容器倡議 (OCI) 格式，或以 Apache Airflow 為基礎建構的 Cloud Composer。

自動執行基礎架構佈建和復原程序

自動化有助於減少人為錯誤，並縮短事件回應所需的時間和資源。使用自動化功能可確保更快從失敗中復原，並獲得更一致的結果。請考慮下列建議，自動佈建及復原資源：

  • 使用 Terraform 等基礎架構即程式碼 (IaC) 工具，盡量減少人為錯誤。
  • 自動執行容錯移轉程序，減少人為介入。自動回覆功能也有助於減少失敗造成的影響。舉例來說，您可以透過 Eventarc 或 Workflows，針對稽核記錄中發現的問題自動觸發補救措施。
  • 使用自動調度資源功能，在容錯移轉期間增加雲端資源容量。
  • 採用平台工程，在服務部署期間，自動為雲端拓撲套用法規要求適用的政策和防護措施。

金融服務業觀點：成本最佳化

這份Google Cloud Well-Architected Framework：金融服務業觀點文件概略說明瞭相關原則和建議，可協助您在 Google Cloud中最佳化金融服務業 (FSI) 工作負載的成本。本文中的建議與 Well-Architected Framework 的成本最佳化支柱一致。

如要為金融服務工作負載進行完善的成本最佳化，需要下列基本要素：

  • 能夠找出浪費的資源使用量，以及有助於提升價值的資源使用量。
  • 培養財務責任感。

如要盡量節省成本，您必須全面瞭解貴機構的成本驅動因素和資源需求。在某些大型機構中，尤其是處於雲端轉型初期的機構，通常由單一團隊負責在大量網域中盡量節省支出。這個方法假設中央團隊最適合找出高價值商機，進而提高效率。

在雲端採用初期或處理非重要工作負載時，集中式方法或許能帶來一些成效。不過，單一團隊無法在整個機構中推動成本最佳化。當資源用量或監管審查程度增加時，集中式方法就無法持續運作。集中式團隊在處理大量金融產品和服務時，特別容易遇到擴充性方面的挑戰。擁有產品和服務的專案團隊可能會抗拒外部團隊所做的變更。

如要有效最佳化成本，支出相關資料必須一目瞭然，且工程師和其他雲端使用者必須有動力採取行動，盡可能最佳化成本。從組織的角度來看，成本最佳化面臨的挑戰是找出應最佳化的領域、負責這些領域的工程師，然後說服他們採取必要的最佳化行動。本文提供相關建議，協助您應對這項挑戰。

本文中的成本最佳化建議會對應至下列核心原則：

使用 Google Cloud 工具找出浪費的費用

Google Cloud 提供多項產品、工具和功能，協助您找出浪費的資源。請參考下列建議。

運用自動化和 AI 技術，有系統地找出需要最佳化的項目

Active Assist 可針對金融服務業的重要服務提供智慧建議，例如微服務適用的 Cloud Run、資料分析適用的 BigQuery、核心應用程式適用的 Compute Engine，以及關聯式資料庫適用的 Cloud SQL。Active Assist 建議免費提供，您不必進行任何設定。這些建議有助於找出閒置資源和未充分利用的承諾。

透過統一介面集中監控及控管 FinOps

您可以透過 Cloud Billing 報表和 FinOps 中心，全面監控成本。這個全面檢視畫面對於財務稽核人員和內部財務團隊來說至關重要，有助於追蹤雲端支出、評估財務狀況、評估各業務部門或成本中心的 FinOps 成熟度，以及提供一致的財務敘述。

分析及擴增支出資料，找出價值所在

Active Assist 能夠有效找出明顯的浪費情況，不過，要找出價值可能比較困難，特別是當工作負載位於不適合的產品上，或是工作負載與業務價值缺乏明確的關聯時。對於金融服務業工作負載，業務價值不僅限於降低成本，價值包括降低風險、遵守法規，以及取得競爭優勢。

如要全面瞭解雲端支出和價值，您需要從多個層面完整掌握資訊：支出來源、支出帶動的業務功能，以及重構或最佳化相關工作負載的技術可行性。

下圖說明如何運用資料-資訊-知識-智慧 (DIKW) 金字塔和工具，全面瞭解雲端費用和價值。 Google Cloud

資料-資訊-知識-智慧 (DIKW) 金字塔說明如何運用雲端支出資料輔助決策。

上圖說明如何運用 DIKW 方法，將原始雲端支出資料精煉為可做為決策依據的洞察資料，進而提升業務價值。

  • 資料：在這個層級，您可以收集雲端資源的原始用量和費用資料串流，並進行處理。中央 FinOps 團隊會使用 Cloud Billing 月結單、帳單匯出和 Cloud Monitoring 等工具，取得精細的詳細資料。舉例來說，資料點可能是指名為 app1-test-vmA 的 VM 在 us-central1 區域執行了 730 小時，費用為 $70 美元。
  • 資訊：在這個層級，中央 FinOps 團隊會使用 Cloud Billing 報表和 FinOps Hub 等工具，整理原始資料，協助回答「使用者在哪些類別的資源上花費最多？」等問題。舉例來說，您可能會發現在美國兩個區域中，機器類型為 n4-standard-2 的 VM 總共花費了 $1,050 美元。
  • 知識：在這個層級，中央 FinOps 團隊會提供適當的業務背景資訊，豐富資訊內容，說明誰花費了資金，以及用途為何。您可以使用標記、標籤、資源階層、帳單帳戶和自訂 Looker 資訊主頁等機制。舉例來說，您可能會發現美國的 app1 測試團隊在 7 月第二週的壓力測試中，花費了 $650 美元。
  • 智慧：在這個層級，產品和應用程式團隊會運用情境化知識評估雲端支出的業務價值，並做出明智的策略決策。您的團隊可能會回答下列問題：
    • 花費在資料分析管道的 $5,000 美元是否能創造商業價值？
    • 我們能否重新設計管道，在不降低效能的情況下提高效率？

以下是分析雲端支出資料的建議。

分析由 Google Cloud

首先，請將詳細的 Cloud 帳單資料匯出至 BigQuery，並使用 Monitoring 記錄檔中的資料。如要取得可做為行動依據的洞察資料並做出決策，您需要建構這類資料，並加入業務背景資訊。

透過可用工具以視覺化方式呈現資料

使用 Looker Studio 等工具，根據 BigQuery 匯出資料建立自訂報表，進一步擴充內建 Google Cloud 資訊主頁。財務團隊可以建構自訂資訊主頁，根據財務指標、法規報表要求和業務部門獲利能力，瞭解雲端支出。然後為高階利害關係人提供清楚的財務敘述，以利分析和決策。

分配支出，推動當責文化

瞭解雲端支出背後的原因後，您需要找出支出者和支出原因。如要達到這種程度的瞭解，需要健全的成本分配做法，也就是將與業務相關的中繼資料附加至雲端資源。舉例來說，如果 Banking-AppDev 團隊使用特定資源，您可以將 team=banking_appdev 等標籤附加至該資源，追蹤該團隊在該資源上產生的費用。理想情況下，您應將 100% 的雲端費用分配給支出來源。實務上，您可能會先設定較低的目標，因為建立支援 100% 成本分配的後設資料結構相當複雜。

請參考下列建議，制定中繼資料策略，以支援成本分配：

  • 有效性：確保代碼有助於找出與業務相關的主要成效指標 (KPI) 和法規要求。這項關聯對於內部退款、法規報告，以及根據業務部門目標調整雲端支出至關重要。舉例來說，下列標記清楚指出支出團隊、所在區域和負責的產品：team=banking_appdev、region=emea、product=frontend。
  • 自動化：如要達到高標記法規遵循程度，請透過自動化功能強制執行標記。手動標記容易出錯且不一致，這在金融服務業環境中是無法接受的，因為可稽核性和財務準確度至關重要。自動標記功能可確保資源在建立時正確分類。
  • 簡單易用：評估簡單且不相關的因素。金融服務業環境十分複雜。為確保這類環境中的成本分配規則容易瞭解及執行，規則必須盡可能簡單。避免針對高度特定的極端情況過度設計規則。複雜的規則可能會造成營運團隊的困惑和抗拒。

使用標記定義分配策略後，您需要決定策略的實作精細程度。所需精細程度取決於您的業務需求。舉例來說，有些機構可能需要追蹤產品層級的費用，有些機構可能需要每個成本中心的費用資料，其他機構則可能需要每個環境 (開發、測試和生產) 的費用資料。

如要為貴機構達到適當的成本分配精細程度，請考慮下列做法：

  • 使用 Google Cloud 專案階層做為費用分配的自然起點。專案代表 Google Cloud中的政策執行點。根據預設，IAM 權限、安全性政策和費用會歸給專案和資料夾。查看從 Cloud Billing 匯出的費用資料時，您可以一覽資料夾階層，以及與費用資料相關聯的專案。如果您的Google Cloud 資源階層反映貴機構的支出責任結構，這是最簡單的費用分配實作方式。
  • 使用標記和標籤可提供更精細的資源定義。可彈性分類帳單匯出內容中的資源。標記和標籤可協助您依應用程式和環境細分費用。

通常您可能需要搭配專案階層結構、標記和標籤，才能有效分配費用。無論選擇哪種費用分配方式，請按照先前所述的最佳化建議，制定完善的中繼資料策略：驗證、自動化和簡化。

推動當責文化，激勵工程師採取行動

雲端 FinOps 團隊負責引導機構瞭解成本和價值。個別產品團隊和工程團隊必須採取必要行動，才能達到成本最佳化。這些團隊也負責金融服務工作負載的成本行為，並確保工作負載提供必要的業務價值。

請參考下列建議，落實問責制並激勵團隊提高成本效益。

建立集中式 FinOps 團隊，負責管理

雲端 FinOps 做法不會自然而然地成長。專責 FinOps 團隊必須定義並建立 FinOps 做法，方法如下：

  • 建立必要的程序、工具和指引。
  • 制定、傳達及強制執行必要政策，例如強制標記、預算審查和最佳化程序。
  • 鼓勵工程團隊負責控管費用。
  • 如果工程團隊未承擔費用責任，請介入處理。

取得高階主管支持和授權

包括技術長、財務長和資訊長在內的高階領導人，必須積極提倡全組織轉向 FinOps 文化。他們的支持至關重要，有助於優先處理成本責任、為 FinOps 計畫分配資源、確保跨職能參與，以及推動 FinOps 需求合規。

鼓勵團隊提高成本效益

工程師和工程團隊可能不會主動專注於成本最佳化。請務必實施下列獎勵措施，讓團隊和個人目標與成本效益保持一致：

  • 將成本最佳化節省的部分金額，重新投入到達成最佳化的團隊。
  • 公開表揚並慶祝節省成本的努力和成就。
  • 運用遊戲化技巧，獎勵有效節省成本的團隊。
  • 將效益指標納入成效目標。

實作成本分攤和交易退單技術

確保團隊清楚掌握自己擁有的雲端資源和費用。將財務責任指派給團隊中適當的個人。使用正式機制強制執行嚴格的標記作業，並實作透明的規則來分配共用費用。

著重於價值和 TCO，而非成本

評估雲端解決方案時，請考量長期總持有成本 (TCO)。舉例來說，為應用程式自行代管資料庫，可能比使用 Cloud SQL 等代管資料庫服務便宜。不過，如要評估長期價值和總擁有成本，您必須考量與自行代管資料庫相關的隱藏成本。這類成本包括專門用於修補、擴充、強化安全性和災難復原的工程工作，這些都是 FSI 工作負載的重要需求。代管服務可提供顯著更高的長期價值，抵銷基礎架構成本。代管服務提供強大的法規遵循功能、內建可靠性功能，並有助於減少營運負擔。

請參考下列建議，著重於價值和總持有成本。

使用產品專屬的技術和工具，最佳化資源

善用產品提供的成本最佳化工具和功能，例如： Google Cloud

可享折扣優惠

請使用 Google 提供的折扣，盡可能降低雲端資源的計費費率。個別產品和工程團隊通常會負責管理資源最佳化作業。中央 FinOps 團隊負責最佳化帳單費率，因為他們掌握整個機構的資源需求。因此可以彙整需求，盡量爭取承諾用量折扣。

您可以享有下列類型的Google Cloud 資源折扣：

  • 企業折扣是根據貴機構在 Google Cloud 的最低總支出承諾，以較低的帳單費率協商而得的折扣。
  • 依資源計算的 CUD：只要承諾在一年或三年內使用一定數量的 Compute Engine 資源，即可獲得這類 CUD。依資源計算的 CUD 適用於特定專案和區域中的資源。如要在多個專案之間共用承諾使用折扣，請啟用折扣共用。
  • 依支出計算的 CUD：只要承諾在一年或三年內，為特定產品支出達到特定金額，即可獲得這類 CUD。依支出計算的折扣適用於帳單帳戶層級。折扣適用於特定區域或全球，視產品而定。

除了企業折扣外，您還可使用 CUD，進一步節省費用。

除了承諾使用折扣，您也可以採取下列方法降低帳單費率：

  • 使用Spot VM 處理容錯和彈性工作負載。Spot VM 比一般 VM 便宜 80% 以上。
  • BigQuery 提供多種計費模式，包括以量計價和版本計價，後者會根據承諾和自動調度資源需求計費。如果您使用大量 BigQuery 資源，請選擇適當版本，以降低分析工作負載的每項時段費用。
  • 請仔細評估您需要使用的服務適用的區域 Google Cloud 。選擇符合成本目標的區域，並考量延遲時間和法規遵循需求等因素。如要瞭解成本、永續性和延遲之間的取捨，請使用Google Cloud 區域挑選器。

金融服務業觀點：最佳化成效

這份文件位於 Google Cloud Well-Architected Framework 的金融服務業觀點中，概略說明瞭相關原則和建議，可協助您在 Google Cloud中，最佳化金融服務業 (FSI) 工作負載的效能。本文中的建議符合 Well-Architected Framework 的效能最佳化支柱。

金融服務業很早就開始進行成效最佳化。這項技術協助金融服務機構克服技術挑戰，幾乎總是能促成或加速新商業模式的建立。舉例來說，自動提款機 (ATM)於 1967 年推出，可自動化處理現金提領程序，協助銀行降低核心業務成本。例如，略過 OS 核心，並將應用程式執行緒固定至運算核心，有助於為交易應用程式實現確定性及低延遲。延遲時間縮短後，金融市場的流動性更高、更穩定，價差也更小。

雲端技術為效能最佳化帶來新商機。此外，這項功能也挑戰了部分過去公認的最佳化模式。具體來說，在雲端中，下列取捨考量會更加透明且可控：

  • 上市時間與成本。
  • 系統層級的端對端效能，與節點層級的效能。
  • 人才供應情況與技術相關決策的靈活度。

舉例來說，在雲端中，您可以輕鬆調整硬體和 IT 資源，以符合特定技能需求。如要支援 GPU 程式設計，您可以輕鬆建立以 GPU 為基礎的 VM。您可以在雲端擴充容量，因應需求激增的情況，不必超額佈建資源。這項功能可確保工作負載能處理尖峰負載，例如非農業就業人數公布當天，以及交易量大幅高於歷史水準時。您不必在個別伺服器層級編寫高度最佳化的程式碼 (例如 C 語言中經過高度微調的程式碼)，也不必為傳統的高效能運算 (HPC) 環境編寫程式碼，只要使用架構完善的 Kubernetes 型分散式系統，就能以最佳方式擴充。

本文中的效能最佳化建議會對應至下列核心原則：

將技術成效指標與主要業務指標對齊

您可以透過多種方式，將成效最佳化對應至業務價值成果。舉例來說，在買方研究部門，業務目標可能是盡量提高每小時的研究產出，或是優先處理有良好記錄的團隊所做的實驗，例如夏普比率較高。在銷售方面，您可以運用數據分析追蹤客戶興趣，並據此優先處理支援最有趣研究的 AI 模型輸送量。

將成效目標與業務主要成效指標 (KPI) 連結，對於改善成效的資金來源也十分重要。業務創新和轉型計畫 (有時稱為「改變銀行」工作) 的預算不同，與照常營運 (BAU) 或「經營銀行」作業相比，可用的資源程度也可能不同。舉例來說， Google Cloud 協助全球系統重要性金融機構 (G-SIFI) 的風險管理和技術團隊，與前台量化分析師合作開發解決方案，在幾分鐘內完成風險分析計算 (例如 XVA)，不必耗費數小時或數天。這項解決方案協助該機構達成相關法規遵循要求。此外，交易員也能與客戶進行更高品質的對話，進而提供更緊密的價差、更穩定的流動性，以及更符合成本效益的避險。

將成效指標與業務指標對齊時，請考慮下列建議：

  • 將每項技術計畫與相關的業務目標和主要成果 (OKR) 連結，例如增加收益或利潤、降低成本，以及更有效率或全面地降低風險。
  • 著重於在系統層級最佳化效能。除了傳統的「變更銀行」與「經營銀行」分離，以及前台與後台的孤島，您還需要考慮其他因素。

優先考量安全性，但不要為了未經證實的風險而犧牲效能

金融服務機構的安全性和法規遵循情況必須達到高標準。維持高標準至關重要，否則可能會失去客戶，並對機構品牌造成無法彌補的損害。通常，最高價值來自於技術創新，例如生成式 AI 和獨特的代管服務 (如 Spanner)。請勿因對營運風險過高或法規遵循情況不佳的普遍誤解，而自動捨棄這類技術選項。

Google Cloud 與 G-SIFI 密切合作，確保機構可在為客戶提供服務的管轄區，採用以 AI 為基礎的反洗錢 (AML) 方法。舉例來說，HSBC大幅提升了金融犯罪 (Fincrime) 部門的績效，成果如下：

  • 確實可疑活動的偵測量提升近 2 至 4 倍。
  • 減少超過 60% 的誤判情形，可以專心調查有參考價值的高風險快訊，進而降低作業成本。
  • 取得可稽核且可理解的輸出內容，以便遵守法規。

請參考下列建議：

  • 確認您打算使用的產品有助於滿足您營運所在管轄區的安全、復原能力和法規遵循要求。為達成這項目標，請與帳戶團隊、風險團隊和產品團隊合作。 Google Cloud
  • 運用 AI 可解釋性 (例如 Shapley 值歸因) 建立更強大的模型並向顧客提供透明度。 透過 Shapley 值歸因等技術，可將模型決策歸因於輸入層級的特定特徵。

  • 使用引用來源、建立基準和RAG等技術，確保生成式 AI 工作負載的透明度。

  • 如果可解釋性不足，請將價值流程中的決策步驟分開，並僅使用 AI 自動化非決策步驟。在某些情況下，由於法規考量 (例如《GDPR》第 22 條)，可解釋的 AI 可能不足以因應需求，或程序可能需要人工介入。 在這種情況下，請在單一控制面板中提供人工服務專員做出決策所需的所有資訊，但自動執行資料收集、擷取、操作和摘要工作。

重新思考架構，以因應新商機和需求

在現有架構中加入雲端功能，可帶來顯著價值。如要獲得更具轉型意義的成果，您需要採用雲端優先方法，定期重新思考架構。

請參考下列建議，定期重新思考工作負載的架構，進一步提升效能。

使用雲端替代方案取代內部部署的 HPC 系統和排程器

如要充分運用更高的彈性、更完善的安全性，以及廣泛的監控和控管功能，您可以在雲端執行 HPC 工作負載，或將內部部署工作負載爆量至雲端。不過，對於某些數值模型化用途 (例如模擬投資策略或 XVA 模型化)，將 Kubernetes 與 Kueue 結合可能提供更強大的解決方案。

切換至以圖形為基礎的模擬程式設計

在 Dataflow 等以圖形為基礎的執行系統中，蒙地卡羅模擬的效能可能會大幅提升。舉例來說，HSBC使用 Dataflow 執行風險計算的速度，比先前的做法快了 16 倍。

執行雲端式交易所和交易平台

與 Google Cloud 客戶的對話顯示，80/20 帕累托法則適用於市場和交易應用程式的效能需求。

  • 超過 80% 的交易應用程式不需要極低的延遲時間。但雲端的彈性、安全性和復原能力可為他們帶來顯著優勢。舉例來說，外匯多交易商平台 BidFX 使用雲端快速推出新產品，並大幅提高可用性和涵蓋範圍，不必增加資源。
  • 其餘應用程式 (不到 20%) 則需要低延遲 (不到一毫秒)、確定性，以及訊息傳送的公平性。傳統上，這些系統是在昂貴的共置設施中運作，越來越多這類應用程式也開始在雲端重新平台化，無論是邊緣或雲端優先應用程式。

確保技術與時俱進，滿足當前和未來的業務需求

過去，許多金融服務機構會建構專有技術，以取得競爭優勢。舉例來說，在 2000 年代初期，成功的投資銀行和交易公司都自行導入了基礎技術，例如發布/訂閱系統和訊息代理程式。隨著開放原始碼技術和雲端服務的演進，這類技術已成為商品，無法提供額外的商業價值。

請參考下列建議，確保技術能因應未來趨勢。

採用資料即服務 (DaaS) 方法，加快上市速度並提高成本透明度

金融服務機構通常會透過自然成長和併購 (M&A) 雙管齊下的方式演進。因此，機構需要整合不同的技術。他們也需要管理重複的資源，例如資料供應商、資料授權和整合點。 Google Cloud 提供機會，在合併後整合中創造差異化價值。

舉例來說，您可以使用 BigQuery 共用等服務，建構可供分析的資料即服務 (DaaS) 平台。平台可提供市場資料，以及來自替代來源的輸入內容。這種做法可免除建構多餘資料管道的需求，讓您專注於更有價值的計畫。此外，合併或收購的公司可以快速且有效率地，合理化合併後的資料授權和基礎架構需求。合併後的企業不必費力調整及合併舊有資料資產和作業，可以專注於新的商機。

建構抽象層，隔離現有系統並因應新興商業模式

對銀行而言，競爭優勢越來越不是核心銀行系統，而是客戶體驗層。不過，舊版銀行系統通常使用以 Cobol 等語言開發的單體式應用程式，並整合至整個銀行價值鏈。這種整合方式難以區分價值鏈的各個層面，因此幾乎無法升級及翻新這類系統。

為解決這項挑戰，其中一個方法是使用隔離層，例如 API 管理系統，或是 Spanner 等暫存層，複製記錄簿並運用進階分析和 AI 技術，簡化服務現代化程序。舉例來說，德意志銀行使用 Spanner 隔離舊版核心銀行資產，並開始創新之旅。