实时业务

关键词： 支付 业务 平台 数字

实时业务（精选八篇）

实时业务 篇1

不久前, 支持银行数字支付的clear Xchange平台发出公告:2016年, 网络平台将为持有银行账户的美国消费者提供实时支付功能。clear Xchange平台在公告中称, 所有使用该平台的机构, 包括美国六大行中的五间银行和一些区域性金融机构, 他们的客户将可以享有实时支付业务。

该网络平台搭建于2011年, 由美国银行、Capital One、摩根大通和富国银行共同运营。借助该平台, 银行能为客户提供个人对个人、商家对消费者以及政府对消费者的支付功能。

关注实时支付欺诈

安全专家警告道, 越来越快捷的支付方式会带来新的安全风险。“越快捷的支付方式意味着欺诈行为发展越快, ”Ontrack是一家专注于创新支付方式的公司, 其公司咨询部的主管汤姆·威尔斯 (Tom Wills) 认为, “银行现行的许多反欺诈方法和流程都是人为监管, 容易出现支付交易延迟的现象。”

威尔斯注意到, 相对缓慢的支付流程能留给机构更充裕的时间来检测并应对可能存在的欺诈行为。然而, 墨西哥、瑞典、新加坡和英国的银行客户在享受越来越高效快捷的支付方式的同时, 由此引发欺诈数量的激增也带来不少担忧。

Aite咨询公司的金融欺诈研究专家雪莉·英斯科 (Shirley Inscoe) 表示, 长期以来, clear Xchange平台的防欺诈措施比大部分金融机构的应对措施都更有力。经过欺诈筛查, 在批处理的情况下, 一天至多会出现两例欺诈。

“clear Xchange平台需要客户注册并搜集客户的相关信息, 包括他们的网上会议内容等, ”英斯科表示, “因活跃于该平台的也就只有少数几家银行, 因此我敢肯定:欺诈是有相关性的。所以, 这几家银行应一起合作, 打击任何企图欺诈的行为。另外, 在过去两年里, 美联储一直在收集如何安全使用实时支付的反馈信息。Clear Xchange实时支付平台可能会成为美联储的测试案例。美联储的项目组将把从clear Xchange上了解到的内容运用到他们的计划制定中去。其中, 富国银行不仅是clear Xchange的运营者, 也是美联储项目组的团队之一, 所以相关技术也将得到共享。”

Nice Actimize安全问题解决公司的高级主管和欺诈研究执行顾问玛丽·安·米勒 (Mary Ann Miller) 也是反洗黑钱专家。她表示, 基础设施、现行自动清算系统的限制以及各类庞大的支付交易, 是美国推行实时支付所面临的独特挑战。米勒认为, 美国要想紧随市场全球化的步伐, 就得推出越来越快捷的付方式。

实时支付平台的运作

clear Xchange平台的实时支付功能并不局限于运营该平台的银行, 也同样适用于其他非线上的银行。

此外, 尽管clear Xchange尚未在公告中阐明该系统是如何运行实时支付业务的, 但在亚特兰大联邦储备银行举行的零售支付风险论坛上, 支付风险研究专家大卫·洛特 (David Lott) 表示, 该平台允许非成员机构和成员机构之间进行实时交易, 部分交易可能会通过ACH网络进行, 而不是在封闭式的clear Xchange平台上进行。再看, 商务交易风险的总体问题不在于财务交易, 而在于包含信息要求的交易, 例如客户在某业务上的账号、采购订单或支付控制信息等。

部分安全专家称, 支付前对所有信息进行验证和核查也是一大挑战, 尤其是通过ACH开放型网络进行的交易。若要成功付款, 只需用户的一个邮箱地址或手机号码, 资金就会借助封闭式的clear Xchange系统或ACH网络直接发送到某张支票或储蓄账户上。该平台于6月15日发出的公告称, “超过1亿的网上银行客户已通过他们的网银平台接入clear Xchange平台, 而其他客户也能借助其平台的网站连接到服务器上。”

应对实时支付风险

“任何创新的支付方式都会助长欺诈的风险, ”米勒说, “我们也对全球其他更快捷的支付方式进行了观察, 欺诈分子会把在线网站门户看作是一家赌场。一旦欺诈拉响, 账户收购和网络攻击就会增多。另外, 这一形式的欺诈发生时间短, 波及范围广。若只是简单地推出更快捷的支付方式, 不谨慎制定防欺诈风险计划, 只会把一切打回原形, 落得用户体验差的下场。”

实时业务 篇2

(试行)

(商业银行讨论稿3．0)第一章 总 则

第一条 为规范武汉电子支付系统(以下简称‚本系统‛)的业务处理，确保本系统高效、安全、稳定运行，加速资金周转，防范支付风险，依据《支付结算办法趴《湖北辖内支付密码系统业务管理办法》(暂行)及有关制度的规定，制定本办法。

第二条 本系统实时业务实行逐笔实时处理，定时批量净额轧差清算资金。

第三条 经中国人民银行武汉分行营业管理部(以下简称‚营管部‛)批准，通过本系统办理支付业务的银行、城市信用合作社、农村信用合作社、邮政储汇局(以下简称银行)以及系统运行者，适用本办法。

第四条 本系统参与者分为直接参与者和间接参与者。

直接参与者是指直接与本系统数据处理中心(以下简称 ‚DPC‛)连接并在中国人民银行开设清算账户的银行机构以及中国人民银行地市以上中心支行(库)。

间接参与者是指未在中国人民银行开设清算账户而委托直接参与者办理资金清算的银行和非银行金融机构以及中国人民银行县(市)支行(库)。第五条 清算账户是指本系统的直接参与者在中国人民银行开设的用于资金清算的存款账户。

第六条 本办法所规定的业务包括本系统实时支付业务以及本办法规定的其他业务。

本系统处理的银行发起的支付业务，其支付信息从发起行发起，经发起清算行、DPC、接收清算行，至接收行止。

发起行是向发起清算行提交支付业务的间接参与者。

发起清算行是向本系统提交支付信息并开设清算账户的直接参与者。

DPC是接收、转发支付信息，并进行资金清算的机构。

接收清算行是向接收行转发支付信息并开设清算账户的直接参与者。

接收行是从接收清算行接收支付信息的间接参与者。第七条 在通过本系统办理业务的代理关系中，发起行为接收行的代理行，接收行为发起行的被代理行。

第八条 支付信息由纸凭证转换为电子信息，或由电子信息转换为纸凭证，具有同等的支付效力。

支付信息由纸凭证转换为电子信息，电子信息产生支付效力，纸凭证失去支付效力；电子信息转换为纸凭证，纸凭证产生支付效力，电子信息失去支付效力。

第九条 营管部对本系统实时业务实行统一管理，对本系统的运行及其参与者进行管理和监督。第二章 业务处理原则

第十条 本系统处理的支付业务的收付款银行账户仅限于单位银行结算账户和个人银行结算账户。第十一条本系统业务分为对公业务和个人业务。

对公业务是指付款账户为单位银行结算账户的业务。

个人业务是指付款账户为个人银行结算账户的业务。第十二条本系统受理银行在受理业务时应按规定对票据和结算凭证进行审查。

第十三条个人结算账户通过本系统转账支付的款项，视同现金按规定由付款银行进行登记报备。

第十四条付款银行在办理单位银行结算账户通过本系统处理的支付业务时，必须确认收付款人签订的付款协议或付款人签发的支付密码的有效性。

第十五条付款银行在办理个人银行结算账户通过本系统处理的支付业务时，必须确认收付款人签订的付款协议的有效性或付款人的取款密码与存折、银行卡等介质同时有效并一致。

第十六条除办理依据付款协议付款的支付业务以外，单位银行结算账户的存款人在与开户银行必须约定使用支付密码办理各种支付结算业务后，方可通过本系统办理各种收、付款业务。在业务办理中，必须按规定使用支付密码。第十七条除办理依据付款协议付款的支付业务以外，个人银行结算账户的存款人可在开户银行允许的业务范围内，通过本系统办理各种收、付款业务。在业务办理中，必须将存折或银行卡等介质与取款密码同时使用。

个人银行结算账户的存款人也可比照单位银行结算账户存款人与开户银行约定使用支付密码，签订有关协议，通过本系统办理单位银行结算账户有关的支付结算业务。第十八条存款人与银行约定使用支付密码通过本系统办理业务的，必须对是否凭有效的支付密码作为银行办理支付的唯一依据

以及双方相应的责任义务予以明确约定。

第十九条银行在受理通过本系统处理的个人支付业务时，必须采用具有加密功能的密码键盘对客户密码进行加密处理，以保障个人密码的安全性。

第二十条支付业务信息在发起方与DPC，以及接收方与DPC之间传递，须符合营管部规定的信息格式，并按照规定编核本系统同城密寸甲。加编有本系统同城密寸甲的业务信息方为有效信息。

本系统同城密寸甲由营管部负责管理。

第二十一条 直接参与者通过本系统办理业务，应按规定支付费用、享有收益。

第二十二条 系统参与者受理本系统有关业务，应使用营管部规定的专用凭证和专用业务印章。专用凭证由营管部统一印制，各参与者应根据业务性质和管 理要求分别按重要空白凭证和普通凭证进行管理。第二十三条 营管部可根据防范风险和管理的需要，对直接参与者所能发起及接收的各类业务实施控制。

各直接参与者应可根据需要，对在本机构开设的存款账户所能办理的业务种类实行控制管理。

第二十四条 本系统运行工作日的起止时间由营管部统一规定。营管部根据需要可以调整运行工作日时间。

第三章 业务处理规定

第二十五条 本系统实时处理下列业务：

(一)同城实时贷记支付业务。包括转账支票委托付款业务、银行本票委托付款业务、直接贷记业务、委托收款划回业务、同城特约委托收款划回业务、个人贷记转账业务。(二)同城实时借记支付业务。包括转账支票委托收款业务、银行本票业务、个人借记转账业务。

(三)对公通存通兑业务。包括转账银行本票通存通兑业务、现金银行本票通兑业务、转账支票通存通兑业务、现金支票通兑业务、现金通存业务。

(四)个人通存通兑业务。个人转账业务通存通兑业务、个人现金业务通存业务、个人现金通兑业务。

(五)跨行委托汇兑业务。包括单位跨行委托汇兑业务和个人跨行委托汇兑业务。(六)实时贷记抹账业务。(七)营管部规定的其他业务。

第二十六条 营管部可根据管理需要对不同支付业务规定相应的交易金额限制，并通过DPC实施控制。

第二十七条 使用现金支票跨行支取现金的，单一账户每日累计支取现金不得超过3次，每次支取金额不得超过人民币10000元。

使用存折或银行卡跨行支取现金的，单一账户每日累计支取现金不得超过3次，每次支取金额不得超过人民币5000元。

