银行核心系统入门简介(2)
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
其它暂时先想到这么多，其实还有其它的东西。比如说日终批处理，不过做到这一块的同行们想来不是技术骨干就是业务能手，也就没必要看这份入门级的东西了。还有拆借，贴现，不过这部分在核心系统里面占的份量很小，业务理解起来也不难，抓住一个熟悉业务的人多问问就问出来了。还有代理业务，不过这种业务的设计也多半是主+明细的方式（比
如说代理单位的汇总信息，以及相应代理业务的明细记录），麻烦的可能反而主要在数据的交互上，也就是什么倒盘啊，信息录入啊什么的，又或者是具体的程序运行效率上，和这个整体设计的关系倒不大。
关于批处理，我做得比较多，还是再简单说两句。一般来说，会要求维护人员按各自的业务模块，维护批处理中的相应程序。不过最后，仍然需要一个总体上能把握的人来协调调度。批处理的程序大致上可以分为三种功能：
实现各类日终自动业务。比如说到期自动扣款（用过信用卡的朋友们应该深有体会吧），贷款的形态转移，储蓄结息（居然现在变成一年四结，有些先进的国外系统还要天天计提，我只能说系统的设计出发点各有不同啊），可能还会有上面提到的日终清算。当然，还包括了各类的日初业务初始化。
实现账务模块数据向总账模块数据的转换，也就是更新总账模块的数据。严谨一点的系统，在更新了总账模块的数据之后，还会用程序来检查一下总账模块的数据与业务模块中的数据是否匹配，一致。（也就是传说中的总分核对）
生成各类报表。这部分可能主要是从总账模块中出，也可能需要综合一下业务模块中的数据。批处理的发起，是由固定的操作人员来执行，没见过设计成按时间点自动运行的。
刚才说到批处理的三项基本功能，而其实在各类功能中，程序的运行顺序还是颇有讲究，不能随意乱放，否则可能会出现无法预知的问题。
批处理的排障，也是一个比较痛苦麻烦的事情，这里真诚的建议各位维护批处理的同行在有大模块上线前，做好心理准备，多多祈祷，实在不行还可以试试拜拜土地。
（注：范文素材和资料部分来自网络，供参考。只是收取少量整理收集费用，请预览后才下载，期待你的好评与关注）
7x24方案 1总体说明 7x24服务，即全天候提供服务；目前一般用于专指夜间批量处理阶段，保持对客户提供基本或全方位金融服务。 核心系统在夜间进行业务批量处理的时候，如计提结息需求，报表需求等，这些业务批量处理需要按账户当日日终余额（或其他数据）进行计算，故需要保持这些数据的一定静止状态，而夜间联机交易需要更新账户余额，在没有7×24实现机制前，银行都需要在批量运行时间段停止夜间的联机交易，而在批量基本运行结束后再次开始联机交易的对外服务。 一般批量处理与联机处理的冲突区就在账户余额，解决批量用账户日终余额与联机用账户实时余额的存储与使用问题，即可很大程度上实现7×24业务服务。实现7x24服务，最关键的要点在于保证两份数据的准确并存： A.动态实时数据（实时余额）：主要是动账及日间查询交易使用 B.日切点的静态数据（上日余额）：主要用于批处理：比如计提、结息、总 分核对、向外围（尤其是财管、管会）供数等。 目前各厂商主要使用的方案有以下几种：
A.单表双余额，国典型的老联想系系统，如神码、繁德 B.双表（双表又分两种：临时表为分户临时表或是流水临时表），典型为中 联及大部分国外系统（神码一开始引进的国外系统也是这种方式） 需要考虑的逻辑主要有： 1.联机交易如何更新余额 2.日终交易如何获取余额 3.账户实时余额的获取（如果临时表是流水临时表，余额需要通过分户账余额 与流水临时表汇总计算取得）。 4.冲正，必须支持跨日/跨年的冲正 下面将一一说明：
2方案设计 2.1双余额动账更新 2.1.1总体说明 分户账上设置余额(ACCTUAL_BAL)、上日余额(PREV_DAY_BAL)、最后交易日期(LAST_TRAN_DATE)。根据以上字段来实现当前余额、上日余额的读取和更新。 仅在动账交易发生时才可能更新上日余额，即如果该账户长期无动账，在此期间将不用更新上日余额（其实此时的“上日余额”字段从名称上来看与实际是不符的） 2.1.2动账处理
银行名称核心系统状况 中国工商银行自主开发，由CB2000升级为NOVA，正在建设第四代新系统 中国农业银行自主开发，部分由高阳开发，现在正在选型国外核心产品进入业务分析中国银行自主开发，现在由FNS升级 中国建设银行自主开发，后由IBM开发 山东农信联社2009年9月选用建行版IBM/CBOD上线新一代系统 厦门国际银行自主开发，先考虑选型Temenos T24 杭州银行（杭州商业银行）自主开发，现考虑选型再造 招商银行自主开发 招商银行纽约分行Temenos T24 上海银行Temenos T24 华夏银行 中信银行 兴业银行神码+自主改造 东营市商业银行兴业银行输出 中国进出口银行神码+SA+时代银通 浙商银行网星升级为中信 吴江农村商业银行网星+SA+时代银通 呼和浩特市商业银行太极 内蒙古农信联社太极 青岛银行银湖+IBM 香港东亚银行DCSA+神码 国家开发银行神码 宁夏农信联社神码 重庆农信联社神码 中国光大银行由南天升级为联想亚信 南京银行联想亚信 江苏银行联想亚信 盛京银行联想亚信 厦门市商业银行联想亚信 宁夏银行联想亚信 上海普通发展银行联想 威海市商业银行联想 江苏银行扬州分行联想 绵阳市商业银行联想 广东发展银行长天 天津银行2001年长天+2002年中太 大连银行中太 石家庄商业银行华腾 焦作商业银行华腾 交通银行由南天对公+联想对私升级为IBS+高阳 江苏银行连云港分行南天 平顶山商业银行南天 深圳发展银行高阳 工银亚洲控股高阳 宝鸡商业银行高阳 咸阳商业银行高阳 渤海银行中联（IBM570/AIX/DB2） 北京银行中联 烟台商业银行中联 徽商银行由南天升级为中联 浙江省农信联社中联 阳江市农信联社中联 阜新商业银行中联 柳州商业银行中联 福建省农信联社中联 平安银行中联 汉口银行中联 富滇银行中联 白山市商业银行中联 秦皇岛市商业银行中联
银行新系统上线总结 ：上线银行系统银行新系统上线心得新系统上线工作总结2016金三上线工作总结 篇一：银行系统工作总结 银行系统工作总结 xx年x月x日，我进入了xx银行，成为xx银行的一员，从事柜员岗位。大半年来，在支行各级领导及同事的帮助下，我立足本职工作，兢兢业业，尽职尽责，努力做好应该做的事，圆满完成年度各项工作，赢得客户的信任，超额完成目标任务。现将半年来工作汇报如下： 一、刻苦钻研，加强学习，不断提高政治理论和业务水平。 一是积极主动参加集中学习。每周我都主动参加支行组织的学习，认真做好笔记，刻苦钻研，努力做到学以致用，学有所用。二是利用业余时间自己学。工作之余，我每天都要自觉加强学习，先后学习了银行相关制度规范，业务操作流程，常思贪欲之害，常修从业之德，珍惜岗位，珍惜荣誉，在思想上不断筑牢防腐思变的防线，在人行组织的案防考试中取得了良好的成绩。尤其入职以来，以银行反假币资考试为契机，认真学习，最终通过该资格考试。三是我行新系统上线期间，我放弃回家机会，利用晚上时间主动练习，以较短时间掌握了银行核心系统操作功能，为顺利完成日常工作奠定了坚实基础。
二、扎实工作，兢兢业业，不断做好本职工作。 一是做好柜台存储业务。从四月份进入xx银行系统以来，我深感起步晚、底子薄，更加主动、更加仔细做好每一笔业务。半年多来，我先后办理近万笔业务，涉及金额超过千万元，无重担差错，深得客户信任。二是积极完成支行下达的任务。工作之余，我广泛动员各方关系，宣传我行政策，积极吸引他们来我行办理存贷业务。每逢节假日和重要节日，我会主动向客户表示节日的问候，不断加强与客户之间联系。10月底，该客户有一笔资金到账，我更是积极联系，主动上门拜访。真诚取得对方信任，最终促使该该客户又在我行存款xx万。三是坚持值好每一班。半年多时间来，我坚持按时上下班制度，坚持值班制度，坚持为客户、提供最优质便捷的服务，没有发生一起迟到、早退、脱岗事件。二，廉洁从业，淡泊名利，不断严格要求自己。 一直以来，我都要求自己清清白白做事，明明白白做人，坚决不乱伸手，不乱想，知足常乐。自觉学习银行安全及风险防范的相关文件，时时刻刻给自己敲响警钟，不忘安全，牢记使命。工作中，坚持按照规章制度办事，坚决维护银行和客户利益，不断服好务、管好自己，做一个合格的银行人。 总之，半年多来，我已融入xx银行这个大家庭，真诚热爱这里共事的氛围，真心喜欢这里的做事文化。半年多来，虽然我逐渐在融入，并在工作上取得了一定成效。但我深知，与支行领导要求相比，与同事相比，我还存在不少差距。新的一年，我将更加
科技部进行组织架构调整的方案 为提高信息科技的管理水平，加强组织体系建设，科技部决定对内部组织架构进行适度调整，对信息科技工作的模式进行尝试，以达到使科技部内部各部门分工合理、职责清晰、相对独立又相互制衡的目的，以促进完善我行IT治理。 此次调整的主要目标是使运行部门全力保障系统运行，开发部门专心开发新产品，项目管理办公室（PMO）做好需求管理和项目质量控制，管理部门抓好信息科技风险管理，技术支持部门做好支行一线服务。 此次组织架构调整的原则： 1、职责清晰； 2、各项工作有充分的备份； 3、各项工作交接责任分明； 4、积极性和效率； 5、当前业务情况和发展规模； 6、可行性； 一、组织架构调整具体方案。 对科技部组织架构进行调整，科技部下设产品研发部、系统运行维护部、综合管理部、项目管理办公室（PMO）、技术支持部五个部门。 组织架构如下：
二、各部门主要职责 科技部负责人负责编制全行IT发展规划和IT预算、IT项目监控，制度执行、重大技术项目和技术问题的协调处理。各部门主要职责如下： 1、产品研发部 工作职责：负责核心业务处理系统、管理信息系统和相关前置系统、外围系统方面的应用软件产品研发、应用系统维护。 具体职责： ⑴设计、开发和测试应用系统； ⑵维护和优化现有应用系统； ⑶项目实施管理； ⑷对运用新技术工具支持业务计划进行评估； ⑸对外购软件和行内开发的软件进行评估； ⑹参与应用架构设计和业务架构设计；
⑺编写和维护应用开发技术手册； ⑻招聘和培训应用软件开发方面的员工； ⑼配置系统相关参数； ⑽科技部负责人布置的其他工作。 2、系统运行维护部 工作职责：负责主机系统、网络系统、机房环境(空调、电力、防火、防水、监控等)以及所有业务系统软件、设备的运行维护、接听服务台电话（此职责待人员到位后履行）。 具体职责： ⑴、管理中心机房所有的IT硬件、运行系统和物理环境； ⑵、制订设备可利用容量计划和管理系统的执行； ⑶、管理备份环境、开发环境和测试环境； ⑷、管理灾难备份中心； ⑸、将应用系统投入生产环境； ⑹、制订并定期实施备份系统与生产系统互相切换演练； ⑺、执行计算机操作，包括每天营业开始、日终、打印、备 份等操作； ⑻、系统用户管理； ⑼、编写和维护计算机运行手册； ⑽、接听、记录分（支）行、网点及部门故障电话； ⑾、科技部负责人布置的其他工作。 3、综合管理部 工作职责：负责信息科技安全管理；所需耗材的初步选型、采购；各种合同、技术资料和档案管理；供应商及外包公司管理、科技部日常事务管理。 具体职责： ⑴、负责每日部门邮件收发； ⑵、制订全行信息科技安全规范、风险控制方面的制度和规则；
核心业务系统 描述：银行核心业务系统主要功能模块包括：公用信息、凭证管理、现金出纳、柜员支持（机构管理和柜员管理）、总账会计、内部账管理、客户信息、活期存款、定期存款、外币兑换、同城票据交换、客户信贷额度管理、定期贷款、分期付款贷款、往来业务、资金清算、金融同业、结算、人行现代支付、外汇买卖业务、国债买卖、保管箱、租赁、股金管理、固定资产管理等。 一、核心系统背景 VisionBanking Suite Core是集团在总结二十余年银行应用系统集成经验的基础上，认真分析中国银行业未来面临的竞争形势，吸纳国外银行系统中先进的设计理念，推出的与国际完全接轨、功能完善、易学易用、扩充灵活、安全可靠的新一代银行核心业务系统。该系统覆盖了银行整个基础业务范围，有助于银行提供给客户更方便、快捷和贴身的“一站式”服务。 在VisionBanking Suite Core银行核心业务系统的开发中，集团将先进的系统设计思想、技术和国内、国际银行界先进的银行业务模式、管理方法结合在一起。系统采用先进的C-S-S三层体系结构，拥有强大、稳定的系统核心。 在全面覆盖传统银行业务的基础上，突出“金融产品”概念，银行可方便定制新的业务品种、产品组装或更改业务模式；系统整合了银行的业务服务渠道，方便银行增值服务范围的扩展，在无须更改系统内核的情况下方便实现与外部系统的互联互通。系统在深化“大集中” 、“大会计”、“一本帐”、“以客户为中心”、“综合柜员制”等成熟的设计思想的基础上，建立了从“客户”、“产品”到“服务” 、“渠道”的集约化经营管理模式，提供了真正的面向客户的服务模式，作到了为客户定制差别化的服务。从而实现了银行集中经营、规范业务、个性服务、丰富渠道、减少风险、辅助决策、降低成本的目标；系统设计严格遵守业务流程和会计核算分离原则，方便于系统快速部署和适应业务流程再造要求。 集团对核心业务系统的不断发展和完善就是以技术的进步来支持和推动银行业务的拓展，为银行的可持续性发展奠定了坚实的基础。 VisionBanking Core的系统实现原则满足了银行业务系统所要求的：先进性、实时性、可靠性、完整性、安全性、网络化、开放性、易扩展性、易维护性、易移植性。 二、系统功能说明
核心业务系统总体设计说明书
目录 §1 综述 (5) §2 系统总体结构 (6) §2.1 系统运行环境 (6) §2.2 系统网络总体架构 (7) §2.3 应用逻辑结构 (8) §3 核心系统技术结构 (9) §4 综合前置系统构架 (10) §5 系统设计总体目标 (11) §5.1 技术设计思想 (11) §5.1.1 三层结构，从面向交易过渡到面向客户、面向服务 (11) §5.1.2 全面贯彻以客户为中心的设计思想 (11) §5.1.3多渠道接入平台系统的采用 (12) §5.1.4 银行服务形式“产品化”及产品定制 (12) §5.1.5 服务模块组织“构件化”、“构件封装”及构件驱动平台 (12) §5.1.6 “引领式”操作模式、流程定制及流程再造 (13) §5.1.7 批处理控制平台，增强批处理的并发程度，缩短批处理的时间 (13) §5.1.8 标准的外部系统接口 (14) §5.2 业务设计思想 (14) §5.2.1 一体化的会计核算体系及核算主体定义 (14) §5.2.2 支持全天候“7X24小时”不间断营业 (14) §5.2.3 支持多分行，支持多级清算 (15) §5.2.4 “全功能柜员” (15) §5.2.5 客户信息集中，统一的客户授信体系，实行额度管理 (15) §5.2.6 加强了内控体系，强化柜员权限管理，完善的系统安全性和灵活的交 易授权机制 (16) §5.2.7 灵活的计息模块，支持“利率市场化” (16) §5.2.8 灵活的收费模块，支持银行自主地制定收费政策 (17) §5.2.9 提供“以客为尊”的一站式服务 (17) §5.2.10 合理利用计算机优势，减轻业务人员的工作量 (17) §6 系统功能要点逻辑设计 (18) §6.1 运行平台和交易组装 (18) §6.1.1 核心交易平台的总体结构 (18) §6.1.2 核心交易平台设计要求 (18) §6.1.3 核心构件库的组成 (21) §6.1.4 构件形成及使用原则 (21) §6.1.5 交易驱动设计结构 (22) §6.1.6 交易驱动设计要求 (23) §6.1.7 交易驱动实现方法 (24) §6.2 报文接口及拆组包 (31) §6.2.1 主报文格式 (31) §6.2.2 系统拆包流程 (31) §6.2.3 系统组包流程 (31)
中联银行核心业务系统 -- 适应国情与国际接轨 系统综述 VisionBanking Core凝聚着中联集团十余年来为国内外金融业开发核心业务系统、实施解决方案的经验，并随着这个日新月异的行业，不断地自我创新和完善。 在VisionBanking Core十几年间不断完善的过程中，始终遵循不变总体指导思想是：借助最先进的开发平台和开发工具，吸收国内外商业银行的成功经验，设计、开发适合银行自身特点、符合国际惯例和未来发展方向、功能完善、易学易用、扩充灵活、安全可靠的银行综合业务网络系统。 中联公司认真分析了中国银行业所面临的竞争形势，在总结十余年银行应用系统集成经验的基础上，吸纳国外银行应用系统中先进的设计理念，推出了与国际完全接轨的最新银行核心业务系统VisionBanking Core，全面支持了银行业务向产品化经营的转变，特别是中国加入WTO之后银行业务发展的需要。 在VisionBanking Core银行综合业务系统的开发中，中联公司不仅采用了目前国际最先进的软件/硬件技术和思想，更将国内、国际先进的银行运作模式和管理方法应用到了银行综合业务系统之中，采用先进的C-S-S三层体系结构，加固了系统的核心，全面整合了银行的传统业务和新兴业务，拓展了新的服务品种，整合了银行的业务服务渠道，使得新服务的出现有更广泛、更畅通的渠道、更灵活快速的应用开发来实现；同时深化了“大会计”、“以客户为中心”、“综合柜员制”等成熟的设计思想，实现了集中核算、集中稽核、集中结算、集约经营的目标，从而提高了计算机在银行系统中的应用水平，提高了计算机在银行系统中的作用，使初期的记帐报帐工具转化为推动银行改革、带动银行业务发展、完善银行管理的科技动力，为银行未来的发展奠定了坚实的基础。 VisionBanking Core的系统实现原则满足了银行业务系统所要求的：先进性、实时性、可靠性、完整性、安全性、网络化、开放性、易扩展性、易维护性、易移植性。 中联银行业务IT系统结构图 中联集团银行业务系统的总体架构不局限于核心业务系统，更是全面的银行业务系统的解决方案。
1、概述 Sm@rtFTS是神州数码银行整体解决方案Sm@rtBanking中银行核心业务处理的开发和运行软件平台。自1994推出第一个版本以来，其强大的事务处理能力、优秀的系统扩展能力和友好的开发界面，使得该产品在全国各类商业银行中得到了广泛应用。 目前，公司推出的Sm@rtFTS是多年来该产品在业务领域和技术领域上的一个最大飞跃。在这个版本的中，第一次真正实现了“交易是配置出来的”这个目标，这使得银行业务人员和系统维护人员今后不再将自己的注意力放在那些繁杂、易错的计算机代码中，而只需通过交易的集成开发环境就可以进行交易的开发和维护。 此外，为适应今后国际竞争的需要，提高系统的扩展能力，在Sm@rtFTS中提出了一个全新的业务体系架构。 1.设计思想产品经营银行是服务性企业，而产品是有形的服务。银行通过有形的产品经营实现业务目标。 产品信息：产品类别、产品编号、可定义的属性（科目、储种/贷种、存期、利率、汇率、费率、起存额、限额等） 产品经营的过程——定义产品（设计）、生产（加工）、销售、服务的过程；产品经营的宽度——产品族的数量；产品经营的深度——产品族中产品的数量。 产品的宽度和深度反映银行生产能力，Sm@rtFTS提供丰富的产品序列，能够满足银行不断增长的业务和管理需要。 客户服务客户管理观念是对传统观念的一次突破，因为银行是服务于客户的，以客户为中心管理必将大大促进银行的服务水平。通过设置统一客户信息，如客户的静态信息：客户姓名、地址、身份、工商税务等；动态信息：客户帐户、客户财务信息等，管理客户活动；客户关系信息：如客户之间的上下级关系，客户帐户关系等，加强以客户为中心的信息管理，可以对不同的客户开展针对性服务，并且还可以进行许多统计决策分析，如：大客户服务、风险控制、成本与效益分析等。 客户服务是实现产品经营的重要条件和关键内容。服务是无形的（产品是有形的），如果没有对客户负责的人，客户服务是空泛的，柜台服务的接触是短暂、与具体问题相关的，自助设备服务的接触是没有交流的，只有客户经理的服务才是富有人性化色彩的。Sm@rtFTS提供了对客户经理、产品经理的支持。 多维会计信息的组织当今市场经济对会计信息提出了许多新的要求，在以管理信息为主导的商业银行综合业务信息系统的设计中有两个突出的方面，一方面是要求核算的精度细，能够对业务进行精确细致的核算；另一方面是要求能从多个角度提供会计核算信息，供决策时参考。举例来说，银行与客户业务往来中，要求能够详细核算各个业务分支机构与客户所进行的各笔业务交易，核算这些交易给银行带来的利润和风险。同时，要从多个角度核算银行的业务状况，可能需要同时按多种口径提供会计信息，如企业性质、企业规模、企业投资方性质、企业财务状况、与银行往来状况等口径提供关于在本行开户企业的统计会计信息。现行单纯按会计科目进行树状分类的会计信息体系实际上是按二维的方式组织会计数据，只能够按会计科目划分口径提供会计统计信息。显然，这样的会计信息体系不能满足这种信息需求。
上海银行“新一代核心业务系统”正式上线 今天，以“携手合作共创辉煌”为主题的上海银行新一代核心业务系统正式上线新闻发布会在沪举行。上海银行行长陈辛、惠普公司亚太和日本地区专业服务事业部高级副总裁连萧思、上海银行总工程师蒋洪、中国惠普有限公司企业计算及专业服务集团咨询与集成事业部总经理吴龙华等出席了上线仪式。上海银行这项基于T24的对公和国际业务系统，由中国惠普有限公司（HP）作为总集成商，协调在银行业具有国际领先地位的核心系统软件供应商Temenos等多家厂商，历时一年半的紧密合作，最终将该行200多家分支行基于核心业务系统的有关信息整体移植、一次切换上线成功。 该系统上线后，上海银行成为国内少数成功将核心业务系统建立在全球先进IT和应用系统平台上的商业银行。这不仅是上海银行以国际先进银行为标杆、培育核心竞争力、全面建设现代金融企业的一项重要举措，也是中国银行业以国际视野推动信息化战略规划、金融科技主导产品和服务创新的成功案例之一。同时，这也是惠普在中国金融业首次实施“核心业务系统”即获得成功的大型项目。有关人士认为，该项目的成功，对国内商业银行加速引进国外先进的核心业务系统，提升中国商业银行应对全球化挑战的核心竞争力，具有积极的示范效应和推动作用。 据介绍，上海银行新一代核心业务系统具备的主要功能特征包括：支持大集中模式的系统建设、产品创新和统一的客户服务；以客户为中心的设计理念，将客户信息作为独立的系统模块，设计专门的客户服务系统对客户信息进行专门的管理；参数化驱动的产品开发，将市场上成熟的业务产品按基本要素进行抽象，提取相同的部分作为参数，通过参数配置进行新产品的定制；提供多渠道全方位的个性化服务，丰富服务内容、提升服务质量，满足客户的个性化需求；通过系统的结构化设计，提供7×24小时全天候服务，避免服务渠道的冲突；分析、决策，提高管理水平，通过完整记录的客户信息和产品信息，为银行的分析、决策系统提供强有力的数据支持；监管、监控，提高抗风险能力，通过在产品、客户、账户、交易等各个层面实现集成的、业务模块间交叉的风险管理和监控。
全国银行核心业务系统 全国法人银行核心业务系统选型清单 -------------------------------------------------------------- 中国工商银行：自主开发,由CB2000升级为NOVA 中国农业银行：自主开发,部分由高阳开发sybase 中国银行：自主开发,现正由FNS升级 中国建设银行：自主开发,后由IBM开发 厦门国际银行：自主开发 杭州市商业银行：自主开发 招商银行：自主开发 上海银行：Temenos+HP 华夏银行：由中联升级为FNS+HP 中信银行：由神码升级为FINSERV+IBM 兴业银行：神码+自主改造 东营市商业银行：兴业银行输出 中国进出口银行：神码+SA+时代银通 浙商银行：由网星升级为中信 吴江农村商业银行：由网星升级为中信 呼和浩特市商业银行：太极 内蒙古农信联社：太极 青岛市商业银行：银湖+IBM 香港东亚银行：DCSA+神码 国家开发银行：神码 宁夏农信联社：神码 重庆农信联社：神码 中国光大银行：由南天升级为联想亚信 南京银行(南京市商业银行)：联想亚信 江苏银行：联想亚信 盛京银行(沈阳市商业银行)：联想亚信 厦门市商业银行：联想亚信 银川市商业银行：联想亚信 上海浦东发展银行：联想 威海市商业银行：联想 江苏银行扬州分行(扬州市商业银行)：联想 绵阳市商业银行：联想 广东发展银行：长天 天津银行(天津市商业银行)：2001年长天+2002年中太大连银行(大连市商业银行)：中太 石家庄市商业银行：华腾 焦作市商业银行：华腾 交通银行：由南天对公+联想对私升级为IBS+高阳 江苏银行连云港分行(连云港市商业银行)：南天 平顶山市商业银行：南天 深圳发展银行：高阳
中国各银行核心业务系统供应商及上级时 间
银行性质银行名称核心系统集成商上线时间或开发时间 四大银行工商银行自己研发 建设银行 IBM 建设银行总行繁德 1998/5-1999/9 农业银行 农业银行总行繁德 1998/3-1999/12 中国银行 FNS "股份制商业银行" 交通银行联想对私，南天对公、高阳IBS 中国交通银行繁德 1997/8-1998/10 招商银行自己研发 民生银行南天》长天（联想）》SAP 民生银行繁德 2000/9-2001/12 浦发银行繁德 2002/6 – 2003/4 光大银行南天》繁德 1995/9-1996/7 中信银行神州数码》FISERV 中信银行繁德 1996/8-1997/7 兴业银行神州数码 兴业银行繁德 1996/7-1997/5，2006年重新合作 广发银行长天 深圳发展银行高阳 华夏银行 FNS 恒丰银行长亮 宁波银行中联华信正合 平安银行中联》ORACLE 浙商银行中联中信 "城市商业银行、农信社、外资银行" 青岛商行银湖 南京银行繁德 2003/10-2004/5 广州银行长亮 2005.9 东莞银行长亮 2006.10，2008.6 北京银行中联》自己开发 上海银行 Temenos 2008年上线 天津银行中泰 大连银行高伟达 成都商行高伟达》重新选型中 吉林银行长亮》ORACLE（逐步更换中） 2008.6 河北银行繁德预计2010/8月上线 西安市商业银行联想》布尔 BULL->中联 内蒙古银行太极》中泰 北部湾银行长亮 2008.11 郑州银行长亮开发中 晋商银行奥尊》神州数码 2009年10月 齐鲁商行中创》神码 2009 唐山商行银润（中创） 包头银行银湖（青鸟实施）
资产负债管理系统简介 一、导读提示 本章介绍的资产负债管理系统是公司2009年12月V2.0设计产品（V1.0为2007年设计产品），体现了公司反思2008年西方金融风暴起因、防范金融风险的最新理论研究成果。 重新设计的资产负债管理系统最突出特点是：以巴塞尔新资本协议第一、第二、第三支柱要求、银监会《商业银行资本充足率审查评估要素及方法》等监管要求为依据，从银行发展战略及高管角度，构建起可操作的银行全面风险管理框架。 二、系统简述 资产负债管理是在世界金融自由化浪潮的冲击下，特别是90年代中后期迅速发展并占据主流地位的现代商业银行经营管理方法。敏感性测试、市值分析、情景模拟、组合管理等先进的管理思想和技术不断发展，使得资产负债管理体系进一步完善，并逐渐成为现代商业银行经营管理框架的核心内容。概括地说，目前西方银行业较为通行的资产负债管理方法和技术有以下四种： 一是基础的风险度量方法――缺口及敏感性分析； 二是动态的、前瞻的度量方法情景分析和压力测试； 三是风险的管理技术表内调节和表外对冲； 四是组合管理技术资金转移计价和风险调整资本收益率等。 这些方法和技术由简单到复杂，由单一到组合，充分展现了西方商业银行风险管理的思想轨迹和技术演变过程。 现代商业银行的资产负债管理体系是一个复杂的系统： 第一，它要求建立由银行高级管理人员和主要业务部门负责人组成资产负债管理委员会，负责制定资产负债管理政策、确定内部资金定价原则、审查市场风险状况、并对风险偏好、风险敞口调节、业务策略选择等有关事项做出决策。 第二，它要求建立专门的资产负债管理团队来承担具体的政策实施、风险计量和管理运作。 第三，它要求建立一个包括识别风险种类、确定风险限额、评估风险收益、调节风险敞口、选择业务策略、配置经济资本、考核风险绩效等一系列环节在内的顺畅的管理流程。 第四，它必须以科学的分析方法、先进的管理工具和有效的管理手段为支柱。 第五，它充分体现了银行全面风险管理框架的总体思路及实施手段的最终效果，从某种意义上说，金融风险管理失控，就是金融企业资产负债管理失控。 资产负债管理系统体现了银行全面风险管理框架，系统的各个子系统或模块要部署实施到银
银行IT系统方案（1）：整体解决方案 描述：银行信息系统建设的二个层面是相辅相成的，“业务处理系统”面向客户服务，旨在以丰富的银行金融产品、综合的服务和销售渠道以及灵活的业务处理流程提供即时的、满足市场需求的银行服务。“经营管理系统”是以业务系统运行过程中产生的数据为基础，以银行经营管理的各个主要因素为对象建立面向银行管理的各个分析主题，以数据基础建立数据模型向银行提供基于数据基础的、量化的决策依据； 一、银行系统背景 自从上世纪八十年代中期以来，中国的各国有银行、股份制商业银行等金融机构经过20多年发展和管理制度变迁，各金融机构结构发生了深刻变化，金融机构的竞争性市场机制和市场体系初步形成，产权多元化的趋势非常明显。 在加入WTO后境外金融机构的冲击，以及随着2003年开始的一行三会（人民银行、银监会、证监会、保监会）的架构设立，《人民银行法》、《商业银行法》、《监管法》的颁布，中国的金融体系正在迅速向国际标准靠拢。所以无论从市场指标、市场集中率还是进入壁垒来衡量，都已经从国有银行高度垄断的市场结构转变为多元主体共同竞争的市场结构。 同时，这种市场竞争的加深以及各金融机构服务能力的比拼，对中国金融电子化、信息化建设的影响将是非常深远的！ 尤其是，从2006年开始在各金融机构实施1104工程开始，标志着管理会计和风险管控在金融机构正式进入实施阶段。另外，从2007年开始的新会计准则的推广，对金融机构的会计核算、财务报告以及信息披露将有深远的影响，也必将进一步推动银行IT架构及金融信息系统的快速发展和与国际惯例接轨。
面对中国金融市场的竞争格局加剧，银行的信息化建设愈发成为银行发展的核心要素。结合目前国内外系统建设的经验，按照未来国内金融市场的发展趋势，集团认为，商业银行的电子信息系统建设应当在“二个层面”上考虑“统一规划，分步实施”，即商业银行电子信息系统建设的整体解决方案包括二类相对独立的组成部分，一类是“业务处理系统”，一类是“经营管理系统”。 二、银行系统方案 银行信息系统建设的二个层面是相辅相成的，“业务处理系统”面向客户服务，旨在以丰富的银行金融产品、综合的服务和销售渠道以及灵活的业务处理流程提供即时的、满足市场需求的银行服务。“经营管理系统”是以业务系统运行过程中产生的数据为基础，以银行经营管理的各个主要因素为对象建立面向银行管理的各个分析主题，以数据基础建立数据模型向银行提供基于数据基础的、量化的决策依据；同时，“经营管理系统”按照决策指导业务系统中关于银行产品、服务等内容的配置、调整，以使业务系统提供的服务能够更快、更充分的贴近市场需求。 “业务处理系统”是商业银行提供金融服务的基础，而“经营管理系统”是商业银行提高核心竞争力和发展潜力的支柱。 三、系统结构图
核心银行基础知识大全
文档修订记录
目录 1前言 (1) 1.1目标 (1) 1.2范围 (1) 2银行IT系统概述篇 (1) 2.1银行IT系统分类 (1) 2.1.1银行系统功能类 (1) 2.1.2银行使用范围类 (1) 2.2银行IT系统总体架构 (1) 2.3银行IT系统特性 (2) 2.4银行IT系统产品化与定制化 (2) 2.5银行IT系统使用技术 (3) 3核心业务系统篇 (3) 3.1核心业务系统概述 (3) 3.2核心业务系统的特点 (3) 3.3核心业务系统的架构 (4) 3.4核心业务系统的技术 (5) 3.5核心业务系统的功能模块 (5) 3.5.1客户信息管理 (5) 3.5.2存款业务 (11)
1前言 1.1目标 本文主要分为十二章来描述核心银行基础知识，让使用者更容易、更便捷的全面了解核心银行各大系统主要功能，以免在使用过成中造成不必要损失及麻烦。 1.2范围 适用于使用银行系统从业人员、银行核心系统运维人员、银行核心系统开发人员，知识内容仅供参考，如有不足和错误之处望有智人士指正。本文编者感激不尽。 2银行IT系统概述篇 2.1银行IT系统分类 银行IT系统可分为两大类，一类为根据系统功能类；一类为根据使用范围类。 2.1.1银行系统功能类 银行IT系统按功能划分大致可以分为四类：业务系统、管理信息系统、渠道系统、其他系统。 2.1.2银行使用范围类 按使用范围分大致可分为总行级系统和部门级系统，前者如核心业务系统，特点是全行上下统一版本。后者如分行特色业务，第三方存管，外汇交易系统等。特点是系统只局限于某个机构在使用，或者说不同机构使用的版本，功能差异很大。 2.2银行IT系统总体架构 商业银行IT系统包括五个层次：渠道层、渠道整合层、核心帐务层、管理层和决策层。
银行核心系统发展调研报告 大多银行业内人士认为现代银行核心业务系统之所以在全球被广为接受，因为它既能够对数据、风险和客户资源进行统一配置，还能塑造出各个银行富有个性的核心竞争力。其参数化配置和模块化产品搭建理念，给银行提供了一个灵活的产品设计平台，这个平台上的产品可以在各种服务渠道上共享，体现了渠道整合和业务统一的思路。同时在这个平台上设计的产品符合国际银行业行业标准，这就如同帮助国内银行业务部门掌握了国际通用语言。 一、银行核心系统的定义 核心银行系统在国际上的标准定义为银行处理核心客户信息、存款产品、贷款产品、支付服务和核心总账的系统部分。作为银行存款、贷款账务处理的重要组成部分，银行核心业务系统是银行业务系统运作的心脏，凡一切关于存款、贷款账户的业务操作都是在核心业务系统中完成的。其主要业务包括：客户信息管理、存款业务、贷款业务、总账以及对这些存、贷款账户的日间操作等。 二、银行核心系统的意义 全球金融海啸后，中国金融市场呈现出开放、活跃、繁荣的行业景象，然而，全新环境下的生存压力与竞争挑战，也成为中国银行业头上悬着的“达摩克利斯之剑”。对中小银行而言，这份感受尤其深
刻，从近几年来中小银行更换核心系统空前旺盛的需求中也可见一斑。 目前，我国各类中小银行的经营模式与市场格局都经历着巨大的变革，依托区域经济优势、建设具有特色的精品银行已成为它们普遍的追求。所谓业务驱动IT、IT支持战略，银行战略和业务上的变化最终都将转化为对IT的需求，银行IT系统中最关键的核心业务系统，则直接决定了银行的运营效率、创新能力、服务水平和市场竞争力，这也正是中小银行重视核心系统建设的根本原由。 三、国内中小银行核心系统的现状 从国内现状看，银行核心系统的设计使用年限不超过5年。现在，之所以有近半数的中小银行任其核心系统“超期服役”或“准超期服役”，主要原因如下： （1）没有系统改造的需求，缺乏内在动力。一些中小银行地处金融市场不发达的小城市或落后地区，在业务上没有对更先进核心系统的需求。 （2）有系统改造需求，但原系统开发商已“出局”。国内从事银行核心系统开发的厂商多数缺乏实力，导致一些核心系统仍在银行服役，而原开发公司已经被淘汰出局。其结果是，银行虽然可以自己对系统进行维护，但是仅凭小银行的实力要完成对原系统的升级改造显得十分困难，甚至不可行。
智慧银行整体建设方案 2018年3月
目录 第一章智慧银行建设驱动力分析 (3) 1.1行业背景 (3) 第二章瑞银科技智慧银行解决方案介绍 (4) 2.1系统总体要求 (4) 2.2系统整体架构 (5) 2.3系统业务功能设计 (5) 2.4智慧银行软件系统功能设计 (8) 第三章瑞银实施案例介绍 (19) 3.1企业介绍 (19)
第一章智慧银行建设驱动力分析 1.1行业背景 中国金融市场对外资银行全面放开，非银行金融机构正逐渐进入 传统银行服务领域，金融脱媒问题日益严峻。新巴塞尔协议实施的要求，监管标准驱动的银行风险管理和合规管理要求压力仍在，相关法律和政策不断改进与完善。客户需求愈来愈多样化和复杂化，银行服务水平与日益提升的客户需求存在差距。由于历史、制度、实践的各种约束，中国银行业的产品和服务还不能满足转型的需要，必须提供创新的产品和 服务，必须颠覆传统的经营模式，必须优化治理结构，必须更新经营理念和企业文化。 在移动互联时代的背景下，最佳客户体验的特征就是为客户提供随时、随地、随心的金融服务。产品和服务的创新是未来银行发展的内在动力，新技术支持下的高效可靠地服务平台和不断创新的产品是银行竞争力的体现。建设符合市场发展需求的智慧银行，顺应技术发展的潮流和客户的需求。 变革和转型的方向是以更好地为客户提供服务为核心，构建更加 智慧的银行。这里的智慧代表着更透彻的感应度量、更全面的互联互通、更深入的智能洞察
第二章瑞银科技智慧银行解决方案介绍 2.1系统总体要求 本次系统建设目标是应用先进的计算机技术、手机技术和业务处 理模式，建设一个架构先进、客户体验良好、安全可靠，能整合手机 银行、网上银行、电话银行、微信银行、智能银行、大堂 IPAD、排 队机、预填单机、多媒体终端等渠道，智能识别客户、智能管理客户 和精准营销的厅堂管理系统，达到提高服务效率、改善客户服务体验 的目的。要求系统和平台具备完善的内部管理功能，满足 7×24小时稳定可靠运行，充分考虑系统容量和业务应用等的可扩展性，支持未来业务发展时系统平稳升级。
国内银行核心系统建设情况调研报告 二〇〇五年七月
前言 核心业务系统，也称为综合业务系统，是银行信息化建设的核心部分，是银行业务经营的基础。随着世界金融环境的不断向前发展，拥有稳健、灵活、安全、可靠的核心业务系统是体现银行核心竞争力的一个重要方面。 国内银行的核心业务系统建设主要经历了三个发展阶段： ●阶段一（七十年代末期——八十年代中期）： 这一阶段是银行信息化建设的起步阶段，银行的储蓄、对公等业务逐渐以计算机处理代替手工操作，本阶段系统特点主要体现为按照业务网点分散建设、单机操作，只是用计算机取代了算盘和手工帐簿； ●阶段二（八十年代中期——九十年代末期）： 这一阶段银行开始通过使用计算机网络技术实现银行部分业务的实时联机处理，并逐步实现了银行在一定区域范围内的数据集中及互联互通；区域集中让所辖银行得以共享数据资源，统一了科目设置，改进了业务流程，提高了服务质量（如通存通兑的实现）； ●阶段三（2000年至今）： 第三阶段即“数据大集中”阶段，全国性的银行数据通信网络框架基本建成，各银行的综合业务处理网络相继建成，一个多功能的、开放的银行信息化体系初步形成；全国性的数据大集中让银行的数据在更大范围内共享，数据的收集和管理更加方便，管理和决策也更加高效便捷。 当前国内银行核心系统的建设正处于第三阶段，大部分全国性银行已经完成了数据大集中的工作，部分银行在采用国内系统实现了“大集中”的基础上开始以国外核心业务系统替代原有综合业务系统。我们将采用国内系统或自行开发系统完成数据大集中的银行称为“第一军团”，将已采用或即将采用国外系统的银行称为“第二军团”。在此背景下，*****金融软件公司解决方案部、企业发展部、国家开发银行事业部特别成立了联合项目小组，共同完成了这份《国内银行核心系统建设情况调研报告》，希望给*****金融软件公司、国内同行及正在从事核心业务系统建设的银行，特别是“第二军团”阵营中的银行提供参考。
银行核心业务系统解决方案罗列 BANCS Core banking Solution TCS Read More BANCS, the flagship product of FNS which is now a part of TCS, is a proven solution that enables Banks to increase productivity and profits by enabling Banks to respond rapidly to market demands for new financial products, providing superior customer service and managing risk across the enterprise. BANCS is multi-currency, multi-entity universal banking solution with an integrated state-of-the-art front end delivery channel. The system offers fast product launching capability, support for all delivery channels, true 24X7 anytime, anywhere service with no downtime. The key to the success of BANCS is its superior open architecture which provides an unequalled level of integration, flexibility and scalability across all platforms. TietoEnator Core Banking Suite TietoEnator TietoEnator's Core Banking Suite consists of components that can be installed independently and integrated into your current banking environment. At the heart of the Core Banking Suite are comprehensive customer, product, and agreement management modules that provides a single and complete view of the financial institution's customers and their engagements with the institution. The Core Banking Suite manages deposit and loan products and credit and debit cards. The application includes a world-leading cash management component, to be used by large corporates to perform cash pooling, sweeping etc in a cross border, multi-currency environment. Product management is possible through a configurable product composer. This gives the bank's business people the flexibility to assemble user-definable banking products with flexible pricing structures and then quickly distribute them through any channel to their banking customers. System Access SYMBOLS SunGard System Access SYMBOLS serves the retail and wholesale banking, treasury and trade requirements of banks worldwide. Banks rely on System Access SYMBOLS to provide straight-through transaction processing for front-to-back office operations with on-line real-time processing capabilities. Supporting multi-currency, multi-language international banking requirements, System Access SYMBOLS also offers connectivity with national clearing systems, SWIFT and I-BAN. Each module or application utilizes a common set of enterprise-wide customer definition and product parameters, to ensure seamless integration of your customer activities and processes. Each module supports the entire life cycle of a product from its inception to maturity with comprehensive enterprise integration across customers, product, risk and accounting control.