银行账务清算方法、装置、设备、存储介质及程序产品

技术领域

本申请涉及数据处理技术领域，尤其涉及一种银行账务清算方法、装置、设备、存储介质及程序产品。

背景技术

随着证券市场蓬勃发展，代理银证系统需要进行大量的账务清算，自证券登记结算制度中券款对付(Delivery Versus Payment，DVP)规则改革以来，券商创新应用层出不穷，因此，需要加快产品创新，提高三方存管产品的先进性，保证代理银证系统可以实时进行银行与券商之间账务清算核对。

现有技术中，代理银证系统在日终与银行主机进行行内对账完后，将当日转账流水产生的对账文件发给所有券商，使得券商可以根据银行的对账文件进行对账，并在对账完成后，将股票买卖和结息流水发给银行，以使银行进行券商的一次清算校验，在等所有券商的一次清算完成后，代理银证系统才将所有券商下所有客户同时进行二次清算，并生成各个券商的交收记录。

但是，上述清算方法实时性差，进行二次清算需要等所有券商的一次清算完成，且将完成文件返回给银行后才可以处理，导致清算效率较慢。

发明内容

本申请提供一种银行账务清算方法、装置、设备、存储介质及程序产品，用以解决现有清算方法实时性差，进行二次清算需要等所有券商的一次清算完成，且将完成文件返回给银行后才可以处理，导致清算效率较慢的问题。

第一方面，本申请提供一种银行账务清算方法，所述方法包括：

接收券商清算文件，并基于所述券商清算文件进行校验，以校验券商进行一次清算的数据是否通过；

每隔预设时间，扫描日终批量更改余额控制表，确定处于正在清算状态的券商信息以及所述处于正在清算状态的券商信息对应的券商个数；所述日终批量更改余额控制表用于存储校验通过的券商清算文件对应的券商信息和对每一券商的处理状态；所述处理状态包括正在清算状态、未清算状态和清算完成状态；

当确定所述券商个数等于预设阈值时，获取每一券商信息对应的客户信息，并基于所述客户信息确定每一客户的账户余额表；所述账户余额表用于存储客户在银行的保证金实时余额、日初余额和当前余额；

基于所述券商清算文件更新每一客户的账户余额表，并基于更新后的账户余额表进行二次清算，以校验更新后的每一客户的保证金实时余额、日初余额和当前余额是否正确。

在一种可能的设计中，所述方法还包括：

当确定所述券商个数小于预设阈值时，再次获取日终批量更改余额控制表中处于正在清算状态的券商信息，直至确定所述处于正在清算状态的券商信息对应的券商个数等于预设阈值；

当确定所述券商个数大于预设阈值时，基于所述券商信息的存储顺序处理预设阈值个处于正在清算状态的券商信息，并将在下个预设时间，处理多于预设阈值的券商信息。

在一种可能的设计中，所述券商清算文件包括：多个客户的日终余额、多个营业部的当前余额和券商总余额；基于所述券商清算文件进行校验，包括：

基于所述券商清算文件获取对应的多个客户的银行账户余额、多个客户的转账金额、多个营业部的前一日账户余额和多个营业部的当日交易发生余额；

针对每一客户和每一营业部，基于所述客户的银行账户余额和所述客户的转账金额校验所述日终余额是否正确，基于所述营业部的前一日账户余额和所述当日交易发生余额校验所述当前余额是否正确；

基于所述多个营业部的前一日账户余额和所述多个营业部的当日交易发生余额校验所述券商总余额是否正确，并将校验出现问题的客户信息存储于券商清算不平表中；每一券商总余额对应一个券商。

在一种可能的设计中，所述方法还包括：

判断所述日终批量更改余额控制表中处于正在清算状态的券商信息对应的券商个数和所述券商清算不平表中客户信息对应的客户个数是否均为零；

当确定所述日终批量更改余额控制表和/或所述券商清算不平表中客户个数不为零时，判断券商清算状态表中每一券商对应的一次清算是否校验通过；所述券商清算状态表用于记录一次清算通过的券商信息；

若一次清算通过，则在营业时间内对所述券商清算文件进行二次清算；所述营业时间为工作日全天；

若一次清算未通过，则生成提示信息，以提醒重新提交券商清算文件。

在一种可能的设计中，所述方法还包括：

获取所述券商清算状态表中的第一券商数量和所述日终批量更改余额控制表中处于清算完成状态的券商信息的第二券商数量；

基于所述第一券商数量和所述第二券商数量确定二次清算是否完成；

当所述第一券商数量和所述第二券商数量一致时，基于所述日终批量更改余额控制表生成交收记录；

当所述第一券商数量和所述第二券商数量不一致时，继续扫描日终批量更改余额控制表。

在一种可能的设计中，基于所述券商清算文件更新每一客户的账户余额表，包括：

获取所述券商清算文件对应的券商信息、币种和借贷标志，并在券商清算资金汇总表中删除所述券商信息对应的券商数据；所述券商清算资金汇总表用于存储所有券商信息对应的券商数据；所述券商数据用于更新账户余额表；

基于所述券商信息、所述币种和所述借贷标志确定每一客户的交收金额，并基于所述交收金额更新每一客户的账户余额表。

在一种可能的设计中，基于所述交收金额更新每一客户的账户余额表，包括：

获取每一客户的对账不平表，并确定所述对账不平表中是否存在数据；所述对账不平表用于存储校验出现问题的客户信息对应的保证金实时余额、日初余额和当前余额；

当确定每一客户的对账不平表中不存在数据时，获取每一客户的当前时刻余额和当前截止余额，利用所述当前时刻余额和所述交收金额更新所述保证金实时余额，利用所述当前截止余额和所述交收金额更新所述当前余额，以及利用所述当前余额更新下一日的日初余额；

当确定每一客户的对账不平表中存在数据时，基于所述校验出现问题的客户信息对应的保证金实时余额、日初余额和当前余额，利用预定义算法计算所述对账不平表对应的差额，并基于所述差额更新每一客户的账户余额表。