第二十八条 通过本系统办理各类业务的凭证上的收款人名称、付款人名称应使用其法定名称，名称为单位名称的，也可使用规范化简称。

收付款人名称必须与对应账号相符一致。

第二十九条 通过本系统办理的票据业务，其业务发起时间应在票据提示付款期内。

第三十条通过本系统办理银行本票业务，其受理银行为票据的付款银行或代理付款银行。提示付款时，持票人为单位的，应按规定在票据背面‚持票人向银行提示付款签章‛处签章；个人持票人凭注明‚现金‛字样的银行本票向银行支取现金的，除应按规定在票据背面‚持票人向银行提示付款签章‛处签章外，还应在票据背面记载本人身份证件名称、号码及发证机关，并交验本人身份证件及其复印件。

第三十一条 通过本系统办理支票业务，可由出票人或持票人到银行办理。

转账支票的出票人到银行办理委托付款的，受理银行为付款银行或代理付款银行。

转账支票的持票人到付款银行办理提示付款的，应按规定在票据背面背书人签章栏签章；到收款银行、或收付款银行以外的其他银行办理委托收款的，应作委托收款背书。

现金支票的持票人到银行办理提示付款的，受理银行为付款银行或代理付款银行。持票人应在票据背面‚收款人签章‛处签章，持票人为个人的还应在票据背面记载本人身份证件名称、号码及发证机关，并交验本人身份证件及其复印件。

第三十二条 发起清算行与DPC、接收清算行与DPC之间发送和接收支付业务信息，应采取联机方式实时处理。出现联机中断的，应及时恢复，当日不能恢复的，必须在日终时采用磁介质方式与DPC核对当日已发生的所有业务。第三十三条 发起行(发起清算行)受理业务后应及时向本系统发送支付业务信息；DPC收到支付业务信息后，应及时转发；接收行(接收清算行)应及时处理并向DPC反馈处理结果。

交易(业务)失败的，DPC应及时向相关各参与者发送失败结果；交易(业务)成功的，DPC应及时向相关各参与者发送成功结果，并以此作为是否纳入清算的标志。

第三十四条 发起行(发起清算行)发起交易后未收到DPC回应结果的，可及时向DPC查询该笔业务的状态。

有查询回应结果的，根据其进行相应处理；无查询回应结果 的，受理银行应留下客户地址及联系方式，暂时留置相关凭证和 现金，向客户出具待处理交易滞留证明。是个人业务的，还应将 存折、银行卡退交客户。

客户应俟后凭待处理交易滞留证明到受理银行续办业务。

银行根据确定的交易结果，收回待处理交易滞留证明后，分 别情况进行处理。

第三十五条 银行在签发银行本票时必须由签发行编制支付密码并按要求记载在银行本票正面。支付密码的编码要素包括出票日期、金额、业务种类、凭证号码、签发行行号(代付款账号)。受理银行在受理银行本票时一律通过本系统或行内业务系统查 验银行本票上支付密码的有效性。银行本票的受理时间与本系统 银行本票业务受理时间一致。

第三十六条 参与者对有疑问或发生差错的支付业务，应在当日 至迟次日12：00前发出查询。查复行应在收到查询信息的当日至

迟次日12：00前予以查复。

查询查复行及系统各节点应建立查询查复登记簿，并对查询 查复信息进行配对管理。

第三十七条 付款银行认为受理银行末按规定对票据和结算凭证进行审查的，应自业务发生之日起三个运行工作日内，通过本系统向受理银行发出查询，明确告知其未按规定审查的详细情形，受理银行应及时查复。未按规定时间向受理银行发出查询的，视作付款银行对受理银行的审查无异议。

第三十八条 委托汇兑业务受理成功后，受理行对汇款人不再承 担查询责任。汇款人如有疑问或汇款出现异常情况，由汇款人开 户银行负责解决。

第三十九条 发起行对发起的实时支付业务不能撤销。第四十条发起行对因自身原因误发实时贷记支付业务的，可向 接收行发送实时贷记抹账业务请求。实时贷记抹账业务的发起必 须经过相应授权。接收行收到发起行的抹账请求后，应立即检查 是否打印收账通知、接收人账户资金情况，能够支付的，即时办 理抹账。否则，退回抹账请求，有关业务的处理由发起行与有关 当事人协商解决。

第四十一条 客户办理本系统有关业务不能成功时，受理银行应 将不能成功的业务理由或其他理由告知客户。

业务理由是指受理银行、收款银行、付款银行所作的拒绝理 由。

其他理由是指受理银行、收款银行、付款银行以及DPC因拒 绝理由以外的原因导致业务不能成功的理由。第四十二条 银行通过本系统对接收的有关业务做拒绝处理时，应按本办法规定的种类，作出与所拒绝业务相匹配的拒绝理由。对涉及票据的实时借记转账和通兑业务的拒绝理由即为该 票据的退票理由，由受理银行代付款银行以交易失败证明形式告 知客户。

第四十三条 本系统实时业务处理拒绝理由包括：(一)收款账号不存在(二)付款账号不存在(三)收款账号户名不符(四)付款账号户名不符(五)付款账户存款不足(六)支付密码错误(七)无此凭证号码(八)账户冻结

(九)已挂失／依法止付(十)银行本票金额不符(十一)银行本票出票日期不符(十二)取款密码错误(十三)磁条信息不符

(十四)收账通知已打印无法抹账

第四十四条 本系统实时业务处理不能成功的其他理由包(一)金额超限额(二)交易超时(三)接收行未注册

(四)账号与账户类型不符无法识别(五)交易币种不存在或未开通此币种交易(六)手续费计算错误

(七)收款账户未开通此类业务(八)付款账户未开通此类业务，(九)收款行未开通此类业务(十)付款行未开通此类业务(十一)受理行未开通此类业务

(十二)收款控制(收款银行被控制收款)(十三)付款控制(付款银行被控制付款)(十四)收款行系统故障(十五)付款行系统故障

第四十五条 通过本系统处理的各种业务凭证应按要求加盖‚武汉电子支付系统业务专用章‛。

第四十六条 发起行受理的单位存款人提交的非本行付款的借方票据和凭证，在通过本系统处理成功后应将对应票据和凭证通过同城票据交换专门场次表外提给付款银行。第四十七条 受理行受理的单位存款人提交的贷记业务凭证以及个人提交的借记和贷记凭证一律截留在业务发起(受理)银行，接收行根据接收的电子数据产生相应的业务凭证。第四十八条 由受理银行交给客户的本系统各种支付业务受理回执，不作资金已收妥的依据，仅用于向受理银行查询。

资金是否已收妥应以收款银行交给收款人的收账通知(凭证)或打印在存折上的贷方(收方)记录为准。

委托汇兑业务中，受理银行交给客户的汇兑凭证回执联作为付款人付款依据。

个人存折上交易结果的记录由其开户银行负责登记。

第四章 业务收费

第四十九条 本系统处理的各类业务的电子交易手续费一律由付款人支付。

银行本票业务的电子交易手续费由付款银行(出票银行)支付，实时贷记抹账业务的电子交易手续费由原交易的付款银行支付。

第五十条除现金存款电子交易手续费由客户直接向受理银行以现金方式支付外，其他业务的电子交易手续费一律以转账方式支付。

第五十一条 银行在受理个人业务时，应明确告知电子交易手续费收费标准和收取方式；开户银行在办理单位业务前，应与存款人书面约定电子交易手续费标准和收取方式。第五十二条 交易成功的，银行应即时收取电子交易手续费；交易失败的，不收取电子交易手续费。

第五十三条 银行代收的本系统电子交易手续费应专户存放，不随对应业务纳入当日轧差清算，并按规定定期与DPC及相关银行结箅。

第五章 资金清算

第五十四条 直接参与者应在其清算账户存有足够的资金，用于本机构及所属间接参与者支付业务的资金清算。

存款人应在银行存款账户中存有足够的资金，用于办理支付业务。

第五十五条 DPC对实时借记业务、实时贷记业务和通存通兑业务按收到的先后／顷序实时处理。

第五十六条 营管部根据有关规定或管理需要，可以对直接参与者的清算账户进行管理。

第五十七条 营管部可以根据需要设定或调整本系统每一工作日的轧差场次和轧差时间。

第五十八条 本系统依据当日交易成功的业务数据产生清算轧差净额，并于当日通过清算账户清算，清算账户禁止隔夜透支。

第六章 日终处理

第五十九条 日终处理时，DPC试算平衡后，应通知各直接参与者与DPC对帐。直接参与者可以从DPC下载当日有关账务信息并对账。

第六十条各直接参与者与DPC对账不符的，可向DPC申请下载账务明细信息进行核对。核对不符的，应以从DPC下载的账务明细信息为准进行账务调整。

第七章 纪律与责任

第六十一条 本系统的各参与者和运行者应遵守本办法以及其他相关规定，不得拖延支付，截留、挪用客户和他行资金；不得因清算账户头寸不足影响客户和他行资金使用；不得疏于系统管理，影响系统安全、稳定运行；不得泄露密寸甲和密钥，影响资金安全；不得有疑不查，查而不复；不得伪造、篡改支付业务，盗用资金。

第六十二条 参与者和运行者因工作差错延误支付业务的处理，影响客户和他行资金使用的，应按中国人民银行规定的同档次流动资金贷款利率计付赔偿金。

第六十三条 参与者违反规定故意拖延支付，截留挪用资金，影响客户和他行资金使用的，应按规定承担赔偿责任。第六十四条 参与者和运行者的工作人员在办理本系统支付业务中玩忽职守，或出现重大失误，造成资金损失的，应按规定承担行政责任，情节严重的，依法追究刑事责任；伪造、篡改支付业务盗用资金的，依法追究刑事责任。第六十五条 参与者未在规定的时间内发出和答复业务查询，造成资金延误的，应按规定承担赔偿责任。

第六十六条 受理银行未按规定进行票据和结算凭证审查，付款银行对。此已按规定查询的，受理银行应承担相应责任，否则，由付款银行承担相应责任。第六十七条 因实时贷记抹账业务产生的相关责任由发起该业务的直接参与者承担，与实时贷记抹账业务的接收行无关。

第六十八条 存款人不按规定通过本系统办理支付结算业务，影响资金使用或造成资金损失的，由其自行负责。第六十九条 存款人违反与银行的约定，开户银行应拒绝为其通过本系统办理业务，情节特别严重的，各银行应停止为其办理支付结算业务。

第七十条参与者和运行者应妥善保管密寸甲，严防泄露。因保管不善泄露密押，造成资金损失的，有关责任方应按规定承担赔偿责任。故意泄露密寸甲情节严重的，应依法追究刑事责任。

第七十一条 因不可抗力造成系统无法正常运行的，有关当事人均有及时排除障碍和采取补救措施的义务，但不承担赔付责任。

