重庆富民银行行长：银行数字化路径与多重赋能
重庆富民银行行长：银行数字化路径与多重赋能
来源： 新浪财经
核心提示要真正解决场景的问题，金融服务的问题，就要往生活服务上，旅游服务上输出，这才是真正解决服务实体经济的问题。
　　7月28日消息，“2018中国资产管理年会”今日在上海召开，重庆富民银行行长孙中东在智慧金融主题论坛“从博弈到融合：智慧金融发展新趋势”中表示，要真正解决场景的问题，金融服务的问题，就要往生活服务上，旅游服务上输出，这才是真正解决服务实体经济的问题。
　　以下为演讲全文：
　　孙中东：各位嘉宾，下午好！我跟大家分享的题目是银行数字化路径和多重赋能，跟今天主题有一定的相关性。因为银行从业这么多年，我一直在银行数字化当中工作，这是全球通用的语言，我们可能叫互联网+，叫互联网银行，叫金融科技。全球通用的语言就是数字化，银行如何做到数字化？能满足我们智能所有的相关需求是我今天分享的主要部分。
　　我分享大概三部分，第一部分有一套方法论和路径体系，这一套方法论，我们银行应该怎么做，最后再分享一下我最新的一些观点，就是多重赋能。这整个体系基本上是我自己的一些观察和思考，还很不成熟，希望大家多提宝贵意见。
　　我们看互联网如火如荼，银行好像还不是太能够跟的上，银行应该向互联网学什么？很多人可能都在学技术，学开源体系，学去IOE。其实互联网不会改变银行的本质，改变的是银行金融风控模式和服务模式。我觉得刚才汪总分享慢慢的干货，其实就是用技术和手段来做到银行在服务模式上的革新和变革。这个就是一个方法论体系，也就是我们看互联网的公司在展业的时候，用什么样的工具，比如说我们看facebook、微信、推特，所有基于互联网公司不是基于网点，怎么样展业，他们都做开放平台体系。
　　国家的互联网+也是讲连接，银行是什么？银行简单来说是三大工业，信用中介，支付中介，信息中介，这些中介其实跟网点都没有什么关系，所以银行完全是可以数字化运营，可以不依赖于网点。我在业界提出1+1+N的建设模式，也得到监管部门的认可。1+1+N模式是什么？这张图希望解答这个问题。我们看银行传统的展业，第一个银行一定要有金融产品，有金融产品，有我们的组合服务，所以第一个1实际上就是银行要想建好必须具备的能够，但是互联网来了，我们必须打造互联网平台，这个平台有跟互联网能够对接的各种可能性，所以我们中间这个平台实际上比较复杂，实际上多场景跟个人客户、企业客户都要连接的平台，在全生命周期里面都要连接上去，再看那个加号银行打造开放平台体系。大家关注一下整个银行开放平台在2012年提出来的，目前来看，整个行业已经非常认可这个标准，欧洲、美洲都已经制定相应的标准。最近的银行也推出API的概念，银行不通过网点展业，通过什么来展业？就是学习互联网，通过开放平台来展业，连接所有互联网上的创新模式和互联网上的一些场景。
　　数字化要量化的，一个银行是不是数字化银行？是不是金融科技的银行？是不是互联网银行是有标准的，前面七个标准是全球所有的银行通用的标准，也就是说银行在没有互联网和有互联网之前都要做到七个能力。这个所有银行这么多年，科技人员，整个银行管理层都是在持续要求，我们打造这个能力。另外这边14个能力实际上是为了应对整个互联网来了以后，银行业应该做能够解决互联网化的问题。
　　所以这21个能力的打造，实际上因为时间关系没有办法展开，这些能力实际上如果打造好，你就是一个标准化的数字化银行，你如果是数字化银行，你赋能对于你来说是高效的，它的逻辑是这样的。就是你自己一定要把自己先打造好，再接受外面金融科技的赋能，所以大家看，现在市场上经常说这个银行做金融科技，这个银行做区块链，那个银行做AI，实际上你对他的银行认知，你觉得他是非常高科技的银行吗？也不见得，就是因为他整个体系并没有了解是不是真正做到全面的数字化。
　　我们来看，这个核心能力是怎么建设的。我稍微展开一点这些能力，我们看一个银行，这三大牌照下面，我们一个一个来看，比如说渠道，银行有各种渠道，渠道层面，我们希望这些渠道做到什么，银行有网点和网银，大家看这些渠道的时候，是不是每个银行都有一致性体验？比如说你打电话给写，我要去你们行换笔外汇，你到网点以后，你交上自己身份证的时候，会员能知道你刚才打电话是想换一笔外汇吗？我觉得未必能够做得到。银行在所有渠道层面上，能不能做到一点接入全程协同，这是非常高的挑战，很多银行做不到。但是客户的体验，互联网越来越注重客户体验和感受的时候，一个银行的渠道都完成不了这么多的情况下，实际上你的路还是比较远。具体后面这些点怎么做到？我就不展开。
　　我们看什么叫以客户为中心？小米最近说他要跟客户交朋友，银行是不是真的以客户为中心，这个能力实际上现在越来越多银行说我要以客户为中心，真正做到以客户为中心了吗？我觉得大家可能都有感受，我也不深说了，实际上我们在整个打造数字化的时候，我们是不是洞察这个客户，能不能了解这个客户？我们在整个银行能力布局上面，是不是把客户做深入的分析和我们整个对他的管理，能不能做到这一点？我们看整个银行的体系，其实有产品银行卖基金，卖证券，卖所有的保险，银行有自己的汇票、信贷、理财，这个产品是什么样的布局？你的布局决定你以后迭代的效率，你的架构决定你的效率，所以你的架构做的好不好也是这样的。
　　所以我们现在在业界基本上说要核心这么来做，这个话解释起来都是比较复杂，但是核心意思都是说，我们核心系统，你要来做，多种外部系统来摆布，每个系统最后通过总线连接。财务系统是绝对我们银行整个报送，成员自己的利润跟整个行业来做沟通的体系，这个体系做到会非常灵活高效。我们看银行管理在哪些层面？其实后端的管理非常复杂，我们从银行来看，我们有利润价值的管理，有客户关系管理，这些管理我们怎么有透明度，我们全行在经营管理过程当中，我们每个都能拿到自己的数据，这些数据怎么支持银行经营和发展。我们看银行运营标准是什么？我们讲标准化，应该银行业务特别复杂，所以从运营角度来说是很大的挑战，怎么做到工厂化、标准化所有的产品。
　　下面介绍一下银行21个能力，实际上希望我们跟互联网做一个连接，比如说基于自建合作植入场景提供银行服务和产品能力，我们把我们的产品植入到京东金融来做，实际上我们有些大银行可能自建，小银行我就建议不要自建，我们跟场景来合作。第二条产业链条，我们在线上做供应链的金融，包括一些技术，我也不展开。实际上说我们这些对于银行业都是比较新的，不是银行原来的数字化能力，这14个能力，银行其实都在路上，今天上午主会场也讲到，现在银行在金融服务里面还起到非常重要的作用，所以银行应该自己首先能够服务实体经济的前提，就是服务好互联网化的变革。所有的企业个人、消费都在互联网上，银行如果在互联网上服务不好，实际上你自己的作用就是一个缺失。所以我们看现在这些能力，现在银行做的怎么样，这个我评估是有一定依据的，实际上在传统银行七个能力方面，商业银行股份制做的还是不错的，做了20几年、30几年，但是在互联网能力方面，其实差距还是比较大的，这是所有银行都在努力做的。
　　如果说我们银行把这些能力不断完善过程里面，我们看怎么赋能？所以现在这个赋能词比较热，我自己总结是三重赋能，一个是给银行赋能，使我非常强大，但是目的是要输出出去，为产业、生态、场景服务。最后一个赋能就是真的能够做到生态之间的互相赋能，所以这里可能现在认识比较清晰就是自我赋能，我们在所谓的ABCDT层面对银行做加强，就是用新技术手段不断来支持我的赋能领域。我刚才说如果你自己的21个能力没有仔细研究，也没有一个规划，当然不是说全做好就是赋能，但是你自己没有规划好，如果做这些东西是没有什么太大的益处。
　　银行基本上是一个金融行业，跟互联网现在接轨的过程当中，必须把自己的真正金融能力和金融对接能力打造出来才好做这个能力。这个能力实际上研究比较充分，我简单说一下，大说据可以做画像，因为这个画像随着大数据出现，我们对于一个人的画像更加丰富，因为银行一直讲客群的定位和分类服务，以前只有银行分析，现在有更多社交信息，互联网关注信息、言论和观点，其实我都科技收集到，这样的话，我会让客户越来越具体和例题。我们可能用大数据来做精准营销，用这些人工智能的技术，一些算法来做，我们可以来用来做反欺诈，对于所有互联网最大风险是欺诈环节，怎么来识别客户？尤其对于客户身份真实性的核查，这是我们做的七层互联网机制，使得最后能漏出来，所有网络通过的时候，我们希望是一个好的，真实的客户。
　　人工智能下一个专题可能有，我们招行的专家也在，所以他们会讲，我们也不太讲了，这一块对于资管领域比较大，我们未来对于人工智能手段来做投资顾问和人工理财服务。这一块大家都知道，刷脸对于人身体各种特征的识别，这个主要是符合于人身份的识别，知道最终是你，其实里面有大量的算法，刷脸其实里面有更多算法的训练，使得他更加精准，包括我们现在讲大数据，或者叫智能风控，我们怎么通过有监督机器学习和无监督机器学习两种手段，有机器学习就是说我们还是有不良的数据，有坏的案例和样本，这样才能做到有监督的机器学习，但是实际上，真正跟互联网操作过程当中，有坏样本的非常少，大部分是无监督的机器学习，他的有效性是很值得怀疑，所以刚才汪总分享的时候也提到这一点，实际上我们怎么把风控的能力不断提升，这部分很重要。
　　移动互联我还是要重点分享一下，大家为什么现在不提移动互联技术，可能觉得移动互联已经做的很久，每家银行都有手机APP，实际上做的很远远不够。实际上有两个方向进一步尝试，一个是用H5来做手机银行，这个最大的特点是可以在我们社交网络里面传播，不是说H5做一个宣传，而是做整个服务的提供，这部分是上海华润银行做的非常好的尝试，他们做一个纯H5的手机银行，在朋友圈可以分享。另外就是SDK，往后走对于移动端的特别解决方案就是SDK，所有的APP都可以在加上SDK以后得到金融的服务，这是非常大的场景和愿景，我希望更多的银行能加入这里面，一起来共同努力，把这个银行服务，能够真正跟场景结合起来，也就是更多的服务实体经济。区块链很清楚，实际上我觉得它跟银行的供应链有天生的一些契合点，我不是太认为他很快就能够有很大的作用在银行，但是我觉得应该是尝试起来，多去看一看这些技术体系，有很多东西可以解决我们银行的痛点问题。比如说票据场景的问题，还有融资便利性问题，来做补充。
　　第二部分我们怎么把21个能力打造出来，再加上ABCDT赋能以后，我们强大的银行金融科技体系怎么进一步输出，输出哪里？实际上中国有一个统计数字，去年一共是1700万个APP，所有行业都是基于移动端的展业，但是我觉得大部分APP活跃度是很低的，或者有一些个人的尝试。但是无论融合，每一个APP后面都是一个鲜活的企业或者是个人，大部分都需要金融的服务，但是大家在金融APP后面看不到银行，可能看到支付的东西，但是银行全部缺位，所以这部分是非常大的蓝海市场，我们能不能打造一个基于全牌照的金融服务体系，植入到APP里面。
　　我们原来说做手机银行，手机就是一个银行的想法，但是手机跟银行，手机APP确实可以做进否服务，但是跟场景无关的服务。所以说怎么把银行能够跟场景结合起来？手机银行做不到，必须要做新的技术模式，就是我们的数字化要再提升。我们是不是可以把银行服务开到APP里面？使得每一个APP都能感受到银行存在，不一定是赋能银行，每个APP里面，其实得到金融服务，谁是最主要的提供者？是银行。为什么在APP里看不见银行？
　　　　所以这个事情真的应该引起我们整个同业的思考，移动端转型，所有的行业都在转型的时候，为什么银行缺位？所以我的想法就是我们要进一步输出，通过我们刚才的基础能力建设，银行打造一个纯数字的银行以后，我们输出到所有的场景里面，我们可能有融资功能，支付功能，投资功能，产业链功能，结合下面所有的新技术体系把这一套东西向最右端输出，我们在尝试。我觉得输出到京东金融不算是真正的输出，因为没有解决，只是一个金融的产品提供，我们真正解决场景的问题，金融服务的问题，就要往生活服务上，旅游服务上输，这才是真正解决服务实体经济的问题。
　　如果大家都想银行业在上面，各种机构也在上面，我们大家互相赋能，我觉得那是一个非常让人产生遐想的一个生态概念。我们在场景端，入驻机构端，我们采用这样一些新的技术，让我们大家互相赋能，真正做到消费产业，B端、C端机构，整个链条打通，互相赋能，就是产业是和消费行业最值得尊重的真正服务老百姓和小微的。所以我们的金融服务也在里面，把整个循环做起来，打通起来，这确实是非常理想的状态，但是我觉得我们应该努力来做这件事。我的分享到此结束，谢谢大家。
责任编辑：Rachel
后参与评论
暂无相关推荐免费发布咨询，坐等律师在线服务
需求发布后
10分钟内收到律师在线回复
平均有多个律师参与回复
得到了圆满解决
您的位置： & &
帮人担保银行征信显示关注是什么意思？办贷款或者信用卡能办吗？
帮人担保银行征信显示关注是什么意思？办贷款或者信用卡能办吗？
精选优质答案
地区：北京-朝阳区
咨询电话：
帮助网友：8588 次
点赞人数：173 人
损失等，你是要负相应的责任的：正常、次级。你这种情况，已经出现了逾期还款问题或者逾期未还，搞不好要承担责任的，类似于三户联保等，按时还款为好，就要担保人进行还款，可以办理信用卡。如果你担保的贷款人不还款了，银行就会冻结你的银行账户、可疑，或者今后甚至出现不还情况。担保一栏一般会出现。建议你还是督促贷款人，只要贷款人不还款、关注怎么可以随便给别人担保。现在出现关注说明已经不正常了，不过贷款和信用卡的申办会受到一定影响的，说明你担保的贷款申请人。这种呆账是会影响到你的信用的
相似优质问题答案
您好，我在2009年的时候帮朋友在桃江农村信用社担保过一次9万元的贷款，今天在征信查询的时候发现我那朋友并没有还款，一直逾期金额8万元，而查询出来的信息提示我就是贷款人，而银行到目前也没有联系过我，这是怎么一回事，当时帮朋友贷款的时候只是签了一些名字和手印，里面的事情我就不再知道了。请问我该怎么办？
地区：北京-通州区
咨询电话：
帮助网友：155 次
点赞人数：1 人
如果银行没有催缴，你应该联系上你的朋友去银行处理这个问题，希望不要影响力个人的信贷
别人用我的身份证复印件和照片办了一张平安银行信用卡我不知情。被征信拉黑怎么办。可以起诉银行吗？
地区：北京-通州区
咨询电话：
帮助网友：370 次
点赞人数：3 人
你好，可以起诉银行。因为办理信用卡需要本人亲笔签字，如果没有那么信用卡审批程序有误。建议委托律师代为起诉。如果有任何不明白的地方可以随时联系。
相关优质咨询
热门法律咨询
最新法律咨询就刚刚,我接到一个电话,拿起电话就听见语-找法网（findlaw.cn)
就刚刚,我接到一个电话,拿起电话就听见语
就刚刚,我接到一个电话,拿起电话就听见语音系统说,我有一张法院传票。还说什么这是最后一次提醒。我听完以后他电话系统说,如有疑问请按9,我按9转到人工。是一个男的。说我有没有接到法院传票。我说没有。他让我报自己的名字,我说了他说帮我查下,说我在肇庆市什么地方用银行卡消费了8千多元。至今没还。还说我“消费”那个地方已经把我告到法院。他问我身份证丢过来没。没有。我说补办了。问我用这身份证办理过银行卡没有。我确实办理过,可我办理的是工商,根本不是他说的那家银行,最后他说可能有人盗用我的身份证。说要帮我查询一下,可我等了几分钟还是没人说话,我就挂了。请问律师。我真的有张法院传票。还是遇见骗子了。 我现在很急。因为8千对我家来说不是小数目。请各位帮帮忙。海“消费”说我必须到上海报案。他说如果可以他能帮我接到绍兴市110.
现在那个所谓的110一直打给我 怎么办啊??
这是诈骗，不必有理会。
免费快速咨询，获得专业律师解答！
当前律师在线 5068 人今日律师解答 17100 条
其他类似咨询银行核心系统
文章来源与某位大神的力作，写的非常好，科目的地方首位科目号有待商榷，但总之看完后很多东西一目了然。
银行核心系统入门简介
本文的目标读者是准备从事银行核心系统开发、维护的从业人员。请注意，是“准备”，换句话说，可以理解为一份对科技人员，尤其是对新入门的科技人员业务知识方面的培训手册，旨在让诸位从业务方面迅速上手（从技术角度上手的手册我已经贴过一份了，所以如果是用的同行，可以结合本手册双剑合璧，效力倍增）。这里的着重点将会主要在于简单的银行会计原理，以及银行整体的业务流程，还有相应的模块实现手法和注意事项，对金融的会计知识方面应该可能会比较粗浅，这一点与金融系统常见的业务培训手册有所不同，注意体会。
基于此，本文将会假设读者具备一定的计算机技术，具备少量银行方面的业务知识，所以如果有从事非部门的读者（比如财务信贷的同事们），就请不要太计较里面的表述。当然如果有错误，还是非常欢迎指出的。
对于已具备了若干开发、维护知识，或者是即将采用国外系统来建设的同行们而言，本文的内容可能就过于浅显了，看得不爽不要怪我没有事先提醒。
考虑到某方面的问题，这里的系统简介将尽可能的脱离某个具体的系统，仅就银行业务核心系统的共性，进行介绍以及探讨。最后再说一下，没有什么手册、心得是万能的，个人的始终是要靠自己的领悟，这里只是希望能让诸位新人不用象很多人当年一样，独自摸索与徘徊。科目常识基本法则之一：资产负债所有者权益。（新会计准则有所不同）比如说，我们手头上有万，买了一个万的房子，找银行贷款了万，那么资产就是万，负债是万，所有者权益是万。可以简单的把所有者权益就理解成为是真正属于自己的钱。再引申一下，早些年乃至现在，香港人所谓的“负资产”的说法是非常错误的，因为“负资产”实际上是指房子的市值比向银行贷的钱还要小，也就是负债大于资产，所以严格的来说，应该称之为“负所有者权益”才对。资产，从理论上来说，是不可能为负的，最多也就是零。一个号称是金融中心的地方，实在是不应该出现这种失误，不过算了，不要和他们计较。就银行业务而言，会使用会计科目号来对账务进行标识，会计科目号最长为位，国家标准，通常分为下面六种，这里只做简单介绍，详细科目可结合著名的的“业务状况表”来进行理解。再次重申，下面的说法绝对不严谨，仅仅只是为了便于人员理解银行的会计原理、业务知识。1.1资产资产类的科目，用“”作为首位科目号，如“”，表示现金。所谓资产，也就是说“理论上属于银行的钱”，比如说现金，贷款等。比如说某家分行，有万现金，然后把这万都贷出去了，那么资产仍是万，只不过归属（科目）由现金变成了贷款。至于这笔贷款能不能收回，这个不归我们管，就算不能回收，只要没被核销（核销，术语之一，可以理解为银行不要这笔贷款了），那么就仍然属于资产，所以我们称之为“理论上属于银行的钱”。资产类科目都是借方科目，也就是借记时余额增加，贷记时余额减少。1.2负债负债类的科目，用“”作为首位科目号，如“”，表示对公存款。本来不属于银行的钱，就称之为“负债”。比如说我们存在银行的钱，虽然银行可以使用这笔钱，比如说把它贷款贷出去啊，比如说打新股啊，买啊，但是这笔钱只要我们去取，原则上银行就应该给我们，也即是大家常常在营业大厅里看到的“存款自愿，取款自由”之类的意思。这类钱，可以简单的理解为“本来不属于银行的钱”，也就银行欠我们的钱。负债，很有趣的东西喔，银行是负债经营的，比如说一家银行贷款有亿，其实它本身是没有那么多钱的，这些钱都是来自于我们存在它那的钱。如果大家一起都去银行的钱取出来，那它就经营不下去了，这种恶劣的行为，称之为“挤提”，是很不友善的，是要负责任的，我们不要去做。负债类科目都是贷方科目，也就是借记时余额减少，贷记时余额增加。1.3所有者权益所有者权益类的科目，用“”作为首位科目号，如“”，表示利润分配。上面说过了，所有者权益，也就是真正属于银行的钱，即是所谓的“核心资本”。原则上，它包括了一家银行注册时的资金，历年来的盈利（假设有盈利的话，当然还要扣除各类成本开销），如果是股份制银行的话，还包括股本金之类的吧。这类科目相对数量较小，金额较大。所有者权益类科目，增加记贷方，减少记借方，余额反映在贷方。1.4资产负债共同类（往来类）（共同类）资产负债共同类，通常表示往来账户，用“”作为首位科目号，如“”，表示通存通兑。这类科目，通常是指一些往来类账户，所谓往来类账户，嗯，就是金融往来的账户喽。这个科目有点麻烦，可能要结合具体业务来解释一下：比如说我们在招行有个账户，然后跑到工行的上去取钱（招行也是，中山这种伟人的故乡居然都不开个点，严重一下），那么取款成功之后，我们的招行上的账户的钱就少了，工行里面的现金也少了。这笔钱是工行替招行先支付的，要找招行要的。所以工行一定会有一个科目，用来标记它有多少钱要找招行要；而招行也要有一个科目，也是要用来标记它有多少钱要给工行。（怎么要，那在后面清算一节里面会提到。至于跨行的取款原理，就不用再细说了吧。）这个用来标记应付，应收的科目，就是往来类科目，对于工行方而言，当时使用到的就是一个类似于资产类的科目（有点类似于应收账款的意思，或者也可以理解成一种短期的贷款，总之就是工行先付出的资金）；招行当时使用的就是类似于负债类的科目。上面提到的，因为是银行与银行之间的业务往来，所以用来标识资产与负债的科目会有分别，如果是行内之间的往来，那么不会搞得那么复杂（或者也可以说搞得更复杂），就会用一个科目来搞定，这个科目根据具体需要，临时用的，有时表示资产，有时表示负债（其实也就是科目上的余额有时是借方，有时是贷方。因为这个科目既不是资产，也不是负债，只是临时用来表示营业往来的，通常每天会清零，也就是所谓的清算。一般而言，城市级别的商业银行因为是一级法人，所以清算之后，行内往来账户上余额为不为零都没什么关系，反正都是自已家的钱；而信用社会比较麻烦一点，因为通常一个联社都是由多个信用社组成，每个信用社都是一个法人，所以联社内部的往来类账户原则上每天应该都清零，否则账务上就不好看了。（注意，这里指的只是行内的往来账，如果是银行与银行间的，那每天一定是要清零的，否则就是属于错误的情况了）这类科目在我们做过的项目里，基本上都简化了，只有一个轧差类型的。也就是把当天的借方发生额和贷方发生额一减，哪个大就谁记在哪边。我记得以前还有一种双方类的科目，那真是玩死人。双方类的科目是指这个科目既有贷方余额，又有借方余额；对应贷方余额，既有借方发生额，又有贷方发生额，同理，对应借方余额，也是既有借方发生，又有贷方发生，如果只有上期的借贷方余额，以及当期的借贷方发生额，那是无论如何也推算不出当期的借贷方余额各是多少的。（必须根据发生账务时，是借方余额，还是贷方余额来判断），不知道这类科目的起因为何，总之如果有的而且可能的话，最好能拆分之几个性质单纯一点的子目来处理。不好意思，因为对这类科目感触颇深，也被玩过很多次，被玩很久，一时激动，就多说了几句。1.5损益类损益类的科目，用“”作为首位科目号，如“”，表示利息收入。损益类科目，理解起来应该不难，就是指银行在一年的业务里面的收支科目。比如的存款利息，对于银行来说是一笔支出；贷款利息，对于银行来说，是一笔收入。这两个科目就都属于损益类科目。一般来说：收入类科目属贷方科目，借记时增加，贷记时减少；支付类科目属借方科目，贷记时增加，借记时减少。在理解上，可能与资产、负债类的科目有些相反：资产是指属于银行自己的钱，是借方科目；对应于这里，收到的钱是银行自己的，却又是贷方科目。
这里，按会计原理来理解可能会更简单一点，下面一章会讲到。1.6或有资产负债类或有资产负债类的科目，用“”作为首位科目号，如“”，表示承兑汇票。闻歌知雅意，顾名思义，“或有”，那自然就是“或者有”，也就是可能没有了，所以如果没见过也不奇怪。这类科目见得少，一般可以忽视它的存在。1.7表外科目用“”作为首位科目号。1.8其它这里再罗嗦一下，在科目下面呢，一般为了便于分类统计，所有的银行都会再设子目（一个子目一般又会对应多个小子目，或者说是说是多个账户），这个子目，有的地方叫“业务代号”，有的地方叫“结算码”，总之都是一个意思。要注意一下，科目号是国标，子目通常是自己内定的，对应于信用联社，就有可能是省里统一定的。也就是说科目这个东西走遍全国大致上都是一样，子目这个东西可能出省，出了城市，或者说一个市里不同的银行，可能都不一样。简单会计原理2.1内部账户这个问题，我在刚学的时候，曾经颇疑惑了一段时间，所以虽然很简单，但还是单独拿出来说一下。所谓内部账户，是与客户账户相对应的。也就是说这些账户不是用来登记、反应客户的账户信息，而是反应行内的账务情况，比如说损益类科目的账户，就都是内部账户。客户的账户，一般是客户来银行开户的时候，才建立的用来登记账务的账户；内部账户，一般是分行成立之初，统一生成的。（一般都一个专门的程序，由操作人员来调用的吧）其实对于内部账，在会计原则上，登记个科目发生可以。至于增加子目，乃至内部账户的概念，主要是为了后续的分类统计以及相应的分析。说到这个账户，就顺便想起了表内表外的问题。表内账，都是正正式式，真金白银的钱；比如我们的存款什么之类的。而表外账，通常是一些统计之类的东西，比如说现在分行里有多少本存折啦，还有已经核销的贷款之类的。表内账的单位，都是“元”；表外账的单位，就百花齐放了，有的是“元”（比如说已核销贷款），有的是“本”或者是“张”，比如说存折或者说什么有价单证。而最后，表外账在汇总统计的时候，不管是什么单位，就是统统一加了事，对于不是财会专业的，尤其是我们搞计算机的人来说，这种加法简直有些不可理喻，总之银行会计上就是这样处理。所以说，一般报表里面，大家会对表内账比较关注，对表外账的要求不是太严格（我是这样偷偷的说，各位怎么处理是大家自己的事）。2.2复式记账法只要是与会计有关的书，就一定会提到复式记账法，也称为借贷记账法，这里就不多解释，简单说一下。“有借必有贷，借贷必相等”，这两句经典的话，是针对表内账的。对于表外账，用的其实是单式记账法，有的叫“收”、“付”，也的也还是用“借”，“贷”，要结合具体的业务来理解，这里就不展开了。如果没有特别说明，下面的描述都是针对表内账的。对于银行业务来说，最简单的是一借一贷，此外，还有一借多贷，一贷多借。多借多贷在银行业务里中不允许的，因为这样无法精确的体现账务的起始与流向。不过在企业会计中，多借多贷又是允许的，所以说凡事无绝对。有些时候，基于某些特殊的的原因（常见的主要是频繁的锁表问题），可能会临时采用单边记账，但是最后一定会汇总补齐，否则就会出现“借贷不平”这样的严重问题。2.3冲账做错了账，要改正它，就可以理解为冲账。冲账有两种，一种是蓝字冲账，一种是红字冲账。所谓的蓝字冲账，是指与原账务方向相反，金额为正的一种记账方式。而红字冲账，就是指与原账务方向相同，金额为负的一种记账方式。蓝字冲账，本质上是做一笔新的业务，仅仅只是实现了最终的余额正确，发生额会虚增，所以一般的明显有错的账务，会要求使用红字冲正。红字冲账因为是负数发生，所以在统计的时候，发生额将会与原来的交易抵销，这样的话发生额就很严谨了。实际上，对于一个系统而言，通常一笔业务的发生，并不仅仅只包括账务的登记，还会更改许多表中的数据。比如说一笔简单的取款交易，除了登记账务之外，客户的账户上的余额还会减少，这个很好理解吧。那么在冲账的时候，还需要将客户上的钱给它加回去。所以，关于冲账业务的设计，其实也是一个比较有趣的话题，这一点，将会在后面的章节中进行探讨。业务流程描述对于一个没有在柜面实习过的人，描述一下银行的业务流程，可能是有助于理解系统架构的。银行的业务，大致上可以分为财务类的业务，以及非财务类的业务。非财务类的业务这里不做讨论。财务类的业务，又可分为自动业务，以及非自动业务。非自动业务，就是那些必须在柜台办理的业务，比如说一些转账业务，或者金额较大的存取款业务之类的。这类业务，因为是由柜员发起的，所以会有一些单据打印留底，以做传票使用。而自动类业务，就是由系统自动处理的，比如说我们在分行有个账户，然后非要跑到分行去取钱，那么分行那部分的账务，对于分行而言就是非自动业务；而分行那部分的账务，对于分行而言就是自动业务。自动业务因为是自动发生，所以需要业务人员打印报表的时候，才能知道发生了什么业务。柜员日间做各种各样的业务，然后到了下午关门以后，打印一份“科目日结单”，然后用柜员手头留存的传票，按科目逐一汇总累计，与打印出的科目日结单上的金额进行比对。有错一定要一查到底。所以原则上，这时打印的科目日结单，应该不包括自动业务，否则就会对应不上。业务系统在批处理的时候，还会进行一些自动的账务处理，然后最后系统还应该会再打印一份完整的科目日结单，以及日计表（可以理解为业务状况表的简洁版）。至于那些自动业务，系统在批处理的时候，或者是柜员主动查也行，总之就是会有一份“他代本”的传票（对应于上面提到的业务，分行的自动业务就应该属于分行的“他代本”传票。而分行的传票因为是非自动业务，所以在交易当时就会有相应传票产生并打印了）到了第二天，分行开门后开始营业前，业务人员需要下载打印各类报表，不过主要的就是前面说的那两份，然后再看看，如果借贷发生、余额都相等，所有的非自动业务都有传票，而且和整个科目日结单都可以对应上，那么就表示昨天的账务完整无误，然后大家就可以欢天喜地的开始新一天的业务了。常见规范及检测4.1传票以及日志从最基本的说起，通常来说，所有的账务程序都需要打印传票传票格式通常都是统一的，找份以前看看就可以了。对应于转账业务，需要打印转账借、贷方双方的传票。而对于现金业务，则只打印一张传票就可以了，借贷方向采用非现金科目的方向。（我个人认为，可能是因为标识了现金传票，所以对方科目就自然是现金，于是就不需要再打印了，猜的）所以我们在开发程序的时候，打印传票这一步，一般不会特别强调，都是默认要做的。如果不太清楚的时候，一定要主动向需求设计人员询向，千万不要嫌麻烦，抱有侥幸心理。这种东西如果测试的时候漏掉了，是一定会有人要求补上的。（我在多项目里都见过漏写传票，然后在程序上线前夕被人要求赶紧加班补制的，所以千万不要嫌麻烦）在日终批处理的时候，可能有些数量庞大的业务，比如说代收付，结息什么之类的，动不动就是几十万笔，一张张生成、打印太不经济，通常会考虑采用打印一张汇总传票，然后加上一份明细清单的方式。还有的时候，如果上百万的话，可能明细清单都省掉，想办法导成电子数据都是有可能的。上面说的是账务相关的业务。而非账务类的业务，如果涉及到修改类的业务的话，比如说修改密码，修改客户名之类的，通常需要登记日志（），用来记录，以便查询。有的时候，为了统计业务量，或者是为了分析排障，还有可能要求对每一笔发送到主机的业务数据都登记下来，这时候最好采用一种统一的方式来进行登记，以及数据的定期清除，因为这类数据量应该比较大。4.2常见检测内容发生一笔业务的时候，是一定需要进行若干检查的。比如最起码，我们去取钱的时候，就一定会检查密码。这里对一些经常见到的，较为普遍的检查简单介绍如下，套用一句合同上流行的话，叫做包括但不仅限于以下条款：账号卡号是否存在，是否可以正常使用账号与客户所提供的凭证（通常这是指存折客户，对于卡用户而言，账号就是卡号，或者是可以根据卡号查询出相应的账号）是否匹配。密码、证件号码（如果需要检查的话）是否与主机数据一致（印鉴什么的需要业务人员肉眼核对。现在又出了一种加密机，如果采用了这种先进技术，那当然还需要检查这种加密后的信息是否一致了）在转账的时候，一定要检查转出转入方的户名与账号卡号中的户名是否一致。（对私客户还好办一点，如果是对公客户的话，名字又长，括号什么的再一加，经常会出现问题，总之是一定要检查）如果是取款类业务（比如转账业务的转出方也算），一定要检查账户的可用余额是否足够。大家一起来。系统架构及部分模块常见设计方案5.1常见总体架构这里如果用图可能效果会更好，不过我不会用，所以就算了。一般硬件架构，都是一个主机，一个前置机（大前置），前置机就对外了，比如业务人员用来作业务的终端啦，，网银，电话银行什么之类的可能就都对应这个大前置了。大前置，或者是中间业务平台，也是一个很值得探讨的问题，可以做得很大，比如建行的大前置，又比如天的中间业务平台其实也不错，这里不做深究。就软件架构而言，核心系统一般可以分为业务模块，账务模块，和总账模块。总账模块通常记录了一些账务的汇总信息，比如说科目总账的日、月、年的发生、余额。银行中大部分的报表都需要通过取总账模块中的数据来生成。总账模块的数据一般是取自账务模块中，当天的账务数据。（当然，也有很多报表，需要整合业务模块与总账模块两部分的数据一起来出）账务模块，就是用来登记账务的，这部分一般会做得比较通用化，方便各个业务模块来调用。业务模块，当然就是实现各个业务的子模块了，通常模块之间相对独立又互有关联，如果是账务类业务，当然就要调用账务模块中的程序。如果是非账务类的业务，那可能业务模块内部处理一下就可以了吧。一般业务模块的数据会对实时性要求较高，而总账模块没有什么实时性的要求，不过总账模块重在统计分析，所以数据量一般会比较大。5.2计息有的系统可能没有把计息单独列为一个模块，而是直接嵌套在各个业务模块之间了，不过设计成一个模块，个人认为可能会显得比较专业一点，至于到底好不好用那就见仁见智了。刚接触银行业务的时候，曾经很执着，很傻很天真的想过活期账户到底是怎样计息的，因为定期账户的计息方式相对简单，余额乘天数就对了，但是活期账户的余额是常常在发生变动的，所以前多年我一直都不知道银行每年给我算的活期利息到底对不对。银行会计上，通常都会通过“积数”这个东西来计息。何谓积数？就是余额＊天数，所以积数的单位应该是“元天”比如说利息（账户余额＊天数＊利率），在这个公式里，账户余额＊天数就等于积数，于是这条公式也可以写为利息（积数＊利息）。定期账户因为账户余额通常不发生变化，所以一般不会涉及到积数。活期账户采用动户累计积数的方式来计息。也就是说账户余额没有发生变动，就什么事都不干；当账户余额需要发生了变动时（比如说取款），那么业务模块里就将上次账户变动日，到当前日期的天数计算一算，然后用变动之前的账户余额乘以这个天数，然后把这个积数累加到之前的积数上。最后计息的时候，就使用这个积数乘以利率再除。在设计的时候，就需要把每次账户变动的日期都登记下来，还需要有地方记录账户的当前积数。对公计息，或者是一些需要计息内部账，有可能是每天计积数，也就是每天把账户余额累加到积数中。之所以这样设计，是因为对公以及内部账户的数量远小于对私账户，每天把每个账户都过一遍，花不了太多时间；而要是每天把储蓄账户都过一遍，就有点类似于结息了。（对私账户多的银行，有可能达到上千万户，尤其是些代理了社保，医保的银行，不可小看）不过现在有些很好很强大的国外系统，对于利息的处理，是每日计提，当然，这样设计也应该会有它的独到之处。刚才这里提到的了需要计息的内部账，那么一般而言，什么样的内部账需要计息呢，我想，应该是不同法人之间上存下放的款项需要计息。对应于一般的商业银行以及统一了法人的信用联社，因为全市是一级法人，可能就没有需要计息的内部账了。而对于没有统一法人的联社，因为每个信用社都是一个独立的法人，那么信用社存放在联社的用来做往来清算用的资金，就是需要计算利息的。还有的银行，对于贷款的处理，也会有资金池的概念，这时总行下拨分行的用于贷款钱，也是要计息的。这里可以看到，对于计息模块而言，积数是一个很好用的东西。积数除了计息，还有很多其它的用途。比如说招行的金卡，说的是“日均存款万元以上不收取账户管理费”，那么，这个日均存款万是如何判断呢，我很久以前曾经问过一个大堂里的（跟我同姓喔，惜乎已经有了），她说是根据积数来判断的，也就是每个月需要增加万的积数，这样听起来就很合理了吧。对于某些业务来说，可能需要登记利息的明细。比如说贷款的复利的计算，就是根据利息来的。无论是正常贷款，还是逾期贷款，都会生成利息。生成的利息如果未及时归还，则会再根据这笔利息生成相应的复利。复利的复利，喔，太可怕了，也还是视为复利吧。总之，我的意思就是说，储蓄、对公账户这样的结息，在计息模块中可以不用登记利息的明细，因为最后结息的时候根据积数一次搞定；而对于贷款（或者是其它有需要的模块），可能需要在每一笔利息产生之后，都把它登记下来，已保留行使进一步措施的权利。除了贷款之外，还有一些定期账户，也最好采用明细的方式进行处理，越细越好，比如什么零存整取，教育储蓄之类的，要是没有详细的每期存款登记，漏存登记等等，是很容易就被它玩死的。通知存款以前觉得它很可怕，现在想想，突然又觉得没那么可怕，无非就是通知取款，通知期限内的积数登记，然后取款又或者取消通知。可能最主要的，就在于通知期限内的积数计算。总之提取一个计息模块，为这类业务特别定制一些明细文件是很好的一个选择。提到计息，也就顺便说一下利息税。国家在这十年来，调整了两次利息税税率，一次是涨成两分，一次是降成五厘，就那么一点钱，调来调去累不累，要收就收，不收拉倒，还搞什么分段计税，烦死个人。在这里，不知道有没有人是负责搞利息税这部分程序的，也不知道去年改这部分程序的时候，有没有很不爽过。其实要是早考虑到这种情况，倒是可以一开始就通过设置利息税参数表，然后修改计息程序，读取利息税参数表，最后根据不同阶段的参数，分段计息算税。这个方法倒是可行的，也实现过，对于整存整取的定期来说，算得上是一劳永逸，不过对于活期而言，每次调整利息税税率的时候可能就要搞一次类似于结息的东西了，好象没有一劳永逸的方法。在国外的先进系统中，还有一种精采的倒起息可以让人一筹莫展。这种玩法的意思，就是说当客户来柜台前做个什么交易的时候，允许账户的起息日期在业务发生日之前。比如说有人月号来到柜台前还一笔贷款的款，然后说我这笔钱明明月号就到账上了啊，为什么银行不给我扣，非得让我贷款逾期之类的话。然后核查，如果属实，那就倒起息一把，现在虽然是月号，但还是当它是月号还的。（好象是这样，也可能是我说错了，大家对这段解释千万不要太放在心上）总之，如果有倒起息的需求，那必须在最开始设计的时候就与其它计息，以及业务流程整合在一起来考虑，如果中途加入这个需求，那改起设计来会比较费劲，改起代码来更是难上加难。最后，我们再来说说计提，这个也和利息有关。计提常用于利息支出，比如说利息支出是，字头，即是一个用于营业收支的损益类的科目。计提的会计分录中，对应的科目是应付利息，字头，是一个负债类的科目。所以说，计提的含义就在于，虽然当前客户利息并未产生（是结息的时候才产生），但是这笔利息（尤其是整存整取的定期利息）迟早是会产生的，所以这里预先计算，或者说估算出营业支出，计到负债的科目上（负债嘛，本来不属于银行的钱，迟早是要被取走的钱），然后到这类账户结息的时候，就直接从应付利息中支出，计到客户账户上，而不走利息支出这个科目了。看懂了吧，这里其实也就包含了管理会计中的概念，实际上是产生一个提前测算成本的动作。诸位搞的朋友们，你们看过《会计学原理》吗？5.3储蓄/对公这部分模块一般没太多可讲的，通常的设计，都是搞个主文件，保存针对每个账户的信息（比如说账号，账户余额，当前积数什么之类的，总之就是与账户有关的信息），然后再搞个账户明细，用来记录每个账户发生过的业务。听闻有的系统设计，不知道是不是考虑到锁表的问题，计划取消主文件，直接上明细，愕然之余只能感叹自己见识浅薄，因为我总觉得明细要考虑冲账的问题，在读取上不如主文件一下搞定那么畅快。而且主文件可以有锁表保护，可以更好的保障数据的正确性。所以私底下，我还是很推崇这种“主明细”的设计方式。以前曾经很无奈地见过有人在新增业务模块时，把主文件和明细混在一起来搞，于是整个业务流向怅然若失，需求有变动时改动几乎无从下手，若非我多年功力，是断断不可能在加两天班后就理顺通过测试的。说起储蓄呢，又忍不住再提一下招行，不可否认，它的一卡通做得真的挺好，本外币，定活期，一张卡全部搞定。我以前就经常把活期转成三个月定期。根据我本人看法，三个月定期从利率差与时间存放差上来说，性价比是最高的，也就是说一年期利率虽然高，但很难保障这点钱在一年内不用。所以推荐大家把以上的存款转成三个月定期，一般忍忍也就可以拿到利息了，当然了货币基金也是一个不错的选择。还有一次自做聪明搞了个一年期的零存整取，性价比不高，而且还得到柜台去办取款手续，把自己麻烦死了，不推荐使用。扯远了，其实本来是想说，活期、定期、外币账户，这些都是一个又一个的账户，而在招行的设计之中，这些账户，都会与我们的那一张小小的卡片关联起来。换句话说，人家的卡号，应该只含具体的卡的信息，比如说卡的有效期，密码，磁道信息什么之类的，不直接对应某个具体账户的；而各个具体账户则应该会有一个与卡号的对应关系。然后到寄对账单的时候啊，打电话介绍买保险等等附加服务的时候，就还是根据卡号来提供服务。不过还是要根据账户的资金流动来分析消费习惯，以及贡献度的高低等等。至于怎么实现，就根据各位自己的核心系统慢慢体会，不过这么多年了，也可能大部分银行都实现了这种功能或者是类似的一卡通，那就当我这段没有讲过吧，总之我觉得这种理念很好很强大，让我用得觉得很方便。至于对公，好象就更加没什么可说的了。5.4客户信息客户信息，卡号，账户号，这三者是层层细化的关系。所以说，整合好三者的关系也是一个不容易的事情。在我见过的几套系统之中，最常见的问题，就是同一个客户对应多个客户信息。这通常又是个历史遗留问题，比如在手工或单机年代，开户时对于身份证明证件要求不是很严格，一个人可能开了很多账户，还可能是用化名开的账户。在移植上线的时候，常常由于重要信息不齐，又要考虑客户层面的因素，很少能强制性补齐客户资料，通常只能在移植时自动生成一些客户信息，这样就造成了很多冗余，而且也不好再做深层的数据挖掘和客户分析。相比较而言，新开立的分行可能这种情况会好一点，而且面对的客户高端一点的，又会更好一点。在新系统上线，做数据移植的阶段，一般客户信息的问题是最先体现出来的，通常新系统会要求得比较理想化，而实际情况千奇百怪。这里说说常见的，比如说新系统一般会要求证件号码唯一，但是因为很多客户的证件信息缺失，所以这个号码唯一可能会有困难；再比如说有时可能会出现证件号码重复，而且还真的不是同一个人。总之这些问题，它不是新系统的错，也不能完全说是旧系统的错，最关键的是在移植的时候如何处理利用好这部分客户信息。再一个问题，就是客户信息的更新。个人认为最好能有一个有效的途径来更新客户信息，尤其是工作单位，电话号码，对于很多流动人员来说，经常会变换。如果每次都要来柜台更新，我想那基本上就可以认为它是形同虚设了。可以说，随着现在以客户为中心的概念的提出以及越来越多的实现，客户信息这个模块也应该会越来越受到重视，以前设计的表结构应该会有些不够用了。目前如果没有新系统要上的同行们，恐怕是要等着改结构加字段了，保重。5.5贷款很多地方都会把一般的商业贷款与按揭贷款和消费贷款（比如车贷、分期付款之类的，总之有点类似于按揭贷款的）区分开来，这样自然有它的道理。我在这里只谈我个人的设计方案。现在的商业贷款常常采用一笔发放，一笔回收的概念（当然有时会有提前还款，但不象按揭贷款这样有个具体还款计划），然后用合同号，或是借据号做为贷款的一个类似于唯一关键字这样的东西。但是有时公司的商业行为中，一个大项目里会包含多个子项目，然后对应不同的子合同，这些合同对应的贷款之前其实都是有关联的，尤其是在算逾期什么之类的时候，有的是一逾全逾，有的又不是。所以我个人觉得，贷款最好做成多笔发放，多笔回收的形式，发放与回收不必一一关联。但最好在贷款录入时（这时不一定已放款），就录入相应的还款计划。贷款的账号，最好与具体的业务信息剥离，类似于储蓄里面“一卡通”的概念一样，每个贷款，有它自己独立的贷款号，然后正常、逾期、两呆，以及相应的利息账号都与这个贷款号关联起来，便于以后的跟踪追查。
而对于按揭贷款来说，因为期限长（常常是二三十年），而且比较具有规律性，所以一般就不用列出还款计划的明细了。不过要注意，一般按揭贷款的首月还款是按天算息的，稍微注意一下就可以了。
最后，特别强调提出一点，见过两家行，都推出过“等本等息”这种经典的业务产品，也就是客户每月按等额法算出的金额还款，但本金的计算则按等本的方式来算。这里要大声疾呼，这种东西从原理上来说就已经是错误的！因为同样金额，同样期限的贷款，等额法的利息是要大于等本法的利息的。等本法计算方便，理解简单；而等额法是数学家们经过精确的计算，推导出公式，最后计算出的一种还款方法。也就是每个月的还本、还息都要严格按照计算出的公式，这样才能达到等额的效果。试想想，这个月还了一定的本金之后，下个月计算出的利息就不一样了吧，这时要求下个月还的本金与还的利息加起来还是和这个月的一样多，而且还要求每个月还的本金加上利息都是一样多。所以，除非是数学学得特别好的同学，咱们一般的程序员不要妄想自己能推导出公式来，照着公式算就行了。如果强行按等额法计算出的钱来制订还款计划，又按等本法的方式还计算每期还款本金，虽然是方便了，但是在每年利率变更，重算利息时，必然会导致利息总和由等额法的利息渐渐趋近于等本法的利息，也就是总利息额将会越来越少，于是要么在本金与利息的问题上无法自圆其说，要么可能会出现利率上调还款金额反降，甚至负利息的问题，不可不查。5.6清算与结算清算与结算本来是两种业务，不过因为结算中通常又会包括清算，要分成两小节，每小节又说不了太多话，所以干脆放在一起算了，而且这一节只谈流程，不讲设计，这种业务流程理顺了自然就可以设计了。先约定一下，商业银行的级别，一般是分行支行两级，有的可能还会有储蓄所这种第三级。简化起见，暂时就分两级来说吧。如果对应到信用社，那就是联社营业部信用社营业部。分社一级省略。先从结算说起，这里的结算业务，指的就是跨行转账，至少我是打算这么说。每家商业银行，都会在当地的人民银行有一个资金账户，可以理解为结算业务用的备付金账户。然后在自己行内，也会开立一个与之对应的“上存人行款项”的账户。理论上，人行的这个账户和我们自己行内的这个账户，表达的都是“该银行存放在人民银行的钱”的这个意思，所以金额也应该相等。那么，这两个账户在不同的银行（也即不同的系统中），如何保障它的一致性？这一般就是通过日终，营业终了时的对账来保障。所以对账是很重要的，这个后面再说。至于结算业务的流程，先从遥远的手工账单机账年代说起吧。在那个时候，结算的途径、概念、术语可以说是五花八门，什么先直后横，先横后直，提出借方，提出贷方，提入借方，提入贷方，信汇，电汇等等等等，不把人转晕誓不罢休。现在好象大小额支付横空杀出，倒是简化了不少。当然也还有行间转账，同城支付，省金融平台，不过概念上渐渐趋向统一化，先不多说，先谈谈当时我理解中的流程：首先如果要转账，我们要在柜台前填一份一式五联的单（一定要用力填哟，不然最后一张纸上看不到什么字迹的），然后这笔钱就从我们的账户上扣下来，划到银行内部的某个往来账户上了。然后这些单据，再手工传递到上一级，上一级再手工传递到人行（当然，也可能上一级就是人行，这里不要太较真），每传一次，这笔资金都会在当前做业务的这一个银行的往来账户中流动，最后通过人行，流到你想转入的银行中，那个你手工填的单，也流到那家银行中。最最后，转入行的业务人员核对单据，账号，户名都没问题，这笔钱就从往来账户划到我们所填的转入账户上去了。在这些过程中，结算的同时就已进行了清算，资金的流向是银行的某支行à银行的当地分行à地人行à地人行à银行当地分行à银行的某支行也就是每一笔转账，在行间的这一步，都是通过它们在人行的资金往来账户，实现了资金的流动。如果是上述的资金流向，就叫先直后横。如果是地人行à银行地分行à银行地分行à银行某支行这种方式，就叫先横后直。这些单据的传递，都是手工的，或者说是落地的。如果是用信件的方式传递，那就是信汇；如果是用打电报的方式传递，那就是电汇。手工的传递都是有场次的，比如一天两场，或是一天一场之类的。所以这个转账的效率有多快，我就不说了。现在科技进步了，手段丰富了，社会于是也就和谐的。先从我个人较为欣赏的大额支付说起。我一向认为大额这个业务设计得是相当的合理，因为资金是点对点，清算行对清算行，大大缩短了流程，更重要的是，信息的传递是自动的。还是上述的，假设转出行与转入行都开通了大额业务，那么资金的流向是：银行的某支行à人行à银行的某支行原则上是这样的实现，当然行内的设计怎么处理我们就不多考虑了。行内当然也可以设计成为先从银行的支行转到上级分行然后再发出，总之人行收到一笔大额的转账信息之后，是会自动、直接发向指定的转入行（假设转入行也开通了大额业务的话）大额系统的对账，不考虑具体的客户账户，只考虑清算行。通俗的说，人行只管银行今天给银行转过去多少钱，转过去了，人行就不管了。至于银行什么时候把这笔钱入到客户账户中，那是银行的事，人行不管。听起来责任还是很清晰的吧，而且这样也有助于减少账户锁表而造成的行间转账失败。因为大额的这种设计，所以实际转账中，几乎是实时的。我从某地信用社转到异地招行，在柜台还没最后签字，收款短信已经来了。因为大额业务发生的时候，是支行对支行的，所以每发生一笔业务之后，实际上这笔资金是暂时体现在该支行的某个行间往来账户上。所以每天大额业务结束后，还需要按清算的流程，将这笔资金按往、来分别清算到上一级分行（或是总行吧，总之就是当地的最高节点），然后分行与人行发下来的电子对账文件进行对账，检查汇总往、来数、金额是否相等。如果相等，那就可以把往来一轧差，转出多的时候就从存放在人行的账户里扣钱，转入多的时候就往那个账户里加钱。至于这个清算的步骤，通常还是由手工发起，不过这里的手工，就不是指传递单据，而是指运行程序。当然，清算程序也可以自动运行，这个根据系统的不同，要求的不同，自行调整设计。5.7额度控制和计息类似，可能有的系统没有把额度单列为一个模块来处理，而是仅仅作为业务模块之中的一个判断项。早期的业务中，的确可以这样处理。不过随着现在金融产品的不断推出，我个人认为还是把额度拿出来单独搞一下会更好处理一点。比如说，一个账户，可能会有几次冻结，也能会有多项额度控制，每次的解冻，又或者是解除控制，都可能会对账户的额度造成不同的影响，如果夹杂在业务模块中，字段的设计，状态的控制可能都会有些问题，单独整成一个模块，或者说是一个大公函，在账务交易（或是账务模块中）的时候，用额度模块来进行一下判断，可以更方便的检测账户的可用额度是否足够。另外，一些账户相关的透支什么的，也可以比较好的按客户来处理，而不是针对每个账户设置是否允许透支。以至于循环授信额度，这些概念都可以拿出来使用，简单的来说，有点类似于储蓄卡向贷记卡的管理方式倾斜，不过我没做过贷记卡，所以这里也提不出太多东西，只好拿个概念出来大家一起参详一下。5.8冲账本着想到哪里就说到哪里的原则，刚才突然想起冲账还没有说，那么这里就说说冲账。冲账的概念前面已经提过，这里我们指的，就是红字冲账。因为蓝字冲账就是再做一笔别的账务，从人员的角度出发，其实是另一个合法的正交易，不能算是冲账。在设计程序的时候，只要是财务类的业务，就一定要考虑冲账的问题，不能偷懒，不能妄想测试人员会遗漏。就算别人忘记了测试，如果在真实业务中发生了问题，是很麻烦的，所以要养成良好的设计、测试的习惯。（这里不谈编码，因为设计好了自然就会写代码的）关于冲账的实现，我知道的有两种方式：第一是正反交易的概念。也就是普通的账务交易，称之正交易。每一个正交易，都需要有一个与之匹配的反交易，如果是按交易码来管理的话，可能会有一个标准来定义反交易的交易码，比如说正交易码加上就是相应的反交易之类的。（这里只是随便举个例子，比如说表示取款，那么就表示取款的反交易）因为冲账在账务处理上，具有一些共性，比如说都是按原来的财务的会计分录，只是金额为负发生账务即可，所以有可能会有一些公共函数来调用，不过总的来说，都是小函数的概念。这种设计的缺点很显而易见，就是交易码，代码量都要翻倍。业务人员在冲账的时候也需要稍微算算交易码，有可能会输错。好处也是很明显的，就是程序之间互相不影响，修改维护都很容易。第二种设计思路就是大函数的概念，也就是使用一个交易来实现冲账。因为前面说过，冲账业务具有一些普遍的共性，就基本原则来说，找到这笔正交易最初的账务，就可以了。所以使用一个大交易来实现。至于各个业务模块冲账后，在财务处理完之后的业务冲账，那可能就需要不断的在这个大交易中挂上各类外挂了。这种设计的缺点也很明显，就是维护起来很不方便，因为相当于把业务模块的冲账都集成到一个大交易中，在版本控制，大量测试的时候可能会有较多冲突。好处就是不占用交易码，也可以减少很多代码量，对于很标准的冲账，甚至不需要特别去考虑冲账的问题。（不过怕的就是不那么标准的冲账）这两种方法各有优缺点，不知道大家的系统中，使用的哪种方式。这里我提出一个集合两者的第三种方法，一起来参详一下：仍然考虑以大交易为主，不过大交易按某个参数表，来决定调用业务模块中的部分程序解决业务模块的冲账问题。如果是非常标准的冲账，就不需要刻意写冲账程序。如果是不标准的冲账，就在参数表中按设计中自已定义好的各类标识符，使大交易可以判断出何时调用业务模块中的冲账子程序（这些冲账子程序可以随时新增，名字也可以自定义，总之是在参数表中来定义）。至于大交易与冲账子程序中间的程序入口参数的传递，因为各个业务模块要求都有所不同，所以可考虑使用一个大字符型字段，或是数据队列传递字符流的方式来解决。5.9其它暂时先想到这么多，其实还有其它的东西。比如说日终批处理，不过做到这一块的同行们想来不是技术骨干就是业务能手，也就没必要看这份入门级的东西了。还有拆借，贴现，不过这部分在核心系统里面占的份量很小，业务理解起来也不难，抓住一个熟悉业务的人多问问就问出来了。还有代理业务，不过这种业务的设计也多半是主明细的方式（比如说代理单位的汇总信息，以及相应代理业务的明细记录），麻烦的可能反而主要在数据的交互上，也就是什么倒盘啊，信息录入啊什么的，又或者是具体的程序运行效率上，和这个整体设计的关系倒不大。关于批处理，我做得比较多，还是再简单说两句。一般来说，会要求维护人员按各自的业务模块，维护批处理中的相应程序。不过最后，仍然需要一个总体上能把握的人来协调调度。批处理的程序大致上可以分为三种功能：实现各类日终自动业务。比如说到期自动扣款（用过信用卡的朋友们应该深有体会吧），贷款的形态转移，储蓄结息（居然现在变成一年四结，有些先进的国外系统还要天天计提，我只能说系统的设计出发点各有不同啊），可能还会有上面提到的日终清算。当然，还包括了各类的日初业务初始化。实现账务模块数据向总账模块数据的转换，也就是更新总账模块的数据。严谨一点的系统，在更新了总账模块的数据之后，还会用程序来检查一下总账模块的数据与业务模块中的数据是否匹配，一致。（也就是传说中的总分核对）生成各类报表。这部分可能主要是从总账模块中出，也可能需要综合一下业务模块中的数据。批处理的发起，是由固定的操作人员来执行，没见过设计成按时间点自动运行的。刚才说到批处理的三项基本功能，而其实在各类功能中，程序的运行顺序还是颇有讲究，不能随意乱放，否则可能会出现无法预知的问题。批处理的排障，也是一个比较痛苦麻烦的事情，这里真诚的建议各位维护批处理的同行在有大模块上线前，做好心理准备，多多祈祷，实在不行还可以试试拜拜土地。
银行核心与前置系统笔记
国内银行核心系统建设情况调研报告
银行核心系统入门简介
自己整理_银行核心系统相关技术知识
银行核心系统概念入门简介
银行核心系统的清算与结算
（0）银行新核心项目开工了！！！
国内外银行核心系统之间的差异
银行核心系统软件开发
没有更多推荐了，