第一篇：招商银行业务系统
银行业务系统介绍
http://blog.csdn.net/housheng33
银行业务系统介绍
核心业务系统、
按照服务对象的不同，可分为二大类。
第一类，服务对象为银行客户，提供的服务包括存款、贷款、结算、代理等。 第二类，服务对象为银行自己，提供的服务包括网点/柜员管理、总账、内部账、现金、凭证、报表等。
国际业务系统、
该系统包括国际结算和外汇清算两部分，能够自动处理信用证、托收、汇款、头寸管理、外汇买卖平盘等业务，实现了国际结算、SWIFT通讯、资金清算和账务处理的无缝连接，自动清分信息、自动清算资金、自动处理账务、自动核对账务
对私(个人)信贷业务系统、
银行信贷管理是指商业银行如何配置信贷资金，才有利于发展经济并增加自身盈利的决策活动。其内容包括：管理信贷关系;管理贷款规模和贷款结构;管理贷款风险，提高贷款经济效益;建立合理的利率体系，正确贯彻利率政策;改进结算服务，加强结算管理。
中间业务系统、
中间业务是未来银行最有前景的业务。 所谓中间业务，是指商业银行不运用或较少运用自己的资金，以中间人的身份替客户办理收付和其它委托事项，提供各类金融服务并收取手续费的业务。它 是 在 基 本 金 融 产 品 ( 如 储 蓄 活 期 、 借 记 卡 等 ) 的 基 础 上 提 供 的 增 值 服 务 。
商 业 银 行 通 过 此 类 增 值 服 务 ， 不 仅 可 以 扩 大 储 蓄 存 款 、 增 加 手 续 费 收 入 ， 同 时 可 以 为 客 户 提 供 多 种 优 质 、 便 捷 的 服 务 ， 从 而 更 好 的 保 持 和 发 展 客 户 关 系 ， 增 加 客 户 的 忠 诚 度 . 目前商业银行的中间业务主要有本、外币结算、银行卡、信用证、备用信用证、票据担保、贷款承诺、衍生金融工具、代理业务、咨询顾问 业务等。在国外，商业银行的中间业务发展得相当成熟。美国、日本、英国的商业银行中间业务收入占全部收益比重均在40%左右，而我国目前商业银行表外业务 的规模一般占其资产总额的15%以上。
http://blog.csdn.net/housheng33
公司网银系统、
光大银行企业网上银行系统是基于光大数据大集中系统为客户提供的Internet服务，具有“一点接入，全辖服务，实时到账”等优势，是专为对公用户量身定做的网上银行服务，对公客户只要注册为网上银行用户，通过互联网登录光大银行网址：，足不出户即可享受银行提供的查询、转账等多项金融服务，实现对公客户与银行间的无缝对接，安全又快捷。
个人网银系统、 CIF系统、
目前各商业银行核心账务数据逐步完成大集中后，处理系统主要包括核心账务处理系统和分布在各省市分行的外围业务处理系统，后者又包括了中间业务、网上银行、手机银行、电话银行、银券通等多种处理系统。由于各地业务需求的不一致，加之目前总行集中处理系统的重点在于核心账务的处理，因此，与银行中间业务和外围服务渠道相关的客户资料及签约关系分散在分行各业务系统的前置处理机上。客户资料的分散存放无法保证各系统客户资料的一致性，也无法进行数据共享。客户为了享受银行不断推出的新产品，必须多次携带本人有效证件到银行网点办理相关业务的签约手续。这给客户带来了极大的不便，银行工作人员也必须多次输入相同的客户信息。所以，有必要在商业银行省级分行内，以总行集中账务处理系统为依托，开发以客户为中心的分行客户服务系统。当然，随着信息技术的发展，在商业银行总行建立与集中账务处理系统相并存的客户信息系统也将是一种趋势。
理财产品销售系统、
理财产品销售系统为银行提供各种理财产品的统一销售管理平台，系统连接行内、行外的多个系统及渠道，实现开放式基金、行内理财产品、新股理财产品、券商理财产品、保险理财产品、信托理财产品、他行理财产品等各类理财产品的自销或代销。使银行充分发挥其地域优势和服务渠道优势，为本地优质客户提供多样的、灵 活的理财服务，同时与同业机构或其他金融机构展开紧密合作，扬长补短。
收单系统(银行卡收单系统)、
收单银行 (Acquiring Bank)服务对象为特约商店，收单银行向商店推广接受信用卡为 付款工具，但收单银行会先在严格审核商店信用的优劣之后，再与商店签约成为特约商店，并提供信用卡单据兑现服务及收取手续费。相关业务包括提供特约商店 POS终端机、电子清算系统EDC及必要的黑名单，并授权特约商店检查信用卡之真伪及有效日。一切步骤完成，特约商店取得持卡人正确签名并完成交易后，即 可持信用卡单据向收单银行申请兑现。
http://blog.csdn.net/housheng33
理财登记过户系统、
随着理财业务的快速发展，投资者对理财产品的需求已经不仅仅追求收益率，而且对产品的灵活性有了更高要求，于是各式各样为适应不同人群需求的理财产品被设计出来，其复杂性已经大大超越了模式相对固定的理财产品业务,以订单处理为主要功能的销售系统已经难以完全支撑新业务品种，需要有一个以理财产品资产为管 理重心的登记过户系统来配合，才能有效的支持新业务。在充分考虑未来理财业务的发展趋势，并参考了国外财富管理系统的业务规划和系统建设经验后，恒生公司 设计、开发了一套先进的、实用的银行业理财产品登记过户系统。
二代支付系统、
超级网银具有：统一身份验证、跨行账户管理、跨行资金汇划、跨行资金归集、统一直联平台、统一财务管理流程、统一数据格式等七种产品特色的二代支付系统。
手机银行、
移动银行(Mobile Banking Service)也可称为手机银行，是利用移动通信网络及终端办理相关银行业务的简称。作为一种结合了货币电子化与移动通信的崭新服务，移动银行业务不仅可以使人们在任何时间、任何地点处理多种金融业务，而且极大地丰富了银行服务的内涵，使银行能以便利、高效而又较为安全的方式为客户提供传统和创新的服务。
电话银行系统、
电话银行服务系统(TELEPHONE BARVER SERVER)是九十年代国际上出现的一种新的银行服务，由于它采用了目前世界上最先进的电脑FAX/语音转换技术，使银行的各种资料通过电话语音和传真机及时准确的传递给客户，把银行的电脑化服务推进到一个崭新的台阶。
电话银行系统(TelephonBarver Server)是近年来国外日益兴起的一种高新技术，它是实现银行现代化经营与管理的基础，它通过电话这种现代化的通信工具把用户与银行紧密相连，使用户不必去银行，无论何时何地，只要通过拨通电话银行的电话号码，就能够得到电话银行提供的其它服务(往来交易查询、申请技术、利率查询等)，当银行安装这种系统以后，可使银行提高服务质量，增加客户，为银行带来更好的经济效益。
票据系统、
银行票据指由银行签发或由银行承担付款义务的票据。主要包括银行本票、银行汇票、银行签发的支票等。
http://blog.csdn.net/housheng33
第三方存管系统、
银行和券商开展客户交易结算资金第三方存管业务，使银行真正负担起“银行管资金”的职责，银行担任客户交易结算资金的出纳和保管职责，负责管理客户交易结算资金管理账户和客户交易结算资金汇总账户，向客户提供交易结算资金存取服务，并为证券公司完成与登记结算公司和场外交收主体之间的法人资金交收提供结算支持，通过总分核对和结算备付金监管等机制，防止证券公司挪用客户交易结算资金。
对公信贷业务系统、
信用卡系统
信用卡能给银行带来三类 利润，一是年费，二是手续费，刷卡消费能使发卡行获得占客户消费经费金额 2% 左右 的佣金; 三是持卡人因透支付给银行的利息， 银行看重的就是透支利息。 超过免息期后， 信用卡透支消费的年利息高达 18%
第二篇：人民银行业务系统、业务术语英文简称汇总
中国现代化支付系统……………………CNAPS 大额支付系统……………………………HVPS 小额支付系统……………………………BEPS 清算账户管理系统……………………SAPS 支付管理信息系统……………………PMIS 支付业务统计分析系统………………PSAS 支付业务监控系统……………………PMCS 中央银行会计集中核算系统…………ABS 国家金库会计核算系统………………TBS 城市处理中心…………………………CCPC 国家处理中心…………………………NPC 前置机系统……………………………MBFE 支票影像交换系统……………………CIS 支付信用信息查询系统………………PCIS 中央银行会计核算数据集中系统……ACS 中央银行会计监督系统………………ACCS 中央债券综合业务系统………………CBGS 行名行号管理系统……………………BCMS
一、中国现代化支付系统
中国现代化支付系统(China National Advanced Payment System,简称CNAPS)是中国人民银行按照我国支付清算需要，利用现代计算机和网络通讯技术所开发建设的，用于处理各银行、清算组织办理异地、同城各种支付业务及其资金清算和货币市场交易的资金清算应用系统。它是各银行、清算组织和货币市场的公共支付清算平台，是人民银行发挥金融服务职能和实现货币政策职能的重要核心支持系统。
现代化支付系统共有4个主要的应用系统，分别是： (1)大额实时支付系统(HVPS)：处理同城和异地跨行之间和行内的大额贷记及紧急小额贷记支付业务，人民银行系统的贷记支付业务以及即时转账业务等。支付指令实时处理，全额清算资金。
(2)小额批量支付系统(BEPS)：处理同城和异地纸凭证截留的商业银行跨行之间的定期借记支付业务，人民银行会计和国库部门办理的借记支付业务，以及每笔金额在规定起点以下的小额贷记支付业务。批量发送支付指令，轧差净额清算资金。
(3)清算帐户管理系统(SAPS)：是支付系统的辅助支持系统，集中存储清算账户，处理支付业务的资金清算，并对清算账户进行管理。
(4)支付管理信息系统(PMIS)：是支付系统的辅助支持系统，集中管理支付系统的基础数据，负责行名行号、应用软件的下载，提供支付业务的查询查复和计费,以及统计监测等服务。
支付管理信息系统(PMIS)包括支付业务统计分析系统(PSAS)和支付业务监控系统(PMCS)两个子系统：
1.支付管理信息系统(Payment Management Information System-PMIS)
支付管理信息系统是中国现代化支付系统的支持系统，包括基础数据管理、行名行号管理、运行控制、计费管理，以及支付业务统计分析、支付业务监控等系统，是一个多功能模块的分散式的管理信息系统。
2.支付业务统计分析系统(Payment Statistical and Analysis System-PSAS)
支付业务统计分析系统是PMIS的重要组成系统，提供资金流量流向、支付业务量等多方面的统计分析处理，供中国人民银行及其授权的用户使用。
3.支付业务监控系统(Payment Monitor and Control System-PMCS)
支付业务监控系统是PMIS的重要组成系统，提供支付系统运行状况、异常支付业务等数据的实时监控，供中国人民银行支付结算司及其授权的用户使用。
二、中央银行会计集中核算系统
中央银行会计集中核算系统(Central Bank Centralized Accounting Book System-ABS)是人民银行采用集中核算方式处理会计业务，并与支付系统或电子联行联接，办理资金汇划和为金融机构提供资金结算服务的网络系统。
三、中国银行国库会计核算系统
中国银行国库会计核算系统(Central Bank Treasury Book System-TBS)是为适应财政国库管理制度和中国现代化支付系统建设而开发的，为适应国库单一账户核算体制的改革，加快国库资金汇划速度，地市级(含)国库会计核算系统与支付系统城市处理中心连接办理支付清算业务，县(市)级国库的支付清算业务通过国库系统发送地市提交支付系统处理。
国家处理中心(National Processing Center，简称NPC)，是连接支付系统所有城市节点和特许参与者的中枢节点，负责接收、转发各CCPC和接收、处理特许参与者的支付指令，以及资金清算的一组硬件和软件系统的总称。
城市处理中心(City Clearing Processing Center，简称CCPC),是支付系统的城市节点，连接NPC和各直接参与者，负责在NPC和直接参与者之间接收和转发支付指令的一组硬件和软件系统的总称。
商业银行前置机系统(Member Bank Front End,简称MBFE)，是摆放在商业银行等银行机构，连接支付系统CCPC，并负责接收、发送通过支付系统处理本行支付业务的系统。
全国支票影像交换系统(CICS/National cheque image clearing system) 综合运行影像技术和支付密码等技术，将纸质支票转化为影像和电子信息，实现纸质支票截留，利用网络技术将支票影像和电子清算信息传递至出票人开户行进行提示付款，实现支票全国通用的业务处理系统。
总中心 (NCCC/national cheque clearing center) 全国票据影像交换系统的核心节点，负责系统的运行和管理，接收并转发全国业务;建立全系统的支票业务登记簿并集中存储所有票据影像信息。
分中心 (RCCC/ regional cheque clearing center) 全国票据影像交换系统的二级节点，按照经济区域或省级行政区域设立，负责辖内票据交换机构的支票影像信息和电子清算信息的接收和转发。
票据交换所 (CH/ACH clearing house/automated clearing house) 全国票据交换系统的基层网点，负责通过前置机发送和接收票据交换业务数据，可根据票据交换机构的委托代为采集支票影像信息及录入电子清算信息，按规定格式组成支票业务报文。
前置机 (CHFE/clearing house front end) 全国票据交换系统中用于发送和接收票据交换业务数据的系统设备，可安装在票据交换所和采用集中接入模式的商业银行。
票据交换机构 (POA/participant of ACH) 全国票据影像交换系统的参与者，通过全国票据影像交换系统办理跨区域支票业务的金融机构。
银行机构代码 (BC/bank code) 指按照中国人民银行规定的编码规则编制的,用于识别银行身份的唯一标识。
提出行 (BFD/PBE bank of first deposit/payee bank) 又称收款行或收款人开户行，指根据收款人委托提出支票，通过全国票据影像交换系统向出票人开户行提示付款的票据交换机构。
提入行 (PBY/paying bank) 又称付款行或付款人(出票人)开户行，指通过全国票据影像交换系统提入支票业务报文，进行核验后发出回执确认付款或作出退票处理的票据交换机构。
提出支票业务报文 (CCI/cheque clearing institution) 支票截留后用于提示付款的电子指令，由支票业务的电子清算信息和影像信息组成。
小额业务代理行 (ABI/agent of BEPS institution) 受未参加小额支付系统的票据交换机构委托，代为办理支票业务回执业务的小额支付系统参与者。
小额业务代理行可以为支付系统直接参与者或间接参与者。
支票回执业务包 (RIOCCI/return item of cheque clearing institution) 用于记载提入行付款核验结果的小额支付系统批量包。
逾期撤销 (AOI/abrogate of overdue instituion) 全国票据影像交换系统对在规定期限内未收到提入行业务处理回执的支票业务报文作自动撤销处理。
支付信用信息查询系统(Payment Credit Information Inquiry System-PCIS)
支付信用信息查询系统是企业和个人信用信息基础数据库的重要子系统，是面向社会公众的基于Web模式的公共信息查询系统。
PCIS系统通过采集、加工、分析银行结算账户违规行为、空头支票信息、信用卡恶意透支信息、银行承兑汇票垫付信息、商业承兑汇票违规信息、信用证垫付信息等违规支付信息，建立健全支付信用的信息披露和违约惩戒制度，有效促进相关当事人恪守信用、履行义务，大力推动非现金支付工具的发展，逐步改善票据信用环境，提高社会整体信用水平。
行名行号管理系统(Bank Code Mangement System,简称BCMS)，是利用互联网平台和浏览器技术实现支付系统参加单位行名行号信息申报、审查、下发和管理的自动化处理。
凭证影像监督系统IAS 中央银行会计核算全国数据集中系统ACS
这二个已经是正式命名立项
补充：
PICP--联网核查身份信息系统
TIPS--国库业务信息系统(税库银横向联网系统)
TPS--国库收支统计分析系统
MAS--中国反洗钱信息监测分析系统
中央银行会计凭证影像事后监督系统(IAS)：IAS是运用影像技术，将原始会计凭证转化为影像电子信息，实现利用影像进行事中控制、事后监督和会计凭证电子化管理的业务处理系统。
其结构与组成：IAS由后督子系统(AAS)和凭证影像子系统(IMS)组成，子系统之间相对独立、通过接口进行数据交换。AAS导入凭证影像信息，IMS导入核算数据和监督结果数据，通过数据共享实现系统整合。
FIMS 中国人民银行财务综合管理系统
第三篇：金融系统概述--银行业务概述
银行核心系统入门简介
本文的目标读者是准备从事银行核心系统开发、维护的从业人员。请注意，是“准备”，换句话说，可以理解为一份对科技人员，尤其是对新入门的科技人员业务知识方面的培训手册，旨在让诸位从业务方面迅速上手(从技术角度上手的手册我已经贴过一份了，所以如果是用400的同行，可以结合本手册双剑合璧，效力倍增)。这里的着重点将会主要在于简单的银行会计原理，以及银行整体的业务流程，还有相应的模块实现手法和注意事项，对金融的会计知识方面应该可能会比较粗浅，这一点与金融系统常见的业务培训手册有所不同，注意体会。
基于此，本文将会假设读者具备一定的计算机技术，具备少量银行方面的业务知识，所以如果有从事非IT部门的读者(比如财务信贷的同事们)，就请不要太计较里面的表述。当然如果有错误，还是非常欢迎指出的。
对于已具备了若干开发、维护知识，或者是即将采用国外系统来建设的同行们而言，本文的内容可能就过于浅显了，看得不爽不要怪我没有事先提醒。
考虑到某方面的问题，这里的系统简介将尽可能的脱离某个具体的系统，仅就银行业务核心系统的共性，进行介绍以及探讨。
最后再说一下，没有什么手册、心得是万能的，个人的LEVEL UP始终是要靠自己的领悟，这里只是希望能让诸位新人不用象很多人当年一样，独自摸索与徘徊。
1 科目常识
基本法则之一：资产 = 负债 + 所有者权益。
比如说，我们手头上有40万，买了一个100万的房子，找银行贷款了60万，那么资产就是100万，负债是60万，所有者权益是40万。可以简单的把所有者权益就理解成为是真正属于自己的钱。再引申一下，早些年乃至现在，香港人所谓的“负资产”的说法是非常错误的，因为“负资产”实际上是指房子的市值比向银行贷的钱还要小，也就是负债大于资产，所以严格的来说，应该称之为“负所有者权益”才对。资产，从理论上来说，是不可能为负的，最多也就是零 。一个号称是金融中心的地方，实在是不应该出现这种失误，不过算了，不要和他们计较。
就银行业务而言，会使用会计科目号来对账务进行标识，会计科目号最长为5位，国家标准，通常分为下面六种，这里只做简单介绍，详细科目可结合著名的的“业务状况表”来进行理解。
再次重申，下面的说法绝对不严谨，仅仅只是为了便于IT人员理解银行的会计原理、业务知识。
1.1 资产
资产类的科目，用“1” 作为首位科目号，如“1011”，表示现金。 所谓资产，也就是说“理论上属于银行的钱”， 比如说现金，贷款等。比如说某家分行，有100万现金，然后把这100万都贷出去了，那么资产仍是100万，只不过归属(科目)由现金变成了贷款。至于这笔贷款能不能收回，这个不归我们管，就算不能回收，只要没被核销(核销，术语之一，可以理解为银行不要这笔贷款了)，那么就仍然属于资产，所以我们称之为“理论上属于银行的钱”。
资产类科目都是借方科目，也就是借记时余额增加，贷记时余额减少。
1.2 负债
负债类的科目，用“2”作为首位科目号，如“2011”，表示对公存款。 本来不属于银行的钱，就称之为“负债”。比如说我们存在银行的钱，虽然银行可以使用这笔钱，比如说把它贷款贷出去啊，比如说打新股啊，买QDII啊，但是这笔钱只要我们去取，原则上银行就应该给我们，也即是大家常常在营业大厅里看到的“存款自愿，取款自由”之类的意思。这类钱，可以简单的理解为“本来不属于银行的钱”，也就银行欠我们的钱。
负债，很有趣的东西喔，银行是负债经营的，比如说一家银行贷款有100亿，其实它本身是没有那么多钱的，这些钱都是来自于我们存在它那的钱。如果大家一起都去银行的钱取出来，那它就经营不下去了，这种恶劣的行为，称之为“挤提”，是很不友善的，是要负责任的，我们不要去做。
负债类科目都是贷方科目，也就是借记时余额减少，贷记时余额增加。
1.3 所有者权益
所有者权益类的科目，用“3”作为首位科目号，如“3121”，表示利润分配。 上面说过了 ，所有者权益，也就是真正属于银行的钱，即是所谓的“核心资本”。原则上，它包括了一家银行注册时的资金，历年来的盈利(假设有盈利的话，当然还要扣除各类成本开销)，如果是股份制银行的话，还包括股本金之类的吧。
这类科目相对数量较小，金额较大。 科目属性忘了。
1.4 资产负债共同类(往来类)
资产负债共同类，通常表示往来账户，用“4”作为首位科目号，如“46411”，表示通存通兑。
这类科目，通常是指一些往来类账户，所谓往来类账户，嗯，就是金融往来的账户喽。 这个科目有点麻烦，可能要结合具体业务来解释一下：
比如说我们在招行有个账户，然后跑到工行的ATM上去取钱(招行也是，中山这种伟人的故乡居然都不开个点，严重BS一下)，那么取款成功之后，我们的招行上的账户的钱就少了，工行ATM里面的现金也少了。这笔钱是工行替招行先支付的，要找招行要的。所以工行一定会有一个科目，用来标记它有多少钱要找招行要;而招行也要有一个科目，也是要用来标记它有多少钱要给工行。(怎么要，那在后面清算一节里面会提到。至于跨行ATM的取款原理，就不用再细说了吧。)这个用来标记应付，应收的科目，就是往来类科目，对于工行方而言，当时使用到的就是一个类似于资产类的科目(有点类似于应收账款的意思，或者也可以理解成一种短期的贷款，总之就是工行先付出的资金);招行当时使用的就是类似于负债类的科目。
上面提到的，因为是银行与银行之间的业务往来，所以用来标识资产与负债的科目会有分别，如果是行内之间的往来，那么不会搞得那么复杂(或者也可以说搞得更复杂)，就会用一个科目来搞定，这个科目根据具体需要，临时用的，有时表示资产，有时表示负债(其实也就是科目上的余额有时是借方，有时是贷方。因为这个科目既不是资产，也不是负债，只是临时用来表示营业往来的，通常每天会清零，也就是所谓的清算。
一般而言，城市级别的商业银行因为是一级法人，所以清算之后，行内往来账户上余额为不为零都没什么关系，反正都是自已家的钱;而信用社会比较麻烦一点，因为通常一个联社都是由多个信用社组成，每个信用社都是一个法人，所以联社内部的往来类账户原则上每天应该都清零，否则账务上就不好看了。(注意，这里指的只是行内的往来账，如果是银行与银行间的，那每天一定是要清零的，否则就是属于错误的情况了)
这类科目在我们做过的项目里，基本上都简化了，只有一个轧差类型的。也就是把当天的借方发生额和贷方发生额一减，哪个大就谁记在哪边。
我记得以前还有一种双方类的科目，那真是玩死人。双方类的科目是指这个科目既有贷方余额，又有借方余额;对应贷方余额，既有借方发生额，又有贷方发生额，同理，对应借方余额，也是既有借方发生，又有贷方发生，如果只有上期的借贷方余额，以及当期的借贷方发生额，那是无论如何也推算不出当期的借贷方余额各是多少的。(必须根据发生账务时，是借方余额，还是贷方余额来判断)，不知道这类科目的起因为何，总之如果有的而且可能的话，最好能拆分之几个性质单纯一点的子目来处理。
不好意思，因为对这类科目感触颇深，也被玩过很多次，被玩很久，一时激动，就多说了几句。
1.5 损益类
损益类的科目，用“5”作为首位科目号，如“5011”，表示利息收入。
损益类科目，理解起来应该不难，就是指银行在一年的业务里面的收支科目。比如的存款利息，对于银行来说是一笔支出;贷款利息，对于银行来说，是一笔收入。这两个科目就都属于损益类科目。
一般来说：
收入类科目属贷方科目，借记时减少，贷记时增加; 支付类科目属借方科目，贷记时减少，借记时增加。
在理解上，可能与资产、负债类的科目有些相反：
资产是指属于银行自己的钱，是借方科目;对应于这里，收到的钱是银行自己的，却又是贷方科目。
这里，按会计原理来理解可能会更简单一点，下面一章会讲到。
1.6 或有资产负债类
或有资产负债类的科目，用“6”作为首位科目号，如“6011”，表示承兑汇票。
闻歌知雅意，顾名思义，“或有”，那自然就是“或者有”，也就是可能没有了，所以如果没见过也不奇怪。
这类科目见得少，一般可以忽视它的存在。 1.7 其它
这里再罗嗦一下，在科目下面呢，一般为了便于分类统计，所有的银行都会再设子目(一个子目一般又会对应多个小子目，或者说是说是多个账户)，这个子目，有的地方叫“业务代号”，有的地方叫“结算码”，总之都是一个意思。
要注意一下，科目号是国标，子目通常是自己内定的，对应于信用联社，就有可能是省里统一定的。也就是说科目这个东西走遍全国大致上都是一样，子目这个东西可能出省，出了城市，或者说一个市里不同的银行，可能都不一样。
2 简单会计原理
2.1 内部账户
这个问题，我在刚学的时候，曾经颇疑惑了一段时间，所以虽然很简单，但还是单独拿出来说一下。
所谓内部账户，是与客户账户相对应的。也就是说这些账户不是用来登记、反应客户的账户信息，而是反应行内的账务情况，比如说损益类科目的账户，就都是内部账户。
客户的账户，一般是客户来银行开户的时候，才建立的用来登记账务的账户; 内部账户，一般是分行成立之初，统一生成的。(一般都一个专门的程序，由操作人员来调用的吧)
其实对于内部账，在会计原则上，登记个科目发生可以。至于增加子目，乃至内部账户的概念，主要是为了后续的分类统计以及相应的分析。
说到这个账户，就顺便想起了表内表外的问题。表内账，都是正正式式，真金白银的钱;比如我们的存款什么之类的。而表外账，通常是一些统计之类的东西，比如说现在分行里有多少本存折啦，还有已经核销的贷款之类的。
表内账的单位，都是“元”;
表外账的单位，就百花齐放了，有的是“元”(比如说已核销贷款)，有的是“本”或者是“张”，比如说存折或者说什么有价单证。而最后，表外账在汇总统计的时候，不管是什么单位，就是统统一加了事，对于不是财会专业的，尤其是我们搞计算机的人来说，这种加法简直有些不可理喻，总之银行会计上就是这样处理。
所以说，一般报表里面，大家会对表内账比较关注，对表外账的要求不是太严格(我是这样偷偷的说，各位怎么处理是大家自己的事)。
2.2 复式记账法
只要是与会计有关的书，就一定会提到复式记账法，也称为借贷记账法，这里就不多解释，简单说一下。
“有借必有贷，借贷必相等”，这两句经典的话，是针对表内账的。对于表外账，用的其实是单式记账法，有的叫“收”、“付”，也的也还是用“借”，“贷”，要结合具体的业务来理解，这里就不展开了。如果没有特别说明，下面的描述都是针对表内账的。 对于银行业务来说，最简单的是一借一贷，此外，还有一借多贷，一贷多借。多借多贷在银行业务里中不允许的，因为这样无法精确的体现账务的起始与流向。不过在企业会计中，多借多贷又是允许的，所以说凡事无绝对。
有些时候，基于某些特殊的的原因(常见的主要是频繁的锁表问题)，可能会临时采用单边记账，但是最后一定会汇总补齐，否则就会出现“借贷不平”这样的严重问题。
2.3 冲账
做错了账，要改正它，就可以理解为冲账。
冲账有两种，一种是蓝字冲账，一种是红字冲账。
所谓的蓝字冲账，是指与原账务方向相反，金额为正的一种记账方式。 而红字冲账，就是指与原账务方向相同，金额为负的一种记账方式。 蓝字冲账，本质上是做一笔新的业务，仅仅只是实现了最终的余额正确，发生额会虚增，所以一般的明显有错的账务，会要求使用红字冲正。
红字冲账因为是负数发生，所以在统计的时候，发生额将会与原来的交易抵销，这样的话发生额就很严谨了。
实际上，对于一个系统而言，通常一笔业务的发生，并不仅仅只包括账务的登记，还会更改许多表中的数据。比如说一笔简单的取款交易，除了登记账务之外，客户的账户上的余额还会减少，这个很好理解吧。那么在冲账的时候，还需要将客户上的钱给它加回去。所以，关于冲账业务的设计，其实也是一个比较有趣的话题，这一点，将会在后面的章节中进行探讨。
3 业务流程描述
对于一个没有在柜面实习过的人，描述一下银行的业务流程，可能是有助于理解系统架构的。
银行的业务，大致上可以分为财务类的业务，以及非财务类的业务。 非财务类的业务这里不做讨论。
财务类的业务，又可分为自动业务，以及非自动业务。
非自动业务，就是那些必须在柜台办理的业务，比如说一些转账业务，或者金额较大的存取款业务之类的。这类业务，因为是由柜员发起的，所以会有一些单据打印留底，以做传票使用。
而自动类业务，就是由系统自动处理的，比如说我们在A分行有个账户，然后非要跑到B分行去取钱，那么B分行那部分的账务，对于B分行而言就是非自动业务;而A分行那部分的账务，对于A分行而言就是自动业务。
自动业务因为是自动发生，所以需要业务人员打印报表的时候，才能知道发生了什么业务。
柜员日间做各种各样的业务，然后到了下午关门以后，打印一份“科目日结单”，然后用柜员手头留存的传票，按科目逐一汇总累计，与打印出的科目日结单上的金额进行比对。有错一定要一查到底。所以原则上，这时打印的科目日结单，应该不包括自动业务，否则就会对应不上。
业务系统在批处理的时候，还会进行一些自动的账务处理，然后最后系统还应该会再打印一份完整的科目日结单，以及日计表(可以理解为业务状况表的简洁版)。至于那些自动业务，系统在批处理的时候，或者是柜员主动查也行，总之就是会有一份“他代本”的传票(对应于上面提到的业务，A分行的自动业务就应该属于A分行的“他代本”传票。而B分行的传票因为是非自动业务，所以在交易当时就会有相应传票产生并打印了)
到了第二天，分行开门后开始营业前，业务人员需要下载打印各类报表，不过主要的就是前面说的那两份，然后再看看，如果借贷发生、余额都相等，所有的非自动业务都有传票，而且和整个科目日结单都可以对应上，那么就表示昨天的账务完整无误，然后大家就可以欢天喜地的开始新一天的业务了。
4 常见规范及检测
4.1 传票以及日志
从最基本的说起，通常来说，所有的账务程序都需要打印传票, 传票格式通常都是统一的，找份以前看看就可以了。
对应于转账业务，需要打印转账借、贷方双方的传票。
而对于现金业务，则只打印一张传票就可以了，借贷方向采用非现金科目的方向。(我个人认为，可能是因为标识了现金传票，所以对方科目就自然是现金，于是就不需要再打印了，猜的)
所以我们在开发程序的时候，打印传票这一步，一般不会特别强调，都是默认要做的。如果不太清楚的时候，一定要主动向需求设计人员询向，千万不要嫌麻烦，抱有侥幸心理。这种东西如果测试的时候漏掉了，是一定会有人要求补上的。(我在N多项目里都见过漏写传票，然后在程序上线前夕被人要求赶紧加班补制的，所以千万不要嫌麻烦)
在日终批处理的时候，可能有些数量庞大的业务，比如说代收付，结息什么之类的，动不动就是几十万笔，一张张生成、打印太不经济，通常会考虑采用打印一张汇总传票，然后加上一份明细清单的方式。还有的时候，如果上百万的话，可能明细清单都省掉，想办法导成电子数据都是有可能的。
上面说的是账务相关的业务。而非账务类的业务，如果涉及到修改类的业务的话，比如说修改密码，修改客户名之类的，通常需要登记日志(LOG)，用来记录，以便查询。
有的时候，为了统计业务量，或者是为了分析排障，还有可能要求对每一笔发送到主机的业务数据都登记下来，这时候最好采用一种统一的方式来进行登记，以及数据的定期清除，因为这类数据量应该比较大。
4.2 常见检测内容
发生一笔业务的时候，是一定需要进行若干检查的。比如最起码，我们去取钱的时候，就一定会检查密码。这里对一些经常见到的，较为普遍的检查简单介绍如下，套用一句合同上流行的话，叫做 -- 包括但不仅限于以下条款：
1、 账号/卡号是否存在，是否可以正常使用
2、 账号与客户所提供的凭证(通常这是指存折客户，对于卡用户而言，账号就是卡号，或者是可以根据卡号查询出相应的账号)是否匹配。
3、 密码、证件号码(如果需要检查的话)是否与主机数据一致(印鉴什么的需要业务人员肉眼核对。现在又出了一种加密机，如果采用了这种先进技术，那当然还需要检查这种加密后的信息是否一致了)
4、 在转账的时候，一定要检查转出转入方的户名与账号/卡号中的户名是否一致。(对私客户还好办一点，如果是对公客户的话，名字又长，括号什么的再一加，经常会出现问题，总之是一定要检查)
5、 如果是取款类业务(比如转账业务的转出方也算)，一定要检查账户的可用余额是否足够。
6、 大家一起来。
5 系统架构及部分模块常见设计方案
5.1 常见总体架构
这里如果用图可能效果会更好，不过我不会用VISIO，所以就算了。 一般硬件架构，都是一个主机，一个前置机(大前置)，前置机就对外了，比如业务人员用来作业务的终端啦，ATM，网银，电话银行什么之类的可能就都对应这个大前置了。大前置，或者是中间业务平台，也是一个很值得探讨的问题，可以做得很大，比如建行的大前置，又比如X天的中间业务平台其实也不错，这里不做深究。
就软件架构而言，核心系统一般可以分为业务模块，账务模块，和总账模块。 总账模块通常记录了一些账务的汇总信息，比如说科目总账的日、月、年的发生、余额。银行中大部分的报表都需要通过取总账模块中的数据来生成。总账模块的数据一般是取自账务模块中，当天的账务数据。(当然，也有很多报表，需要整合业务模块与总账模块两部分的数据一起来出)
账务模块，就是用来登记账务的，这部分一般会做得比较通用化，方便各个业务模块来调用。
业务模块，当然就是实现各个业务的子模块了，通常模块之间相对独立又互有关联，如果是账务类业务，当然就要调用账务模块中的程序。如果是非账务类的业务，那可能业务模块内部处理一下就可以了吧。
一般业务模块的数据会对实时性要求较高，而总账模块没有什么实时性的要求，不过总账模块重在统计分析，所以数据量一般会比较大。
5.2 计息
有的系统可能没有把计息单独列为一个模块，而是直接嵌套在各个业务模块之间了，不过设计成一个模块，个人认为可能会显得比较专业一点，至于到底好不好用那就见仁见智了。
刚接触银行业务的时候，曾经很执着，很傻很天真的想过活期账户到底是怎样计息的，因为定期账户的计息方式相对简单，余额乘天数就对了，但是活期账户的余额是常常在发生变动的，所以前20多年我一直都不知道银行每年给我算的活期利息到底对不对。
银行会计上，通常都会通过“积数”这个东西来计息。何谓积数?就是余额*天数，所以积数的单位应该是“元 天”
比如说
利息 = (账户余额*天数*利率)/ 360，在这个公式里，账户余额*天数就等于积数，于是这条公式也可以写为 利息 = (积数 * 利率) / 360。
定期账户因为账户余额通常不发生变化，所以一般不会涉及到积数。 活期账户采用动户累计积数的方式来计息。也就是说账户余额没有发生变动，就什么事都不干;当账户余额需要发生了变动时(比如说取款)，那么业务模块里就将上次账户变动日，到当前日期的天数计算一算，然后用变动之前的账户余额乘以这个天数，然后把这个积数累加到之前的积数上。最后计息的时候，就使用这个积数乘以利率再除360。
在设计的时候，就需要把每次账户变动的日期都登记下来，还需要有地方记录账户的当前积数。
对公计息，或者是一些需要计息内部账，有可能是每天计积数，也就是每天把账户余额累加到积数中。之所以这样设计，是因为对公以及内部账户的数量远小于对私账户，每天把每个账户都过一遍，花不了太多时间;而要是每天把储蓄账户都过一遍，就有点类似于结息了。(对私账户多的银行，有可能达到上千万户，尤其是些代理了社保，医保的银行，不可小看)不过现在有些很好很强大的国外系统，对于利息的处理，是每日计提，当然，这样设计也应该会有它的独到之处。
刚才这里提到的了需要计息的内部账，那么一般而言，什么样的内部账需要计息呢，我想，应该是不同法人之间上存下放的款项需要计息。对应于一般的商业银行以及统一了法人的信用联社，因为全市是一级法人，可能就没有需要计息的内部账了。而对于没有统一法人的联社，因为每个信用社都是一个独立的法人，那么信用社存放在联社的用来做往来清算用的资金，就是需要计算利息的。还有的银行，对于贷款的处理，也会有资金池的概念，这时总行下拨分行的用于贷款钱，也是要计息的。
这里可以看到，对于计息模块而言，积数是一个很好用的东西。积数除了计息，还有很多其它的用途。比如说招行的金卡，说的是“日均存款5万元以上不收取账户管理费”，那么，这个日均存款5万是如何判断呢，我很久以前曾经问过一个大堂里的MM(跟我同姓喔，惜乎已经有BF了)，她说是根据积数来判断的，也就是每个月需要增加150万的积数，这样听起来就很合理了吧。
对于某些业务来说，可能需要登记利息的明细。比如说贷款的复利的计算，就是根据利息来的。无论是正常贷款，还是逾期贷款，都会生成利息。生成的利息如果未及时归还，则会再根据这笔利息生成相应的复利。复利的复利，喔，太可怕了，也还是视为复利吧。总之，我的意思就是说，储蓄、对公账户这样的结息，在计息模块中可以不用登记利息的明细，因为最后结息的时候根据积数一次搞定;而对于贷款(或者是其它有需要的模块)，可能需要在每一笔利息产生之后，都把它登记下来，已保留行使进一步措施的权利。
除了贷款之外，还有一些定期账户，也最好采用明细的方式进行处理，越细越好，比如什么零存整取，教育储蓄之类的，要是没有详细的每期存款登记，漏存登记等等，是很容易就被它玩死的。
通知存款以前觉得它很可怕，现在想想，突然又觉得没那么可怕，无非就是通知取款，通知期限内的积数登记，然后取款又或者取消通知。可能最主要的，就在于通知期限内的积数计算。总之提取一个计息模块，为这类业务特别定制一些明细文件是很好的一个选择。
提到计息，也就顺便说一下利息税。国家在这十年来，调整了两次利息税税率，一次是涨成两分，一次是降成五厘，就那么一点钱，调来调去累不累，要收就收，不收拉倒，还搞什么分段计税，烦死个人。在这里，不知道有没有人是负责搞利息税这部分程序的，也不知道去年改这部分程序的时候，有没有很不爽过。其实要是早考虑到这种情况，倒是可以一开始就通过设置利息税参数表，然后修改计息程序，读取利息税参数表，最后根据不同阶段的参数，分段计息算税。这个方法倒是可行的，也实现过，对于整存整取的定期来说，算得上是一劳永逸，不过对于活期而言，每次调整利息税税率的时候可能就要搞一次类似于结息的东西了，好象没有一劳永逸的方法。
在国外的先进系统中，还有一种精采的倒起息可以让人一筹莫展。这种玩法的意思，就是说当客户来柜台前做个什么交易的时候，允许账户的起息日期在业务发生日之前。比如说有人7月14号来到柜台前还一笔贷款的款，然后说我这笔钱明明7月7号就到账上了啊，为什么银行不给我扣，非得让我贷款逾期之类的话。然后核查，如果属实，那就倒起息一把，现在虽然是7月14号，但还是当它是7月7号还的。(好象是这样，也可能是我说错了，大家对这段解释千万不要太放在心上)总之，如果有倒起息的需求，那必须在最开始设计的时候就与其它计息，以及业务流程整合在一起来考虑，如果中途加入这个需求，那改起设计来会比较费劲，改起代码来更是难上加难。
最后，我们再来说说计提，这个也和利息有关。计提常用于利息支出，比如说利息支出是5211，5字头，即是一个用于营业收支的损益类的科目。计提的会计分录中，对应的科目是应付利息2611， 2字头，是一个负债类的科目。所以说，计提的含义就在于，虽然当前客户利息并未产生(是结息的时候才产生)，但是这笔利息(尤其是整存整取的定期利息)迟早是会产生的，所以这里预先计算，或者说估算出营业支出，计到负债的科目上(负债嘛，本来不属于银行的钱，迟早是要被取走的钱)，然后到这类账户结息的时候，就直接从应付利息中支出，计到客户账户上，而不走利息支出这个科目了。看懂了吧，这里其实也就包含了管理会计中的概念，实际上是产生一个提前测算成本的动作。诸位搞IT的朋友们，你们看过《会计学原理》吗?
5.3 储蓄/对公
这部分模块一般没太多可讲的，通常的设计，都是搞个主文件，保存针对每个账户的信息(比如说账号，账户余额，当前积数什么之类的，总之就是与账户有关的信息)，然后再搞个账户明细，用来记录每个账户发生过的业务。听闻有的系统设计，不知道是不是考虑到锁表的问题，计划取消主文件，直接上明细，愕然之余只能感叹自己见识浅薄，因为我总觉得明细要考虑冲账的问题，在读取上不如主文件一下搞定那么畅快。而且主文件可以有锁表保护，可以更好的保障数据的正确性。
所以私底下，我还是很推崇这种“主+明细”的设计方式。以前曾经很无奈地见过有人在新增业务模块时，把主文件和明细混在一起来搞，于是整个业务流向怅然若失，需求有变动时改动几乎无从下手，若非我多年功力，是断断不可能在加两天班后就理顺通过测试的。
说起储蓄呢，又忍不住再提一下招行，不可否认，它的一卡通做得真的挺好，本外币，定活期，一张卡全部搞定。我以前就经常把活期转成三个月定期。根据我本人看法，三个月定期从利率差与时间存放差上来说，性价比是最高的，也就是说一年期利率虽然高，但很难保障这点钱在一年内不用。所以推荐大家把5K以上的存款转成三个月定期，一般忍忍也就可以拿到利息了，当然了货币基金也是一个不错的选择。还有一次自做聪明搞了个一年期的零存整取，性价比不高，而且还得到柜台去办取款手续，把自己麻烦死了，不推荐使用。
扯远了，其实本来是想说，活期、定期、外币账户，这些都是一个又一个的账户，而在招行的设计之中，这些账户，都会与我们的那一张小小的卡片关联起来。换句话说，人家的卡号，应该只含具体的卡的信息，比如说卡的有效期，密码，磁道信息什么之类的，不直接对应某个具体账户的;而各个具体账户则应该会有一个与卡号的对应关系。然后到寄对账单的时候啊，打电话介绍买保险等等附加服务的时候，就还是根据卡号来提供服务。不过还是要根据账户的资金流动来分析消费习惯，以及贡献度的高低等等。
至于怎么实现，就根据各位自己的核心系统慢慢体会，不过这么多年了，也可能大部分银行都实现了这种功能或者是类似的一卡通，那就当我这段没有讲过吧，总之我觉得这种理念很好很强大，让我用得觉得很方便。
至于对公，好象就更加没什么可说的了。
5.4 客户信息
客户信息，卡号，账户号，这三者是层层细化的关系。所以说，整合好三者的关系也是一个不容易的事情。
在我见过的几套系统之中，最常见的问题，就是同一个客户对应多个客户信息。这通常又是个历史遗留问题，比如在手工或单机年代，开户时对于身份证明证件要求不是很严格，一个人可能开了很多账户，还可能是用化名开的账户。在移植上线的时候，常常由于重要信息不齐，又要考虑客户层面的因素，很少能强制性补齐客户资料，通常只能在移植时自动生成一些客户信息，这样就造成了很多冗余，而且也不好再做深层的数据挖掘和客户分析。相比较而言，新开立的分行可能这种情况会好一点，而且面对的客户高端一点的，又会更好一点。
在新系统上线，做数据移植的阶段，一般客户信息的问题是最先体现出来的，通常新系统会要求得比较理想化，而实际情况千奇百怪。这里说说常见的，比如说新系统一般会要求证件号码唯一，但是因为很多客户的证件信息缺失，所以这个号码唯一可能会有困难;再比如说有时可能会出现证件号码重复，而且还真的不是同一个人。
总之这些问题，它不是新系统的错，也不能完全说是旧系统的错，最关键的是在移植的时候如何处理利用好这部分客户信息。
再一个问题，就是客户信息的更新。个人认为最好能有一个有效的途径来更新客户信息，尤其是工作单位，电话号码，对于很多流动人员来说，经常会变换。如果每次都要来柜台更新，我想那基本上就可以认为它是形同虚设了。
可以说，随着现在以客户为中心的概念的提出以及越来越多的实现，客户信息这个模块也应该会越来越受到重视，以前设计的表结构应该会有些不够用了。目前如果没有新系统要上的同行们，恐怕是要等着改结构加字段了，保重。 5.5 贷款
很多地方都会把一般的商业贷款与按揭贷款和消费贷款(比如车贷、分期付款之类的，总之有点类似于按揭贷款的)区分开来，这样自然有它的道理。我在这里只谈我个人的设计方案。
现在的商业贷款常常采用一笔发放，一笔回收的概念(当然有时会有提前还款，但不象按揭贷款这样有个具体还款计划)，然后用合同号，或是借据号做为贷款的一个类似于唯一关键字这样的东西。但是有时公司的商业行为中，一个大项目里会包含多个子项目，然后对应不同的子合同，这些合同对应的贷款之前其实都是有关联的，尤其是在算逾期什么之类的时候，有的是一逾全逾，有的又不是。所以我个人觉得，贷款最好做成多笔发放，多笔回收的形式，发放与回收不必一一关联。但最好在贷款录入时(这时不一定已放款)，就录入相应的还款计划。
贷款的账号，最好与具体的业务信息剥离，类似于储蓄里面“一卡通”的概念一样，每个贷款，有它自己独立的贷款号，然后正常、逾期、两呆，以及相应的利息账号都与这个贷款号关联起来，便于以后的跟踪追查。
而对于按揭贷款来说，因为期限长(常常是二三十年)，而且比较具有规律性，所以一般就不用列出还款计划的明细了。不过要注意，一般按揭贷款的首月还款是按天算息的，稍微注意一下就可以了。
最后，特别强调提出一点，见过两家行，都推出过“等本等息”这种经典的业务产品，也就是客户每月按等额法算出的金额还款，但本金的计算则按等本的方式来算。
这里要大声疾呼，这种东西从原理上来说就已经是错误的!因为同样金额，同样期限的贷款，等额法的利息是要大于等本法的利息的。等本法计算方便，理解简单;而等额法是数学家们经过精确的计算，推导出公式，最后计算出的一种还款方法。也就是每个月的还本、还息都要严格按照计算出的公式，这样才能达到等额的效果。试想想，这个月还了一定的本金之后，下个月计算出的利息就不一样了吧，这时要求下个月还的本金与还的利息加起来还是和这个月的一样多，而且还要求每个月还的本金加上利息都是一样多。所以，除非是数学学得特别好的同学，咱们一般的程序员不要妄想自己能推导出公式来，照着公式算就行了。如果强行按等额法计算出的钱来制订还款计划，又按等本法的方式还计算每期还款本金，虽然是方便了，但是在每年利率变更，重算利息时，必然会导致利息总和由等额法的利息渐渐趋近于等本法的利息，也就是总利息额将会越来越少，于是要么在本金与利息的问题上无法自圆其说，要么可能会出现利率上调还款金额反降，甚至负利息的问题，不可不查。
5.6 清算与结算
清算与结算本来是两种业务，不过因为结算中通常又会包括清算，要分成两小节，每小节又说不了太多话，所以干脆放在一起算了，而且这一节只谈流程，不讲设计，这种业务流程理顺了自然就可以设计了。
先约定一下，商业银行的级别，一般是
分行—支行两级，有的可能还会有储蓄所这种第三级。简化起见，暂时就分两级来说吧。如果对应到信用社，那就是联社营业部—信用社营业部。分社一级省略。
先从结算说起，这里的结算业务，指的就是跨行转账，至少我是打算这么说。每家商业银行，都会在当地的人民银行有一个资金账户，可以理解为结算业务用的备付金账户。然后在自己行内，也会开立一个与之对应的“上存人行款项”的账户。理论上，人行的这个账户和我们自己行内的这个账户，表达的都是“该银行存放在人民银行的钱”的这个意思，所以金额也应该相等。那么，这两个账户在不同的银行(也即不同的系统中)，如何保障它的一致性?这一般就是通过日终，营业终了时的对账来保障。所以对账是很重要的，这个后面再说。
至于结算业务的流程，先从遥远的手工账/单机账年代说起吧。在那个时候，结算的途径、概念、术语可以说是五花八门，什么先直后横，先横后直，提出借方，提出贷方，提入借方，提入贷方，信汇，电汇等等等等，不把人转晕誓不罢休。现在好象大小额支付横空杀出，倒是简化了不少。当然也还有行间转账，同城支付，省金融平台，不过概念上渐渐趋向统一化，先不多说，先谈谈当时我理解中的流程：
首先如果要转账，我们要在柜台前填一份一式五联的单(一定要用力填哟，不然最后一张纸上看不到什么字迹的)，然后这笔钱就从我们的账户上扣下来，划到银行内部的某个往来账户上了。
然后这些单据，再手工传递到上一级，上一级再手工传递到人行(当然，也可能上一级就是人行，这里不要太较真)，每传一次，这笔资金都会在当前做业务的这一个银行的往来账户中流动，最后通过人行，流到你想转入的银行中，那个你手工填的单，也流到那家银行中。最最后，转入行的业务人员核对单据，账号，户名都没问题，这笔钱就从往来账户划到我们所填的转入账户上去了。
在这些过程中，结算的同时就已进行了清算，资金的流向是
A银行的某支行A银行的当地分行A地人行B地人行B银行当地分行B银行的某支行
也就是每一笔转账，在行间的这一步，都是通过它们在人行的资金往来账户，实现了资金的流动。
如果是上述的资金流向，就叫先直后横。如果是A地人行B银行A地分行B银行B地分行B银行某支行这种方式，就叫先横后直。
这些单据的传递，都是手工的，或者说是落地的。如果是用信件的方式传递，那就是信汇;如果是用打电报的方式传递，那就是电汇。手工的传递都是有场次的，比如一天两场，或是一天一场之类的。所以这个转账的效率有多快，我就不说了。
现在科技进步了，手段丰富了，社会于是也就和谐的。先从我个人较为欣赏的大额支付说起。我一向认为大额这个业务设计得是相当的合理，因为资金是点对点，清算行对清算行，大大缩短了流程，更重要的是，信息的传递是自动的。还是上述的CASE，假设转出行与转入行都开通了大额业务，那么资金的流向是：
A银行的某支行人行B银行的某支行 原则上是这样的实现，当然行内的设计怎么处理我们就不多考虑了。行内当然也可以设计成为先从A银行的支行转到上级分行然后再发出，总之人行收到一笔大额的转账信息之后，是会自动、直接发向指定的转入行(假设转入行也开通了大额业务的话)
大额系统的对账，不考虑具体的客户账户，只考虑清算行。通俗的说，人行只管A银行今天给B银行转过去多少钱，转过去了，人行就不管了。至于B银行什么时候把这笔钱入到客户账户中，那是B银行的事，人行不管。听起来责任还是很清晰的吧，而且这样也有助于减少账户锁表而造成的行间转账失败。
因为大额的这种设计，所以实际转账中，几乎是实时的。我从某地信用社转到异地招行，在柜台还没最后签字，收款短信已经来了。
因为大额业务发生的时候，是支行对支行的，所以每发生一笔业务之后，实际上这笔资金是暂时体现在该支行的某个行间往来账户上。所以每天大额业务结束后，还需要按清算的流程，将这笔资金按往、来分别清算到上一级分行(或是总行吧，总之就是当地的最高节点)，然后分行与人行发下来的电子对账文件进行对账，检查汇总往、来数、金额是否相等。如果相等，那就可以把往来一轧差，转出多的时候就从存放在人行的账户里扣钱，转入多的时候就往那个账户里加钱。
至于这个清算的步骤，通常还是由手工发起，不过这里的手工，就不是指传递单据，而是指运行程序。当然，清算程序也可以自动运行，这个根据系统的不同，要求的不同，自行调整设计。
5.7 额度控制
和计息类似，可能有的系统没有把额度单列为一个模块来处理，而是仅仅作为业务模块之中的一个判断项。早期的业务中，的确可以这样处理。不过随着现在金融产品的不断推出，我个人认为还是把额度拿出来单独搞一下会更好处理一点。
比如说，一个账户，可能会有几次冻结，也能会有多项额度控制，每次的解冻，又或者是解除控制，都可能会对账户的额度造成不同的影响，如果夹杂在业务模块中，字段的设计，状态的控制可能都会有些问题，单独整成一个模块，或者说是一个大公函，在账务交易(或是账务模块中)的时候，用额度模块来进行一下判断，可以更方便的检测账户的可用额度是否足够。
另外，一些账户相关的透支什么的，也可以比较好的按客户来处理，而不是针对每个账户设置是否允许透支。以至于循环授信额度，这些概念都可以拿出来使用，简单的来说，有点类似于储蓄卡向贷记卡的管理方式倾斜，不过我没做过贷记卡，所以这里也提不出太多东西，只好拿个概念出来大家一起参详一下。
5.8 冲账
本着想到哪里就说到哪里的原则，刚才突然想起冲账还没有说，那么这里就说说冲账。 冲账的概念前面已经提过，这里我们指的，就是红字冲账。因为蓝字冲账就是再做一笔别的账务，从IT人员的角度出发，其实是另一个合法的正交易，不能算是冲账。
在设计程序的时候，只要是财务类的业务，就一定要考虑冲账的问题，不能偷懒，不能妄想测试人员会遗漏。就算别人忘记了测试，如果在真实业务中发生了问题，是很麻烦的，所以要养成良好的设计、测试的习惯。(这里不谈编码，因为设计好了自然就会写代码的)
关于冲账的实现，我知道的有两种方式：
第一是正反交易的概念。也就是普通的账务交易，称之正交易。每一个正交易，都需要有一个与之匹配的反交易，如果是按交易码来管理的话，可能会有一个标准来定义反交易的交易码，比如说正交易码加上5000就是相应的反交易之类的。(这里只是随便举个例子，比如说0001表示取款，那么5001就表示取款的反交易)因为冲账在账务处理上，具有一些共性，比如说都是按原来的财务的会计分录，只是金额为负发生账务即可，所以有可能会有一些公共函数来调用，不过总的来说，都是小函数的概念。这种设计的缺点很显而易见，就是交易码，代码量都要翻倍。业务人员在冲账的时候也需要稍微算算交易码，有可能会输错。好处也是很明显的，就是程序之间互相不影响，修改维护都很容易。
第二种设计思路就是大函数的概念，也就是使用一个交易来实现冲账。因为前面说过，冲账业务具有一些普遍的共性，就基本原则来说，找到这笔正交易最初的账务，就可以了。所以使用一个大交易来实现。至于各个业务模块冲账后，在财务处理完之后的业务冲账，那可能就需要不断的在这个大交易中挂上各类外挂了。这种设计的缺点也很明显，就是维护起来很不方便，因为相当于把业务模块的冲账都集成到一个大交易中，在版本控制，大量测试的时候可能会有较多冲突。好处就是不占用交易码，也可以减少很多代码量，对于很标准的冲账，甚至不需要特别去考虑冲账的问题。(不过怕的就是不那么标准的冲账)
这两种方法各有优缺点，不知道大家的系统中，使用的哪种方式。这里我提出一个集合两者的第三种方法，一起来参详一下：
仍然考虑以大交易为主，不过大交易按某个参数表，来决定调用业务模块中的部分程序解决业务模块的冲账问题。如果是非常标准的冲账，就不需要刻意写冲账程序。如果是不标准的冲账，就在参数表中按设计中自已定义好的各类标识符，使大交易可以判断出何时调用业务模块中的冲账子程序(这些冲账子程序可以随时新增，名字也可以自定义，总之是在参数表中来定义)。至于大交易与冲账子程序中间的程序入口参数的传递，因为各个业务模块要求都有所不同，所以可考虑使用一个大字符型字段，或是数据队列传递字符流的方式来解决。
5.9 其它
暂时先想到这么多，其实还有其它的东西。比如说日终批处理，不过做到这一块的同行们想来不是技术骨干就是业务能手，也就没必要看这份入门级的东西了。还有拆借，贴现，不过这部分在核心系统里面占的份量很小，业务理解起来也不难，抓住一个熟悉业务的人多问问就问出来了。还有代理业务，不过这种业务的设计也多半是主+明细的方式(比如说代理单位的汇总信息，以及相应代理业务的明细记录)，麻烦的可能反而主要在数据的交互上，也就是什么倒盘啊，信息录入啊什么的，又或者是具体的程序运行效率上，和这个整体设计的关系倒不大。
关于批处理，我做得比较多，还是再简单说两句。一般来说，会要求维护人员按各自的业务模块，维护批处理中的相应程序。不过最后，仍然需要一个总体上能把握的人来协调调度。批处理的程序大致上可以分为三种功能：
实现各类日终自动业务。比如说到期自动扣款(用过信用卡的朋友们应该深有体会吧)，贷款的形态转移，储蓄结息(居然现在变成一年四结，有些先进的国外系统还要天天计提，我只能说系统的设计出发点各有不同啊)，可能还会有上面提到的日终清算。当然，还包括了各类的日初业务初始化。
实现账务模块数据向总账模块数据的转换，也就是更新总账模块的数据。严谨一点的系统，在更新了总账模块的数据之后，还会用程序来检查一下总账模块的数据与业务模块中的数据是否匹配，一致。(也就是传说中的总分核对)
生成各类报表。这部分可能主要是从总账模块中出，也可能需要综合一下业务模块中的数据。
批处理的发起，是由固定的操作人员来执行，没见过设计成按时间点自动运行的。 刚才说到批处理的三项基本功能，而其实在各类功能中，程序的运行顺序还是颇有讲究，不能随意乱放，否则可能会出现无法预知的问题。
批处理的排障，也是一个比较痛苦麻烦的事情，这里真诚的建议各位维护批处理的同行在有大模块上线前，做好心理准备，多多祈祷，实在不行还可以试试拜拜土地。
第四篇：某某村镇银行支票影像系统业务知识培训汇报
永清村镇银行支票影像系统
业务知识培训情况汇报
支票影像交换系统是指运用影像技术将实物支票转换为支票影像信息，通过计算机及网络将影像信息传递至出票人开户银行提示付款的业务处理系统。它是中国人民银行继大、小额支付系统建成后的又一重要金融基础设施。影像交换系统定位于处理银行机构跨行和行内的支票影像信息交换，其资金清算通过中国人民银行覆盖全国的小额支付系统处理。它的建立为客户提供了极大的便利。
为规范支票影像系统的业务处理，提高清算系统参与者的管理水平及运行维护和业务操作人员的技术、业务水平，确保支票影像系统快速、高效、安全、稳定运行，加速资金周转，防范支付风险，确保永清吉银村镇银行支票影像系统接入人民银行网络里间连运行。2012年3月，永清吉银村镇银行召开了综合业务系统支票影像支付系统业务培训会议。会上，副行长王玉兰做了重要讲话，通报了该系统进程和前期准备的情况，要求参训人员以此次培训为契机，进一步深入学习技术理论和实际应用，迅速提高此业务的技术水平，尽快适应支票影像支付系统应用上线工作的需要。此次支票影像系统参与者操作培训历时两周，永清吉银村镇银行10余名综合柜员、库管员、主管会计及相关人员参与培训，培训课程根据河北省支付系统间接参与者的具体业务精
心安排，主要内容为支票影像系统相关业务处理，涵盖了支票影像系统业务介绍、常规业务流程、参与者操作规范和应急管理、支票影像系统管理，内容丰富、切合实际。培训结束后，针对培训内容对参训人员进行了测试考核，参训人员全部以优异成绩通过考核。
第五篇：银行业务管理系统设计说明书
完成日期：2010年12月19
目 录
1. 引言 ........................... 1 1.1 1.2 1.3 1.
4编写目的 ........................... 1 背景 ........................... 1 定义 ........................... 1 参考资料 ...........................
12. 程序(子系统)系统的组织结构 ................... 1 3. 界面设计要求 ........................... 2 4. 本软件系统中各程序(子系统)的设计说明 .................... 2 4.1 4.
2程序(子系统)1的设计说明 ..................... 2 程序(子系统)2的设计说明 .....................
35. 子系统相互关系表 .................... 3
1. 引言
1.1 编写目的
本说明书确定系统的功能模块和数据结构，为下阶段开发工作提供依据。
1.2 背景
软件系统的名称： ComputerBankAccountSystem 本项目的任务提出者： 刘源
本项目的任务开发者： 刘源、黄宗宣、谷效萱、安建、谢琳琳、茹梦
1.3 定义 1.4 参考资料
2. 程序(子系统)系统的组织结构
提示:用层次图表列出系统内各层模块。着重标明一下每位小组成员完成了哪些模块。
3. 界面设计要求
提示：登录界面和主窗体界面的设计。
我实现用MDI 父子窗口来整体管理 建立一个总控制平台LandMenu
登陆界面LandForm和相应的Server业务员登陆界面
4. 本软件系统中各程序(子系统)的设计说明
提示：在本节中要求按模块依次说明在“
2、程序(模块)系统的组织结构”中列出的每个模块的设计内容，包括：
程序(子系统)功能描述 程序(子系统)性能描述 该程序(子系统)的输入项 该程序(子系统)的输出项 该程序(子系统)的算法 该程序(子系统) 设计思想 接口设计
LandMenu主菜单LandForm登陆窗体 ChoiceMenu用户选择菜单 GetMoney取款窗体 SaveMoney存款窗体 SelectMoney查询窗体
Server业务员验证界面 ServiceLand业务员登陆界面 ServiceMenu业务选择界面 OpenAccount开户窗口 ScanRecord查看记录窗口
一个class类 GetInfo 其中放置判断密码输入正确、获取金额、存款、取款、获取利率、更新账户信息、插入新记录、插入新账号
4.1 程序(子系统)1的设计说明
提示：简单描述子系统的功能、设计思想、界面以及每位小组成员完成的情况。
整个在Dataset数据集上设置有tableapatper适配器 用存储过程来制定特定对象放入数据集 或直接拉入整个表
在使用存储过程是 适配器需要相应的数据类型匹配 多注意可空“?”
4.2 程序(子系统)2的设计说明
提示：本节内容同4.1节。
(依次将本软件系统中所有的程序(子系统)的设计说明给出。)
对GetInfo类使用了断开连接和连接操作 断开连接多用于查询 可以迅速查询表的内容
连接状态多用于更新数据库信息
在对数据库的属性设置上我们采用完全复制来调试程序
5. 子系统相互关系表
提示：根据第4节的内容理清各模块间的调用/被调用关系，并填写下表。
子 系 统 相 互 关 系 表