第八章 附 则

第七十二条 DPC联机存储支付信息的时间为30个运行工作日。

支付信息的脱机保存时间按照同类会计档案的时间保存。第七十三条 本办法由营管部负责解释、修改。第七十四条 本办法于2005年月 日起试行。

武汉电子支付系统借方凭证事后处理流程

一、原则

本系统实时处理的提出借方业务，在通过本系统处理成功后，应将业务对应的票据和凭证通过同城票据交换专门场次提给

二、发起行的处理

发起行当日受理的单位存款人提交的非本行付款的借方票据和凭证，通过本系统处理成功后，在电子业务对应的纸质票据和凭证上打印磁码，集中装入事后交换专用票据袋，随同次日一次清算送交人民银行电子结算中心。

三、电子结算中心的处理

电子结算中心在次日一次交换清分结束后，开设本系统事后票据交换专场。该场票据交换只将票据清分到各交换行，不做帐务处理。

事后票据清分结束后，票据应装入事后交换专用票据袋，随次日一次清算票据袋一起，于次日上午送交付款行。

四、付款行的处理

付款行收到本系统事后交换的借方票据和凭证，应与原电子交易核对，或按照各行相关事后监督规定执行。

武汉电子支付系统 实时业务处理手续

武汉电子支付系统项目组

2005年二月

第一部分实时贷记支付业务

一、转账支票委托付款业务

二、直接贷记支付业务

三、委托收款划回

四、同城特约委托收款划回等贷记支付业务

五、个人贷记转账业务第： 二部分实时借记支付业务

一、转账支票业务：

二、银行本票业务

三、个人借记转账业务 第三部分通存通兑业务

一、对公业务通存通兑

二、个人业务通存通兑 第四部分跨行委托汇兑

一、单位跨行委托汇兑

二、个人跨行委托汇兑 第五部分银行专用业务

一、实时贷记抹账第六部分差错和异常处理

一、差错的处理(一)密押错误的处理(二)行号错误的处理．

(三)重复发送的处理(四)接收人差错的处理(五)报文无法识别的处理

三、异常情况的处理

(一)联机异常的处理

(二)无回应结果的处理。(三)滞留业务的处理

(四)日终账务无法下载的处理

(五)DPC日终试算不平的处理．(六)支付业务信患核对不符的

(七)被拒绝业务的处理

第七部分业务收费 第八部分轧差清算 第九部分查询查复

第十部分 密押的使用和管理

第一部分实时贷记支付业务

一、转账支票委托付款业务(一)受理行(发起行、付款行)转账支票的出票人签发票据后，按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，直接到付款银行(开户银行)办理委托付款。

付款银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，检查付款帐户是否开通武汉电子支付系统业务，银行行内系统允许付款的，向收款行发起交易信息。

武汉支付系统数据处理中心(以下简称DPC)反馈交易成功信息的，同时在进账单第一、二联及票据上加盖‚武汉电子支付系统业务处理专用章‛，在票据上加盖‚转讫‛章，并将进账单

第一联(送票回执联)交客户，进账单第二、三联(贷方凭证和收账通知)截留在受理行。会计分录为：

借：XX科目一一付款人账户

贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理 专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。