在一种可能的设计中，基于所述差额更新每一客户的账户余额表，包括：

分别获取保证金账号清算临时表和日终更改余额状态表中的记录数；所述保证金账号清算临时表中的记录数为各个券商对应的客户的交收记录数；所述日终更改余额状态表中的记录数为更新账户余额表后的客户个数或客户进行交易记录的个数；

基于所述记录数确定所述日终批量更改余额控制表中券商是否更新成功。

在一种可能的设计中，所述方法还包括：

在基于所述券商清算文件更新每一客户的账户余额表之前，将所述券商清算文件与所述账户余额表对应的客户数量进行比对，以查找是否存在未进行一次清算的客户信息；

当确定存在未进行一次清算的客户信息后，基于所述账户余额表进行二次清算。

第二方面，本申请提供一种银行账务清算装置，所述装置包括：

接收模块，用于接收券商清算文件，并基于所述券商清算文件进行校验，以校验券商进行一次清算的数据是否通过；

扫描模块，用于每隔预设时间，扫描日终批量更改余额控制表，确定处于正在清算状态的券商信息以及所述处于正在清算状态的券商信息对应的券商个数；所述日终批量更改余额控制表用于存储校验通过的券商清算文件对应的券商信息和对每一券商的处理状态；所述处理状态包括正在清算状态、未清算状态和清算完成状态；

确定模块，用于当确定所述券商个数等于预设阈值时，获取每一券商信息对应的客户信息，并基于所述客户信息确定每一客户的账户余额表；所述账户余额表用于存储客户在银行的保证金实时余额、日初余额和当前余额；

二次清算模块，用于基于所述券商清算文件更新每一客户的账户余额表，并基于更新后的账户余额表进行二次清算，以校验更新后的每一客户的保证金实时余额、日初余额和当前余额是否正确。

第三方面，本申请实施例提供一种电子设备，包括：至少一个处理器和存储器；所述存储器存储计算机执行指令；所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计所述的银行账务清算方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第一方面以及第一方面各种可能的设计所述的银行账务清算方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上第一方面以及第一方面各种可能的设计所述的银行账务清算方法。

本申请提供的银行账务清算方法、装置、设备、存储介质及程序产品，可以在券商发送完券商清算文件后，基于券商清算文件校验券商进行的一次清算是否成功，并在校验通过后，将相应的券商信息登记到日终批量更改余额控制表，进一步的，添加二次清算扫描任务，该二次清算扫描任务每隔预设时间扫描日终批量更改余额控制表，查询等待二次清算的券商信息和正在二次清算的券商个数，如果正在清算的券商个数小于预设阈值，则逐个为券商添加二次清算的任务，直到正在处理的券商个数等于预设阈值；进一步的，根据券商清算文件更新客户的保证金实时余额、日初余额和当前余额，以进行二次清算，这样，在某个券商发送完清算文件，一次清算成功后实时进行二次清算，处理客户余额和交收，无需等待其他券商，大大提高了清算时效性。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为适用于本申请实施例的银行账务清算方法的应用场景图；

图2为本申请实施例提供的银行账务清算方法的流程示意图；

图3为本申请实施例提供的具体的银行账务清算方法的流程示意图；

图4为本申请实施例提供的对券商进行二次清算方法的流程示意图；

图5为本申请实施例提供的结束日终清算方法的流程示意图；

图6为本申请实施例提供的银行账务清算装置的结构示意图；

图7为本申请实施例提供的电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一设备和第二设备仅仅是为了区分不同的设备，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。

需要说明的是，本申请的技术方案中，所涉及的金融数据或用户数据等信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

下面对本申请涉及到的术语进行解释：

代理银证系统：可以指的是银行处理投资者和证券公司间转账业务的重要系统，主要服务于证券公司A股业务、B股业务、股票质押融资业务转账。

日终清算：可以指的是代理银证系统日终与银行主机对账完后，将当日转账流水产生的对账文件发给券商，券商根据银行的对账文件完成对账后，将股票买卖和结息流水发给银行，银行根据券商文件进行清算的过程。

自证券登记结算制度DVP规则改革以来，券商创新应用层出不穷，银行必须加快产品创新，提高三方存管产品的先进性，由于7*24小时银证转账属于三方存管业务领域的重大创新，难以实现7*24小时银证转账。

一种可能的实现方式中，代理银证系统日终清算在证券营业日16:00停止转账，进一步的，在停止转账后，代理银证系统日终与银行主机进行行内对账，并在对账完后，将当日转账流水产生的对账文件发给所有券商，券商根据银行的对账文件完成对账后，将股票买卖和结息流水等文件发给银行，银行接到文件后，解析该文件并入库，然后核对并校验每一个客户的金额、营业部的余额、总余额，在全部核对成功后表示券商一次清算成功，进一步的，等所有券商一次清算完成后，代理银证系统将对所有券商下所有客户同时进行二次清算，并将客户当日股票买卖的金额汇总到客户在银行的保证金余额上，同时生成各个券商的交收记录。

但是，上述清算方法实时性差，进行二次清算需要等所有券商的一次清算完成，且将完成文件返回给银行后才可以处理，导致清算效率较慢。

针对上述问题，本申请提供一种银行账务清算方法，可以在券商发送完券商清算文件后，基于券商清算文件校验券商进行的一次清算是否成功，并在校验通过后，将相应的券商信息登记到日终批量更改余额控制表，进一步的，添加二次清算扫描任务，该二次清算扫描任务每隔预设时间扫描日终批量更改余额控制表，查询等待二次清算的券商信息和正在二次清算的券商个数，如果正在清算的券商个数小于预设阈值，则逐个为券商添加二次清算的任务，直到正在处理的券商个数等于预设阈值；进一步的，根据券商清算文件更新客户的保证金实时余额、日初余额和当前余额，以进行二次清算，这样，在某个券商发送完券商清算文件，一次清算成功后实时进行二次清算，处理客户余额和交收，无需等待其他券商，大大提高了清算时效性。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图1为适用于本申请实施例的银行账务清算方法的应用场景图。如图1所示，该应用场景包括：第一券商的第一终端设备101、第一券商的服务器102、第二券商的第二终端设备103、第二券商的服务器104、代理银证系统105和代理银证系统105对应的显示设备106；其中，第一券商的服务器102和第二券商的服务器104用于根据银行的对账文件进行对账，并将完成对账后的文件发给代理银证系统105。

