我从事银行IT行业十余年，目前从事银行IT项目管理的工作，后期我会持续输出关于银行业务和IT系统知识及项目经验分享的文章和视频，感兴趣的朋友可以关注一下！

银行核心系统经历了几个时代的转变， 本质上是围绕交易与核算关系的演变而变化。 交易与核算分离能使核心系统更专注于交易确认和对客服务， 实现复杂的交易流程， 会计确认和核算处理由核心之外的专业系统、 模块完成， 衔接交易数据和会计核算数据， 能保证银行交易数据与核算数据的一致性， 在这样的情况下， 会计引擎应运而生， 承担起交易核算分离的重要角色。统一的会计引擎， 使交易与核算处理分离， 交易系统更专注对客服务； 同时支持多法人、 多准则的会计处理； 参数化的会计规则， 由专业人员统一进行参数化维护， 自动产生会计分录。 交易与核算分离图示：

一、业务与核算分离在同业的实践分析

1 . 国外银行实践

西方现代企业管理的通用概念， 对客提供产品与服务与会计核算一直是自然分离的， 欧美银行遵从此理念，业务职能和 IT 架构上充分体现了交易与核算松耦合。随着金融危机蔓延， 各国政府不但增强了对商业银行传统会计审核的要求， 对会计计量规则、 核算规则、信息披露都作出了更严格的规定。 根据目 前掌握的资料，国外银行主流的会计核算逻辑架构如图 2 所示。

从图 2 可看出， 国外银行的主流核算架构交易与核算分离已经实现得非常彻底， 所有的交易系统数据都由会计引擎进行统一核算， 以此为基础建设新的会计核算体系， 全球商业银行的 CFO 和 CIO 可以统一、 多维度审视全行的财务经营状况。

2. 国内银行实践

根据调研， M 银行和 P 银行在国际化软件包的实施过程中， 通过吸收国际化软件包的先进理念， 对交易和核算分离进行了不同程度的实践。 通过实现核算和交易分离， 强调专业化分工， 增强产品创新的速度， 提升业务运营和会计核算的效率。

( 1) P 银行

P 银行新上线的核心系统以行方设计为主。 目 前的核心仅限存款交易、 会计、 公共等功能， 新建了独立的会计核算平台( 会计引擎) 可从核心系统、 票据系统等交易系统接收交易流水。 信贷等交易系统尚未接入会计核算平台， 暂时在信贷系统内部核算之后， 将会计分录传输至大总账，如图 3 所示：

由图 3 可以看出， P 银行采用了承担交易核算分离的会计核算平台架构， 但由于行方历史原因并未实现彻底的分离， P 银行的实施模式对多数银行的核心系统建设具有较大借鉴意义。

( 2) M 银行

M 银行核心系统范围仅限存款、 贷款交易系统， 交易流水传送到会计引擎， 引擎生成分录后对接SAP总账。资金、 国际结算、 支付、 信贷等外围系统都在统一核算平台进行核算( 如图 4 所示) 。

M 银行是国内银行业全新自 主建设全套 IT 系统的典型案例， 也是国内第一家实现企业级重构以及交易与核算彻底分离的银行。 但 M银行实施周期太长， 各家银行在借鉴时需要在代价和结果之间做好平衡。

二、 会计引擎在银行的实践

1 . 银行系统边界划分原则

核心系统负责存款业务全程交易处理、 贷款业务后台交易处理、 部分管理维度信息的产生， 定位为客户账户交易系统。 会计引擎承接会计核算职能， 将业务事件转化为会计分录。 总账系统将负责进行各系统账务汇总及内部核算， 与外围系统功能划分遵循的原则：

( 1) 由交易系统完成交易环节处理， 由会计引擎完成生成会计分录环节， 以明确分工， 避免因业务多变造成核算侧的频繁改造；

( 2) 外围系统负责传入信息的准确性， 核心系统原则上不落地、 不修改、 不核查， 以减少手工处理及操作风险， 优化操作流程， 提升客户及用户体验。

2. 会计引擎设计原则

