Financial Services Cloud 在台灣金融業的落地實踐

摘要

• 本文核心：Financial Services Cloud（FSC）在台灣不能直接套用美規版本——金管會法規、合規報告格式、與既有核心系統的串接，三個面向都需要本地化改造。
• 誠實聲明：本文的金融導入經驗來自我們 CTO 在澳洲一級銀行與中型銀行的 FSC 實戰；台灣金融業的具體應用，是我們把這些經驗對應到本地法規與系統環境的判斷。
• 三類金融機構，三種落地策略：銀行重整合、保險重流程、證券重合規。
• Taiwan-specific 改造清單：客戶 360 度檢視、KYC 與金檢報告、與 AS400／大型主機核心系統的同步機制。
• 預算現實：第一年總成本通常是授權費的 2.5–3 倍——許多客戶低估了「整合成本」，以為授權費就是總成本。
• 附決策框架：三個問題判斷你的機構現在該不該啟動 FSC。

一、寫在前面：經驗來源

Salesforce 官網有 FSC 的功能列表，那不是這篇要寫的東西。這篇是給正在評估「我的銀行／保險／證券公司要不要導入 FSC」的決策者看的：在台灣，這條路長什麼樣。

經驗來源誠實聲明：我們的 CTO 過去在澳洲擔任 Salesforce CTA 期間，於兩家澳洲 Tier 1 銀行與一家澳洲中型銀行親自交付過 FSC 導入。本文把這些澳洲經驗對應到台灣金融業會遇到的具體情境。澳洲與台灣的合規環境不同，所以後文會明確標出哪些是直接通用、哪些需要本地化。

二、FSC 的核心：可組裝的金融資料模型

技術上，FSC 不是一個全新的產品，而是 Service Cloud + Sales Cloud 之上的一組「金融業專用元件」：

• Person Account / Household Object：把法人與自然人的關係、家戶成員（夫妻、共同帳戶、信託受益人）建模成一級物件。台灣的「家庭整合理財」場景特別適合這個模型，但前提是核心系統能把家戶關係資料同步出來。
• Financial Account：把存款、貸款、保單、信用卡、投資商品統一成一個父型別，子物件繼承。這是讓「客戶 360 度檢視」變成現實的關鍵——前提是你願意把核心系統的資料映射過來。
• Compliance Data Model：KYC、AML、Suitability Assessment 都有預設物件。這在金管會的合規報告場景下能省下大量自訂工。
• Action Plans：把開戶、續期、理賠等流程模板化。配合 OmniStudio 可以做出「導引式」的客戶服務介面。

關鍵在於——這些是「資料模型 + 流程框架」，不是「即用即上線的解決方案」。每個機構都需要客製，差別只在客製範圍是 30% 還是 70%。

三、三類金融機構，三種落地策略

3.1 銀行：重點在「整合」

我們在澳洲協助的某 Tier 1 銀行案例：核心系統散落在六個不同年代的平台——存匯（Mainframe）、放款（Java EE）、信用卡（COBOL）、財富管理（Murex）、保險（早期 Salesforce）、信託（自建）。客戶資訊在每個系統各有一份，且常常不同步。三個資料完整性問題很常見：

1. 同一個客戶在不同系統有不同的客戶 ID
2. 地址、電話、Email 各系統各有版本，誰是真的沒人知道
3. KYC 資料分散，重新驗證時無法判定哪份最新

對應台灣：台灣銀行的核心系統數量通常少一些（4–5 套），但「跨系統客戶 ID 不一致」「KYC 資料分散」兩個問題完全相同。澳洲的標準做法可以直接搬：

1. Mulesoft 作為整合層，不要讓 FSC 直連核心系統。讓 FSC 永遠只跟 Mulesoft 對話，後面 Mulesoft 接什麼隨時可換。
2. 第一階段只做「讀」，把核心系統的資料同步成 FSC 的 Financial Account；先讓「客戶 360 視圖」可用就好。
3. 第二階段才開始做雙向（理財建議從 FSC 寫回核心系統），這時要設計交易一致性、回滾、稽核紀錄。

