关于银行自行维护ATM端末软件的技术与可能性 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

最近一个朋友问我在这里好不好, 被放在这里牧羊,还不错啦!他也问到了关于银行自行维护ATM端末软件的事,在这里把我的意见提出来就教方家.
关于自己开发维护全部ATM程序,我在各国除了CitiBank之外没有看到成功的案例(因为我见识比较浅薄). CitiBank可以成功也是因为ATM硬件是他们自己设计的!另外有个别厂牌的ATM软件因为原来就是设计给银行自己维护的,所以有成功.后面我会分两种状况(个别厂牌,通用软件)来说明
个别厂牌的部份:
IBM 473X: IBM在473x的时代,出了一个端末软件,ATM的交易画面跟操作流程都通过设定档(Customization Image, CI)来设定.基本上满足了ATM的功能,银行只要学怎么设定设定档就可以使用.所以银行自己维护.后来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%相容的端末软件.
以上这类(个别厂牌的标准软件),基本上对于银行端的维护有很大的好处.在技术的要求上并没有太高的门槛,一个信息人员经过十几个小时的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就发现监控做不好,管理作不好同时在状况发生的时候也不知道端末发生了甚么事.
在ATM端末使用ISO8583的部份,也许是我个人的偏见,始终觉得这是一个笨蛋作法.因为在ISO8583 framework里面并没有定义设备管理的信息,同时电文的往返方式也没有考虑到自动化设备是24小时放在外面给不会用的人用.网络状况也不在确保个情况.如早年我少量介入了贵X商业银行的项目.他们用ISO8583, 听说是因为大家在规范上争论不休,结果有一个卖Server的销售(完全没有做过自动化设备的)就出个馊主意,说那就用 唯一的金融电文标准-ISO8583吧 .
这真是晕呀!
以上是我自己的看法,请指教吧!
另外顺便请教是否有那一位先进愿意提供一下上海银联跨行接口数据规范,人行大小额支付系统数据规范,小弟不胜感激！！！