具体的，以券商为第一券商和第二券商为例，代理银证系统105在日终与银行主机进行行内对账完后，将当日转账流水产生的对账文件发给第一券商的服务器102和第二券商的服务器104，在第一券商的服务器102和第二券商的服务器104根据银行的对账文件完成对账后，分别将股票买卖和结息流水等券商清算文件发给代理银证系统105；其中，第一券商和第二券商可以基于第一终端设备101和第二终端设备103查看对账文件以及股票买卖和结息流水等信息，本申请实施例对查看的信息不作具体限定。

进一步的，代理银证系统105在接收到第一券商的服务器102发送的券商清算文件后，根据券商清算文件校验第一券商进行一次清算的数据是否通过，并在校验通过后，即一次清算成功，将第一券商的券商信息登记到日终批量更改余额控制表中，相应的，在代理银证系统105在接收到第二券商的服务器104发送的券商清算文件后，也继续上述步骤，并将校验通过后的第二券商的券商信息登记到日终批量更改余额控制表中。

进一步的，代理银证系统105可以每十分钟扫描日终批量更改余额控制表，以查询等待二次清算的券商信息和正在二次清算的券商个数，当确定正在处理的券商个数等于阈值“2”时，可以根据券商清算文件中的客户交收金额更新到银行的保证金实时余额、日初余额和当前余额，同时要将客户的清算标志更新为已清算，用于支持重跑二次清算，进一步的，当对第一券商和第二券商均二次清算完成后，备份交收流水，并更新第一券商和第二券商的二次清算标志为已完成，结束日终。

相应的，银行人员可以基于显示设备106查看二次清算的结果以及交收流水等信息，本申请实施例对可以查看的内容不作具体限定。

需要说明的是，本申请实施例对设置阈值的大小不作具体限定，其可以基于代理银证系统105的处理性能或者应用场景进行设定，也可以人为修改，本申请实施例对此不作具体限定。

