關於銀行自行維護ATM端末軟體的技術與可能性

最近一個朋友問我在這裡好不好, 被放在這裡牧羊,還不錯啦!他也問到了關於銀行自行維護ATM端末軟體的事,在這裏把我的意見提出來就教方家.

關於自己開發維護全部ATM程式,我在各國除了CitiBank之外沒有看到成功的案例(因為我見識比較淺薄). CitiBank可以成功也是因為ATM硬體是他們自己設計的!另外有個別廠牌的ATM軟體因為原來就是設計給銀行自己維護的,所以有成功.後面我會分兩種狀況(個別廠牌,通用軟體)來說明

個別廠牌的部份:

IBM 473X: IBM在473x的時代,出了一個端末軟體,ATM的交易畫面跟操作流程都透過設定檔(Customization Image, CI)來設定.基本上滿足了ATM的功能,銀行只要學怎麼設定設定檔就可以使用.所以在1990, 2000之間台灣有大約10家銀行自己維護.后來Diebold把他移植到Diebold的ATM上叫做Turbo 3X.國泰銀行也曾經是用戶.他的好處是容易維護,缺點是彈性小了點.目前各廠牌模擬473X都沒有做到使用CI(包含Diebold,除非你跟Diebold台灣指定要用turbo 3x).(另外據小道消息, Wincore也有標準的473x模擬可以用CI,只是我沒有看到過).

Diebold 912(用912來稱呼有點問題不過因為Diebold發展了好幾代的軟體都有同樣的特性,只好用電文格式的名稱來稱呼. 911是另外一種用於美國國內的格式,主要的差異在於支援國際需要所以912有一些調整如金額欄位的長度等): Diebold也有一組端末軟體,也是一樣 ATM的交易畫面與操作也都是透過設定檔(Customization Data)來設定後由主機下載下去的,不同的是Diebold的Customization Data設計的很有彈性,完全是用流程圖方式來思考,所以彈性很大.基本上目前世界級的銀行都是採用這樣標準而可以自行維護.目前除了Diebold有之外, NCR,Wincore都有100%相容的端末軟件.

NCR NDC+: NCR也有一組端末軟體叫NDC (NCR Direct Connect, Diebold的912以前叫DDC, Diebold Direct Connect),設計方式與電文跟Diebold幾乎完全一樣.基本上目前世界級的銀行都是採用這類標準而可以自行維護.目前除了NCR有之外, Diebold,Wincore都有100%相容的端末軟件.在台灣有一個客戶叫做ABN.所以他是完全support FISC II晶片卡的.

以上這類(個別廠牌的標準軟體),基本上對於銀行端的維護有很大的好處.在技術的要求上並沒有太高的門檻,一個資訊人員經過十幾個小時的training.幾乎都可以上手.我們一般看到的狀況是讓資淺的ATM主機AP人員負責.而這類的軟體缺點是必須要使用他的標準電文格式(我倒不覺得是缺點,因為他們的電文都設計的很有規範).這些軟體的另外一個優點是幾乎不會有Bug.因為全世界有幾十萬台在run. 能碰到Bug算好運.我之前 support 912 5年,只遇到一個端末軟體的Bug,而且應該是大中華區那 5年唯一被證實的bug.

通用型軟體

目前世界上有兩種標準希望能產生通用型的 ATM端末軟體, WOSA/XFS與 J/XFS. WOSA/XFS是Microsoft主導,J/XFS是IBM跟SUN主導的standard.目前兩者都是CENT的standard. WOSA比較早, J/XFS比較晚出來目前支援WOSA的硬體廠商比較多,但是J/XFS也發展出可以把WOSA的硬體通吃的技術.這種標準在目前來看,我發現中國大陸前三年十分熱門,但是現在沒有聲音了,幾個大型案子也都掛在那裡沒有進展.加拿大在2000年左右也有這樣的project,目前沒有看到great success.

這樣的方式要用可就得要比較高的技術,維護的人對於 ATM端末的硬體設計原理, 通訊, ATM端末軟體的運作方式還有Java (J/XFS)或是C, VB, Delphi之類的 (WOSA/XFS) programming language要熟練. 需要維護的code量也比較多.

我個人的看法, 這類通用型軟體專案成功的機率在目前不是太高.主要的原因有幾個

1) 硬體及軟體技術難度高,銀行比較少有這樣的時間慢慢的讓這樣的專案發展成熟

2) 硬體廠商的排斥,所有的硬體廠商都希望這樣的專案用他們的軟體.但是只能選一家.但是選了軟體卻還需要各家廠商提供driver來一起運作.落選廠商在這方面都比較不配合,同時在發生問題的時候也很難確認誰要出面解決.我看到的幾個失敗案例都是敗在這一關.中選廠商提供了XFS軟體可以在自己的ATM上用.放到別家的ATM時,就發生問題或是落選廠商根本不提供XFS需要的底層driver.專案就掛了

3) 硬體的behavior不同是失敗的主要原因. WOSA或是J/XFS都只定義了呼叫硬體的API介面,卻沒有定義這樣的呼叫之後的硬體動作.產生的結果是,同樣的程式到了不同的硬體上因為硬體的設計不同導致運作的結果都有一點點不同.然後軟體人員都需要因為這些不同做調整.因此產生不了通用軟體.

在ATM電文方面業界一直有各種發展路線,很難評斷!從最早的沒有規範到473x的4 way, 912, NDC+的3way, ISO8583或是IFX的XML.特別有趣的一支,在台灣是各家銀行自己定.我的看法比較傾向應該採用473x, 912或NDC+這類的ATM專用電文.因為在設計上就已經充分考慮了ATM的特別需要, 運作起來比較便利也比較穩定.我看到台灣各家銀行的自訂電文格式的時候通常的會發現充分支援交易的需要也完全配合主機的開發能力但是產生的效應就是管理需要沒有被考慮到.以前對Service Level要求不高的時候還可以.但是到了現在,一但要求Service Level就發現監控做不好,管理作不好同時在狀況發生的時候也不知道端末發生了甚麼事.

以上是我自己的看法!