自2011年3月14日東日本大地震發生3日後、瑞穗銀行發生大規模系統故障。救援金遲遲無法轉帳、分行服務停擺、ATM交易停止一連發生。影響層面極廣、10日後問題才告段落。此番瑞穗銀行大規模系統故障、是繼9年前(2002年4月)系統整合敗後(第一勸業、富士、興業三家銀行合併)、第2度發生的重大事故。為何事故一再重複?追根究底還是要從瑞穗銀行根本的原因檢討、才能得到問題解決的對策。

自1989郵局核心系統從SAFE轉換至CAP,開啟台灣核心銀行系統更換風潮,迄今20年陸續有21的案例發生,詳情請看本文.

最近IBM發怖新聞，謂要推動結合官方與銀行，共同開發一個適合台灣的銀行使用之新核心系統共用平台，當然前題還是台灣需要一個新核心系統架構與平台，理由則是個別銀行獨自投資開發無論從成本與人力都不划算。其實無論是『共同開發』與『共同利用』，對台灣都不是新創意，都曾發生過。

SAFE大約在1985年左右我曾經支援過2個客戶，當然這兩家客戶現在已經更換了其他系統，但是迄今我仍然對SAFE的設計架構十分讚賞-可用四個字形容-乾淨俐落，充分利用了CICS的特點，拿來做活期性存款(SAVING DEPOSIT)系統，實在是再恰當不過了。

核心銀行系統(Core Banking System)對一個銀行而言是must be have而非nice to have。既然是必需的投資、那麼理應不計成本也不需精算投資報酬也要投資建置才對、這是C階層從一個新設銀行角度來看、但是如果從一個已經存在的老銀行來看、C階層除了CIO還會繼續持這種看法外、其他成員是不會認同這種看法的。這時C階層成員會認為、維護一個核心銀行系統花費龐大的費用、又說不出其直接的價值的CIO是會被認為無創意又無能。反之能夠表現出核心銀行系統的價值又能夠降低維護費用的CIO絕對在C階層中是擔當意見領袖的厲害腳色、因此CIO的位置與核心銀行系統息息相關一點也不為過。

從日本許多地方銀行紛紛捨棄自有系統加入共用中心、雖說主因是自力維持一個核心銀行系統的不經濟性、但是另一方面也是銀行體認到核心銀行系統並無差異化的必要、換句話說現在每家銀行的核心銀行系統提供的商品範圍與服務水準都差不多、有差異化的商品與服務無需也不必要置於核心銀行系統內、因為現有的技術與經驗足以完全的整合核心銀行系統與新商品系統而無需非要置於核心銀行系統內才可以取得整合性。依此觀點、核心銀行系統已經是一個提供Transaction Service的系統、重心是Transaction而非對銀行客戶提供Commodity Service、這點才是日本地方銀行願意參加共用中心的主因。

這絕對是見仁見智的問題、沒有標準的答案。從技術(Techenology)、成本(Cost)、市場(Marketing)各方面來看、過去是沒得選未來則不會選。但是從應用(Application)來看、把CICS/VSAM/COBOL搬到Open和把Websphere/DB2/Java搬到Mainframe是一樣頑固的個性。反之則因各有所長、各擅其事、即便同處一室、亦會保持風度、只是相敬如「冰」。回到主題、到底Core Banking是擺在Mainframe好還是Open好?其實這問題等於是問Core Banking用CICS/VSAM/COBOL開發好呢?還是用Websphere/DB2/Java開發好呢?這個問題的答案也是見仁見智的問題、沒有標準的答案、但是我的答案其實很簡單、那就是-新瓶裝舊酒?大可不必、舊瓶裝新酒?那是騙人。

很多人喜歡將建構核心銀行系統比喻成建構一建築物、如是則Platform如鋼骨結構、隔間裝璜如Application。