可选的，上述终端设备可以是具有显示屏并且支持网页浏览的各种电子设备，终端设备也可以被称为终端(terminal)、用户设备(User Equipment，UE)、移动台(MobileStation，MS)、移动终端(Mobile Terminal，MT)等。终端设备可以是手机(mobile phone)、智能电视、穿戴式设备、智能音箱、智能安防设备、智能网关、平板电脑(Pad)、带无线收发功能的电脑、虚拟现实(Virtual Reality，VR)终端设备、增强现实(Augmented Reality，AR)终端设备、工业控制(industrial control)中的无线终端、无人驾驶(self-driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。上述终端设备包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等。

基于图1所示的应用场景，本申请实施例还提供一种银行账务清算方法。图2为本申请实施例提供的银行账务清算方法的流程示意图。如图2所示，该银行账务清算方法包括：

S201、接收券商清算文件，并基于所述券商清算文件进行校验，以校验券商进行一次清算的数据是否通过。

本申请实施例中，券商清算文件可以包括多个客户的日终余额、多个营业部的当前余额、券商总余额以及交收金额；所述日终余额为第三方客户在一天结束时对应的最终余额；所述营业部的当前余额为第三方营业部在发送券商清算文件前对应的当前余额；一个客户对应一个营业部；所述营业部为用户提供股票买卖；所述券商总余额为所有的第三方营业部对应的当前余额之和；一个券商可以对应多个营业部和多个客户；所述交收金额为客户进行股票买卖的变动流水金额，如买入A股100元，卖出A股200元，对应交收金额为-100元和+200元。

在本步骤中，代理银证系统在接收到券商清算文件后，将客户的金额变动流水实时登记到临时表中，并根据券商清算文件校验客户余额+第三方发生额是否等于第三方此客户的最终余额、校验第三方营业部的昨日余额+今天发生额是否等于当前的余额、校验第三方昨日总余额+今天发生额是否等于当前券商总余额，校验通过后说明一次清算成功，则将该券商的券商信息登记到日终批量更改余额控制表中。

其中，所述发生额可以指的是交收金额；所述券商信息为用于表示券商身份的信息，不同的券商对应不同的券商信息，如券商信息可以为标识号信息、券商名称等，本申请实施例对此不作具体限定。

需要说明的是，本申请实施例对多个客户的日终余额、多个营业部的当前余额、券商总余额以及交收金额对应的具体数值不作限定，其基于实际情况确定。

S202、每隔预设时间，扫描日终批量更改余额控制表，确定处于正在清算状态的券商信息以及所述处于正在清算状态的券商信息对应的券商个数；所述日终批量更改余额控制表用于存储校验通过的券商清算文件对应的券商信息和对每一券商的处理状态；所述处理状态包括正在清算状态、未清算状态和清算完成状态。

本申请实施例中，预设时间可以指的是提前设定的用于扫描日终批量更改余额控制表对应的间隔时间，每隔预设时间，进行一次二次清算扫描任务，即每隔预设时间，扫描一次日终批量更改余额控制表，查询等待二次清算的券商信息和正在二次清算的券商个数，本申请实施例对预设时间对应的数值大小不作限定，其可以基于应用场景以及场景需求设置，如可以设置为10分钟。

在本步骤中，可以每十分钟扫描日终批量更改余额控制表，查询等待二次清算的券商信息和正在二次清算的券商个数，并基于券商个数的大小确定进行二次清算的券商。

S203、当确定所述券商个数等于预设阈值时，获取每一券商信息对应的客户信息，并基于所述客户信息确定每一客户的账户余额表；所述账户余额表用于存储客户在银行的保证金实时余额、日初余额和当前余额。

其中，所述保证金实时余额为客户在银行预存的保证金对应的实时余额；所述日初余额为下一天开始之前对应的客户在银行的存储余额；所述当前余额为当天结束时对应的客户在银行的最终存储余额。

本申请实施例中，预设阈值可以指的是提前设定的用于进行二次清算的券商个数，当正在处理券商个数等于预设阈值时，可以依次对券商进行二次清算，当正在处理券商个数小于预设阈值时，可以逐个为券商添加二次清算的任务，直到正在处理的券商个数等于预设阈值；而当正在处理券商个数大于预设阈值时，则添加十分钟后的轮询批处理任务，即十分钟后再次扫描日终批量更改余额控制表，查看是否有处理完的券商，进而将未处理的券商添加二次清算的任务。

可以理解的是，预设阈值对应的大小可以基于应用场景或实际情况需求确定，本申请实施例对预设阈值对应的大小不作具体限定，如预设阈值可以设置为20。

在本步骤中，如果确定处于正在清算状态的券商个数小于20，则逐个为日终批量更改余额控制表中存储的券商基于存储顺序依次添加二次清算的任务，直到正在处理的券商个数等于20；进一步的，异步处理每个券商的二次清算任务，即获取每一券商信息对应的客户信息，并基于客户信息确定每一客户在银行的保证金实时余额、日初余额和当前余额；其中，所述银行的保证金实时余额、日初余额和当前余额提前存储于账户余额表中，每一客户信息对应一个账户余额表；所述客户信息为表示客户身份的信息，每一客户对应唯一的客户信息，如客户信息可以为标识号信息、客户名称等，本申请实施例对此不作具体限定。

需要说明的是，本申请实施例对保证金实时余额、日初余额和当前余额对应的具体数值不作限定，其基于实际情况确定。

S204、基于所述券商清算文件更新每一客户的账户余额表，并基于更新后的账户余额表进行二次清算，以校验更新后的每一客户的保证金实时余额、日初余额和当前余额是否正确。

在本步骤中，券商二次清算时要根据券商清算文件中的客户交收金额更新到客户在银行的保证金实时余额、日初余额和当前余额，即实时余额＝当前时刻余额+交收金额，当前余额＝当前截止余额+交收金额，日初余额(下一日)＝当前截止余额+交收金额，同时要将客户的清算标志更新为已清算，用于支持进行二次清算，以校验更新后的每一客户的保证金实时余额、日初余额和当前余额是否正确。

进一步的，当所有券商都二次清算完成后，备份交收流水，并更新所有券商二次清算标志为已完成，结束日终清算流程。

因此，本申请实施例提供一种银行账务清算方法，使得代理银证系统可以通过实时处理券商文件且实时二次清算处理客户交收金额，提高清算效率，节省了清算时间，同时可以保证客户的资金安全，也保证了己方账务平衡。

在一种可能的设计中，所述方法还包括：

当确定所述券商个数小于预设阈值时，再次获取日终批量更改余额控制表中处于正在清算状态的券商信息，直至确定所述处于正在清算状态的券商信息对应的券商个数等于预设阈值；

当确定所述券商个数大于预设阈值时，基于所述券商信息的存储顺序处理预设阈值个处于正在清算状态的券商信息，并将在下个预设时间，处理多于预设阈值的券商信息。

本申请实施例中，存储顺序可以指的是校验券商进行一次清算成功后，将券商信息录入日终批量更改余额控制表的顺序。

示例性的，当查询到日终批量更改余额控制表处理中的处于正在清算状态的券商个数小于预设阈值20时，则逐个为日终批量更改余额控制表中处于未清算状态的券商添加二次清算的任务，直到处于正在清算状态的券商个数等于20，则进行券商二次清算任务；当查询到日终批量更改余额控制表处理中的处于正在清算状态的券商个数大于预设阈值20时，则基于券商信息的存储顺序优先处理前20个处于正在清算状态的券商信息，并添加10分钟后轮询批处理任务，即10分钟后，处理其他的券商信息。

可选的，当确定所述券商个数大于预设阈值时，可以基于所述券商信息的优先级等级信息的高低进行排序，并基于排序顺序处理预设阈值个处于正在清算状态的券商信息，并将在下个预设时间，处理多于预设阈值的券商信息；其中，所述优先级等级信息为所述券商信息优先处理的等级高低，针对特殊需求的券商，可以为券商添加优先级信息，使得优先级高的券商优先处理。

因此，本申请实施例通过确定每次进行二次清算的券商个数，使得可以及时进行券商的二次清算任务，无需等待所有券商汇总数据，极大提高的处理的实时性，缓解了统一处理所有数据时的计算压力。

在一种可能的设计中，所述券商清算文件包括：多个客户的日终余额、多个营业部的当前余额和券商总余额；基于所述券商清算文件进行校验，包括：

基于所述券商清算文件获取对应的多个客户的银行账户余额、多个客户的转账金额、多个营业部的前一日账户余额和多个营业部的当日交易发生余额；

针对每一客户和每一营业部，基于所述客户的银行账户余额和所述客户的转账金额校验所述日终余额是否正确，基于所述营业部的前一日账户余额和所述当日交易发生余额校验所述当前余额是否正确；

基于所述多个营业部的前一日账户余额和所述多个营业部的当日交易发生余额校验所述券商总余额是否正确，并将校验出现问题的客户信息存储于券商清算不平表中；每一券商总余额对应一个券商。

本申请实施例中，所述券商清算不平表用于存储券商对应的多个客户在进行一次清算校验时出现问题的客户信息，即银行与券商对账不平的用户信息。

在本步骤中，代理银证系统根据券商清算文件获取对应的多个客户的银行账户余额、多个客户的转账金额、多个营业部的前一日账户余额和多个营业部的当日交易发生余额，所述银行账户余额对应为客户余额，所述转账金额对应为第三方发生额，所述前一日账户余额对应为第三方营业部的昨日余额，所述当日交易发生余额对应为今天发生额。

进一步的，针对每一客户，校验客户的银行账户余额+转账金额是否等于日终余额，即第三方此客户的最终余额；针对每一营业部，校验前一日账户余额+当日交易发生余额是否等于当前余额，同时，校验所有营业部的前一日账户余额+今天发生总额是否等于券商总余额，即所有营业部的当前余额是否等于券商总余额；校验通过后说明券商一次清算成功，否则将校验出现问题对应的客户信息存储于券商清算不平表中。

因此，本申请实施例可以校验券商一次清算是否成功，对券商进行一次清算的数据进行验证，提高了二次清算所需数据的准确性。

在一种可能的设计中，所述方法还包括：

判断所述日终批量更改余额控制表中处于正在清算状态的券商信息对应的券商个数和所述券商清算不平表中客户信息对应的客户个数是否均为零；

当确定所述日终批量更改余额控制表和/或所述券商清算不平表中客户个数不为零时，判断券商清算状态表中每一券商对应的一次清算是否校验通过；所述券商清算状态表用于记录一次清算通过的券商信息；

若一次清算通过，则在营业时间内对所述券商清算文件进行二次清算；所述营业时间为工作日全天；

若一次清算未通过，则生成提示信息，以提醒重新提交券商清算文件。

本申请实施例中，营业时间为工作日全天24小时，在该营业时间内对券商清算文件进行二次清算包括：判断当前时间点是否在一周工作日5天的8个小时之内，如工作日每天14:00-22:00；若是，则继续扫描日终批量更改余额控制表；若否，则添加10分钟后的轮询处理任务，直至下一个工作日开始。

在本步骤中，通过查询日终批量更改余额控制表中待处理状态(未处理状态)的且券商清算不平表中是否有记录的数据；若有记录的数据，则查询券商清算状态表中是否所有券商已清算完成；若所有券商已清算完成，则判断当前时间点是否大于工作日5*8小时的营业日期，若是，则添加10分钟后的轮询处理任务，若否，则查询日终批量更改余额控制表处理中的数据，并基于该数据进行二次清算；若没有记录的数据或存在券商没有清算完成，则添加10分钟后的轮询处理任务。

其中，添加10分钟后的轮询处理任务，是为了方便券商重新提交券商清算文件；由于一次清算未通过，说明券商和银行对账不平，则可以生成提示信息，以提醒券商核对提交的券商清算文件，并查找券商清算文件中的问题进行修改，进而重新提交修改后的券商清算文件，本申请实施例对提示信息的内容和发送形式不作具体限定，其内容可以为“用户1的交易流水存在问题”，发送形式可以为以短消息的方式发送到券商的终端设备上。

因此，本申请实施例针对一次清算未通过的券商信息，还可以等待其重新提交券商清算文件，并以重新提交券商清算文件进行一次清算校验以及二次清算，提高了数据清算的成功率。

在一种可能的设计中，所述方法还包括：

获取所述券商清算状态表中的第一券商数量和所述日终批量更改余额控制表中处于清算完成状态的券商信息的第二券商数量；

基于所述第一券商数量和所述第二券商数量确定二次清算是否完成；

当所述第一券商数量和所述第二券商数量一致时，基于所述日终批量更改余额控制表生成交收记录；

当所述第一券商数量和所述第二券商数量不一致时，继续扫描日终批量更改余额控制表。

本申请实施例中，所述交收记录可以指的是二次清算过的各个券商的交易流水记录，本申请实施例对交收记录对应的具体内容不作限定，其可以包括转账记录、账户余额等信息。

在本步骤中，查询券商清算状态表中清算完成券商与日终批量更改余额控制表中处理完成券商数量是否一致；若一致，则校验所有券商是否完成清算并更新券商清算总控表中清算完成标志为完成，并基于日终批量更改余额控制表生成交收记录，以及更新券商清算总控表生成交收记录的标志为完成；若不一致，则添加10分钟后的轮询批处理任务；其中，所述券商清算总控表用于记录不同日期的所有券商完成二次清算的数据，即一天内所有券商完成二次清算对应一条数据，所述券商清算总控表包括多个日期的所有券商完成二次清算的数据。

因此，本申请实施例可以基于券商清算状态表中第一券商数量与日终批量更改余额控制表中第二券商数量确定券商的二次清算是否完成，准确判断出所有券商的二次清算是否完成，提高券商二次清算的准确性。

在一种可能的设计中，基于所述券商清算文件更新每一客户的账户余额表，包括：

获取所述券商清算文件对应的券商信息、币种和借贷标志，并在券商清算资金汇总表中删除所述券商信息对应的券商数据；所述券商清算资金汇总表用于存储所有券商信息对应的券商数据；所述券商数据用于更新账户余额表；

基于所述券商信息、所述币种和所述借贷标志确定每一客户的交收金额，并基于所述交收金额更新每一客户的账户余额表。

本申请实施例中，所述币种可以指的是货币类型，如人民币、美元等；所述借贷标志可以指的是购买和卖出的标记，如购买100元，借贷标志为-，卖出100元，借贷标志为+等，本申请实施例对借贷标志对应的标识类型不作限定，还可以用字母、符号等表示，如“a、b”表示，a表示购买，b表示卖出。

在本步骤中，在对日终批量更改余额控制表中的处于正在清算状态的券商信息进行二次清算时，删除处于正在清算状态的券商信息在券商清算资金汇总表中对应的券商数据，以便重复执行；进一步的，按照券商信息、币种、借贷标志统计券商单户结息的交收数据，即交收金额，如-100元，+200元等；并将借贷标志取反后插入券商清算资金汇总表，市场类型为“Z”，资金类型为“3”，进一步的，基于交收金额更新每一客户的账户余额表。

其中，所述借贷标志取反可以指的是将借贷标志转换为统一的标准类型，如均转换为“+、-”表示；所述市场类型和所述资金类型为提前定义的，用于区分股票交易类型，便于后续的查询，如某个资金类型为“3”对应的交易均为A股交易，则可以基于资金类型“3”查询到A股交易的记录，本申请实施例对市场类型和资金类型对应的股票交易类型不作具体限定，以上仅是示例说明。

因此，本申请实施例基于券商清算文件更新每一客户的账户余额表时，可以删除券商信息对应的券商数据，防止重复处理该券商信息，减少冗余处理，提高了更新的速率。

在一种可能的设计中，基于所述交收金额更新每一客户的账户余额表，包括：

获取每一客户的对账不平表，并确定所述对账不平表中是否存在数据；所述对账不平表用于存储校验出现问题的客户信息对应的保证金实时余额、日初余额和当前余额；

当确定每一客户的对账不平表中不存在数据时，获取每一客户的当前时刻余额和当前截止余额，利用所述当前时刻余额和所述交收金额更新所述保证金实时余额，利用所述当前截止余额和所述交收金额更新所述当前余额，以及利用所述当前余额更新下一日的日初余额；

当确定每一客户的对账不平表中存在数据时，基于所述校验出现问题的客户信息对应的保证金实时余额、日初余额和当前余额，利用预定义算法计算所述对账不平表对应的差额，并基于所述差额更新每一客户的账户余额表。

本申请实施例中，预定义算法为提前定义的用于计算券商清算文件与银行交易数据之间差额的算法，如券商核对的券商清算文件中券商总余额为10万元，但是银行二次清算得到的券商总余额应为11万元，则基于预定义算法计算二者差额为1万元；本申请实施例对预定义算法不作具体限定，其还可以为加权减法等。

在本步骤中，当确定每一客户的对账不平表中存在数据时，根据券商清算中对账不平表中的差额更新保证金账户清算临时表中的差额信息；当确定每一客户的对账不平表中不存在数据时，根据保证金账户清算临时表中篮子号开始循环更新账户余额表，进而按照篮子号更新账户余额表中的日初余额、实时余额、当前余额；其中，篮子号为存储用户信息对应的交收金额的表的标识号，一个用户信息对应一个篮子号。

具体的，基于交收金额更新每一客户的账户余额表，包括利用当前时刻余额和交收金额更新保证金实时余额，利用当前截止余额和交收金额更新当前余额，以及利用当前截止余额和交收金额更新下一日的日初余额。

其中，所述保证金账户清算临时表用于存储各个券商的券商数据，如券商信息、币种和借贷标志，以及每个券商信息对应的各个客户的交收金额、日初余额、实时余额、当前余额、交收记录数以及差额信息等；所述差额信息为特定字段，可以反馈给券商进行数据修正。

因此，本申请实施例可以针对校验出现问题的客户信息对应的保证金实时余额、日初余额和当前余额进行更新，以提醒券商出现问题并及时修正，提高二次清算的稳定性。

在一种可能的设计中，基于所述差额更新每一客户的账户余额表，包括：

分别获取保证金账号清算临时表和日终更改余额状态表中的记录数；所述保证金账号清算临时表中的记录数为各个券商对应的客户的交收记录数；所述日终更改余额状态表中的记录数为更新账户余额表后的客户个数或客户进行交易记录的个数；

基于所述记录数确定所述日终批量更改余额控制表中券商是否更新成功。

本申请实施例中，所述日终更改余额状态表用于存储篮子号、零金额记录数、非零金额记录数、总记录数以及更新记录数；所述零金额记录数可以指的是没有金额交易的记录数，如买入100元，卖出100元，对应零金额记录数，相应的，非零金额记录数可以指的是有金额交易的记录数；金额记录数+非零金额记录数＝总记录数；所述更新记录数可以指的是更新账户余额表的记录数；本申请实施例对零金额记录数、非零金额记录数、总记录数以及更新记录数对应的具体数值不作限定，其基于实际情况确定。

在本步骤中，在按照篮子号更新账户余额表中的日始余额、实时余额、当前余额后，相应的，会在日终更改余额状态表插入一条记录，包括篮子号，零金额记录数，非零金额记录数，总记录数，更新记录数；进一步的，判断此券商的日终更改余额状态表中总记录数或更新记录数和保证金账号清算临时表中记录数是否一致；若一致，则将日终批量更改余额控制表中状态更新为完成，表示券商更新成功；若不一致，则将日终批量更改余额控制表中状态更新为失败，表示券商更新失败。

因此，本申请实施例可以基于保证金账号清算临时表和日终更改余额状态表中的记录数确定券商是否更新成功，提高券商更新的准确性。

在一种可能的设计中，所述方法还包括：

在基于所述券商清算文件更新每一客户的账户余额表之前，将所述券商清算文件与所述账户余额表对应的客户数量进行比对，以查找是否存在未进行一次清算的客户信息；

当确定存在未进行一次清算的客户信息后，基于所述账户余额表进行二次清算。

本申请实施例中，由于可能存在券商没有清算的交易流水数据，使得券商清算文件与账户余额表对应的客户数量不等，则代理银证系统需要对该交易流水数据进行清算。

在本步骤中，当确定存在未进行一次清算的客户信息后，即在循环篮子号更新账户余额表中的当日的日始余额不等于当前余额的记录，将日始余额改为当前余额，并根据差额更新实时余额。

因此，本申请实施例可以查找到券商没有进行清算的数据，但可以进行二次清算，查漏补缺，提高二次清算的完整性，减少数据遗漏。

结合上述实施例，图3为本申请实施例提供的具体的银行账务清算方法的流程示意图，如图3所示，所述银行账务清算方法包括如下步骤：

步骤A：查询日终批量更改余额控制表中是否存在待处理状态(正在清算状态)的且券商清算无问题的数据，若存在数据，则执行步骤B；否则，则执行步骤C。

其中，每个券商一次清算校验通过后向日终批量更改余额控制表中添加的一条待处理数据，故日终批量更改余额控制表用于存储校验通过的券商清算文件对应的券商信息和对每一券商的处理状态。

步骤B：查询日终批量更改余额控制表处理中的数据是否超过20条；若是，则执行步骤D；否则，添加券商更新余额批处理任务(二次清算的任务)，并执行步骤C。

步骤C：查询日终批量更改余额控制表中是否存在待处理状态的且券商清算不平表有记录的数据，若存在数据，则执行步骤E；否则，则执行步骤D。

步骤D：添加十分钟后的轮询批处理任务，即10分钟后再次执行步骤A。

步骤E：查询券商清算状态表中是否所有券商已二次清算完成，若是，则执行步骤F；否则，则执行步骤D。

步骤F：判断当前时间点是否大于5*8营业日期22:00，若是，则执行步骤G；否则，则执行步骤D。

步骤G：查询日终批量更改余额控制表中正在处理的数据(处于正在清算状态的券商)是否超过20条，若是，则执行步骤D；否则，添加券商更新余额批处理任务，并执行步骤H。

其中，如果存在多个清算完成但存在不平记录的券商，则循环添加更新余额批处理任务，且每次添加前都判断正在处理的是否超过20个任务。

步骤H：查询券商清算状态表中二次清算完成券商与日终批量更改余额控制表中处理完成券商(处于清算完成状态的券商)数量是否一致；若一致，则校验所有券商是否完成清算并更新券商清算总控表的清算完成标志为完成，以及更新券商清算总控表生成交收记录的标志为完成；若不一致，则执行步骤D。

上述银行账务清算方法包括二次清算，图4为本申请实施例提供的对券商进行二次清算方法的流程示意图，如图4所示，所述二次清算方法包括如下步骤：

步骤1：判断此券商在日终批量更改余额控制表中状态是否为处理中(正在清算状态)；若是，则执行日终清算流程；若否，则将日终批量更改余额控制表中状态更新为处理中，并删除券商清算资金汇总表中此券商数据，以便重复执行；进一步的，按照券商、币种、借贷标志统计券商单户结息的交收数据，并将借贷标志取反后插入券商清算资金汇总表，市场类型为“Z”，资金类型为“3”；进一步的，根据券商清算中对账不平表中的差额更新保证金账户清算临时表中的差额信息，并根据保证金账户清算临时表篮子号开始循环更新账户余额表，以及更新保证金账户清算临时表此条数据更新标志为1；相应的，按照篮子号更新账户余额表中的日初余额、实时余额、当前余额、最后更新日期，并计数，以及往日终更改余额状态表插入一条记录，包括篮子号，零金额记录数，非零金额记录数，总记录数，更新记录数，使得可以判断此券商日终更改余额状态表和保证金账号清算临时表中记录数是否一致；若一致，则执行步骤2，若不一致，则执行步骤3。

步骤2：循环篮子号更新账户余额表中的当日的日始余额不等于当前余额的记录，并将日始余额改为当前余额，以及根据差额更新实时余额，进一步的，将日终批量更改余额控制表中状态更新为完成，次数加1。

步骤3：将日终批量更改余额控制表中状态更新为失败，次数加1。

需要说明的是，上述流程中计数和次数加1的目的是为了方便记录和查询。

其中，所述日终清算流程可以定时23:00运行，本申请实施例对日终清算流程的运行时间不作具体限定，图5为本申请实施例提供的结束日终清算方法的流程示意图，如图5所示，该结束日终清算方法包括如下步骤：

步骤a：查询日终更改余额状态表中券商数是否等于分组表中券商数；若是，更新券商清算状态表中账户余额变更标志为完成，并执行步骤b；若否，则执行步骤c。

其中，所述分组表为每个券商对应的表，在本申请中将日终更改余额状态表中券商分为多个表，对应分组表。

步骤b：判断日终更改余额状态表中保证金账号处理的数目和保证金账号清算临时表中记录数是否一致；若是，则更新A股清算表(券商清算状态表)中其他保证金余额标志为已更改，并更新券商第二次清算完成标志为已完成；进一步的，备份券商清算临时表中交收数据到流水表中，并检查A、B股日终是否完成，完成则更新平台状态为初始态；若否，则执行步骤c。

步骤c：报错，以生成警告信息，以提醒批处理执行失败。

需要说明的是，A股进行二次清算流程，B股可以不进行二次清算流程，本申请实施例对此不作具体限定。

因此，本申请提供的银行账务清算方法，可以实时进行二次清算，无需等待其他券商的一次清算完成，大大提高了清算的时效性。

在前述实施例中，对本申请实施例提供的银行账务清算方法进行了介绍，而为了实现上述本申请实施例提供的方法中的各功能，作为执行主体的电子设备可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。

例如，图6为本申请实施例提供的银行账务清算装置的结构示意图，如图6所示，该装置包括：接收模块601，扫描模块602，确定模块603和二次清算模块604；其中，所述接收模块601，用于接收券商清算文件，并基于所述券商清算文件进行校验，以校验券商进行一次清算的数据是否通过；

所述扫描模块602，用于每隔预设时间，扫描日终批量更改余额控制表，确定处于正在清算状态的券商信息以及所述处于正在清算状态的券商信息对应的券商个数；所述日终批量更改余额控制表用于存储校验通过的券商清算文件对应的券商信息和对每一券商的处理状态；所述处理状态包括正在清算状态、未清算状态和清算完成状态；

所述确定模块603，用于当确定所述券商个数等于预设阈值时，获取每一券商信息对应的客户信息，并基于所述客户信息确定每一客户的账户余额表；所述账户余额表用于存储客户在银行的保证金实时余额、日初余额和当前余额；

所述二次清算模块604，用于基于所述券商清算文件更新每一客户的账户余额表，并基于更新后的账户余额表进行二次清算，以校验更新后的每一客户的保证金实时余额、日初余额和当前余额是否正确。

在一种可能的设计中，所述装置还包括处理模块，所述处理模块，用于：

当确定所述券商个数小于预设阈值时，再次获取日终批量更改余额控制表中处于正在清算状态的券商信息，直至确定所述处于正在清算状态的券商信息对应的券商个数等于预设阈值；

当确定所述券商个数大于预设阈值时，基于所述券商信息的存储顺序处理预设阈值个处于正在清算状态的券商信息，并将在下个预设时间，处理多于预设阈值的券商信息。

在一种可能的设计中，所述券商清算文件包括：多个客户的日终余额、多个营业部的当前余额和券商总余额；所述接收模块601，具体用于：

基于所述券商清算文件获取对应的多个客户的银行账户余额、多个客户的转账金额、多个营业部的前一日账户余额和多个营业部的当日交易发生余额；

针对每一客户和每一营业部，基于所述客户的银行账户余额和所述客户的转账金额校验所述日终余额是否正确，基于所述营业部的前一日账户余额和所述当日交易发生余额校验所述当前余额是否正确；

基于所述多个营业部的前一日账户余额和所述多个营业部的当日交易发生余额校验所述券商总余额是否正确，并将校验出现问题的客户信息存储于券商清算不平表中；每一券商总余额对应一个券商。

在一种可能的设计中，所述装置还包括判断模块，所述判断模块，用于：

判断所述日终批量更改余额控制表中处于正在清算状态的券商信息对应的券商个数和所述券商清算不平表中客户信息对应的客户个数是否均为零；

当确定所述日终批量更改余额控制表和/或所述券商清算不平表中客户个数不为零时，判断券商清算状态表中每一券商对应的一次清算是否校验通过；所述券商清算状态表用于记录一次清算通过的券商信息；

若一次清算通过，则在营业时间内对所述券商清算文件进行二次清算；所述营业时间为工作日全天；

若一次清算未通过，则生成提示信息，以提醒重新提交券商清算文件。

在一种可能的设计中，所述装置还包括数量比对模块，所述数量比对模块，用于：

获取所述券商清算状态表中的第一券商数量和所述日终批量更改余额控制表中处于清算完成状态的券商信息的第二券商数量；

基于所述第一券商数量和所述第二券商数量确定二次清算是否完成；

当所述第一券商数量和所述第二券商数量一致时，基于所述日终批量更改余额控制表生成交收记录；

当所述第一券商数量和所述第二券商数量不一致时，继续扫描日终批量更改余额控制表。

在一种可能的设计中，所述二次清算模块604包括获取单元和更新单元；

具体的，所述获取单元，用于获取所述券商清算文件对应的券商信息、币种和借贷标志，并在券商清算资金汇总表中删除所述券商信息对应的券商数据；所述券商清算资金汇总表用于存储所有券商信息对应的券商数据；所述券商数据用于更新账户余额表；

所述更新单元，用于基于所述券商信息、所述币种和所述借贷标志确定每一客户的交收金额，并基于所述交收金额更新每一客户的账户余额表。

在一种可能的设计中，所述更新单元包括确定单元、第一更新单元和第二更单元；

具体的，所述确定单元，用于获取每一客户的对账不平表，并确定所述对账不平表中是否存在数据；所述对账不平表用于存储校验出现问题的客户信息对应的保证金实时余额、日初余额和当前余额；

所述第一更新单元，用于当确定每一客户的对账不平表中不存在数据时，获取每一客户的当前时刻余额和当前截止余额，利用所述当前时刻余额和所述交收金额更新所述保证金实时余额，利用所述当前截止余额和所述交收金额更新所述当前余额，以及利用所述当前余额更新下一日的日初余额；

所述第二更新单元，用于当确定每一客户的对账不平表中存在数据时，基于所述校验出现问题的客户信息对应的保证金实时余额、日初余额和当前余额，利用预定义算法计算所述对账不平表对应的差额，并基于所述差额更新每一客户的账户余额表。

在一种可能的设计中，所述第二更新单元，具体用于：

分别获取保证金账号清算临时表和日终更改余额状态表中的记录数；所述保证金账号清算临时表中的记录数为各个券商对应的客户的交收记录数；所述日终更改余额状态表中的记录数为更新账户余额表后的客户个数或客户进行交易记录的个数；

基于所述记录数确定所述日终批量更改余额控制表中券商是否更新成功。

在一种可能的设计中，所述装置还包括查找模块，所述查找模块，用于：

在基于所述券商清算文件更新每一客户的账户余额表之前，将所述券商清算文件与所述账户余额表对应的客户数量进行比对，以查找是否存在未进行一次清算的客户信息；

当确定存在未进行一次清算的客户信息后，基于所述账户余额表进行二次清算。

本申请实施例提供的银行账务清算装置的具体实现原理和效果可以参见上述实施例对应的相关描述和效果，此处不做过多赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。各模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上各模块的功能。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

图7为本申请实施例提供的电子设备的结构示意图。如图7所示，该电子设备可以包括：收发器701、处理器702、存储器703。

处理器702执行存储器存储的计算机执行指令，使得处理器702执行上述实施例中的方案。处理器702可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

存储器703通过系统总线与处理器702连接并完成相互间的通信，存储器703用于存储计算机程序指令。

收发器701可以用于接收券商清算文件。

系统总线可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。收发器用于实现数据库访问装置与其他计算机(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(RandomAccess Memory，RAM)，也可能还包括非易失性存储器(Non-Volatile Memory，NVM)。

本申请实施例提供的电子设备，可以是上述实施例的代理银证系统。

本申请实施例还提供一种运行指令的芯片，该芯片用于执行上述实施例中银行账务清算方法的技术方案。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，当该计算机执行指令在计算机上运行时，使得计算机执行上述实施例中银行账务清算方法的技术方案。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，其存储在计算机可读存储介质中，至少一个处理器可以从计算机可读存储介质读取计算机程序，至少一个处理器执行计算机程序时可实现上述实施例中银行账务清算方法的技术方案。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例方法的部分步骤。

应理解，上述处理器可以是中央处理单元(Central Processing Unit，简称CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，简称ISA)总线、外部设备互连(Peripheral Component Interconnect，简称PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，简称EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(Static Random-Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-OnlyMemory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电控单元或主控设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。