一、项目背景

目前， 不少银行已经开始积极推进业务中台化，以适应数字化转型和金融市场变化的需求。业务中台化可以帮助银行更好地整合和共享业务资源，提高业务处理效率，快速响应市场变化，并降低风险。

与此同时，银行种类繁多中间业务产品，发展有先后，时间跨度久，升级变化少，技术平台普遍老旧，没有跟上新架构的发展。主要有以下突出问题:1.系统平台主要是单体应用，存在业务量上限瓶颈和并发压力，特别是批量平台、监管账户流水推送等重要、高频交易面临性能压力；2.平台缺乏规划，业务上线时间较为久远，功能不清晰，相似或同类型业务重复开发；3.各项业务上线时间较为久远，功能不清晰，对账清算无统一规范，差错处理规则不明确，结果未有效监控，存在潜在账务风险。

二、项目方案

本项目主要目标有以下目标：

1、通过模型化和参数化，提升研发效率。建立通用业务模型，实现交易数量收敛，基于的更完善的开发平台、通用的业务模型，快速实现业务代码开发和业务流程串联,实现业务快速上线；引入订单交易模式，解耦支付和交付，为产品运营创新提供基础。

2、实现中间业务统一对账、清算、差错处理，根据不同业务场景，落实“以本行为准”或“以三方为准”的规范对账规则，落实“日终自动结转”、“隔日自动清算”、“隔日手工清算”的几种清算模式；把对账清算纳入统一对账平台，实现对处理结果的监控。

参数和模型化

通用业务模型的基础是系统的参数化，业务参数配置按照层级可以分为基础参数、产品参数、场景参数。基础参数作为全局的标准参数，约定了业务参数的含义及数据类型，并且进行统一管理避免重复定义；产品参数按照业务产品划分，同一产品下场景可以共享参数，并且可以设置限制子场景进行修改；场景作为产品的子类，可以直接继承父产品参数，并且可以对未限制参数进行重写，灵活应对不同场景。

按照业务类型，系统设计了代收代付模型、财政支付模型、非税模型、财税库模型、资金监管业务模型、司法查控模型等通用模型。具体的每个模型中，我们将同类型的业务产品整合成通用模型，功能相似的交易抽取成规范化的公共交易，差异较大或者业务特有的则保留为模型中的特色交易。既减少了一半以上的现有交易接口，又为后续同类型产品制定了规范，大大降低了后期开发维护的成本。以代收代付模型为例，模型中有以下公共交易和特色交易。

通过在通用业务模型的基础上构建产品模型，通用交易只需要增加参数化配置将多个产品整合成一个模型交易。产品的特色处理可以通过模型预留锚点，开发产品对应的钩子组件。

通用模型的调用流程如图1所示：

1、用户从渠道端不同的充值入口发起水费、电费等民生类充值缴费，再由交易中心分别向中间业务发起交付处理。

2、中间业务网关接收到交付请求后，根据路由配置，将不同业务的缴费请求，统一路由到代收代付CAP模型中的三方缴费交易。

3、特色应用进行三方缴费处理，并根据水费、电费等业务产品对应的参数配置，判断是否进特殊校验、特殊登记等特色化处理。

4、根据业务产品配置的三方地址及特殊赋值等参数配置，对上送报文进行特殊赋值，并映射到对应的三方地址进行充值操作。

图1

支付交付分离的订单模式

支付交付分离的订单模式将支付动作从交付中抽离，可以实现多支付工具灵活组合，多个产品一次支付，适用于几乎所有中间业务场景。手机银行作为主要客户使用渠道，支持多笔交易合并成一个订单进行支付，支付则支持人民币账户、数币账户、积分等多种支付工具，用户界面截图如图2所示。在支付交付分离场景下，中间业务作为交付平台专注于产品功能及业务逻辑的实现，可以避免后续支付工具的迭代对产品模型产生影响，从而使中间业务模型更具通用性。

图2

支付交付分离的订单模式的交易流程主要步骤如下，设计流程如图3所示：

1、渠道向交易中心发起交易

2、交易中心向聚合收单发起下单支付

3、渠道调起三方支付/收银台 ，用户进行支付操作

4、通知聚合收单 ，收单组合多种行内支付工具行内记账

5、交易中心向中间业务发起交付请求，中间业务进行业务校验、业务登记

6、中间业务向三方发起缴费通知

图3

统一对账清算

中台架构下的各个业务系统接入对账中心平台，由对账中心进行集中处理，实现行内系统间的统一对账。可以规范对账规则，减轻业务系统压力，提高对账执行效率。

统一对账：业务系统通过统一的对账文件形式上传流水，提供两两勾兑、三方勾兑等对账模型，以及提供定制化对账模型应对多种复杂场景。