陷阱：很多銀行被 SI 廠商說服第一階段就做雙向，結果交易一致性、回滾、稽核紀錄沒做好，上線後雷聲大作。我們建議銀行客戶在合約裡明訂「第一階段不做雙向」這一條，避免被話術帶偏。

3.2 保險：重點在「流程」

保險業的痛點是流程冗長：核保、理賠、續保、保單變更，每個流程都跨 5–10 個角色，紙本與電子文件混雜。

我們在澳洲協助的某中型保險業者，把核保流程從平均 14 天縮短到 3 天，關鍵是：

• 用 OmniStudio 重設計核保人員的操作介面
• 整合 OCR 把紙本健告書數位化
• Action Plan 自動分派任務並追蹤 SLA

對應台灣：台灣保險業的核保流程比澳洲更冗長（紙本佔比更高、跨單位簽核更多）。澳洲的優化路徑可以直接搬，但時程會拉長 30–50%——主要花在跟法遵團隊重新設計流程、把現有的章戳簽核改成電子簽核。

注意點：保險業最常見的失敗是把流程「電子化」而不是「重設計」。如果新系統只是把紙本表單變網頁表單，效率不會大幅提升。真正的價值在於重新設計流程，把不必要的步驟拿掉——這需要保險公司自己的核保主管深度參與，不是 IT 自己決定。

3.3 證券：重點在「合規」

坦白說：證券業我們沒有直接交付過 FSC 案例。下面的觀察來自 Salesforce 官方 FSC for Securities 文件、業界研討會分享，以及我們在澳洲銀行業導入時對相鄰金融商品（投資型保單、結構型商品）合規模組的實作經驗。

證券業在台灣面臨的合規負擔最重——投資人適合度評估、不當銷售防範、交易紀錄保存、金管會的定期報告。FSC 內建的 Suitability Framework 是個好起點，但仍要客製：

• 把金管會「投資人風險屬性問卷」翻成 FSC 的 Assessment Object
• 與既有的 RBA（風險基礎方法）系統整合
• 報告格式要對應金管會「業者管理資訊系統」的 schema
• 不當銷售的偵測規則要寫進 Apex Trigger / Flow，並留下完整的判斷紀錄

台灣特殊提醒：金管會近年對「投資型保險」與「結構型商品」的銷售紀錄要求極為嚴格，包含通話錄音逐字稿都要保存。FSC 不是錄音工具，但要設計好錄音檔的引用欄位與 retention policy。

四、Taiwan-specific 改造清單

導入 FSC 在台灣，這些 90% 一定要做（澳洲版本不需要、台灣必須做）：

每家機構還會有自己的特殊需求——例如壽險的保單續期通知、證券的盤前盤後處理、銀行的房貸申請流程。

五、預算現實：別只看授權費

我們在澳洲多個 FSC 專案的實際預算分布：

• 授權費：30–40%
• 整合（含 Mulesoft）：30–40%
• 客製開發：15–25%
• 變革管理與訓練：5–10%

第一年總成本通常是授權費的 2.5–3 倍。

對應台灣：預算結構大致相同，但「整合」這一項通常更貴——因為台灣金融業的核心系統世代更老、文件更不完整，整合工時要再加 20–30%。如果你的提案沒這樣編，這個專案會在第六個月吵預算。

第二年的成本結構會穩定下來：授權費佔 60–70%、維運與小改 20–30%、新需求開發 10–20%。這是 FSC 真正的甜蜜點——當你跨過第一年，後續的維運成本通常比舊系統低很多。

六、案例：某澳洲中型銀行第一年的實際數據

我們協助的某澳洲中型銀行（約 200 萬客戶、全國數百間據點），導入 FSC 第一年的實際數據：