首先， 分录与交易解耦， 相互变化不影响对方。 前端交易产品创新不受后端会计处理的制约， 会计准则变化不影响前段业务运营； 其次， 根据要素来匹配核算规则， 核心系统设计时要尽可能将交易与产品细分或原子化， 核算要素越少， 越能适应通用的交易系统； 再次，架构设计上一定要实现交易与核算分离， 会计引擎要保留逐步上收全行会计核算的功能； 最后， 功能上具备集中各类业务核算规则的可扩展性， 核算规则应由交易系统提供。

3. 可行性方案

从同业机构的成功经验来看， 要做到彻底的交易与核算分离， 首先要在逻辑架构上建立全行统一的会计引擎或会计核算平台， 所有交易系统都直接提供交易流水给会计引擎， 引擎根据核算规则产生会计分录， 经过内部检查、 校验、 汇总等过程， 将结果传给总账系统。 考虑到系统单独建设成本和系统间通讯、 对账成本， 物理架构上会计引擎不一定要单独建设。核心系统仅专注于交易本身， 将交易流水传递到全行统一的会计引擎， 引擎生成分录之后， 传递到总账系统。

考虑到目 前各银行部分外围交易系统都是内部核算( 比如资金交易系统、 国际结算系统等) ， 生成分录后传给总账系统。 同业核心系统建设阶段有可能沿用这种核算模式， 即外围交易系统将会计分录传递到会计引擎，由引擎传向总账， 引擎其实不承接外围系统的核算功能，只是作为对接总账的统一入口 。 从核心系统项目 按期投产角度， 采用这种核算架构的同业应该不在少数， 但会计引擎一定要考虑后续逐步接收全行其他交易系统的核算功能， 类似于 P 银行的核算逻辑结构图。

4. 其他问题

( 1) 辅助计量

辅助计量包括会计项下的计提、 摊销、 估值、 减值等新准则变化、 实际利率调整、 金融工具估值、 中间业务收入计量等功能。 单独建设辅助计量模块使交易系统与会计引擎都更加独立， 以适应会计准则对金融产品复杂核算要求的不断变化， 与对客服务无关， 此模块只处理因会计核算需要而对交易明细做出计量， 即依据会计准则完成交易明细级的账务调整。

( 2) 财务数据核算

关于财务类数据的核算， 同业一致认为财务类数据不属于银行的前台交易数据， 应归属于办公类系统。 财务数据的核算主要是在财管系统内部完成， 不经过核心系统的会计模块或会计引擎， 直接将账务信息传至总账，甚至直接在总账内部完成财务数据核算。

5. 技术实现方案

( 1) 交易与核算分离图示

统一的会计引擎， 使交易与核算处理分离， 交易系统更专注对客服务； 同时支持多法人、 多准则的会计处理； 参数化的会计规则， 由专业人员统一进行参数化维护， 自动产生会计分录。 会计引擎逻辑示意如图 5 所示。

( 2) 会计引擎功能设计图

基于目 前对会计引擎功能的理解， 结合全行系统可行性规划方案， 把会计引擎的业务需求转换为系统设计示意图， 如图 6 所示。

新核心系统建设完成后， 核心系统要按照会计引擎的标准接口 提供交易流水； 外围系统逐步完成改造， 如果产品和交易类型无法细分满足引擎核算需求， 可暂时通过会计引擎的分录接入接口提供会计分录；

引擎内部进行核算必要性检查， 根据交易流水的核算要素匹配数据库中的核算规则生成分录， 最终产生明细分录。 产生明细分录后可以提供给统一的数据平台，也可以将分录汇总后传给总账， 视后续统一规划确定。

( 3) 会计引擎系统架构图

结合银行内部业务场景以及前述对会计引擎逻辑架构和功能设计的理解， 我们对会计引擎底层系统架构进行了初步设想， 底层使用运行 UNIX 操作系统的小型机， 系统响应时间、 批量运行时间以及并发交易支持具有很好的支持能力和可扩展性； 数据库采用业界主流的Oracle 数据库， 为系统提供可靠稳定的数据存储功能；应用层部署主流的 J2EE 应用服务器， 可实现 JAVA 应用程序的快速开发和灵活部署， 且具有极高的安全性能。

会计引擎内部功能主要分为业务处理、 核算规则维护以及日 常管理( 如图 7 所示) 。

我从事银行IT行业十余年，目前从事银行IT项目管理的工作，后期我会持续输出关于银行业务和IT系统知识及项目经验分享的文章和视频，感兴趣的朋友可以关注一下！