银行核心业务系统总体设计说明书12020年5月29日文档仅供参考四川农信综合业务网络系统总体设计说明书四川省农村信用合作社南天电脑系统有限公司 8月1. 系统网络拓扑 42. 系统逻辑结构 53. 数据流说明 64. 核心系统逻辑架构 75. 交易模式 85.1. 通讯方式 85.2. 数据一致性保证 95.3. 复核交易处理 115.4. 抹帐交易处理 125.5. 授权交易处理 136. 机构逻辑结构 166.1. 清算机构逻辑 176.2. 机构的设置 176.3. 机构管理层次 186.4. 机构核算单元上收 196.5. 数据要素设计 197. 帐务结构与核算方式 227.1. 帐务组织结构 227.2. 数据模型和帐务登记 257.3. 帐号结构 307.4. 双边分录 317.5. 流水设置 337.6. 交易处理规则 338. 应用实现框架 348.1. 交易开发配置流程 348.2. 交易服务处理过程 368.3. 应用实现规则 389. 关键实现说明 449.1. 并行处理 449.2. 24小时处理 479.3. 费用处理 519.4. 资金清算 569.5. 数据安全 6210. 总体需求说明 6410.1. 支持商业规则可配置化和业务逻辑可配置化 6410.2. 全面产品管理 6810.3. 完整灵活的收费处理 7010.4. 批处理控制平台 7010.5. 历史数据及管理分析与核心相分离 7110.6. 统一的外部系统API 7310.7. 前台系统先进性要求 73四川农信综合业务网络系统的目标是:结合四川农信具体情况,建立一套以客户为中心、账务核算统一、本外币一体化、业务、网点综合化、事中控制、支持24小时服务、支持全面产品管理、参数化、模块化设计的新一代综合业务系统。
为了保证这一目标的达成,结合四川农信的新一代综合业务系统的要求,从底层开始对整个综合业务系统进行了设计和规划从内容来看,总体设计需要涉及的主题有以下一些方面n 系统网络拓扑n 系统逻辑结构n 数据流说明n 核心系统逻辑架构n 交易模式n 机构逻辑结构n 帐务结构与核算方式n 应用实现框架n 关键实现说明1. 系统网络拓扑系统网络拓扑如图所示,结构上划分为四层,包括:省中心、地市中心、县中心和网点省中心:全部业务系统都集中运行于省中心,包括:核心业务系统、综合前置系统等关键应用参用数据库服务器与应用服务器分离的做法,而且双机互为备份存储采用专业存储设备进行高速存储在中心局域网上还有管理和监控前端等地市中心:四川省农信地市中心可能存在两种情况,一种是地市中心存在统一管理功能,此类地市中心在地市有统一的管理监控前端;另一种地市中心仅有网络汇集的功能县中心:具备县联社的统一管理功能;也是县内网络到地市或到省中心的网络汇集点;同时,全县的网络前端服务器集中于此网点:是对外直接服务的窗口,所有的网点终端经过远程网络连接的方式连接到县中心前端服务器进行业务处理,在将来一些自助服务设备也会在网络直接连接。
2. 系统逻辑结构系统逻辑结构如图所示:本次项目实施的四川省农信综合业务网络系统(SC6000),包括:后台核心业务系统OFP CoreBanking、中台交换前置和中间业务平台系统OFP PreBranch和前台柜面前端系统OFP AutoBranch后台核心业务系统CoreBanking:负责完成银行全面帐务管理和基础金融产品,是整个银行的帐务核心,并为银行后续的业务管理和分析提供基础分析数据基于核心业务系统,传统柜面业务都获得服务支持,并支持以客户为中心、面向产品管理、高度参数化、全面支持24小时不间断服务等一系列新一代综合业务系统的优良特性中台交换前置和中间业务平台系统OFP PreBanch:负责完成后台应用间的交换和互联,并基于平台提供的成熟框架,连接系统外第三方应用并支持丰富的中间业务开发前台柜面前端系统OFP AutoBranch:负责完成所有柜服务的前端展现和处理采用LINUX操作系统实现3. 数据流说明如系统逻辑结构图中所示,在交易处理中:当进行银行传统金融业务处理时(包括:活期、定期、贷款、结算等),柜员在前台发起交易,交易请求直接发送到后台核心业务系统中实现业务处理;当进行中间业务和银行扩展金融业务处理时(包括:代收费、大额、小额等),柜员在前台发起交易,交易请求首先到达中台前置系统,由中台系统进行本地业务处理和业务调度,根据需要调用后台核心业务系统和第三方业务系统。
基于统一的业务系统接口规范和交换前置的应用处理,在中心后台的两个应用间不允许存在相互间的直接访问,必须经过交换前置系统进行请求的转发例如:在将来的国际业务系统需要进行业务记账,业务请求首先到达中台交换前置系统,经过中台的应用解析,在将请求逐笔的传递到核心业务系统中实现记账除了柜面的请求,其它的服务渠道包括:ATM、POS、银行、网上银行等的业务交易全部都是首先上到中台交换前置系统,进行本地必要的业务处理,然后在向相应的服务端应用发出调用请求由于在三个应用平台系统中,核心业务系统是主要业务的处理端和服务端,也是整个系统框架的基础部分与核心部分,因此核心业务系统的设计至关重要,在下面的讨论中,我们也将主要面向核心系统进行阐述,对中台OFP PreBranch和前台OFP AutoBranch请参看相关文档,在此不再赘述4. 核心系统逻辑架构核心系统在技术逻辑结构上设计如图:逻辑架构上,核心系统分为核心服务层和金融产品层两个层次相对隔离,经过标准调用接口,实现访问调用核心服务层包括提供全行的会计核算、客户管理、公共管理功能稳定、高效,并具备前瞻性的设计,是确保四川农信综合业务系统可持续发展的重要保证。
p 会计核算的其中会计核算实现业务的综合核算功能;p 客户管理收集全行客户信息,并建立客户与账户全面关联关系;p 公共管理实现系统公共参数的统一管理,包括:机构管理、柜员管理等金融产品层设计上采用插件式的思想,新的业务可灵活、容易的”插入”到CoreBanking系统中来在各金融产品服务中实现业务的明细核算功能实现上,应用请求首先经过统一的交易分发管理,调用相应的处理服务流程完成服务金融产品层中,提供的服务大致上包含三个主要的类型:p 专门的核心调用接口提供给银行内部的其它应用群进行帐务处理调用p 丰富的金融产品组件提供银行柜面调用,如:活期、定期、贷款等p 核心层的专用调用组件,提供业务人员直接使用如:报表管理、客户管理、前后台管理等5. 交易模式交易模式描述的内容包括交易的通讯方式、数据一直性保证、复核交易的处理、抹帐交易的处理、授权交易处理5.1. 通讯方式p 通讯协议采用TUXEDO－FMLp 对于柜面交易采用同步短连接方式p 系统除了提供交易报文通讯外,还支持交易的文件传输,在文件传输时只允许前台申请上送或下传当后台需要下发文件时,需在交易报文中带下传输文件名,由前端平台再进行文件传输处理。
p 为了保证系统的正常运行,减轻后台和网络压力,原则上柜台交易一般为一次通讯,有需要时原则上可进行一次查询,应尽量避免多次通讯p 在AutoBranch中,在tpinit时把详细的client端信息带到后台,以满足后台的管理要求同时为了解决对一些前台提醒的通知信息的处理,在AutoBranch中增加通知的公共处理,方式为在柜面前端的固定位置进行提醒5.2. 数据一致性保证p 事务处理系统统一在后端启动事务处理在交易配置时,是否启动事务为后端SYSMNG配置配置是否由主控启动事务配置不由主控启动事务的交易,由应用自行在处理过程中启动事务处理一般,对于交易类型为记账和管理的交易由主控启动事务;而查询和其它交易,则根据需要自行启动事务规则上,查询交易无事务,而且需要使用脏读由PreBranch发起的交易,PreBranch和CoreBanking分别启动事务在交易过程中还有一种特例,部分处理(如:获取柜员流水号、账号顺序号、授权交易处理等)需要跳出事务处理块执行,此时需要数据库中建立另一个连接,在新连接中启动完成单独动作,然后在回到第一个事务处理块详细请参见8.3.6. 数据库连接方法p 数据的一致性保证不同的逻辑单元间,由于中途存在网络因素,有不同的事务处理,可能存在双方不一致的可能性。
分两种情况描述如何处理不一致在柜台交易处理过程中,会出现因为网络等原因导致的前端交易上送后没有得到确定的成功失败返回(一般是超时退出),如果处理是记账交易,柜员必须查询后台,而且以后台交易的结果为准为了保证资金的安全,在未能获取后台交易结果前,必须分情况进行处理,当办理的是需要收取客户资金的交易(如存款)则默认为交易成功,并收取客户资金;当办理的是需要支付客户资金的交易(如取款)则默认为交易失败,不支付客户资金当网络恢复后,柜员查询后台的交易处理结果,根据后台的处理结果采用抹帐、冲正、重做、补登等手段完成后续处理例如:柜员办理一笔存款交易时出现超时,这时柜员经过查询交易查询后台流水,如果发现该笔交易后台是未成功的,则再次办理一笔存款交易如果发现是成功的,这申请补打存款凭条、存折(没有该功能时可柜员手工填写)如果发现是网络不通,则手工填写凭条、存折给客户,等网络通了再处理当交易是由PreBranch发送后台的交易,则需建立应用间自动冲正机制或自动重发机制,在网络状态不明的情况下,中台自动发起抹帐交易(或重发动作),并返回前端失败在中台日终时,需要启动PreBranch与CoreBanking的对帐,对帐中数据以PreBranch数据为准进行错帐处理。
因此在柜面前端,交易的一致性经过柜员的确认以及业务制度配合保证;在无人值守的后台应用间,交易的一致性经过交易时的自动冲正机制(自动重入)以及日终的交易对帐确保5.3. 复核交易处理系统中的复核交易有两种,一种是对某些业务流程中要求的复核交易(如联行中的往帐报单复核交易),这些交易是复核后才完成帐务处理的,属于事中复核,这些交易一般是每种业务单独有自己的复核交易;一种是业务流程中没有复核要求,出于安全考虑而增加的事后复核(如对公的存取款),这些交易的复核使用公共的复核交易不论是那一种复核,现在都采用后台复核的方式,待复核的数据都存在后台,不再在前端保留电子日志对于非公共的复核交易,交易模式上与一般交易没有太多差别,这里不再具体说明,下面主要对公共的复核交易进行说明公共复核交易采用统一的交易入口,流程如下:公共复核交易基于后台柜员日志表(参看后台流水设置),需要公共复核的交易,在正常交易发起时,在后台柜员日志中会插入一条记录,标记为待复核,同时将需要复核的要素拼装成字符串后在后台存放前台发起公共复核交易时,按照前端输入的查询条件查询待复核流水和每条流水对应的复核要素串一起下传前台,在前台完成复核要素的比对处理,在结束复核交易时将成功复核的流水批量发到后台修改对应柜员日志的复核状态。
5.4. 抹帐交易处理抹帐是指对原交易的取消处理,在业务发起当天,如果发现交易有错,在经过授权的条件下发起抹帐交易,取消原交易抹帐交易使用统一的交易入口(除个别批量发起的业务,如传票套记帐),以后台柜员日志表中的柜员日志号为。