但更重要的是——第二年的維運成本下降 35%。

對台灣機構的預期差異：

• 客戶滿意度基線值在台灣通常更高（消費者期待更嚴格），絕對提升幅度可能比澳洲低 5–10 個百分點
• 合規報告優化幅度會更大，因為台灣金管會的報告格式比澳洲 APRA 更繁瑣
• 整體 ROI 出現的時間可能晚 2–3 個月，因為核心系統整合的不確定性更高

七、決策框架：你現在該不該啟動 FSC？

我建議三個問題自我檢驗：

問題 1：核心系統能不能被改造成「資料源」而不是「資料孤島」？

如果你的核心系統 vendor 不肯開 API、文件不存在、唯一懂 API 的工程師已退休——FSC 的客戶 360 視圖會做不出來。先解決這個再來談 FSC。

問題 2：合規團隊能不能從 Day 1 參與設計？

很多金融機構把合規團隊當成「最後檢查」的角色。在 FSC 導入裡，這是最大的風險來源。合規必須從第一次需求討論就在場，因為金管會的要求會根本性地影響資料模型與權限設計，不是上線前才能補。

問題 3：你願意在第一年把預算的 60% 花在非授權的整合上嗎？

如果答案是「我們希望第一年只花授權費」——那你還沒準備好做 FSC。請先做變革管理與內部 IT 能力建設。

三個答案都是 yes，才值得啟動。否則先解決前置條件，比硬上更省錢。

八、結語：FSC 不是萬靈丹，是起點

我見過很多金融客戶把 FSC 想成「裝了就好」。實際上 FSC 是「給了你一個合理的起點，省下你重新發明輪子的時間」。後面 70% 的價值來自你願意花多少功夫做本地化、整合、流程設計。

我們把澳洲累積的 FSC 經驗帶回台灣，不是「複製貼上」，而是「翻譯與在地化」。每一個案例都有它的 context——你的核心系統世代、合規團隊參與深度、預算結構準備。歡迎來聊您的具體情境。

九、12 個月的導入路徑圖

我們給金融客戶的標準 12 個月節奏（中型機構規模）：

關鍵節點：第 6 個月的「50 人試點」與第 11 個月的「雙系統並存」是兩個必要的減震器。跳過任何一個，第 12 個月的全面切換會踩雷。

十、貼身的供應商挑選準則

選 SI 廠商比選 Salesforce 本身重要得多。這是我們建議客戶在 RFP 階段就問的問題：

1. CTA 認證：團隊裡有沒有 Salesforce CTA？沒有的話，誰負責架構決策？
2. 金融業實績：過去三年導過幾個金融客戶？可以提供 reference call 嗎？
3. Mulesoft 能力：Mulesoft 是內部團隊還是外包再外包？
4. DevOps 實踐：他們自己用 Git + CI/CD 嗎？還是 Change Set？
5. 變革管理：有沒有專責的變革管理顧問？
6. 接手能力轉移：交付完之後，客戶內部要怎麼維護？

如果一個供應商在前三個問題裡有兩個含糊以對，請另外找。金融業的導入失敗成本太高，不能賭。

十一、台灣金融業的常見採購陷阱

這幾個陷阱我們在澳洲多家客戶身上看過至少三次，台灣的環境只會更明顯：

陷阱一：授權數量買太少

第一次預估時，業務和 IT 算的都是「現有需要用 Salesforce 的人」。導入後才發現，理財專員的助理、客服中心的支援人員、稽核同仁都需要看資料。典型再買量是初次的 1.5–2 倍。

對策：第一次預估時加 50% buffer，並要求 Salesforce 在合約裡明訂後續加購不另收 onboarding 費用。

陷阱二：Sandbox 數量與類型雙雙低估

台灣金融客戶最常踩的環境陷阱有兩層。

