這份Google Cloud 架構完善架構：金融服務業觀點文件概述了相關原則和�����，可協助您在 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 值歸因等技術，可將模型決策歸因於輸入層級的特定特徵。
如果可解釋性不足，請將價值流程中的決策步驟分開，並僅使用 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 隔離舊版核心銀行資產，並開始創新之旅。