统一差错处理：对账完成后产生的差错记录，通过人工或者系统自动方式，调用业务系统的差错处理接口进行差错调整。

统一清算：根据业务系统提供的记账分录、借贷账号配置，在对账完成后，由对账中心进行清算处理，支持行内行外统一清算，支持清算前余额核对，支持部分业务自动清算。

统一监控：对0余额账户定时进行余额监控；对有实时交易发生的待清算账户，定时监控核心实时余额与业务系统日间交易轧差相比较。

三、创新点

中台架构下的中间业务生态协同平台的设计特点，主要有从以下三方面的阐述意义和创新性。

目前互联网行业采用中台订单模式较为普遍，而银行业系统范围，中台架构以及订单模式还未有广泛的应用；把中间业务生态协同平台纳入中台架构，更是凤毛麟角。传统的订单模式通过标准订单实现交易流程统一管理，只有交付流程（资金与业务办理在一起完成），支付工具只能在交付服务中固化，不支持多个产品一并下单；适用于涉及流程较固化的场景，如行内转账、贷款放款、汇兑等业务场景。业务中台的订单模式能够提供一个统一的用户界面，支持跨多个产品的复杂场景的产品无差异的一体化销售,整合生态协同平台的不同产品和服务的购买流程。这使得客户可以更方便地进行产品购买和订单管理,提升客户体验。

通过支付交付分离的订单设计模式，把支付相关的的数据、资源、经验、模式沉淀下来，形成数据化和标准化的专业服务能力。实现支付能力的组件化和标准化，通过标准化的方式为业务提供稳定可靠的服务，实现服务共享重用，避免竖井式建设。金融产品工厂作为产品的交付方，可以专注于产品功能和账户管理，从而可以实现业务与资金支付的解耦,降低系统实时处理压力，有助于提高系统的稳定性和可扩展性。

其次，通过业务流程建模提炼业务产品模型和流程模型，通过标准化、结构化的建模方式可以有效的规范需求和设计的颗粒度，并在这个过程中抽取业务的共性和公用能力，从而形成带业务属性的产品模型和公共的能力中心，从而达到业务产品的快速创新，以更低的成本更快的交付响应满足业务需求。

最后，统一对账中心通过提供统一的对账、清算差错处理和资金监控能力，不仅能有效提高平台整体账务风险把控能力，也减轻了生态协同平台的工作压力，把主要精力集中在产品创新上。

四、技术实现特点及优势

中台架构下的中间业务生态协同平台，主要有以下三个特点：1.支付交付分离的订单模式；2.通用的业务模型;3.统一对账清算功能。

1.支付交付分离的订单模式

我们把客户发起的一次交易按订单的模式进行处理。标准订单流程分为：创建、核准、支付、交付四个阶段。

创建。是指客户渠道端将客户的交易请求，发送给业务中台的交易中心；通过统一的创建订单的接口，交易中心实现对渠道端服务的统一；

核准。对订单基本要素进行核对和检查，核准的对象包括实物、现金、凭证、业务要素等。

支付。根据所对应产品的配置，进行业务涉及到的资金处理流程，支付是双向的，可以向客户收取资金，也可以是向客户支付资金；

交付。交付是指实际办理具体业务的过程，是银行将金融产品或者服务交付给客户的过程。在中间业务生态协同场景下，即是完成代理客户向三方系统代扣、缴费等业务办理。

在支付交付分离的订单模式下，交易中心通过对多支付工具进行组合支付的支持，能配合渠道端实现业务层面丰富的营销活动创新。而中间业务生态协同平台作为中台的产品工厂，不再关注客户的支付流程，专注于产品功能和业务逻辑的实现，能够更高效地支持业务发展。

2.通用业务模型

在中间业务生态协同平台上，建立通用业务模型，实现交易数量收敛，基于的通用的业务模型，通过参数配置即可快速实现业务代码开发和业务流程串联,实现业务快速上线。

流程建模是用标准化、结构化的方法，对企业运营实际的可视化表达。通过对系统内业务流程采用流程模型理念，结合架构设计原则提炼中间业务生态协同平台产品模型。一方面，标准化描述业务流程，实现功能共用，通过去差异化形成全行统一的业务流程。另一方面，通过分层方式逐级细化流程，每个分层都有明确的定义。

3.统一对账清算

通过中台架构下的对账中心，把对账逻辑抽取成公共的几种对账模型，进行统一的对账、清算、差错处理以及账务监控。

统一对账：支持两两勾兑和三方勾兑，基于统一的对账文件，有统一的对账规范，只支持通过流水号勾兑。

统一清算：根据业务系统提供的记账分录、借贷账号配置，在对账完成后，统一由清算中心进行清算。清算统计规则由业务系统提供并确认后，生成清算记录并入库（以核心或者三方为准）。

