电子银行系统的制作方法

专利名称：电子银行系统的制作方法
技术领域：
一般来说，本发明涉及银行业，更具体来说，涉及用于促进银行交易的处理的电子银行系统。
背景技术：
用于将银行或交易票据(例如资金转帐、付款处理以及对帐单和报表请求)从客户过帐给银行机构的现行系统一般依靠过时的人工方法，这些方法费时、低效而且易于出错和丢失。这类系统往往依靠基于纸张的方法，它们涉及对纸单证的人工干预和物理传递，其中每一项都造成缓慢的处理速度和过度的延时。银行交易的各方往往必须等待相当长的时间让银行完成一项具体交易。对于每天进行大量本地和国际银行交易的较大机构，现行系统的低效变得更为明显。
例如，在供应商与大客户之间的典型付款交易中，供应商准备及提交要递交给客户的发票。客户接收发票，并将它转交给发起与供应商的交易的相应发起部门。发起部门审查及核准发票以便付款。已核准的发票则转到应付帐目中，在这里准备支票。由于该系统是基于纸张的过程，因此它极大地依靠内部邮件通信联系，并且可能耗费大约四周来完成。支票转交给适当的管理人员进行确认和签名。然后把支票递交给供应商。收到支票的供应商随后将它呈送给银行以便付款。交易的这个最后部分需要进一步的处理时间(即，从一小时到三天)，要求人工干预和零售银行业务系统来完成交易。虽然客户可能定期或实时地经由电子方式(例如因特网)收到银行对帐单，但由于低效的支票兑付及票据交换过程，使得可能需要二十至三十天使上月的发票与付款一致。如果支票在此过程中丢失，则重复此过程。
因此，需要提供一种电子银行系统，它可自动处理客户发出的银行票据，以便自动处理现金业务(monetary transaction)，例如向银行帐户或受益人(即收款人)进行电子支付或者帐户之间转帐，其中具有最小延时或人工干预，同时利用现有的硬件、软件和通信组件。还需要一种电子银行系统，它提供对其中涉及多家银行的帐户的未偿债务的准确实时评估，从而缩短协调帐户所需的时间。

发明内容
本发明涉及一种电子银行系统，它可用来提供银行与客户之间的有效自动接口，其中，客户可从其场所或设备以电子方式向系统的多个会员银行中的一个发出银行票据，从而发起对所请求的现金业务的自动处理。本发明的电子银行系统可方便地适合与现有硬件、软件及通信组件配合使用。该电子银行系统通过全球计算机网络还在工作上与大量专有零售银行业务系统兼容。在本发明的一个具体实施例中，提供一种电子银行系统，用于通过本地或全球计算机网络(如因特网)以最小延时和人工干预来自动处理包括向适当货币帐户进行资金转帐的现金业务。
在本发明的一个方面，提供一种电子银行系统，包括主办银行服务器，适合接收交易请求以及处理交易请求；用于在自动操作中发起交易请求的装置；主办银行服务器与发起装置之间的数据通信中的全球计算机网络，用于将交易请求从发起装置传送给主办银行服务器；以及用于将发起装置与主办银行服务器接口以及用于把交易请求转换成与主办银行服务器兼容的可读形式并建立它们之间的安全数据通信连接的装置。
附图简介以下参照附图详细描述本发明的各种实施例，其中相似的项目由相同的参考标号标识，附图包括