(二)接收行(收款行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷：XX科目一一收款人账户

(三)持票人持转账支票到付款银行提示付款，付款银行按规定对票据进行审查，并比照第一部分一(一)、(二)内容处理。

二、银行本票委托付款业务 7．受理行(发起行)银行本票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到付款银行办理提示付款。

受理银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，银行行内系统允许付款的，向收款行发起交易信息。

DPC反馈交易成功结果的，同时在进账单第一、二、三联及票据上加盖‚武汉电子支付系统业务处理专用章‛，并将进账单

第一联(送票回执联)交客户，进账单第二、三联(贷方凭证和收账通知)截留在受理行。会计分录为：

借：开出本票

贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。也可另行处理。2．收款行(接收行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，并向DPC反馈检查结果，等待DPC反馈交易结果。

DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷：XX科目一一收款人账户

三、直接贷记业务(支款凭证)付款人(单位银行存款账户存款人)填制直接贷记支付凭证(单联式)到付款银行办理支付业务，其业务处理比照第一部分一(一)、(二)内容处理。

四、委托收款划回业务

(一)受理行(接收行、收款行)发出委托收款

收款人按规定填制托收凭证(电划)连同商业汇票等债权证明，提交给开户银行，银行按规定审查后，通过票据交换表外提给付款银行，或邮寄付款银行。(二)付款行(发起行)付款银行按规定进行付款审查。不能付款的，按规定进行处理。同意付款的，付款银行录入托收凭证要素，银行行内系统允许付款的，向收款行发起交易信息。

DPC反馈交易成功结果的，同时在托收凭证第三、四联及商业汇票等债权证明上加盖‚武汉电子支付系统业务处理专用章‛，在托收凭证第三联及商业汇票等债权证明上加盖‚转讫‛章。会

计分录为：

借：XX科目一一付款人账户

贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同委托收款凭证第三、四、五联及商业汇票等债权证明退还收款行，不作账务处理。(三)接收行(收款行、受理行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷：XX科目一一收款人账户

五、同城特约委托收款划回业务

(一)受理行(接收行、收款行)发出委托收款

收款人按规定填制特约委托收款凭证(电划)，提交给开户银行，银行按规定审查后，通过票据交换表外提给付款银行。

(二)付款行(发起行)付款银行按规定进行付款审查。不能付款的，按规定进行处理。同意付款的，付款银行录入特约委托收款凭证要素，检查付款帐户是否开通武汉电子支付系统业务，银行行内系统允许付款的，向收款行发起交易信息。

DPC反馈交易成功结果的，同时在特约委托收款凭证第三、四、五联上加盖‚武汉电子支付系统业务处理专用章‛，在特约委托收款凭证第三、五联上力口盖‚转讫‛章。会计分录为：

借：XX科目一一付款人账户

贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同委托收款凭证第三、四、五联退还收款行，不作账务处理。

(三)接收行(收款行、受理行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷：XX科目一一收款人账户 个人贷记转账业务

(一)受理行(发起行、付款行)个人付款人按规定填制个人跨行电子支付业务凭证，在业务类型‚转账‛栏注明‚√‛后，持付款账户对应的存折或银行卡到付款银行办理。

银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，银行行内系统允许付款的，向收款行发起交易信息。

DPC反馈交易成功结果的，同时在个人跨行电子支付业务凭证上打印成功处理结果，并在第一、二联上加盖‚武汉电子支付系统业务处理专用章‛，在个人跨行电子支付业务凭证第一联上加盖‚转讫‛章。将个人跨行电子支付业务凭证第二联(回执联)连同存折或银行卡交客户，第一联截留在受理行。会计分录为：

借：XX科目一一付款人账户

贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证连同存折或银行卡退给客户，第一联留存备查，不作账务处理。(二)接收行(收款行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷：XX科目一一收款人账户

第二部分实时借记支付业务

一、转账支票委托收款业务(一)受理行(发起行、收款行)转账支票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到收款银行(开户银行)办理委托收款。

收款银行受理票据和进账单后，按规定进行凭证审查，收款帐户是否开通武汉电子支付系统业务，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。

DPC反馈交易成功结果的，同时在进账单第一联及票据上加盖‚武汉电子支付系统业务处理专用章‛，在进账单第二、三联上加盖‚转讫‛章，并将进账单第一(送票回执联)交客户，票据俟后通过专场票据交换表外提给付款银行。会计分录为：

借：存放中央银行款项一一同城电子支付往账

贷：XX科目一一收款人账户

DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。(二)接收行(付款行)付款银行接到借方交易信息后，检查付款账户余额、支付密码的有效性及账号和户名的一致性，该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。

DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录为：

借：XX科目一一收款人账户

贷：存放中央银行款项一一同城电子支付往账

二、银行本票业务

(一)受理行(发起行、收款行)银行本票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到收款银行(开户银行)办理提示付款。

收款银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。

DPC反馈交易成功结果的，同时在进账单第一联及票据上加盖‚武汉电子支付系统业务处理专用章‛，在进账单第二、三联上加盖‚转讫‛章，并将进账单第一联(送票回执联)交客户，票据俟后通过专场票据交换表外提给付款银行。会计分录为：

借：存放中央银行款项一一同城电子支付往账

贷：XX科目一一收款人账户

DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。(二)接收行(付款行)付款银行接到借方交易信息后，检查本票是否为本行签发、支付密码的有效性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录

三、个人借记转账业务 一同城电子支付来账

(一)受理行(发起行、收款行)个人付款人按规定填制个人跨行电子支付业务凭证，在业务类型‚转账‛栏注明‚√‛后，持付款账户对应的存折或银行卡到收款银行办理。

银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，向付款行发起交易信息。

DPC反馈交易成功结果的，同时在个人跨行电子支付业务凭证上打印成功处理结果，并在第一、二联上力口盖‚武汉电子支付系统业务处理专用章‛，在个人跨行电子支付业务凭证第一联上加盖‚转讫‛章，并将个人跨行电子支付业务凭证第二联(回执联)连同存折或银行卡交客户。会计分录为：

借：存放中央银行款项一一同城电子支付往账

贷：XX科目一一收款人账户

DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明‚交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证连同存折或银行卡退给客户，第一联留存备查，不作账务处理。(二)接收行(付款行)付款银行接到借方交易信息后，检查付款账户余额、取款密码的有效性、磁条信息的有效性及账号和户名的一致性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。

DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。会计分录为：

借：XX科目——付款人账户

贷： 存放中央银行款项一一同城电子支付来账

第三部分通存通兑业务

一、对公业务通存通兑业务(一)转账银行本票通存通兑业务 1．受理行(发起行)银行本票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到收款银行以外的银行办理提示付款。

受理银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向收款行和付款行发起交易信息。

DPC反馈交易成功结果的，同时在进账单第一、二、三联及票据上加盖‚武汉电子支付系统业务处理专用章‛，并将进账单第一联(送票回执联)交客户，进账单第二、三联(贷方凭证和收账通知)截留在受理行。票据俟后通过专场票据交换表外提给付款银行。会计分录为：

借：存放中央银行款项一一同城电子支付往账

贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。2．付款行(接收行)付款银行接到借方交易信息后，检查本票是否为本行签发、支付密码的有效性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录 借：开出本票

贷： 存放中央银行款项 同城电子支付来账 3．收款行(接收行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，并向DPC反馈检查结果，等待DPC反馈交易结果。

DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷：XX科目一一收款人账户(二)现金银行本票通兑

1．受理行(发起行、兑付行)银行本票的持票人持个人身份证件及现金银行本票到签发银行以外的银行办理兑付。受理银行受理票据后，按规定对客户身份、凭证进行审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。

DPC反馈交易成功结果的，打印武汉电子支付往账借方补充凭证，在票据及武汉电子支付往账借方补充凭证上加盖‚武汉电子支付系统业务处理专用章‛和‚现金付讫‛章，现金清点无误后交客户，票据俟后通过专场票据交换表外提给付款银行。会计

借：存放中央银行款项一一同城电子支付往账

贷：现金

DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据退给原办理业务的客户，不作账务处理。2．接收行(付款行)付款银行接到借方交易信息后，检查本票是否为本行签发、支付密码的有效性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录为： 借：开出本票

贷： 存放中央银行款项一一同城电子支付来账

受理银行受理票据后，按规定对客户身份、凭证进行审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。

DPC反馈交易成功结果的，打印武汉电子支付往账借方补充凭证，在票据及武汉电子支付往账借方补充凭证上加盖‚武汉电子支付系统业务处理专用章‛和‚现金付讫‛章，现金清点无误后交客户，票据俟后通过专场票据交换表外提给付款银行。会计

借：存放中央银行款项一一同城电子支付往账

贷：现金

DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据退给原办理业务的客户，不作账务处理。2．接收行(付款行)付款银行接到借方交易信息后，检查本票是否为本行签发、支付密码的有效性，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。事后提入的借方凭证作附件。会计分录为：

借：开出本票

贷： 存放中央银行款项一一同城电子支付来账(三)转账支票通存通兑业务 1．受理行(发起行)转账支票的持票人按规定填制进账单，并在‚通过武汉电子支付系统‛ 栏注明‚√‛后，到收款银行或付款银行以外的银行办理委托收款。

受理银行受理票据和进账单后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向收款行和付款行发起交易信息。

DPC反馈交易成功结果的，同时在进账单第一、二、三联及票据上加盖‚武汉电子支付系统业务处理专用章‛，并将进账单第一联(送票回执联)交客户，进账单第二、三联(贷方凭证和收账通知)截留在受理行。票据俟后通过专场票据交换表外提给付款银行。会计分录为：

借：存放中央银行款项一一同城电子支付往账

贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据和进账单退给原办理业务的客户，不作账务处理。2．付款行(接收行)付款银行接到借方交易信息后，检查付款账户余额、支付密码的有效性及账号和户名的一致性，该账户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章，事后提入的借方凭证作附件。会计分录

借：XX科目一一付款人账户

贷： 存放中央银行款项 同城电子支付来账 3．收款行(接收行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证(两联)，并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷：XX科目一一收款人账户(四)现金支票通兑业务

1．受理行(发起行、兑付行)现金支票的持票人持现金支票到开户银行以外的银行办理兑付，持票人为个人的，还应提交个人身份证件。

受理银行受理票据后，按规定对客户身份、凭证进行审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起交易信息。

DPC反馈交易成功结果的，打印武汉电子支付往账借方补充凭证，在票据及武汉电子往账支付借方补充凭证上加盖‚武汉电子支付系统业务处理专用章‛和‚现金付讫‛章，现金清点无误后交客户，票据俟后通过专场票据交换表外提给付款银行。会计分录为：

借：存放中央银行款项

贷：现金 同城电子支付往账

DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，打印武汉电子支付系统交易失败证明(代退票理由书)，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同票据退给原办理业务的客户，不作账务处理。2．接收行(付款行)付款银行接到借方交易信息后，检查付款账户余额、支付密码的有效性及账号和户名的一致性，该账户是否开通武汉电子支付系统业务，并向DPC反馈检查结果，等待DPC反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给DPC。DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章，事后提入的借方凭证作附件。会计分录

(五)现金通存业务 一同城电子支付来账

(一)受理行(发起行、付款行)存款人按规定填制现金缴款单，持现金到开户银行以外的银行办理现金缴存业务。

受理银行受理凭证和现金后，清点现金并按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向收款行发起交易信息。

反馈交易成功结果的，同时在现金缴款单第二联上加盖 ‚武汉电子支付系统业务处理专用章‛，第一、二联上加盖‚现金收讫‛章，并将第一联交客户。会计分录为：

借：现金

贷：存放中央银行款项一一同城电子支付往账

反馈交易失败结果的，可视情况选择重新发起交易。无 法成功处理的，打印武汉电子支付系统交易失败证明，注明交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同凭证和现金退给原办理业务的客户，不作账务处理。(二)接收行(收款行)收款银行接到贷方交易信息后，检查账号和户名的一致性、该帐户是否开通武汉电子支付系统业务，并向 反馈检查结果，等待 反馈交易结果。

反馈交易成功结果的，打印武汉电子支付来账贷方补充 凭证(两联)，并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷： 科目一一收款人账户

二、个人业务通存通兑(一)个人转账业务通存通兑 1．受理行(发起行)个人付款人按规定填制个人跨行电子支付业务凭证，在业务类型‚转账‛栏注明‚√‛后，持付款账户对应的存折或银行卡到收、付款银行以外的银行办理转账业务。

受理银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，向收、付款行发起交易信息。

DPC反馈交易成功结果的，同时在个人跨行电子支付业务凭证第一、二联上加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证第二联(回执联)连同存折或银行卡交客户，第一联截留在受理行。会计分录为：

借：存放中央银行款项一一同城电子支付往账

贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明‚交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证连同存折或银行卡退给客户，第一联留存备查，不作账务处理。2．付款行(接收行)付款银行接到借方交易信息后，检查付款账户余额、取款密码的有效性、磁条信息的有效性及账号和户名的一致性，该账户是否为银行结算账户，并向 反馈检查结果，等待 反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给。

反馈交易成功结果的，打印武汉电子支付来账借方补充 凭证，加盖‚转讫‛章。会计分录为：

借： 科目一一付款人账户

贷： 存放中央银行款项一一同城电子支付来账

收款行(接收行)收款银行接到贷方交易信息后，检查账号和户名的一致性，收款账户是否为银行结算账户，收款账户为单位银行结算账户的，还要检查该帐户是否开通武汉电子支付系统业务，并向反馈检查结果，等待 反馈交易结果。

反馈交易成功结果的，打印武汉电子支付来账贷方补充 凭证并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷： 科目一一收款人账户(二)个人现金通存业务

受理行(发起行、付款行)个人按规定填制个人跨行电子支付业务凭证(付款人栏空缺)，在业务类型‚存现‛栏注明‚√‛后，持收款账户对应的存折或银行卡到收款银行以外的银行办理存款业务。

受理银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，现金清点无误后，银行前台操作员录入款凭证要素，向收款行发起交易信息。

DPC反馈交易成功结果的，同时在个人跨行电子支付业务凭证第一、二联上加盖‚武汉电子支付系统业务处理专用章‛和‚现金收讫‛章，并将第二联交客户。会计分录为：

借：现金

贷：存放中央银行款项一一同城电子支付往账 DPC反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明‚交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同凭证和现金退给原办理业务的客户，第一联留存备查，不作账务处理。2．接收行(收款行)收款银行接到贷方交易信息后，检查磁条信息的有效性、账号和户名的一致性，收款账户是否为银行结算账户，并向DPC反馈检查结果，等待DPC反馈交易结果。

DPC反馈交易成功结果的，打印武汉电子支付来账贷方补充凭证，并加盖‚转讫‛章。会计分录为：

借：存放中央银行款项一一同城电子支付来账

贷：XX科目一一收款人账户(三)现金通兑

1．受理行(发起行、收款行)个人付款人按规定填制个人跨行电子支付业务凭证(收款人栏空缺)，在业务类型‚取现‛栏注明‚√‛后，持付款账户对应的存折或银行卡到付款银行以外的银行办理。

受理银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，向付款行发起交易信息。

反馈交易成功结果的，同时在个人跨行电子支付业务凭 证第一、二联上力口盖‚武汉电子支付系统业务处理专用章‛和‚现金收讫‛章，并将清点无误的现金、个人跨行电子支付业务凭证第一联(回执联)连同存折或银行卡交客户，第二联截留在受理行。会计分录为：

借：存放中央银行款项

贷： 现金

同城电子支付往账 反馈交易失败结果的，可视情况选择重新发起交易。无法成功处理的，在个人跨行电子支付业务凭证处理结果栏注明‚交易失败原因，加盖‚武汉电子支付系统业务处理专用章‛，将个人跨行电子支付业务凭证连同存折或银行卡退给客户，第一联留存备查，不作账务处理。(二)接收行(付款行)付款银行接到借方交易信息后，检查付款账户余额、取款密码的有效性、磁条信息的有效性及账号和户名的一致性，收款账户是否为银行结算账户，并向 反馈检查结果，等待 反馈交易结果。拒绝付款的，应将拒绝付款理由反馈给。

DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证，加盖‚转讫‛章。会计分录为：

借：XX科目一一付款人账户

贷： 存放中央银行款项一一同城电子支付来账

第四部分跨行委托汇兑

一、单位跨行委托汇兑(一)发起行(受理行)单位存款人填制从付款银行领购的电汇凭证，到付款银行以外的其他银行，办理从指定账户发起的汇兑业务。

受理银行受理凭证后，按规定进行凭证审查，审查通过的，银行前台操作员录入收付款凭证要素，向付款行发起委托汇兑信，息。

DPC反馈交易成功结果的，同时在电汇凭证第一、二、三联上加盖‚武汉电子支付系统业务处理专用章‛，将电汇凭证第一联交客户，第三联截留在受理行，第二联俟后通过专场票据交换表外提给付款银行，不作账务处理。DPC反馈交易失败结果的，可视情况选择重新发起。无法成功处理的，打印武汉电子支付系统交易失败证明，注明失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同凭证退给客户，不作账务处理。(二)接收行(付款行、汇兑发起行)付款银行接到委托汇兑信息后，检查付款账户余额、支付密码的有效性及账号和户名的一致性，该帐户是否开通武汉电子支付系统业务，并向p卜反馈检查结果，等待／圹c反馈交易结果。付款行拒绝借记付款账户的，应将拒绝付款理由反馈给0／L。反馈成功信息的，打印武汉电子支付来账借方补充凭证，第一联作记账凭证，加盖‚转讫‛章，并与事后提入的借方凭证核对，第二联代发电依据。会计分录为：

借： 科目一一汇款人账户

贷： 联行往账

二、个人跨行委托汇兑(一)发起行(受理行)个人存款人持汇款账户对应的存折或银行卡到开户银行以外的其他银行，办理从指定账户发起的汇兑业务。

个人存款人在受理行购买并填制电汇凭证，连同存折或银行卡交受理银行。受理银行通过专用设备读取存折或银行卡中的账户信息，同时按规定进行凭证审查，审查通过的，银行前台操作员录入款凭证要素，客户通过专用设备输入取款密码，向付款行发起委托汇兑信息。

反馈交易成功结果的，同时在电汇凭证第一、二、三联上力口盖‚武汉电子支付系统业务处理专用章‛，将电汇凭证第一联交客户，第三联截留在受理行，第二联俟后通过专场票据交换表外提给付款银行，不作账务处理。DPC反馈交易失败结果的，可视情况选择重新发起。无法成功处理的，打印武汉电子支付系统交易失败证明，注明失败原因，加盖‚武汉电子支付系统业务处理专用章‛，连同凭证退给客户，不作账务处理。(二)接收行(付款行、汇兑发起行)付款银行接到委托汇兑信息后，检查付款账户余额、取款密码的有效性、磁条信息的有效性及账号和户名的一致性，该账户是否为银行结算账户，并向DPC反馈检查结果，等待DPC反馈交易结果。付款行拒绝借记付款人账户的，应将拒绝付款理由反馈给DPC。

DPC反馈交易成功结果的，打印武汉电子支付来账借方补充凭证第一联作记账凭证，加盖‚转讫‛章，并与事后提入的借方凭证核对，第二联代发电依据。会计分录为：

借：XX科目一一汇款人账户

贷： 联行往账

第五部分银行专用业务

一、实时贷记抹账业务

(一)发起行(收款行、原贷记业务发起行)发起行发现错发实时贷记交易时，在该笔业务进行轧差前，经行内授权，调出原错误贷记交易记录，向付款行(原交易收款行)发起交易信息。统可以重新发起。(二)行号错误的处理

实时业务 篇3

信息是当今每个企业的命脉。企业需要实时了解业务的运营状况, 需要在运营过程中对业务运营数据进行深入分析。但可用的运营数据量通常过于庞大, 基于磁盘的传统系统无法快速处理以得出有效结果。因此, 即便要进行最基本的分析, 企业也不得不将来自运营应用程序的数据减少至分析模型所能承受的数据量。这意味着运营应用程序与分析环境基本断开, 从而导致数据收集与深入分析之间会产生明显的时间差。

SAP HANA数据库可以在不影响SAP ERP应用程序或任何其他运营软件性能的情况下实现对运营数据的直接访问。企业可以在内存中以接近实时的速度同步关键事物表, 从而使这些表易于访问, 以便进行分析和查找。数据在内存中可用之后, 部门可从大量列表中迅速查找单行项目 (如预订凭证、销售线索或服务请求) , 而不会对运营系统造成影响。这也简化了支持详细行项目直接访问模型以及用于更复杂分析处理的分析模型的建模工作流。

二、业务数据的解析

对于希望保持竞争优势、优化流程和快速响应需求的企业而言, 业务数据的报告、分析和解释都具有极端的重要性。数据仓库、商务智能平台和商务智能工具与内存计算相结合, 能更好地帮助企业实现目标。来自生产型SAP应用和所有外部数据源的业务信息, 可通过提供的工具集成、转换和合并到SAP Net Weaver BW中。SAP Net Weaver BW提供的报告和分析工具, 可支持公司评估和解释数据并为数据分发提供便利。

◆孟繁汀窦文琦

使用SAP Net Weaver BW执行的数据仓储构成将数据转换为价值信息的商务智能解决方案的基础。集成的公司特定数据仓储可以为企业集团汇总的决策者提供针对目标考量的信息。无论数据来自SAP软件还是非SAP软件, 也不管是历史数据还是当前数据, 采用SAP Net Weaver BW的数据仓储都支持:

●集成从源系统检索的数据

●转换

●合并

●清理

●存储

●为分析和解释进行检索

三、合并工具组件

合并组件可提供合并财务报表法定要求的完整功能。其中包括对资产负债表、收益表、现金流量表以及公司及部门提供的附录 (例如中国GAAP、美国GAAP和国际会计标准) 的支持。它可帮助公司及时提供管理信息以及遵守外部报告要求。

同时还能帮助企业根据用户定义的组织单位和用户定义的层次结构执行管理合并。例如可执行合并模拟, 确定兼并或收购、不同的货币兑换方法或更改合并规则的影响。另外还支持基于价值的会计、数据收集、验证、货币换算、部门间事物消除和投资条目合并的自动生成, 所有这些都依据内部程序和会计法规要求进行。内外部合并可基于相同的数据, 因此可以协调统一财务会计和管理会计系统。此外, 管理合并的数据结构还提供分析客户组、目的地、产品组或分销渠道合并收入所需的灵活性。 (下转21页) (上接33页)

四、业务分析特性

从判断竞争局势和理解客户需求到推动创新和降低运营成本, 明智的决策均基于可靠的数据。尽管许多企业发现自己的数据已经泛滥, 但他们仍在努力将数据提供给最能够有效利用的人们。这些人包括财务控制人员、销售运营经理、营销活动经理、以及其他需要及时访问数据和深入分析的人员, 他们旨在支持符合战略的决策, 以便最终能够提高业务绩效。但对大多数人而言, 商务智能仍是高级用户和IT专家的专属领域。对于其他需要深入分析数据以便有效开展工作的员工而言, 必须等待数小时或数天才能生成自己所需的报告。

SAP Business Objects Analysis软件可为Microsoft Office用户提供执行多维分析的直观功能。该软件在安装时不会干扰现有的SAP软件环境, 因此可从SAP Business Explorer工具平滑地过渡到SAP Business Objects BI解决方案。

SAP Business Objcetcs BI的关键特性包括:

●内容重用—为S A P B E x用户提供为S A P Net Weaver BW开发的现有数据集和使用SAP BEx开发的查询

●分析面板—使用户能够快速过滤、分解并钻取数据以获取业务洞察力

●使用嵌入式分析进行Microsoft Power Point现场演示—视觉呈现直接从SAP Net Weaver BW刷新的最新信息

●高性能—无论数据量多少, 通过内存加速都可充分发挥Microsoft Excel的强大功能, 立即进行深入分析

五、结论

内存计算技术能够支持在服务器的主内存中处理超大量的实时数据, 从分析和交易中提供及时的结果。随着SAP与Sybase逐渐融合, SAP大数据框架形成以SAP HANA为核心, 以Sybase数据库为重要组成部分的统一整体。SAP HANA作为快速处理、实时分析海量数据的创新技术, 将引领数据库领域的发展。H

(作者单位:兰州石化自动化研究院)

摘要：随着企业业务的扩大, 信息化的深入, 能否快速处理海量数据并有效进行实时分析, 将决定企业是否可以迅速应对市场行情变化、做出决策。企业需要实时洞察业务运营状态, 以便迅速应对不断变化的市场形势。本文通过引入SAP内存计算和基于HANA数据库的SAP NetWeaver Business Warehouse组件, 分析了基于SAP HANA在业务分析领域的新变革。

网络实时业务监控系统的分析与实现 篇4

网络监测系统中的重要组成部分之一就是网络监测仪, 其功能是获取相应的数据包, 对数据信息进行分析, 并将上述分析结果传到中央服务器。具体而言, 包括以下标准模块, 即抓包模块、通信模块以及质量分析模块.

抓包模块功能主要体现在两个方面。第一, 网络数据信息快速获取;第二, 基于过滤规则对报文进行过滤。对于监测过程中信息的获取, 系统具有较高的要求, 需要在高速链路上进行大规模帧数据的捕获而不能丢包。抓包模块根据中央服务器过滤规则进行信息的筛选。其基本的实施步骤如下:

从网卡驱动获得网络包, 根据包地址以及端口号, 确定HASH值, 然后再以HASH值为基础, 从表中查找规则;在此过程中, 若符合过滤规则, 则会将相关的数据信息传到质量分析模块;若与过滤规则不相符, 则就会将该数据信息丢弃。

质量分析模块是整个系统的核心, 主要是利用所获取的网络数据流, 对网络系统的性能质量进行测定。网络质量指标包括延迟、错包、丢包、包分片、重传包以及乱序和抖动等相关步骤。通过包捕获模块, 将不需要的数据信息去掉后再传至分析引擎, 后者根据所获取的数据包得到实时网络质量情况;以视频质量评估模型为基础, 对预测视频质量情况实时获取, 并且得出能够有效反映视频质量值的IR值。获取网络质量需要分析以前数据包的时间以及相应的统计信息, 需将接收包中的元信息保存在事实库中。实施步骤如下:从网络系统中获得模块获取数据包;对事实库进行更新, 确定当前网络质量情况;以视频质量评估模型为基础, 对视频IR值进行确定。

对于通讯模块, 其功能主要是负责与监测仪通讯以及网络业务数据信息的相互传输。其中, 业务数据主要包含配置数据信息、周期范围内的监控信息数据以及媒体流数据等。中心监测服务器获取网络业务数据以后, 将其保存在数据库之中, 并严格按照用户要求, 传至web界面模块;同时, 中心监测服务器接受用户对监测仪的操作命令, 比设备配置、工作模式的切换等。

二、服务器系统设计

对于网络实时监测服务器而言, 其主要构成是数据库服务、业务监控网络通讯以及Web服务和业务模块;其在计算机中运行, 同时也可分别在几台不同的计算机上运行, 共同组成一个中心监测服务器。服务器系统, 采用的是struts、hibernate框架, 这是目前比较流行的, 可以有效控制上层和下层数据信息的有效交互。从整个系统软件组成结构来看, 其属于项目开发模块, 包括web页面、业务和通讯模块, 并且包括第三方的服务和相关组件。

三、通信系统设计

网络系统中的监测仪和中央服务器之间的通讯具有双向性, 因此通讯过程中的Exporter、Collector角色之间也是互换的。网络系统发送端向接收端发送的消息格式通常为IPFIX协议, 其通讯流程具有独立性。本文所探讨的系统, 首先需对系统中的消息进行全面统计、归纳, 并在此基础上总结出常用系统消息, 包括服务发现消息、统计信息、心跳消息、配置消息、详细媒体消息以及配置上传和下发消息等。系统将这些消息模板固定和保存在网络监测仪以及中央服务器中, 以便于使得上述消息在整个网络系统中得以有效传送, 从而节省了模板消息大量传送过程中的成本, 也可以有效地提高了消息数据传送效率, 这对提高网络业务实时监控质量, 具有非常重要的作用。

四、结语

网络实时业务监控的主要针对业务异常, 如通讯中断、网络系统设备故障等问题;正常的网络业务交易过程, 可不在实时监控范围之内, 一方面可以节省资源, 另一方面也可以有效提高实时监控质量和效率。本文主要就网络监控系统的组成及实施进行了简要分析, 为相关工程人员做出相关建议。

参考文献

[1]王晓明.基于形式化方法的网络业务流自相似性研究[J]电脑知识与技术, 2013 (10) .

实时业务 篇5

1 系统功能与结构

气象资料业务系统 (简称MDOS) , 主要功能包括观测站 (含国家站和区域站) 数据传输监控、质量控制疑误信息处理、基本信息查询与管理、信息查询与统计、产品制作与数据服务、元数据管理等, 处理数据类型包括小时数据、分钟数据、小时辐射数据、日数据、日照数据等5 类基本气象数据和台站元数据信息, 是一个集数据传输监控、质控信息处理与查询反馈、基础信息管理、信息报警、雷达定量估算降水和GIS数据显示, 产品制作与数据服务、数据质量评估考核及元数据处理为一体, 以省级数据监控、处理与查询为核心, 涵盖台站级处理与反馈, 衔接国家级处理与查询的综合性气象资料业务平台。

MDOS由数据库、 数据入库系统、 质量控制系统、业务操作平台、统计处理系统、报警系统、文件上传系统、元数据管理系统等组成[1]。 该系统主要应用在台站级和省级, 台站级由台站级数据采集处理系统组成, 负责观测数据及元数据的上传、质控信息的处理与反馈。 省级由数据入库系统、数据库存储管理系统、质量控制系统、业务操作平台、报警系统、文件上传系统和统计处理系统组成, 主要完成数据的质量控制、处理及查询反馈。

平台包括数据传输显示与监控、国家站数据质控信息处理、区域站数据质控信息处理、基本信息查询与管理、信息查询与统计、产品制作与数据服务、信息报警、数据质量评估考核、雷达定量估算降水和GIS数据显示及日清等功能, 其组成结构如图1 所示。

2 系统功能模块介绍

1) 数据传输信息显示与监控。 主要由接收数据显示与监控和上传数据显示与监控两个基本模块, 每个模块包括小时数据、小时辐射数据、分钟数据、日数据、日照数据和区域站数据等6 类信息监控。

2) 国家站数据质控信息处理。 国家级站数据质控信息处理包含国家站省级处理与查询反馈、国家站台站处理与反馈、系统偏差检测。 其中省级处理与查询提供省级、国家级质量控制后疑误信息和第三方人工质疑的疑误信息处理功能。 通过省级处理与查询、已查询待确认、已处理等步骤, 实现省级数据处理中心的业务功能。

国家级站台站处理与反馈负责处理省级数据处理中心分发的质量控制查询信息, 通过台站处理与反馈、信息报警互动等步骤实现疑误信息处理与反馈, 在台站对省级数据修改持异议的情况下可通过信息报警系统实现与省级的信息交流互动。 台站数据处理员可通过数据查询与质疑, 提出疑误信息。

3) 区域站数据质控制信息处理。 主要由区域站省级处理与查询反馈、区域站台站处理与反馈两个基本模块, 其中省级处理与查询包括处理与查询、数据修改、查询、质量控制状态信息显示、数据处理员确认等操作; 台站处理与反馈包括处理与反馈、处理情况查询等操作, 与国家站处理相同。

4) 元数据信息处理。 主要由审核与反馈, 疑误申请, 疑误处理, 建立新台站, 撤销台站, 台站变动登记, 图像、观测记录和规范, 备注纪要信息登记模块。

5) 基本信息检索查询。 主要由国家站台站信息查询、国家站台站信息设置、区域站台站信息查询与设置、邻近参考站信息、元数据信息文件导入和导出、用户管理和系统运行日志等模块。

6) 信息查询与统计。 主要为台站的数据传输信息统计查询。

7) 产品制作与数据服务。 产品制作与数据服务包括数据查询与统计服务和A、J、Y文件管理。 数据查询与统计服务提供对小时数据、日数据、候数据、旬数据、 月数据和年数据的统计值的显示。 A、J、Y文件管理涵盖了A、J和Y文件的查询和文件制作。