统一差错处理:由各个对账渠道提供差错处理接口，统一对账生成差错并展示，由业务人工确认后触发差错处理，然后统一对账调用各个系统的差错处理接口进行处理。

统一监控：对0余额账户定时进行余额监控；对有实时交易发生的待清算账户，定时监控核心实时余额与业务系统日间交易轧差相比较。

五、项目过程管理

中台架构下的中间业务生态协同平台已完成上线，并且借助平台的新特性，业务部门已开始进行引流促活的运营。课题主要经历了以下几个阶段。

1、需求分析(2023年8月)

分析中间业务产品现有流程，提炼标准化功能点，梳理特殊支付方式及对账清算规则，完成生态协同平台的业务可行性分析报告。

渠道系统、中台系统等配套系统分析对接生态协同平台需要改造的功能点，制定系统改造清单。

完成生态协同平台下所有业务场景的业务需求说明文档编写。

2、系统设计与架构(2023年9月)

工作内容主要包括：微服务架构设计、通用模型设计、概要设计、接口设计。

遵循先进性、安全性、高效性、可持续性等主要原则进行生态协同平台系统的整体架构设计，并出具技术可行性分析报告。生态协同平台系统按照业务种类拆分成代收代付、资金监管等模型并分别出具概要设计说明书。

渠道系统、中台系统、生态协同平台系统完成接口设计文档编写。

3、系统开发(2023年10月)

生态协同平台根据业务需求说明文档，完成业务功能性开发以及安全或性能等方面的非功能性开发，并出具开发自测报告。渠道系统根据系统改造清单完成对接中台架构下的改造点功能开发，并出具开发自测报告。中台系统根据系统改造清单完成生态协同平台接入改造开发，并出具开发自测报告。

4、系统测试（2023年11月）

完成技术测试报告编写，并按照数据迁移测试、接口幂等性测试等内容进行技术测试。完成业务功能测试报告编写，按照业务需求说明及测试案例进行功能性测试。完成系统性能测试报告编写，按照交易耗时、服务器性能、数据库性能等指标进行性能测试。

5、系统部署与上线（2024年1月）

编写上线部署方案，包括生态协同平台、渠道系统、中台系统等系统的资源清单，执行步骤，验证方案等。制定容灾演练方案，并在准生产环境进行演练并出具演练报告。

完成生态协同平台系统正式上线及渠道系统、中台系统配合改造上线。完成生产上线总结并出具上线报告。

六、运营情况

系统已上线公共代缴费、资金监管以及特色业务等业务模型，其中包括水电天然气缴费、ETC消费代扣、预售房资金监管、存量房资金托管、财政集中支付等共计52个业务品种。全新的批量平台系统已上线代缴电费、财务支付、柜面批量转账、批量个人信息开卡查询等18个产品。

截至2024年8月底，业务模型总交易笔数:139万笔，交易累计金额:56亿元；批量平台总交易笔数:243万笔,总交易金额:36亿元。

七、项目成效

系统采用通用模型化以后，对开发成本压降有较大的作用，目前统计数据显示，开发工作量在30%左右。在模型更加完善、开发人员对平台和模型更加了解的基础上，完全有希望达到甚至超过开发工作量压降50%的目标。

系统采用通用支付交付分离的订单模式以后，业务可以通过快速配置支付工具结合生态类产品形成线上营销活动，这已经成为我行业务进行客户运行的常规手段。不仅提升了存量客户的黏性，也吸引了不少新的客户，带动了更多活期储蓄的留存。以水电缴费线上活动为例，活动在短短一个月内，以很低的成本获得了约1000个新客户；园林卡充值线上活动中，带动了约3000户代发客户的活期留存。在存贷利差日益收窄的市场背景下，本系统通过更加丰富、个性化的生态化产品，提高客户满意度和忠诚度，帮助银行提升客户黏性，在非息收入、降低获客成本方面做出共享。

八、经验总结

随着金融科技的不断发展，银行业面临着越来越多的市场竞争和客户需求变化。中间业务这种生态协同的场景，我们考虑创新性的采用支付与交付两个独立的处理流程（资金与业务办理分开完成），通过标准订单实现交易流程统一管理。可在产品上统一配置，支持多支付工具和权益，多个产品灵活组合，一次支付。通过订单模式，银行可以实现系统之间的解耦，让中台的交易中心管理订单、支付中心管理支付、生态协同平台专注于业务产品创新，各司其职，发挥各系统专业的能力。

在中间业务生态协同场景下，通过把系统纳入中台架构，银行可以更好地适应市场变化，提高自身的竞争力和创新能力，满足不断增长的客户需求，为银行业务的持续发展注入新的活力，开启金融科技创新的新篇章。