第一層：類型低估。台灣客戶習慣「能省就省」，多半只買 Partial Sandbox，不買 Full Sandbox。但對銀行業、金融業而言，Full Sandbox 是唯一能完整模擬 Production 的環境——資料量、效能、批次任務、整合行為都跟 Production 一致。Partial Sandbox 只有部分資料，大型批次跑不起來、合規測試的代表性不足、效能調校做不準。為了省那一座 Full Sandbox 的錢，最後在 UAT 與上線階段付出十倍代價——這是我們在澳洲銀行專案最常給客戶的提醒。不該省的錢不要省，這是其中最典型的一條。

第二層：數量低估。許多金融客戶第一次只買 1 個 Full Sandbox + 2 個 Partial。實際開發過程會發現嚴重不夠用——尤其是合規測試需要獨立環境、客戶資料 masking 需要特殊設定，UAT、效能、修復測試又各自需要環境，三個 sandbox 完全不夠四五條 workstream 並行。

對策：

• 銀行 / 大型保險：至少 2 個 Full Sandbox + 3 個 Partial Sandbox 起跳，分別給開發整合、UAT、效能、合規、修復用。
• 中型金融機構：1 個 Full + 3 個 Partial，搭配 Hutte / 類似 scratch org 工具補足開發階段的環境隔離需求。
• 採購階段就把這寫進 BOM，不要等到上線前三個月發現環境不夠才追加——那時候已經來不及了。

陷阱三：合約裡沒寫「資料所有權」

有些 SI 廠商在合約裡留下灰色地帶——當客戶想換廠商，原 SI 是否有義務協助匯出 metadata 與設定？許多合約沒寫清楚，導致客戶換廠商時被勒索。

對策：在 RFP 階段就要求合約附「資料與 metadata 完整移交條款」，明訂格式（Salesforce DX project format）與時程。

陷阱四：選錯 Partner——本土經驗不等於 FSC 經驗

這是我們在台灣金融客戶身上看到最痛、卻也最容易避免的陷阱。台灣本土的 Salesforce Partner，目前沒有任何一家有完整的 FSC 導入實戰經驗。多數 Partner 過去交付的是 Sales Cloud、Service Cloud、或產業中立的 Salesforce 客製專案——這些經驗很有價值，但 FSC 不是其中之一。

當一家沒有 FSC 經驗的 Partner 接下 FSC 案子，常見的失敗模式有兩種：

• 把 FSC 當 Sales Cloud 用：忽略 Person Account / Household / Financial Account 的金融資料模型，把所有東西塞回 Account / Contact / Opportunity。失去了 FSC 的核心價值，等於用 FSC 的授權費跑 Sales Cloud。
• 胡亂設計 Anti-Pattern：複製貼上其他客戶的 Apex Trigger、把合規規則寫進 hardcoded if-else、為了「彈性」做出多層動態 metadata 但沒有 governance——這些 anti-pattern 累積到第 6–9 個月會讓專案走向失敗，而且難以回頭。我們在澳洲與台灣都看過踩雷的客戶，多半是上線後第 12–18 個月才開始重做架構，代價遠超過第一次找對 partner 的差價。

對策：

1. 要求 reference call：請對方拿出至少一個已上線、可被引用的 FSC 客戶，不接受「我們有經驗但不能透露」這種說法。
2. 架構責任要明確：FSC 的架構決策必須由具備 Salesforce CTA 認證的人簽字。如果 partner 沒有 CTA，這部分要外請或聯合接案。
3. Anti-Pattern 黑名單寫進 SOW：在 SOW 直接列出禁止的設計模式（hardcoded 規則、跨 Topic 共用 Permission Set、未審查的 AgentExchange 模板等），避免後期才發現踩線。
4. 在地 Partner + 海外架構顧問混合接案是我們對台灣金融客戶常給的建議——本地 Partner 負責執行與在地對接，海外架構顧問負責守 FSC 架構紅線。