8) 数据质量考核。 数据质量考核具有两个部分功能:查询反馈统计和数据质量评估考核功能查询反馈统计包括国家级查询与反馈, 省级查询及反馈两部分功能。 国家级查询与反馈提供了一个时间段内省级对国家级查询的反馈情况。 省级查询及反馈统计了某段时间内台站对省级查询的反馈情况。

数据质量评估考核包括数据质量统计、观测质量台站及要素统计、 观测质量台站小时降水量、国家站单时次观测质量、正点数据质量曲线、分要素正点数据可用率、 分台站数据可用率等功能模块。基于台站、要素的分类方式, 使用表格、曲线的形式展现数据的可用率。

3 数据处理流程

开展实时历史地面气象资料一体化工作, 是保障气象观测数据质量控制实时性、 数据的完整性, 提高数据的可用性。 数据质量控制处理流程分省级和台站级。

3.1 省级数据质量控制处理流程

对台站上传的国家级站气象要素数据文件 (包括无人自动站数据文件) 、国家级站日照数据文件、国家级站日数据文件、 区域站气象要素数据文件、国家级站辐射数据文件5 类原始观测数据进行质量控制[2]。

处理流程包含数据的“时清”、“日清”和“月清”流程。

3.1.1 时清流程

时清流程是指对某时次数据的完整性、准确性进行分析, 对实时数据缺测、异常等情况进行处理。时清流程是日清、月清的基础;其处理对象是正点要素数据文件和小时逐分钟数据文件的全部要素数据。 时清表示该小时的数据已经处理完毕, 并不特指1h (特别是当该小时不在值班期间时) 。