图1A是示意图，说明一种支付过程，作为由根据本发明的一种电子银行系统的实现促进的应用之一；图1B是根据本发明的一个实施例的电子银行系统的示意图；图2是本发明的一个实施例的电子银行系统的整体结构的示意图；图3A至3F共同表示流程图，详细说明本发明的一个实施例的支付模式中的电子银行系统的操作步骤；图4是流程图，详细说明本发明的另一个实施例的对帐单及核对模式中的电子银行系统的操作步骤；以及图5是流程图，详细说明本发明的又一个实施例的对帐单显示模式中的电子银行系统的操作步骤。
发明详细说明本发明针对处理现金业务的电子银行系统及方法。在一种操作模式中，本发明的电子银行系统适合自动处理现金业务以及以快速方式、以最小人工干预向金融帐户进行适当的资金转帐(即付款)。例如，本发明的电子银行系统还适合利用例如因特网等全球计算机网络以及现有硬件和软件组件。本发明可方便地与包括但不限于银行、支付处理中心、金融票据交换所等现金数据处理实体合作实现。
本发明的自动特征为例如具有大量本地和国际现金业务的大机构等用户提供以同步方式与银行系统办理业务的能力。这改进了处理时间，以及使用户能够以快速实时方式、以最少人工干预使其支付系统与银行系统的帐目记录自动协调。
该系统的主要终端用户包括财政部(treasury)用户，他们访问该系统以便在实施处理之前确保交易的核准。财政部用户通常是在大机构中负责管理机构的全球不动产和金融资产、债务以及与收益、投资、债务、外汇、贷款及保险相关的风险的小组成员。因此，本发明的系统提供一种有用的工具，用于使财政部用户能够以集中且自动的方式维护和管理机构的日常财务经营。
在本发明的一个实施例中，电子银行系统包括三个主要组件核心交易处理组件，用于生成和发起现金业务；核心接口组件，用于经由因特网与银行服务器通信；以及银行接口组件，它们共同配合组成与核心接口组件的通信链路，同时鉴权、验证、办理及确认本系统的交易。
本发明在其各种实施例中可提供以下功能1.向第三方进行电子资金转帐；2.相同银行的共同帐户之间的电子资金转帐；3.不同银行的共同帐户之间的电子资金转帐；4.一般类型付款；5.自动日终电子银行对帐单检索及核对；6.对第三方生成传真付款通知；7.对接收银行生成传真预期付款通知(销售应收收入)；8.为本发明的系统提供备份的自动电报功能性；9.生成现金状况报告以表明客户的财务负债；以及10.通过本发明的系统直接集成、在任何会员银行联机检索帐户余额。
参照图1A，说明支付过程220，它表示本发明所促进的若干应用其中之一。支付过程220以步骤222开始，在其中，受益人或收款人准备并提交付款发票给客户230、如个人、公司或大机构。假定客户230是包括采购和财务部门的足够大实体，在步骤224，发票传送给客户负责审查发票并将它送往适当部门进行进一步处理和核准的接收部门(如采购部门)。接收部门把发票信息输入工商企业或工作流程软件系统，在其中它被传送到适当各方进行处理。采用电子工作流程核准过程对发票信息进行检验、以电子方式捕捉以及对付款进行核准，该过程在应付帐部门与发起此工作的发起部门之间协调。在步骤226，发票传送给发起部门供其审查和核准。在步骤228，发票核准转交给应付帐，在其中以电子支付指令的形式准备电子支付。步骤224至228通常经由工作流程核准过程在客户230的内部实现。在步骤232，客户230经由计算机网络将电子支付指令转发给银行。银行232则继续处理此信息，并按照客户230的请求进行付款。同时，在步骤234，当支付指令发送到银行232时，传真通知被转发给受益人222，确认现金业务请求已经转发到银行。现金业务可通过多种方式中任一种进行，例如通过从客户的帐户向受益人的银行帐户进行电子划款，或者通过向受益人发送支票。
参照图1B，表示根据本发明的一个实施例的电子银行系统，总体上由参考标号10表示。系统10包括串行连接的以下各项核心交易组件12，可能是银行系统的客户操作的计算机服务器；与核心交易组件12通信的核心接口组件14，它在某些应用中可由提供核心交易组件12的同一个计算机服务器支持或者由不同计算机服务器支持；全球计算机网络16(例如因特网)；以及银行接口组件18，由客户的银行操作的银行服务器20支持。银行接口组件18经由全球计算机网络16与核心接口组件14进行通信。系统10还可以可选地包括受益人服务器22，它连接到全球计算机网络16，用于与客户进行通信。核心交易组件12以及核心接口组件14安装在客户的设备上。
核心交易组件12构成客户可访问的内联网系统的一部分，可采用从机构用于支持和促进无纸化环境中配合工作的任何标准商业软件中选择的基于企业的软件来编程。这些软件可包括但不限于可向德国SAP AG购买的SAPR/3Enterprise ERP。虽然本发明的电子银行系统表示及描述为采用SAP软件及应用模块来编程，但本发明不限于这类软件程序，而是可通过替换本领域已知的其它软件来修改。
一旦现金管理事务经过用户或客户的指定核准官员的审查和核准，则核心交易组件12编程为自动产生电子交易票据或付款指令，这是自动处理的而没有其它人工干预。所产生的交易票据经由数据通信链路24转发给核心接口组件14。核心接口组件14准备交易票据，用于(经由数据通信链路26)通过全球计算机网络16传送给适当的银行服务器20。核心接口组件14通过全球计算机网络16实现核心交易组件12与相应银行服务器20之间的通信。交易票据通过全球计算机网络16传送以及由银行接口组件18接收，银行接口组件18可能是例如专用计算机或者提供银行服务器20的计算机服务器的一部分，并编程为鉴权、验证、办理及确认交易票据内包含的交易。银行接口组件18配置成与银行服务器20的特定零售银行业务系统配合工作。银行接口组件18将交易票据制作成银行服务器20的零售银行业务系统特定的形式。一旦银行服务器20接收到交易票据，即执行包含在交易票据中的指令。
参照图2，针对本发明的一个实施例更详细地说明系统10。系统10包括内联网区域13、接口区域15、防火墙区域17以及全球计算机网络区域19。内联网区域13一般包括专用本地服务器21，采用企业商业软件系统编程，例如采用SAPR/3，它是一种综合可定制的核心软件系统，设计用于支持应用模块、例如作为SAP财务会计模块(SAP Fi)的子集的SAP财政部模块(SAP-TR)。除其它功能外，本地服务器21还执行本发明的核心交易组件12的操作。本地服务器21经由通信链路23与至少一个工作站或客户计算机32进行通信，以便允许接入授权用户、如客户的指定人员。客户机或客户计算机32支持图形用户界面(GUI)软件、例如SAPGUI软件版本4.6D。
内联网区域13还包括连接到本地服务器21的核心交易数据库存储器34，用于为本地服务器21所处理的数据提供存储及检索装置。核心交易数据库存储器34装有适当的数据库软件、例如Oracle5.7.3。
接口区域15包括接口服务器25(提供核心接口组件14的功能)，它经由本地服务器21与接口服务器25之间建立的通信链路24和防火墙38连接到本地服务器21。防火墙38用于将客户的内联网区域与接口区域隔离。它的主要功能是保证对接口区域和服务器的数据业务由相应的系统和用户进行授权访问。接口服务器25采用开放式接口软件来编程，用于通过核心交易组件12与银行服务器20之间的全球计算机网络16、本例中为因特网来实现通信。在本发明的优选实施例中，开放式接口软件由SAPBusiness Connector开发，如以下描述的流程图所述。实现SAPBusiness Connector的接口服务器25通过远程功能调用(RFC)与实现SAPR/3系统的本地服务器21进行通信。接口服务器25将来自本地服务器21上的核心交易组件12的所有RFC格式的通信转换为可扩展标记语言(XML)。在本实施例中，超文本传输协议(HTTP/HTTPS)格式用于通过全球计算机网络16的通信。分别经由包括一对防火墙40和42的防火墙区域17将接口区域15保持与全球计算机网络16分隔开。接口服务器25经由分别通过防火墙40和42的通信链路26电连接到全球计算机网络16。从接口服务器25传送的数据通过全球计算机网络16、经由通信链路28传递给银行服务器20。
核心接口组件14还包括连接到接口服务器25的核心接口数据库存储器36。核心接口数据库36类似于核心交易数据库存储器34，适合为与核心接口组件14关联的所有操作提供存储及检索装置。核心接口数据库存储器36最好是建立在防火墙38之后，与内联网计算机区域13同侧，如图2所示。
在本发明中，核心交易组件12对客户的银行处的适当银行服务器20产生现金业务票据以便进行现金业务，例如进行付款或者管理客户的银行帐户中的现金。每个现金业务票据由在本例中属于核心交易组件12的SAPR/3Fi-TR模块产生。交易票据以中间文档(IDOC)的形式制作。IDOC被转发给接口服务器25，在其中它们被转换成XML，然后再转发给客户的银行处的预先指定的银行服务器20。预先指定的银行服务器20接收XML，以及银行接口组件18将XML文档重新格式化为适合由银行服务器20处理的格式。
参照图3A，表示一个流程图，说明根据本发明的原理的系统10的支付模式。本例中，在发起付款时，核心交易组件12通过运行支付程序(即SAP中的交易F110和F111)自动选择付款交易(例如供应商发票和员工工资)。系统10的算法在步骤50中以从核心交易数据库34中检索用于由支付程序准备付款建议或交易票据的参数开始。用于付款建议的参数的实例可包括典型的付款交易参数，例如过帐日期(即，应付款项已经核准支付的日期)、下一付款挤兑日期(即，用来评定应付款项到期日的下一付款挤兑的过帐数据)、公司代码(即，要共同处理的公司代码或公司代码间隔的列表)、支付方法(例如，支票、汇票和银行国外转帐)以及供应商/客户帐户(即，要考虑的供应商/客户帐户的范围)。
在步骤52，核心交易组件12产生交易建议，允许用户查看所有输出的交易票据，其中包括核心交易组件12将处理的付款。这允许用户在实际对付款交易进行过帐之前经由计算机32实现最初的复核。算法进入步骤54，其中，支付程序由核心交易组件12执行，从而产生准备发布的支付凭证或票据。在步骤56，算法根据采用SAPR/3程序的相应支付方法确定包括参数的配置和选择在内的支付凭证或票据的适当格式，例如“ZFR00440”用于USD(美元)支票支付，“RFFOEDI1”用于电子资金转帐(EFT)支付，等等。
支付凭证以中间文档(IDOC)的形式产生，并在步骤58发布到核心接口组件14。在一个实例中，对于EFT支付，支付程序产生两种文档“PAYEXT”IDOC和“EUPEXR”IDOC。每个PAYEXT IDOC包含每个银行一个收款人的支付信息。EUPEXR IDOC是对于各银行产生的参考IDOC，并包含对相应主办银行发布的具有PAYEXTIDOC编号列表的支付票据的所有汇总信息。例如，在SAPR/3中，IDOC经由远程功能调用(RFC)目标端口递交给核心接口组件14。在本例中，当IDOC在步骤60被递交后，核心交易组件14立即将IDOC状态更新为“03”，其中带有表明数据已经正确传递到端口的消息“数据传递到端口成功”。
在步骤62，核心接口组件14所接收的IDOC被存储和排列在RFC队列中。EUPEXR IDOC被接收，以及汇总信息与PAYEXT IDOC编号一起作为在本文中称为T_BC_支付_参考和T_BC_支付_参考_详细资料的表被映射及存储。
在步骤64，算法进行检查，以确定到核心接口组件14的通信链路24是否是活动的。如果核心接口组件14的服务器25关机或者是不活动的，则SAPR/3对RFC队列中的所有IDOC排队，直到服务器再次开机。队列经过配置，使得挂起的IDOC每分钟再次被发送给RFC端口，直到传送成功或者尝试次数达到999次。对于每次传送，重试次数在步骤66中加一。在步骤68，算法查询尝试次数是否大于999。如果查询为“否”，则算法进入步骤70，在其中，IDOC被重新提交给RFC队列。否则，算法进入步骤72，在其中，SAP监测人员被告知连接问题以便允许发起故障排除。在步骤74，监测人员解决连接问题，并进入步骤70进行重新提交。SAP监测人员一般由客户的员工组成，并由客户授权监测构成本发明的系统的组成部分的系统、服务器、组件及过程，其中包括其硬件和软件两个方面。监测人员准备实施适当动作对操作过程中可能出现的任何异常情况进行校正或故障排除。
如果在步骤64确定连接是活动的，则算法进入图3B的步骤76。
在图3B的步骤76，核心接口组件14接收具有支付信息的PAYEXT IDOC，并将IDOC参数字段映射为适当的变量。在步骤78，作为接口服务器25的核心接口组件14编程为将IDOC以本文称为T_BC_支付_交易的数据库表的形式存储在又称作电子银行DB(数据库)的核心接口数据库存储器36中。随后，在步骤80，本地服务器21的核心接口组件12编程为通过采用对核心接口组件14(本例中为接口服务器25)的SAPRFC调用，将本地服务器25的核心交易组件12中的IDOC状态更新为“06”，其中带有消息“转换成功”。
在步骤82，核心接口组件14将IDOC格式化为“MT100”指令(即客户转帐)，它符合环球银行间通信协会实施的标准格式。然后，所产生的MT100指令在步骤84编译成格式化为可扩展标记语言(XML)的交易文档。这个操作通过对匹配经由参考IDOC(即EUREXR IDOC)接收的信息的所有IDOC编号从T_BC_支付_交易表中检索所有支付指令来实现。执行这个过程以便根据主办银行编译支付指令，用于以后作为单个文档向相应主办银行服务器20进行传送和过帐。每个交易文档的支付指令的最大数量取决于主办银行。各银行的交易文档的正确制作和传递的具体要求存储在本文中称作EBANKING.CNF配置文件的配置文件中。
格式化为SWIFT MT100(SWIFT代表“环球银行间通信协会”)并环绕相应的XML标记的交易文档等待传送到主办银行服务器20。在步骤86，从EBANKING.CNF配置文件中检索银行相关参数或要求。在步骤88，银行相关参数被用来采用市场出售的特定散列算法来制备具有数字签署证书的所有交易文档。为了安全目的，证书用于在递送之前鉴权或数字签署文档。主办银行服务器20采用数字签署证书来检验真实性以及确保交易文档中包含的信息在传送过程中没有改变。算法采用EBANKING.CNF配置文件中包含的银行相关参数创建XML交易文档的数字签名。
在步骤90，核心接口组件14建立到特定主办银行服务器20的安全连接。这通过建立安全套接字层(SSL)会话来实现。交易文档的数字签署证书与根证书认证路径一起用来发起该会话。算法在步骤92确定是否建立了成功连接。如果没有建立连接，则算法进入步骤94。核心接口组件14将交易文档与银行相关参数一起以本文称为T_BC_故障_服务的数据库表形式存储在核心接口数据库存储器36中。该表记录所有故障，包括核心接口组件服务。在步骤96，算法发起交易文档的递送的自动重试。本例中，故障服务的重试大约每三分钟进行一次。
算法进入查询步骤98，以便确定重试次数是否大于三。持续无法建立连接电子邮件通知被发送给技术支持及业务小组以便进行适当的校正操作。为业务小组或财政部用户准备具有交易代码“ZF0642”、又称作支付状态工具的报告，以便查看核心交易组件12发布的所有支付指令的状态。提供若干选项，其中，作为应急方法，业务小组可重试传送或产生自动电报/传真，以便将交易文档传递给相应银行。
向银行发送支付指令的应急方案或备用选项可用于核心接口组件14或主办银行服务器20无法处理支付指令的情况中。在这个应急方案中，包含支付指令的交易文档配置成具有汇总报告的适当电报格式，让核心交易组件12的用户产生测试代码。电报自动传送到银行。
如果在步骤98的查询为“是”，则算法进入步骤100，在其中，通过采用对核心交易组件12的SAPRFC调用，将核心交易组件12中的IDOC状态改变为“13”，其中带有消息“付款过帐时出错”。在步骤102，电子邮件消息被发送给核心交易组件12的授权用户，以便经由传统方式建立的电报传送手动发布交易文档。用户执行交易ZF0642以便查看从核心交易组件12发布的支付指令的状态，以及对具有状态代码“13”的所有支付产生电报报告。向用户显示电报报告，在其中，根据银行提供的保密公式计算测试代码。每家银行采用不同的公式。对每个银行制作单独的报告，表明已失败的所有支付。
在步骤104，授权用户经由电报传送向主办银行发布交易文档，并完成操作。在成功传送之后，用户将IDOC状态代码更新为“12”，表明支付成功地由银行确认。
如果步骤98的查询为“否”，则算法进入步骤88，开始重新建立与主办银行服务器20的安全连接。
一旦在步骤90建立了到主办银行服务器20的安全连接，并且步骤92的查询为“是”，则算法进入步骤105。在步骤105，核心接口组件14将包含支付指令和数字签名的交易文档通过全球计算机网络16传送到主办银行服务器20的银行接口组件18。客户的银行27采用本领域已知的其零售银行业务系统着手执行付款交易。
在图3C，算法进入步骤106，在其中，核心接口组件14等待来自本例中包含在服务器20中的银行接口组件18、其中包含过帐到银行的支付指令的每个的响应状态代码及消息的格式化为XML的响应文档。在步骤108，核心接口组件14接收来自银行接口组件18的响应文档。在银行与客户之间传递的所有XML文档均记录在本发明的系统中，并且一般分别标识为“文档已发送”和“文档已接收”。在步骤110，响应文档的返回代码和消息以本文称为T_BC_文档_已接收的表的形式存储在核心接口数据库存储器36中用于审计目的。核心接口组件14在步骤112处理各支付指令的响应文档中的状态。算法进入步骤114，在其中，各支付指令的状态由核心接口组件确定。
对于查询步骤114中的返回代码“成功”，算法进入步骤116，在其中，MT100格式化支付指令被确定为由主办银行成功接受。然后，核心接口组件14通过采用对核心交易组件12的SAPRFC调用，将核心交易组件12中的IDOC状态更新为“12”，其中带有消息“支付成功地由银行确认”。列出成功支付的报告可采用交易“ZF0642”来产生，下面将会进行说明。
对于查询步骤114中的返回代码“DE”、“01”或“09”，算法进入步骤120，在其中，MT100格式化支付指令被确定为无效。支付指令包含数据合法性错误。该错误通常因核心交易组件12输入的不正确的基本数据或配置文件信息而包含在商业数据中。算法进入步骤122，在其中，核心接口组件14将核心交易组件14中的IDOC状态更新为代码“11”，发信号通知银行的支付接受因合法性而失败。算法进入图3D的步骤124。在步骤124，核心接口组件14向核心交易组件14的用户发送电子邮件通知，其中具有来自银行的适当错误消息。算法进入查询步骤126，在其中，确定拒绝的有效性。如果查询为“否”，则算法进入步骤128，在其中，核心交易组件12的用户发起交易“ZF0646”、又称作支付撤消工具，用于将IDOC状态设置为“31”，以及发起“ZF0642”，用于实现支付状态报告，以及支付指令经由电报传送提交给银行。在步骤130，从银行接收电报确认作为证实，以及系统10的操作完成。
如果在查询步骤126确定拒绝为有效，则算法进入步骤132，在其中，核心交易组件12的用户发起交易ZF0646并撤消支付。在步骤134，用户对产生错误的数据进行必要的校正。在步骤136，经校正的支付指令重新输入核心交易组件12，在其中，算法重新进入图3A的步骤50。
再参照图3C，对于查询步骤114中的返回代码“失败”，算法进入步骤138，在其中，主办银行服务器20的服务或组件被确定为出故障。算法进入步骤140，在其中，返回代码作为银行侧的技术故障被处理，以及核心接口组件14将核心交易组件14中的IDOC状态更新为代码“13”，其中带有消息“传递支付指令时出错”，发信号通知银行的支付接受因技术问题而失败。算法进入图3E的步骤142。在步骤142，核心接口组件14向核心交易组件12的用户发送电子邮件通知以及因技术性问题而使支付拒绝的原因。算法进入步骤144，在其中，核心交易组件12的用户发起交易“ZF0642”用于支付报告，以及支付指令经由电报传送提交给银行。在步骤146，从银行接收电报确认作为证实，以及系统10的操作完成。
再参照图3C，对于查询步骤114中的返回代码“DUDE”或“DUOK”，算法分别进入步骤148或步骤150，在其中，支付指令被确定为重复。银行对于随DE错误而拒绝的支付而返回“DUDE”返回代码。银行服务器20对于在前一次传送中接受的支付而返回“DUOK”返回代码。在步骤148或150其中任一个步骤，算法进入图3F的步骤152。在查询步骤152，核心接口组件14确定返回代码是“DUDE”还是“DUOK”。如果返回代码为“DUDE”，则算法进入步骤154，在其中，核心接口组件14检查核心交易组件12中的支付指令的上一个IDOC状态。在查询步骤156，核心接口组件14确定状态代码是否为“11”或者支付被银行拒绝。如果查询为“否”，则算法进入图3D的步骤124。如果查询为“是”，则算法进入步骤158，在其中，核心接口组件14向技术人员发送电子邮件通知，用于进行为什么再次传递支付的故障诊断，以及系统10的操作完成。
在查询步骤152，如果返回代码为“DUOK”，则算法进入步骤160，在其中，核心接口组件14检查核心交易组件12中的支付指令的上一个IDOC状态。在查询步骤162，核心接口组件14确定状态代码是否为“12”或者支付成功地由银行确认。如果查询为“否”，则算法进入步骤164，在其中，核心接口组件14将核心交易组件14中的IDOC状态更新为代码“12”，其中带有消息“支付成功地由银行确认”。系统10的操作完成。
在查询步骤162，如果结果为“是”，则算法进入步骤166，在其中，核心接口组件14向核心交易组件12的用户和技术人员发送关于支付为重复的以及要采取校正操作的电子邮件通知。系统10的操作完成。
要注意，如果出现错误，传送给主办银行服务器20的支付指令不应当由银行接口组件18自动修复。所有具有错误的支付指令被返回给核心接口组件14，其中具有详细消息及返回代码。
核心接口组件14可配置成采用交易“ZF0642”对于所有成功支付(即状态代码“12”)产生支付通知报告。
参照图4，针对本发明的另一个操作模式和实施例示出详细说明系统10的操作的流程图。银行对帐单通常在银行营业时问之后每天检索一次以及在商定时间检索，用于自动核对。这个时间通常在第二天的早晨。从银行接收的数据包含关于银行对帐单中每项交易的性质的信息。例如，表明交易代码，以便说明例如支票付款交易、电子支付、银行转帐或客户收据。
相对每项的参考信息(例如支票编号、参考编号)也可包含在银行对帐单中。根据银行对帐单中包含的信息，存储在核心交易组件12中的所有未决交易可在核对时自动清算。电子银行对帐单被接收并由核心接口组件14转换成核心交易组件12可识别的格式。
在步骤168，核心交易组件12发起对帐单请求，它被发送给核心接口组件14。在步骤170，核心接口组件14接收对帐单请求并将它转换成XML文档。在步骤172，核心接口组件14从EBANKING.CNG配置文件中检索要求参数，以便通过全球计算机网络16建立安全套接字层(SSL)会话。在步骤180中建立经由银行接口组件18到主办银行服务器20的安全连接。算法进行到查询步骤182，以便确定是否成功建立连接。如果查询为“否”，则算法进行到查询步骤174，以便确定尝试次数是否大于三。如果查询为“否”，则算法回到步骤180。如果查询步骤174中的查询为“是”，则算法进行到步骤176，在其中，核心接口组件14向核心交易组件12的用户和技术人员发送电子邮件通知，告知他们连接问题。在步骤178，核心接口组件14向核心交易组件12提出“故障”异常情况，以便手动重新发起对帐单请求。
如果建立了成功的连接，则算法进入步骤184，在其中，XML对帐单请求由接口服务器25的核心接口组件14经由全球计算机网络16传递给主办银行服务器20。在步骤186，主办银行服务器20将包含银行对帐单的请求响应发送给相关银行接口组件18，在其中对帐单、即MT940对帐单被转换成XML，然后经由全球计算机网络16转发给核心接口组件14。在步骤188，核心接口组件14分别以本文称作T_BC_文档_已发送和T_BC_文档_已接收的表的形式将对帐单请求和请求响应存储在核心接口数据库36中用于审计目的。在步骤190，根据SWIFT标准格式化成MT940的银行对帐单从请求响应中提取，并存储在核心交易组件12中。在步骤192，核心交易组件12导入银行对帐单中包含的数据以便核对交易。系统10的操作完成。
参照图5，针对本发明的另一个操作模式和另一个实施例示出详细说明系统10的操作的流程图。在本发明中，在本例中经由计算机32为用户提供在线银行对帐单访问，用于直接从主办银行服务器20实时查看对帐单。提供对帐单查看访问只是用于查看目的而不用于调整。在步骤194，响应用户请求，核心交易组件12通过又称作在线对帐单报告工具的交易“ZF0640”发起对帐单请求，用于查看在线银行对帐单。在步骤196，核心接口组件14接收对帐单请求并将该请求格式化为XML文档。在步骤198，核心接口组件14检索银行相关要求，以便通过全球计算机网络16建立与主办银行服务器20的SSL连接。建立安全连接的尝试在步骤200进行。在查询步骤202，核心接口组件14确定是否已经建立安全连接。如果查询为“否”，则算法进入步骤204，在其中，向请求用户显示与“ZF0640”功能对应的返回连接错误消息，以及系统10的操作完成。
如果查询步骤202中的查询为“是”，则算法进入步骤206，在其中，包含对帐单请求参数的对帐单请求被传递给银行接口组件18。银行接口组件18处理该对帐单请求，用于上传给主办银行服务器20。主办银行服务器20以SWIFT MT940的格式产生银行对帐单，送往银行接口组件18。银行接口组件18将银行对帐单转换成XML格式，并将它传送给核心接口组件14。在步骤208，核心接口组件14接收银行对帐单。在步骤210，核心接口组件14将来自银行对帐单的MT940数据处理成结构化输出，并将输出上传给核心交易组件12，用于向用户显示。
虽然以上已经详细表示和描述了本发明的各种实施例，但它们不是意味着限制。本领域的技术人员可能知道对这些实施例的某些修改，这些修改打算由所附权利要求涵盖。例如，虽然全球计算机网络16、如因特网表示为用于提供客户的本地服务器21与银行的服务器20之间的数据连接通路或链路，但网络16也可以是用于在客户及其银行所在的大建筑物内进行通信的局域网(LAN)、或者例如其中客户及其银行位于共同商业区的广域网(WAN)。
权利要求
1.一种用于允许银行客户远程授权和请求由其银行进行计算机化现金业务的自动银行系统的方法，所述方法包括以下步骤在客户的场所提供计算机化系统；在客户的系统上接收客户手动输入的对于客户的银行办理现金业务的请求；响应请求，在客户的系统上自动运行现金业务程序，用于产生正确格式化的现金业务文档作为中间文档(IDOC)；在客户的系统中自动将所述IDOC在远程功能调用(RFC)队列中保持预定的时段，从而允许所述IDOC被传递到客户的系统的电子银行接口服务器中以便进一步处理；将所述接口服务器编程为自动将所述IDOC转换成可扩展标记语言(XML)格式化文档；自动通过计算机网络将所述XML格式化IDOC从所述客户的系统传送到所述客户的银行中的兼容电子银行服务器；以及响应所述IDOC，经由所述银行的所述服务器自动处理所请求的现金业务。
2.如权利要求1所述的方法，其特征在于，还包括以下步骤自动操作所述银行的电子银行服务器向所述客户发送XML格式化状态文档；在所述客户的系统上自动接收所述状态文档；操作所述客户的系统以允许所述客户阅读所述接收的状态文档；以及自动将所述接收的状态文档记录到所述客户的系统中的核心交易数据库存储器中。
3.如权利要求1所述的方法，其特征在于，自动运行所述现金业务程序的所述步骤包括以下步骤输入用于所述请求的现金业务的参数；创建现金业务建议；以及执行现金业务运行以产生所述IDOC。
4.如权利要求1所述的方法，其特征在于，所述RFC队列保持步骤包括以下步骤向所述客户的银行中的电子银行服务器的RFC目的地发布所述IDOC；将IDOC状态更新为表明数据成功传递到端口的数字化代码；使在所述端口接收的所述IDOC编制到RFC队列中；以及检查以确定到所述客户的银行中的所述服务器的通信链路是活动的还是不活动的。
5.如权利要求4所述的方法，其特征在于还包括以下步骤通过对重试计数器的数值加“1”，对所述银行的所述接口服务器为不活动的进行响应；确定重试次数是否大于预定最大数值；以及如果所述重试次数没有超过所述最大数值，则向所述RFC队列重新提交所述IDOC；以及重复所述检查步骤。
6.如权利要求5所述的方法，其特征在于还包括以下步骤通过通知故障排除人员在建立与银行的所述接口服务器之间的通信链路时的问题，对所述重试次数大于所述预定数值进行响应；响应链接问题已经解决的通信，向所述RFC队列重新提交所述IDOC；以及重复所述检查步骤。
7.如权利要求4所述的方法，其特征在于还包括以下步骤通过将IDOC参数字段映射到适当的变量，对活动的接口服务器进行响应；将IDOC数据存储在电子银行DB(数据库)中；更新所述IDOC状态以表明可接受的转换；将所述IDOC格式化为符合环球数据银行通信协会实施的标准格式的指令；将所述格式化的IDOC以及后续格式化的IDOC均编译成格式化为可扩展标记语言(XML)的交易文档；从eBanking.CNF配置文件中检索银行相关参数；采用客户证书为每个XML格式化文档创建数字签名；建立到所述客户的银行中的所述计算机服务器的安全连接；确定是否成功建立了安全连接；以及通过经由计算机网络将包含交易指令和数字签名的每个交易文档传送给所述客户的银行中的所述计算机服务器，对成功建立的安全连接进行响应。
8.如权利要求7所述的方法，其特征在于还包括以下步骤通过将所述XML文档与银行相关参数一起记录在标为“故障服务”的数据库中，对建立安全连接的失败进行响应；自动重试创建数字签名、建立安全连接以及确定是否已经建立安全连接的这些相继步骤；确定所述重试次数是否大于预定最大数值；以及如果所述重试次数不大于所述最大数值，则继续进行所述自动重试步骤。
9.如权利要求8所述的方法，其特征在于还包括以下步骤通过将所述IDOC状态更新为表明付款过帐时错误的代码，对所述重试次数超过所述最大数值进行响应；对于经由先前以传统方式建立的电报或传真传输发布付款，向客户的授权职员发送电子邮件通知；响应所述电子邮件，所述授权职员经由电报或传真向所述银行发布或提供所述现金业务文档；以及更新IDOC状态代码以表明所述现金业务成功完成已经由所述银行确认。
10.如权利要求7所述的方法，其特征在于还包括以下步骤等待来自所述银行的所述计算机网络上的响应；从所述银行接收格式化成XML的响应文档，其中包含传递给所述客户的银行的每个现金支付指令的响应状态代码和消息；在电子银行数据库中存储所述响应文档；为每个相关现金业务指令处理所述响应文档中的状态；以及确定来自各现金业务的银行的状态。
11.如权利要求10所述的方法，其特征在于，确定各现金业务的状态的步骤包括以下步骤为成功地由所述银行处理的现金业务指明相当于“成功”的状态代码；以及将相关IDOC状态更新为具有表明所述银行已经通知了所述现金业务成功进行的代码。
12.如权利要求10所述的方法，其特征在于还包括以下步骤表明与导致所述银行拒绝所述现金业务的数据错误对应的状态代码；以及将所述交易的所述IDOC状态更新为表明因数据错误引起的交易拒绝的代码。
13.如权利要求12所述的方法，其特征在于还包括以下步骤向客户的授权职员发送电子邮件通知，表明所述现金业务的拒绝的原因；通过所述授权职员的操作确定所述拒绝是否有效；通过所述授权职员的操作响应有效的拒绝，采用电子银行交易请求以撤消所述现金业务请求；经由所述授权职员的操作校正导致所述银行拒绝所述现金业务的所述数据；以及通过所述银行系统重新处理所述已校正现金业务以便完成。
14.如权利要求13所述的方法，其特征在于还包括以下步骤通过所述授权职员的操作响应无效的拒绝，采用适当的电子银行交易代码，用于经由测试电报传输向所述银行发布所述现金业务；以及经由所述客户的计算机系统接收来自所述银行的证实所述现金业务完成的确认。
15.如权利要求10所述的方法，其特征在于还包括以下步骤为银行因未知原因无法完成所述现金业务表明与“失败”对应的状态代码；以及响应所述“失败”代码而将IDOC状态更新为表明失败的现金业务的代码。
16.如权利要求15所述的方法，其特征在于还包括以下步骤经由电子邮件通知从所述银行向所述授权职员发送所述银行无法完成所述现金业务的原因；通过所述授权职员的操作，采用适当的电子银行交易代码，经由测试电报或传真向所述银行发布授权以完成所述现金业务；以及经由从所述银行到所述客户的电报或传真接收完成所述现金业务的确认。
17.如权利要求10所述的方法，其特征在于还包括以下步骤从所述银行表明返回状态代码，它对应于因数据错误而被银行拒绝的前一次传输的电子银行的重复传输所用的“DUDE”，或者对应于银行成功处理的前一次传输的电子银行的重复传输所用的“DUOK”；经由所述客户的计算机系统确定所述返回状态代码是对应于DUDE还是DUOK；响应DUDE的状态代码而确定所述现金业务的上一个IDOC状态是否表明所述交易因数据错误而被银行拒绝；响应因数据错误引起的拒绝，向技术人员发送电子邮件通知，用于对所述现金业务重复传到银行的原因进行故障排除；以及响应不是因数据错误引起的拒绝，向客户的授权职员发送电子邮件通知，表明现金业务被银行拒绝的原因。
18.如权利要求17所述的方法，其特征在于还包括以下步骤响应“DUOK”的状态代码，确定所述现金业务的上一个IDOC状态是否表明所述交易由银行成功处理；响应所述紧靠前面的确定步骤中的“否”回答，将所述IDOC状态改为表明成功处理的代码；以及响应前一个相关确定步骤中的“是”回答，向客户的授权职员以及客户的技术人员发送电子邮件通知，用于表明所述现金业务在所述自动银行系统中被重复。
19.如权利要求1所述的方法，其特征在于还包括以下步骤采用调度程序通过所述客户的操作发起对银行对帐单的请求；将所述请求传递给客户的所述接口服务器，用于转换为XML文档；从电子银行配置文件中检索所要求的在所述计算机网络上建立安全套接字层(SSL)会话所必需的参数；在所述计算机网络上建立到所述银行的电子银行服务器的安全连接；确定是否成功建立所述连接；响应不成功连接，确定重试次数是否大于所允许的最大数值；响应所述重试次数未超过所述最大数值，重复所述安全连接建立步骤；响应所述重试次数超过所述最大数值，向客户的职员以及技术人员发送电子邮件，通知连接或对帐单检索故障；以及向调度程序提出“失败”异常情况，以便允许对所述对帐单的手动请求。
20.如权利要求19所述的方法，其特征在于还包括以下步骤通过将包含对帐单请求参数的XML文档传递给所述银行的电子银行服务器，响应所述安全连接建立步骤中的成功连接；在来自所述银行的XML格式化响应中检索客户的系统对帐单；将所述XML格式化请求以及响应都存储在所述客户的电子银行数据库中；从所述电子银行数据库中检索所述对帐单，以便在指定文件夹中创建文件；以及通过使用标准化银行商业软件来核对所述对帐单。
21.如权利要求1所述的方法，其特征在于还包括以下步骤通过所述客户的操作，采用电子银行交易代码发起请求显示已完成的现金业务的对帐单；经由客户的所述接口服务器，将所述请求转换为XML格式化文档；从电子银行配置文件中检索所要求的在所述计算机网络上建立到所述银行的电子银行服务器的安全连接所必需的参数；在所述计算机网络上建立到所述银行的电子银行服务器的安全连接；确定是否成功建立所述连接；以及通过返回向所述客户显示的连接错误消息，响应所述连接的不成功建立。
22.如权利要求21所述的方法，其特征在于还包括以下步骤通过向所述银行的所述电子银行服务器传递包含对帐单请求参数的XML文档，响应所述连接的成功建立；在所述客户的所述电子银行接口服务器上接收来自所述银行的XML格式化对帐单的响应；以及提取所述对帐单，用于向所述客户显示。
23.一种用于发起和自动处理现金业务的自动电子银行系统，所述系统包括发起装置，用于允许银行的远程客户有选择地发起要自动处理的现金业务请求；银行主服务器，适合自动接收和处理所述现金业务请求；所述银行主服务器装置与所述发起装置之间数据通信的计算机网络，用于将付款交易请求从所述客户的发起装置传送给所述银行主服务器；以及接口装置，位于所述发起装置与所述计算机网络之间，用于自动将所述发起装置与所述银行主服务器接口，以及用于将所述现金业务请求转换为与所述银行主服务器兼容的可读形式。
24.如权利要求23所述的系统，其特征在于还包括安全装置，用于建立所述发起装置与所述银行主服务器之间的数据的安全传送。
25.如权利要求23所述的系统，其特征在于还包括编程装置，用于操作所述发起装置、接口装置以及银行主服务器来自动响应所述现金业务请求，从而所述银行主服务器完成所述现金业务，以及确保产生详细说明完成付款交易中执行的每个必要跟踪步骤的全部必要的电子记录。
26.如权利要求23所述的系统，其特征在于，所述发起装置包括至少一台计算机，用于允许客户产生所述现金业务请求；客户的本地计算机服务器，连接在所述至少一台计算机与所述接口装置之间；以及核心交易数据库存储器，用于存储用于操作所述本地计算机服务器执行以下步骤的必要计算机程序通过制备中间文档(IDOC)形式的现金业务票据以及各种相关支付参数的所有必要跟踪记录，响应客户的现金业务请求。
27.如权利要求26所述的系统，其特征在于，所述接口装置包括客户的接口计算机服务器，连接在所述本地计算机服务器与所述计算机网络之间；以及核心接口数据库存储器，用于存储操作所述接口计算机服务器将通信从所述本地计算机服务器转换成所述通信网络上的通信所用的格式所用的必要计算机程序，以及用于存储所述IDOC、交易文档、返回代码以及涉及与所述银行主服务器装置的交易的消息。
全文摘要
一种用于发起和自动处理现金业务的自动电子银行系统包括发起装置，用于保存交易记录并允许银行的远程客户有选择地发起要自动处理的现金业务请求；银行主服务器，适合自动接收及处理现金业务请求；银行主服务器装置与发起装置之间数据通信的计算机网络，用于将付款交易请求从客户的发起装置传送给银行主服务器；以及接口装置，位于发起装置与计算机网络之间，用于自动将发起装置与银行主服务器接口，并用于将现金业务请求转换成与银行主服务器兼容的可读形式，其中客户的发起装置定期从银行主服务器的响应中接收确认数据，以便允许发起装置每天自动核对交易记录。本发明还针对一种用于允许银行客户远程授权及请求由其银行进行计算机化现金业务的自动电子银行系统的方法。
文档编号G06Q20/00GK1703706SQ03821811
公开日2005年11月30日 申请日期2003年9月16日 优先权日2002年9月16日
发明者A·M·阿尔－阿利 申请人:沙特阿拉伯石油公司