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

說實在的在此要強調的是-程式語言實在不是重點。新語言也多繼承就語言的功能與語法，因此，在我看來每種語言提供幾乎相同的功能，例如:字串處理、編輯處理、邏輯處理、計算處理..)，指令的格式也大同小異。所以，一個有經驗的程式設計師應該很容易以過去對某種語言的熟練經驗、舉一反三，很快的去熟練另一種語言。如果說JAVA與C++,C#是近親，那麼JAVA與COBOL則是遠親。近親遠親都有血緣關係，僅是相似程度大小罷了。

這問題就是核心系統究竟是買平台(例:UCP,CSF,SAFE,CAP,BENEFIT,NBX,TOP,TOX)再加上應用系統的開發或是買一個國外的套裝軟體(尚未有國產的GLOBAL產品)再客製化的選擇。

日本大型金控(MEGE BANK)之一，三井住友銀行2009年3月末，國内約460分支行導入新営業端末「CUTE」。CUTE的導入原因是為了提升櫃檯事務處理的効率化及商品提案力的強化而開發。

今後10年，不，這個世界變得太快了，誰能預測到那麼長的時間？應該說今後幾年，銀行最大的改變應是思考與作為「社會經濟的舞台上扮演什麼角色？」這件事。可以說過去銀行銀行是站在顧客上門的想法與做法(「保守」是美德之一)，即便近年來，銀行縱有主動出擊的想法，無奈「包袱」(我所指的包袱範圍可是包山包海，例如戰略、組織、運作、人資等等)過重，難有突破，追根究底，這都是深受長期「保守」心態所約束。所以縱有思要有所改變，其姿態(綁手綁腳)與速度(抄襲別人多，自己原創少)，與其他行業相較(流通，電信)，還是顯得緩慢且無效率。

年初(2010)日本第七銀行ATM事業部業務、技術高階主管(日本7-ELEVEN投資設立的銀行)在台灣NEC陪同下，受邀訪問台灣統一資訊(台灣7-ELEVEN，集團內系統商)，此行主要目的即是分享日本7-ELEVEN的金流(支付、清算)應用經驗。

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