具体流程:

1) 接班0.5h内, 对上一班交代的注意事项进行检查核实。

2) 完成日数据文件、元数据信息的处理。

对各类正点资料的接收情况进行监控。 根据日清界面的“小时数据多要素缺测信息”查询小时观测要素缺测的情况。 发现有报文缺失的现象, 应及时通知台站上传数据文件。

处理国家站数据质控信息。 对于省级能处理完成的数据, 尽量在省级处理完成;省级不能处理或者需要台站进行核实的数据, 可提交给台站处理。查看台站反馈的质控信息, 同意台站处理则结束质控流程, 不同意台站处理则通知台站并将质控信息再次转交台站。

3) 当班最后0.5h, 值班员完成 “ 日清” 界面工作, 主要包括数据完整率、缺报信息、质控信息处理情况、元数据审核、下班注意事项及其他需要说明的情况进行小结, 填写值班日志, 交班。

3.1.2 日清流程

日清流程是时清流程的集合, 主要包括以下内容:

1) 核查数据完整性:核查当班期间的国家站分钟数据、小时数据、日数据、日照数据、辐射数据以及区域站小时数据的完整性。

2) 处理疑误信息: 日值与小时统计值矛盾、 天气现象与相关要素值矛盾。

3) 处理元数据信息: 元数据与观测数据矛盾、元数据疑误信息。

4) 应急响应期间, 每日业务值班时间应根据需求调整, 8 时前完成前一日业务值班后至当前期间的数据处理工作。

3.1.3 月清流程

月清流程在日清流程基础上进行, 主要包括:

1) 对系统性偏差检查, 对长时间异常的区域站, 通知各市业务科或省级保障中心尽早进行维修。

2) 元数据信息、统计值及报表文件的处理;

3) 每月10 日前完成国家站A、J文件制作并上报国家级。

3.1.4 A、J文件制作流程

A、J文件制作流程在时清、 日清和月清流程基础上进行, 主要包括:

1) 每月2 日接收台站上传的天气概况信息, 5日完成质量控制。

2) 在1 个工作日内将质量控制疑误信息反馈台站查询。

3) 省级在12h内对台站反馈结果进行确认。 同意台站处理则结束质控, 不同意台站处理则通知台站并将质控信息再次转交台站。

4) 每月10 日前完成国家站A、J文件质量控制并上报国家气象信息中心。

3.2 台站级数据质量控制处理流程

处理并反馈省级提交给台站的疑误查询信息。处理流程如下。

3.2.1 地面自动站观测资料上传

按业务规定上传国家级测站实时地面气象分钟数据文件、小时数据文件、日数据文件、日照数据文件、辐射数据文件。

每日定时观测后, 登录MDOS平台查看本站数据完整性, 对缺测时次及时补传。

3.2.2 疑误信息处理与反馈

台站对疑误信息的反馈包括定时反馈、 被动反馈和更正数据反馈。

1) 定时反馈:在每日定时观测时次后, 登录MDOS操作平台, 查询本站国家站和区域站未处理疑误信息并反馈。 保证疑误数据在下一次定时观测前完成反馈。

2) 被动反馈: 收到疑误信息电话后, 实时登录MDOS操作平台反馈;接到显性错误电话后, 先核对显性错误数据值, 检查相应观测仪器, 查明可能引起出现错误数据的原因, 并及时进行相关数据处理和观测仪器维护等工作。 对省级转交台站处理的疑误信息, 及时查明原因, 通过MDOS操作平台进行数据处理和反馈。 台站在收到疑误信息12h之内完成反馈。 守班时段应急响应期间, 接收到疑误电话后1h内进行反馈。

3) 更正数据反馈:对台站本地更正过的数据要及时向省级进行反馈, 更正报时效内的数据既可通过 “MDOS数据查询与质疑” 功能主动填报反馈, 也可发送更正报进行修改; 时效外的数据可通过MDOS平台的“数据查询与质疑”进行修改。

3.2.3 元数据信息登记

当台站的基本信息、站网信息、观测信息、要素信息、仪器设备发生变动, 或需登记备注、纪要信息时, 24h之内应登录MDOS操作平台登记该类信息。

3.2.4 数据处理月清工作

每月1 日20 时前完成上月气候概况填报工作。

4 本地业务化工作

安装、调试一体化数据库、消息服务器、应用软件、气象资料业务系统 (MDOS) , 及系统参数的本地化修改。

4.1 系统参数的本地化

打开config.ini配置文件, 修改原始数据库段、应用数据库段和元数据库, 以及省级编报中心、设置生成邻近站的距离、修改区域站相邻站范围、完善观测站观测任务参数的配置, 修改国家站和区域站A、J、Y文件服务器存放地址, 修改上传远端服务器地址、用户名、密码及路径的配置, 修改关于质控参数的设置。

4.2 台站参数的本地化

导入了宁夏26 个国家级自动站元数据的, 对27 个国家级自动站、10 个国家级无人自动站、区域自动站 (2013 年174 个, 2014 年578 个, 2015 年851 个) 等参数的录入和校对。

其中国家级自动站参数包括台站基本参数和台站辅助参数。 台站基本参数, 包括台站名称、经度、纬度、拔高、压、温、湿、风、降水、地温、草温、蒸发、云、能、天等观测任务字段48 项。 台站辅助参数, 包括是否上传分钟、小时、日、日照、辐射数据文件, 台站数据处理人员电话, 台站管理人员电话等。区域自动站参数, 包括台站名称、经度、纬度、拔高、压、温、湿、风、降水、地温等观测任务字段31 项。

4.3 疑误数据的处理

疑误数据分为显性错误数据、可疑数据和缺测数据3 类。

显性错误数据:不在气候学界限值范围内的数据, 也就是各要素气候学界限值。

