银行系统业务学习

银行的基础架构建设

主要研究解决的问题: 如何建设信息技术基础性资源。

典型的模型：

7 * 24小时不间断运行的核心系统设计

简介

联机交易＋批量任务

联机交易：只负责记录和更新当笔交易状态和交易的账户余额；

批量任务：对于如会计计提存款／贷款利息、计提费用、报表等每日或月末进行的处理；

以下是典型的银行系统日终批量由三步组成:日切(Cut Off)、日终批量(End Of Day)、 日初(Begin Of Day)。

日初批量(BOD)开启一个银行的逻辑处理日。如:定期存款到期处理、 常设指令执行。日切(Cutoff)标志一个逻辑日的日切。将所有联机交付渠道的交易日志合并为一个,用于批处理。同时为下一工作日创建新的日志。 日终批量(EOD)标记一个逻辑日的结束。处理交易日当天完成的交易。利息处理,当日在线交易过帐。这里 EOD 包括了月末(EOM)、季末(EOQ)、 年末(EOY),如在月末那一天的 EOD 就是 EOM

实现方式

以双余额方式为例：

为了能使联机业务能够 24 小时不间断,就要求联机业务与批处理能够同时并行进行,为此采用双日期、双余额的分户帐设计。

双日期分别设为‘最后交易日’和‘上次交易日’;双余额分别设置为 ‘帐户余额’和‘上次帐户余额’及与余额有关的‘余额方向’和‘上次余额方向’。

系统的交易日期在系统中具有唯一性,它保存在系统的日期表中。

前台显示的日期来源于主机系统 的日期表(即交易后由后台返回的日期)。如果后台主机日期表的日期发生变更,联机交易的日期也同时改变。

换日后进行联机记帐交易时,首先要检查帐户的‘最后交易日’与‘当前交易日’是否相同,如果 不同,说明该帐户第一次更变余额,此时要将‘帐户余额’放入‘上日余额’,‘余额方向’放入‘上 日余额方向’,同时,‘最后交易日’更改为此‘当前交易日’。

换日后进行批处理时,如果要进行总分核对等与分户余额有关的处理时,首先要检查‘最后交易日’ 与‘当前交易日’是否相同,如果相同,说明换日后进行此批处理过程前,此分户已经发生过记帐 交易,它的‘帐户余额’已经发生了变化,这时就要用‘上日余额’进行核对或统计。

核心的模块：贷款

贷款就是银行要找到合适的人，把钱贷出去，贷款过程中要经历：贷款人申请、银行审批、放款、还款、贷后管理等复杂过程。

贷款的回收方式变化多端，其主要是在两个要素上进行变化和组合：金额、时间。

回收的 金额 由两部分组成：本金、利息。

回收的 时间 分为：按期结清、一次结清、自由还款、逐期结清。

将上述两要素的各项值进行组合就有了各种变化多端回收方式。

还款计划会随着用户的还款进程，在还款日之后发生变化。

还款计划还会随着贷款产品的组成要素的值发生变化，从而产生变化。

还款计划生成以后，在核心系统的数据库中是以表的形式进行存放，还款计划需要通过批量任务进行更新。

新纪元

核心变革驱动力

催生核心银行系统变革的驱动力，

每一代都不同，

第一代：节约人工成本，利用计算机代替手工。

第二代：提高业务办理效率，利用网络实现联机交易。

第三代：管理变革，需要进行数据大集中。

第四代：业务转型，需要以客户为中心。

新一代：金融科技驱动，核心上云。

前几代核心换代的驱动力都可总结为以业务变革为驱动力，新纪元将以科技发展为第一驱动力。

在瘦核心、大外围的架构下，外部环境变化、内部组织变革适应外部变化等业务变化因素，直接变化外围即可轻松应对，无需对核心大动干戈，所以不将以业务为主要变革驱动力。而在未来，外部商业环境变化的最大因素是“科技”，量子计算、区块链、AI等才是从根本改变商业形态、金融格局的源动力。科技改变了商业服务模式，甚至创造了新的、更便捷的服务方式，比如，扫码支付等便捷的科技手段使支付的流量、并发量呈几何级数上升，对银行系统乃至核心提出巨大的考验，等等，催动核心因“科技”而进化，科技将成为第一驱动力。

互联网分布式核心

现在大多数互联网分布式核心都可以分为两个部分来看，分布式技术平台和分布式应用平台。

分布式技术平台是指开发核心时采用分布式基础架构，在此技术上开发的应用支持分布式部署。基础架构：分布式事务、分布式数据库访问、分布式批量框架、分布式缓存、分布式消息队列、分布式业务集成。分布式技术平台上开发的核心，拥有云原生能力，可以实现核心上云。

分布式应用则是对核心系统的业务模块、功能、库表等进行切割，变成不同粒度子模块，能灵活进行组合和拆分，而不像传统核心打包成一个大平台组在一起。这也是适应SOA风格设计的需要。

互联网核心+传统核心并行的双核心架构

双核心，也就是维持原有核心不变，新建一套互联网核心，一稳一快，来满足银行的业务发展需求。双核心解决方案也是互联网金融下讨论最多的核心改造方案。一个银行在选择基础架构的时候，选择哪种核心架构，对于后续IT支撑的要求是不一样的。双核心的架构，还需要根据银行的业务特点，划分新老核心的业务边界，面临I、II、III类账户切分的问题，只有业务层面的东西梳理清楚了，IT架构才能更好地为业务服务。

双核心架构与早期信用卡业务系统独立在核心之外有异曲同工之妙。早期，银行急于快速上线新兴的信用卡业务，但信用卡的各种记账、计息、计提等功能操作与传统核心的存贷有非常大的不同，在原有核心上做改造非常麻烦、且时间周期冗长，直接采购的信用卡系统或模块独立自成一派，放进传统核心中对核心的改造也非常大，故有不少银行将信用卡系统独立在核心之外记账。现在的互联网核心的双核心架构实则与当年的信用卡系统的做法类似，都是为了解决核心改造漫长困难与新兴业务快速发展的矛盾而出现的解决方案。