歐美與日本核心系統現況如何?特別是大型銀行的核心系統大多老舊,新核心系統轉換對策如何?從國外的經驗看台灣核心銀行系統的轉換對策應該如何?本文作者有一些個人看法.
歐美核心銀行系統現況
歐美核心銀行系統大約在 1960-1970 年代開始發展 , 大多數的銀行 , 特別是大型銀行 , 都採取自己開發核心系統的對策 , 而不假手外力 . 其中雖然歷經多次的功能追加與架構的局部修正 ( 主要是新技術的植入 ), 然而畢竟年代已久 , 隨著金融法規的鬆綁與市場競爭的激化 , 維護目前的系統確實不符經濟效益 , 所以自 1990 年代起陸續有許多大型銀行開始進行核心系統的更新計劃計劃 . 舉例來說 , 花旗銀行原先的核心系統 -COSMOS 是早在 1972 年建構在 IBM 的主機系統的一個自給自足型的系統 (Self-Contained), 採取這樣的核心銀行發展策略對花旗銀行非常重要 . 因為當時花旗銀行正處於高度擴展階段 , 積極布局全球新興市場 , 需要一個高效率的系統來支援其靈活的市場策略 . 迄 1980 年代中期 , 花旗總共在全球 90 個國家佈署了該系統 , 當然由於每個地區由於法令與市場的差異性 , 花旗並非維護一個版本來滿足全球的客戶 , 而是劃分幾個主要區域分別配置資源各自維護其系統 , 因此花旗銀行雖然說表面是一個系統 (COSMOS), 然而實際上是同時在全球維護多個不同版本的 COSMOS 系統 . 在此情況之下 , 既然核心系統經常性的維護是不可避免的 , 但是如果維護 COSMOS 的代價是那麼昂貴的話 ( 花旗銀行內部估計 , 因為 Y2K 而必需花美金 4 億以上的來修改現有程式 ), 那麼是否要繼續投資舊系統或者乾脆重新建構一個新系統就值得研究 . 事實上早自 1980 初 , 花旗銀行就打算應用新的技術重新建構其核心系統 , 迄 1990 年幾次的嘗試都終告失敗 ( 主的要的原因都因技術能力不足 ), 有報告指出 , 花期銀行花了超過 10 億美元嘗試更換核心系統而終至失敗 ( 同期許多規模相當的銀行情況也是如此 ). 在此 , 稍為解釋何謂 " 技術能力不足 ", 花旗銀行曾經想過利用新技術開發一個新的平台 , 在這個平台上能夠同時執行原有的應用程式也能夠提供足夠的彈性讓新的應用系統更快速容易的開發 , 然而經過技術上仔細的評估後發現並不容易 , 原先的應用程式是開發於 IBM 主機系統上 VTAM,CICS,VSAM 環境下 , 在新的平台上要模擬類似的功能並不容易 , 最後還是放棄 . 最後花旗銀行還是選擇投資一家印度軟體公司 i-Flex 共同合作開發一套新應用軟體 Flexcube, 並於 2000 年起開始佈署於歐州與亞洲 ( 筆者撰寫本文時 ,Oracle 正巧宣佈收購花旗擁有 i-Flex 全部股權 ). 其實在歐美 , 大多數的大銀行採取的核心銀行系統轉換策略 , 都非採取一次轉換 (flip-flop) 而是採取包裝 (Wrapping) 對策 , 也就是在原先核心系統外掛新的功能與應用 , 新的投資不願意耗用在舊系統架構下 , 舊的應用系統亦將隨時間而逐漸消逝 . 至於規模較小的銀行 , 如地區銀行則仍舊採取套裝軟體 (Package) 一次轉換對策 .
日本核心銀行系統現況
日本的核心銀行系統也是在 1965 年代開始 , 相較於大多數歐美大銀行的核心系統自上線後迄今並未做架構上完全的汰換 ( 局部修正 ), 日本的大銀行 ( 一般稱之為都市銀行 ) 自 1965 年第一次連線後大約每隔 10 年即作一次大規模的系統更新 ( 參閱拙作 日本核心銀行系統發展經緯 ), 迄 1987 年總共進行 3 代的大規模系統的重新建構 , 以第 3 代 On-Line 言 , 都市銀行大約花費 700-1000 億日圓 ( 地方銀行行也大約花費 200 億日圓 ). 日本的銀行之所以願意完全捨棄原先系統 , 花費如此龐大的人力與物力去開發一個全新的系統 ? 其主要理由是每隔一階段 , 銀行的需求已經無法依賴修改原先的系統而達成 , 而必須徹底捨棄原先的包袱重新思考新系統的架構 . 其所以如此 , 筆者以為一方面與日本的民族性格有關 , 另一方面也因那個年代是日本經濟最蓬勃發展的時期 , 日本的銀行在那個時期莫不全力擴張市場 , 獲利也達到高峰 . 同時期歐美銀行經營狀況正好與日本相反 , 所以在 1980 年代筆者可以大膽斷言日本銀行的 IT 是先進於歐美 .
然而日本自 1987 年第 3 代連線後 , 迄今 2005 年未聞第 4 代連線 ? 對此 , 筆者 2002.3 曾經請教過日本富士通負責瑞穗銀行 ( 富士通最大銀行客戶 ) 客戶的部長谷口典彥 樣 , 據谷口部長言 , 日本 3 代連線就技術而言已達頂峰 (24*365 連續稼動 ,1000 筆 / 秒等 ), 現有的問題是日本銀行的經營知識 (know-how) 不足 . 筆者解釋這句話的意思為日本銀行第 1,2,3 代 On-Line 技術架構有其一貫性 ( 日本 IBM 稱之為 DSE-Data System Environment 架構 ), 在這種架構下的應用系統已不敷現有銀行經營的需求 , 所以已經不需要再去強調第 4,5.. 代了 . 然而日本新一代核心銀行現況究竟如何 ? 筆者以為都市銀行 ( 主要指 4 大金控 , 瑞穗 , 東京三菱 , 三井住友 , 日聯 - 將併入東京三菱 ) 終究無法立即擺脫第 3 代系統 ( 過於龐大與複雜 , 轉換成本與風險太高 ), 至少在往後的 10-20 年 ( 日本 IBM 仍承諾東京三菱繼續維護其核心系統 -SAIL 至少 10 年 )3 代系統仍是日本勘定系的主要系統架構 ( 核心銀行系統在日本被稱之勘定系-日文勘定意即結帳的意思), 然而為了應付銀行對核心系統新需求 ( 綜合型產品與服務 ) 都市銀行將採取漸進且穩健的轉換策略 - 遷都方式 , 也就是現在開始建構新核心系統架構 , 新需求將開發在新系統架構上 , 新舊核心系統採取並存策略 , 舊應用系統逐漸淘汰終致舊系統完全由新系統取代 . 而新舊系統間則建構一個 Hub 系統作為系統間整合的橋樑 ( 參閱拙作 ” Hub System 在核心銀行系統的角色地位 ”). 至於其他規模較小的銀行 ( 地方銀行 , 信用金庫等 ) 則開始有採用國外套裝軟體的案例 ( 新生銀行 , 駿河銀行 ). 以及捨棄自有系統選擇加入共用中心 (NTT), 推測中小銀行除了少數仍有能力自營 ( 選擇套裝軟體修改 ) 外 , 大部份將被迫選擇加入共用中心 , 以降低核心銀行龐大的開發及維護費用 .