可疑数据:没有通过气候极值、内部一致性、时间和空间一致性等质量控制方法检查的数据。

缺测数据:有观测任务, 但无有效值的数据。

通过一体化业务系统提出的疑误数据情况见表1。

统计方法: 疑误数据总量=可疑数据+错误数据+显性错误数据+缺测数据;

错误率%= (错误数据+显性错误数据) /疑误数据总量;

通过MDOS操作平台进行人机对话处理疑误数据的情况见表2。

统计方法:疑误数据总量=可疑数据+实际错误数据+缺测数据;

错误率%=实际错误数据/疑误数据总量;

从表1 和表2 中, 可以看到数据的错误率还是很高的, 造成的主要原因是在2014 年5 月20 日业务试运行切换后, 一体化系统软件存在点问题, 主要是能见度和视程障碍现象不匹配, 导致国家级自动站有大量的错误数据。 在MDOS操作平台经过人机对话处理错误数据, 使国家级自动站错误率由20.14%下降到7.45%, 区域自动站错误率由11.95%下降到4.94%。

5 结束语

实时业务 篇6

1 常规性能分析

在以前的常规性能研究中, 人们倾向于对DCF方式竞争机制的探讨来进行建模分析, 来获取在饱和状态时, 其最大的吞吐量以及终端所发送数据帧的碰撞频率。对于实时业务性能, 数据帧的传输延迟和丢失才是问题的关键。虽然有研究证明信道访问延迟MAC竞争是关键, 但其研究背景是假设终端具有相同的MAC参数, 有条件限制, 研究结果并不明确。也有数据显示, 终端所发送的业务性能受MAC参数影响, 且性能受参数影响波动较大, 具体数据概念模糊。说明原有方法在研究过程中有其弊端, 无法分析不同类型终端共存时的业务性能, 而具有不同MAC协议参数和多终端无线局域网的应用已然成为关注的热点, 急需着性能研究的新突破。

2 成熟模式分析

IEEE802.11网络通常是由基本服务集BSS (Basic service set) 所构成。IEEE802.11标准提出以下两种MAC层接方式来满足不同应用, 一种是分布式协调模式DCF (distribute coordination function) , 一种是点协调模式PCF (point coordination function) 。IEEE802.1标准的DCF模式下, 多个网络节点共享无线媒介, 所建立的模型能够准确地衡定给定网络状态下的媒介服务时间。在PCF模式下, 引入协作通信机制, 能够在一定条件下提高系统吞吐量, 改善系统性能。无线局域网的基本访问方法是DCF, DCF采用载频侦听多址访问、碰撞回避 (CSMA/CA) 机制接入信道。无线局域网中的每个站点都必须实现DCF。PCF只能用于基础网络结构。两者提供的服务类型不同。DCF方式使用RTS (request t seed) 和CTS (clear to send) 消息来预留信道, 但其存在发送延迟的弊端。PCF在竞争周期中对特定终端业务的占用以及对实时业务服务质量的保证都由于DCF, 体现在其对CFP (contention free period) 的引入。但从另一方面讲, 因为PCF的操作复杂, 在数据业务中支持不佳, 应用不多。现代局域网主要研究在无线网中被广泛应用的DCF模式, 从其实时业务的性能入手。

3 关于DCF

在IEEE802.11标准下的DCF模式, 主要采用具有冲突检测的载波帧听多路访问方法提供访问方式, 利用竞争窗口的二进制指数回退机制协调多个终端对共享链路的访问, 减少竞争信道中无法通信的状态。具体操作为:终端数据发送后, 等待信道空闲DIFS (DCF interframe space) 断过后启动回退窗口计数器, 它的初始值为[0, w-1]之间的任意数。经过一个空闲时隙, 计数器自动减1。当计数器数据为0时终端发送数据就是在信道上;接受端如正确接受数字, 直接发送下一个数据帧。当两个终端计数同时为0, 则重新开始一次竞争回退过程, 这时初始值改变为[0, 2W-1]之间的随机值, W为上次计数初始值。重传数据在达到最大重传数据后还碰撞, 为废用帧, 直接发送下一个。另外, 为避免信道被某终端长时间占用, 在两次连续的数据分组发送之间也必须进行随机延迟。

综上所述, 本文通过资料的整合, 对在信道饱和状态时, IEEE802.11下两种标准模式下DCF和PCF的市场及利弊和对以DFC为主模式的具体操作进行分析。为了保证业务的质量, 扩大网络的容量, 分析模式旨在探讨无线区域网中实时业务性能的有效方法, 保持实时业务上满意的延迟性。此小结在一定程度上反映出MAC与业务性能的关系, 确保了无线局域网中实时业务的容量和提供服务的质量, 在多终端无线局域网研究中具有一定价值。

参考文献

[1]李超杰.基于网络感知的可用宽带评估机制研究[J].电视技术, 2011 (13) .

[2]陈昊成.基于网络计算的资源管理与分配系统的设计与实现[D].哈尔滨工业大学, 2010.

短彩信类业务实时信控新方法与实践 篇7

关键词：短彩信业务,垃圾短彩信,实时信控方法

传统信控模式下, 短彩信等PUSH类业务需要经过业务平台承载业务、生成计费话单, 再交由BOSS系统进行计费账务处理形成账单, 最后根据用户账户余额判定是否停止其对应服务功能从而完成信控。由于从业务使用到完成信控之间流程较长, 容易被不法份子采取高频群发手段给运营商造成较大运营风险。尤其是通信行业进入4G时代以来, 无线环境、传输速率、交换能力的不断提升, 以及自动发送工具的出现, 为不法份子实施通讯诈骗、非法牟利提供了条件。不少省市的通信运营商均遭遇过此类问题, 只能采取加强实名制管理、渠道管控等有限手段被动防御, 事倍功半且防不胜防。不仅造成满意度下降、欠费增高问题, 也导致垃圾短彩信泛滥, 影响企业形象, 浪费资源。为此, 本文提出了一种新的信控方法并在中国移动四川公司彩信业务系统中进行了实践, 取得良好的效果。

1 四川公司垃圾彩信现状

受上述背景情况影响, 四川公司自2014年5月以来, 垃圾彩信数量飞速增长, 仅5、6两月就造成新增垃圾彩信月均6000万条, 新增彩信欠费月均3000万, 垃圾彩信投诉更是高达860件每周, 投诉量迅速攀升至全国前列, 形势异常严峻。而不法分子往往采取大量购买新卡、高频发送、发完即弃卡的策略逃避监管, 现有信控手段无法有效防范。公司当期有关垃圾彩信数量、欠费、投诉变化分析如图1所示。

2 解决思路

针对严峻的形势以及现有技术手段的缺陷, 四川公司在充分分析了恶意号码发送特征以及其它解决思路缺陷的基础上, 创新性提出了“发送鉴权+策略管控”的实时信控方法, 来高效、准确地解决彩信业务实时信控问题。其信控原理是当用户发起短彩信请求时, 短彩信中心向实时信控系统发送鉴权请求, 信控系统实时接收请求, 并实时收集用户发送特征, 结合预定信控策略识别是否为恶意用户并反馈鉴权结果, 短彩信中心根据鉴权结果转发请求或拒绝发送。

2.1 组网方式

本方案组网方式由彩信中心、彩信实时信控系统以及BOSS系统组成。彩信中心负责将用户请求通过DCC消息转发至彩信实时信控系统, 并根据彩信实时信控系统鉴权结果转发请求或拒绝发送, 彩信实时信控系统负责接收请求, 并实时收集用户发送特征结合预定信控策略识别是否为恶意用户并反馈鉴权结果, BOSS系统负责将BOSS系统白名单定期同步至彩信实时信控系统。彩信实时信控系统架构如图2所示。

2.2 工作原理

图3为信控过程工作原理图。

1) 彩信中心增加一个控制模块GFEP, 负责将EMPP协议转换为DCC协议, 当用户发送一个请求时, 彩信中心不直接转发而是向彩信实时信控系统发起鉴权请求;

2) 彩信实时信控系统计数模块通过DCC消息接收鉴权请求并记录用户本次请求信息;计数模块采用多通道技术与分布式技术并发处理彩信中心请求, 通过负载均衡提高并发处理能力 (目前处理能力为27000条/秒, 彩信中心承载能力为2700条/秒) , 还可通过线性扩展继续提高并发处理能力;

3) 计数模块采用多维扫描技术对用户发送请求进行实时统计, 一般可分为实时扫描1分钟时间片、每分钟扫描30分钟时间片、每30分钟扫描1天时间片内数据等几种模式, 也可根据恶意号码发送特征变化相应调整, 确保数据记录的及时性与完整性;

4) 鉴权模块采用SOA架构搭建组件式策略引擎, 包括发送频率、发送数量、在网时间和缴费记录等基本规则, 一般根据恶意号码发送特征针对性制定, 比如:1分钟内50条、30分钟内100条或则1天内150条, 判定阀值配置化, 可任意调整;未达判定阀值的当次请求反馈鉴权通过并继续参与后续识别过程, 白名单号码直接鉴权通过 (数据从BOSS系统同步) , 黑名单号码实时识别并添加, 一旦进入黑名单则直接拒绝;进入黑名单号码增加其对在网时间和近期缴费记录的判断, 避免误伤正常用户 (目前系统运行的数据显示, 尚未出现此类情况) ;

5) 所有过程性数据以及计算过程均在内存库中处理, 以进一步提高处理性能;

6) BOSS系统定期向彩信实时信控系统同步白名单, 其白名单号码本身已经经过BOSS系统信用管理、身份管理、要客管理等多种机制检验, 用户可信任程度高;

7) 彩信实时信控系统鉴权完毕后反馈至彩信中心, 彩信中心根据鉴权结果转发请求或拒绝发送。

3 方案的优点

本方案优点一是高效, 最快可在0.06秒内完成对恶意号码的识别与信控, 能有效遏制高频群发手段而对正常用户又无使用影响感知;二是准确, 通过对比拦截号码数据与被拦截号码彩信话单数量, 未发现一起有超过拦截策略预定阀值情况出现, 至今也未出现一起因拦截而导致无法使用投诉;三是效果好, 四川公司彩信实时信控系统于2014年7月14日上线, 上线后彩信欠费大幅降至月均不足10万元, 垃圾彩信投诉降至周均60条, 彩信总数量已回落至去年正常水平;四是改造简单, 容易实现, 四川公司彩信实时信控系统不需修改现有业务流程, 建设周期只有15天, 研发资金也不到60万, 至今已累计挽回经济损失1.7亿元, 后续还将继续发挥作用。

4 结束语

实时业务 篇8

关键词：异构网络,实时多业务,判断矩阵,接入网络

0 引言

随着智能终端大规模普及,用户对不同业务的个性化服务需求也越来越多,所以在无线异构网络环境中,网络之间的协同、融合互通可以给用户提供更好的通信服务,选择最佳的网络接入可以提高服务质量和用户满意度[1]。3GPP将3G业务分为4种类型,包括流类、背景类、会话类、交互类。不同的业务所需考虑的主客观因素、特性也就各不相同,包括带宽、时延、抖动、费用、用户策略等,也就构成了多属性决策问题[2,3]。

在异构网络中,如何选择最合理、高效的网络接入移动用户已然成为了该领域的研究热点,较为常见的是基于多属性判决策略选择最优网络接入。例如文献[1]提出根据网络属性和用户偏好,分别采用TOPSIS算法和AHP算法进行两次判决,利用效用函数选择网络。文献[4]则通过模糊多属性分析法确定主观权重,熵值法确定网络客观权重,根据隶属度加权得到最优网络。文献[5]是利用AHP对用户策略和不同业务确定主观权重,引入熵权确定网络客观权重,最后通过TOPSIS进行加权排序,获得最优网络。上述算法虽然都考虑了用户策略的主观权重和网络属性的客观权重,但在多属性多业务环境下,都只考虑了实时单一业务的情况,而没有兼顾到同一时刻有多种业务对网络选择的影响,可能会导致效率降低,负载不均衡、乒乓效应等情况。

针对上述问题,本文在已有观点的基础上提出了一种基于实时多业务的异构网络选择算法。该算法考虑用户属性的主观因素和网络属性的客观因素,同时考虑实时多业务场景及其优先级差异,重新构造判断矩阵从而选择出最优网络。实例和仿真结果证明了本文算法的有效性。

1 实时多业务网络选择算法

本文算法基于3GPP的业务分类加以研究讨论,算法需要首先确定主观权重,然后确定客观权重,最后根据主客观权重选择最优网络。

1.1 主观权重

层次分析法AHP由T.L.Satty在20世纪70年代提出,现已成为有效解决多属性判决问题最为常用也是最为重要的方法之一。AHP可以很好地反映出用户的需求、偏好等主观属性的影响[6,7,8,9]。

1.1.1 建立层次结构模型

业务类型的不同,其对属性参数的要求也不同,如表1所示。根据业务类型对Qo S属性的要求,本文选取时延、抖动、带宽、丢包率作为Qo S的设置参数。

为了更好体现用户的需求,除Qo S的相关参数属性外,还选择费用、安全性、网络负载、历史偏好等属性作为判断参数。根据AHP的层次结构,即目标层、准则层、方案层,构造出本文算法的层次结构模型如图1所示。

1.1.2 构造判断矩阵

为了确定各属性参数对最优网络选择的影响程度,需将其量化以便于计算。在层次分析法中,Satty等建议通过引用1~9及其倒数来标度属性两者之间的重要程度,以此来构造判断矩阵。其标度值及含义如表2所示。

由表1可知,不同的业务对属性参数的重要程度是不同的,所以给每个业务选取一个最为重要的属性来表征该业务。这里设定会话类的属性为抖动,交互类为时延,流媒体类为带宽,背景类为丢包率。本文算法基于同一时刻有多类业务在进行,为方便起见,这里只考虑同时有2类业务存在情形。将Qo S的属性元素两两组合成一组,例如(时延,抖动)、(时延,带宽)、(时延,丢包率)、(抖动,带宽)、(抖动,丢包率)、(带宽,丢包率)等,即可利用属性表征业务视为同一时刻有两类业务在同时进行。把两两组合后的一组元素视为一个新元素,利用新产生的元素替换原有的Qo S属性元素。根据属性元素利用上述的1~9标度法构造一个判断矩阵A:

其中aij表示同一时刻的两类业务对应属性间重要程度的比值,n为元素的个数。

1.1.3 确定权重

根据特征根和方根法计算出权重,然后进行归一化处理就可以得到权重向量。

①设Aw=λmaxw,可得:

式中λmax为A的最大特征根,w为对应的特征向量,n为评价参数个数,aij为矩阵A中的元素值。

②计算wi的n次方根:

③对归一化处理,即:

④一致性检验。因为判断矩阵是由用户主观上得出的,所以有必要进行一致性的检验。

其中C.I.是一致性指标,n为判断矩阵阶数,C.R.是一致性比例,R.I.是平均随机一致性指标查表可得。当C.R.<0.1时,认为具有满意的一致性,否则对判断矩阵A修正,直到获得满意的一致性。

由以上可得,各个判决属性参数的权重向量

1.2 多业务的优先级权重

在实时多业务的情况下要同时考虑两类业务,在选择最优网络的时候业务之间的网络属性可能会产生相互的冲突,也就是说不同业务对网络属性的要求之间会出现相互矛盾的情况。这就要求用户要根据自己的喜好或实际情况在业务产生冲突时要确定各个业务之间的优先级,优先满足某类业务。

依照上述层次分析法,针对各类业务的优先级构造出判断矩阵B=(bij)n×n,i,j=1,2,…,n,n为业务数量。遵照上述的层次分析法的权重向量的计算方法,可以得出判断矩阵B的权重向量

将由前面计算出的判决属性参数的权重向量和业务类型优先级的权重向量进行结合作为主观权重向量。根据式(4)可得统一后的权重向量为最后确定的主观权重向量,n为业务数量。

1.3 客观权重

1.3.1 构造决策矩阵

根据多属性的判决元素,将判决参数作为决策指标,可用网络为候选方案。由当前网络环境下的参数值可得多属性决策矩阵C=(cij)m×n,m为候选网络数量,n为判决元素数量。

不同指标类型之间可能会存在矛盾性和不公平性,比如效益型指标和成本型指标,需要对矩阵C进行标准化处理。

对于效益型指标,例如业务带宽、安全性等,其值越大越好,需按式(5)规范化处理。

对于成本型指标,例如抖动、丢包率、费用等,其值越小越好,需按式(6)规范化处理。

进行归一化处理后就可得到标准化决策矩阵D=(dij)m×n,即:

1.3.2 客观权重

基于信息论,信息熵是对系统差异程度的度量。熵权是一种客观赋权方法,体现了各个指标之间的动态变化程度及相互之间的竞争关系,引入熵权可消除多属性之间的主观随意性。如果属性之间的差异越大,熵则越小,所反映出的信息量就越大,反之亦然[4,5,10,11]。本文采用熵值法确定客观权重。

①由标准化决策矩阵D,由式(8)可得出网络判决属性的信息熵。

其中,Ei表示评价属性的信息熵,dij表示属性的标准化值,m表示网络个数。

②计算评价属性的偏差度Pi为:

可知,Pi越大,差异度越大,信息量也越大;反之dij则越小。

③计算网络属性的客观权重向量。

由以上得到了评价属性的客观权重向量为:

1.4 综合权重

由上述分析和计算已经得到了主观权重和客观权重,为了全面考虑多方面因素对选择接入网络时的影响,需将主客观因素综合起来作为决策依据。由式(11)计算出实际的综合权重向量

其中为主观权重向量,为客观权重向量,α根据实际业务对网络的相应要求确定。

1.5 选择最优网络

理想方案的序数偏好算法TOPSIS(Technique for Order Preference by Similarity to an Ideal Solution)是处理单一决策的多目标情况而提出的排序方法。它的核心思想是最优方案应该与理想方案的距离最近,与最差方案的距离最远。其中理想方案由网络属性的最优值构成,最差方案则由网络属性的最差值构成,距离为加权后的欧几里得距离[2,3,12,13]。

(1)将上述决策矩阵D进行无量纲化处理,由式(12)可得无量纲的标准化矩阵R=(rij)m×n,m为候选网络数量,n为属性元素数量。

其中dij为矩阵D中对应位置元素的值。

(2)构建规范化矩阵,由式(13)可得规范化矩阵V=(vij)m×n。

其中wj为综合权重向量,rij为矩阵R中对应位置元素的值。

(3)确定正理想解A+和负理想解A-。

其中,vij为规范化矩阵V中元素的值,CB是正指标类参数,CC是负指标类参数。

(4)通过n维欧几里得距离来测量候选方案到正理想解和负理想解的距离。

计算与理想方案的贴进度:

其中,S+i为候选方案距A+的距离,S-i为候选方案距A-的距离,vij为规范化矩阵V中元素的值,v+i为A+中元素值,vi为A-中元素值。

(5)对前面得到的各个候选网络的贴进度C*i值进行排序,选取其值最大的候选网络作为最优网络接入。

2 仿真实验和结果分析

本文在Matlab环境下进行仿真实验,以此来验证所述算法的可行性和有效性。

2.1 仿真实验

假定存在4种无线网络环境,包括Wi MAX、UMTS、GSM、WLAN,多模终端位于同时被这4种无线网络环境覆盖的范围内。本文算法是在实时多业务的情况下讨论的,所以针对不同的业务对网络参数的严格程度不同,考虑到不同的业务类型针对网络参数有不一样的严格程度,这里设定背景类业务α=0.5,流类业务α=0.6,交互类业务α=0.7,会话类业务α=0.8。本文将采用传统的多属性判决选择算法进行对比实验。传统的AHP算法是在只有某一类业务情况下的网络选择,并没有考虑实时多业务的具体情况。仿真实验中把传统的多属性选择算法AHP与本文改进后的基于实时多业务算法进行实验对比,得出相应结果。

模拟的仿真场景如下所述,在异构网络覆盖的区域内,用户在t1时刻正在进行交互类业务例如网页浏览等,而在t2时刻用户开始会话类业务例如语音会话(IP电话)。在异构网络区域内的t2时刻用户同时进行网页浏览和网络语音通话,这就构成了实时多业务场景。在场景中,各种业务按参数为λ的泊松分布过程到达网络的重叠覆盖区域,各类业务的持续时间则服从均值为μ的指数分布。

根据Wi MAX、UMTS、GSM、WLAN这4类网络相应属性的实际情况,假定在上述仿真场景下多模终端监测到的网络参数如表3所示。

2.2 结果与分析

根据以上假定的仿真场景及参数值,将本文所述基于实时多业务算法和传统的单一业务算法进行了实验对比。仿真实验结果如图2-图4所示。

从图2中可以看出,随着业务到达率的不断增加,不论是实时多业务还是实时单一业务的平均切换率都有一定的波动,但实时多业务在平均切换率的整体数值上比实时单一业务要有明显的减少。由图3可知,当业务到达率增加时,业务的阻塞率也在不断地增大,然而实时多业务的阻塞率要较低于实时单一业务。图4表明,当业务到达率不断增大时,实时多业务比实时单一业务的网络负载更低更加均衡一些。

由以上实验结果和分析可以得出,当同时进行多种类型的业务时,同时考虑多种业务要比只考虑单一的业务得到了更优的性能,在切换率、阻塞率以及网络负载等方面都得到了一定的优化,一定程度上提升了用户的体验。

3 结语