首页 > 资讯 > 精选 >数字化转型背景下的金融交易业务中台实践

851

分享到

数字化转型背景下的金融交易业务中台实践

2023-06-05 06:06:49 851人浏览薄情痞子

摘要

转载本文需注明出处：微信公众号EAWorld，违者必究。引言：目前金融业IT系统大多由业务部门或渠道进行竖井式建设，这种模式的好处是系统专业性强，但同时也给运营及IT管理部门带来分散性阵痛。那么如何在强监管与统一风控的形势下，实现统一管控、

数字化转型背景下的金融交易业务中台实践 转载本文需注明出处：微信公众号EAWorld，违者必究。

引言：

目前金融业IT系统大多由业务部门或渠道进行竖井式建设，这种模式的好处是系统专业性强，但同时也给运营及IT管理部门带来分散性阵痛。那么如何在强监管与统一风控的形势下，实现统一管控、快速响应、应需而变、按期交付？中台架构就是在这种背景下应运而生。本文主要以某城商行基于BIIP实施的交易中台的实践案例展开分享，一起和大家探讨企业数字化转型中的背景、技术方案及功能架构。

目录：

1、竖井建设模式痛点

2、交易中台功能架构

3、交易中台技术方案

4、交易中台后期的发展方向

一、竖井建设模式痛点

现状：竖井式建设，矩阵式架构

银行业IT建设是国内架构最清晰、方法论最完备的，同时也是最复杂的，因此也势必比其它行业将面临更多的挑战与机遇。

目前大部分银行业的IT系统建设往往由各业务部门依据其各自条线建设专业对口的如“竖井”般纵向IT系统，IT和运营管理部门则对所负责的业务再进行横向建设，各银行依据其规模和业务量大小，IT系统的数量从百套至千套不等，如此数量众多的系统纵横交错构成当前复杂的矩阵式的IT系统现状。

竖井建设模式的痛点

竖井式建设模式带来系统专业性强，也给运营及IT管理部门带来分散性阵痛。

数字化转型背景下的金融交易业务中台实践

竖井式建设带来的好外是专业性强、业务对口，交互界面友好，但系统建设规模扩大后，却给后期的维护与新系统引入的建设带来一系列的问题。

同一个功能，比如转账交易，几乎所有的渠道都有涉及，各系统通过ESB直接调用核心服务，在监管部门强监管政策密集出台的今天，往往一份监管要求下达，分析后几乎所涉及的渠道或业务子系统都需要进行改造，比如“261”、“账户分类“等。

同时应对复杂的市场环境；新业务的开展、风险部门对于全行业务风控要求、运管新规等；其它很多项目对于进度控制都有严格要求，甚至是“限期上线”。这些都给IT部门带来巨大的挑战。

而挑战，往往也意味着机遇，“中台战略”就是在这样背景呼之欲出，成为解决矛盾的一种有效可行方案。

二、交易中台功能架构

以在某银行基于BIIP（业务与创新平台）建设的金融交易中台为例，讲述该实施案例中台的业务逻辑架构。

数字化转型背景下的金融交易业务中台实践

中台业务逻辑架构

“中台” 总体的设计概念是 “瘦核心、纯渠道、厚中台”，中台的定位就是对风控与业务逻辑集中。

“瘦核心”：“瘦核心”是目前为应对当前多核心化的一个被广泛接受的概念，让核心计算和I/O能力集中处理当下高并发量的交易及账务处理，而不将宝贵的核心资源使用在复杂多变的业务需求中，核心的第一要务是具有稳定性的服务响应与输出。尤其是在多核心框架实施后，哪怕核心对需求进行响应，也可能涉及多核心的变动与改造。

“纯渠道”：“纯渠道”是指渠道本职的领域在于展现层，它专业性就在于人机交互或第三方数据交互。

“厚中台”：“厚中台”负责处理核心与渠道剥离的业务逻辑、监管政策落地。为风控及业务规则提供了一个具有一致性且能快速交付的途径。

在该方案中，交易中台先期进行的金融交易与准入交易接驳。实现对已接驳交易逻辑规则的统一管控和逻辑实现。

数字化转型背景下的金融交易业务中台实践

交易中台功能架构

以下列举该中台应用已经落地的部分功能，该功能主要分为两类，一类是简单准入规则的校验，另一类是逻辑判定。

在简单准入规则的校验中实现了渠道准入、时段准入、地域准入、交易类型准入等简单控制。

在逻辑判定中实现了黑名单规则、限额规则、频度规则、以及综合规则等稍复杂的中台功能。

数字化转型背景下的金融交易业务中台实践

引入中台架构后，渠道只处理基本要素完整性；新增子系统客户化部分减少，投产更快；原有功能改造中台统一管理，风险更可控；对监管需求能更快速推动。

数字化转型背景下的金融交易业务中台实践

下面就实现几个功能点简单介绍一下，如人行提出的“交易安全锁”中，通过交易准入可以实现人行文件中要求对全渠道进行“夜间锁”、“常用地锁”、“境外锁”等功能。

通过规则判定类可以实现“外管黑名单”、“涉恐黑名单”多核心同步的“开户黑名单”以及ATM取现限额等功能。

三、交易中台技术方案

数字化转型背景下的金融交易业务中台实践

交易中台技术方案

Primeton BIIP是一款领先的SOA应用平台，秉承一贯的产品理念和特色，采用了先进的SOA架构，基于JavaEE、Eclipse等开放的技术和平台，支持在线业务配置化开发，并把平台化扩展技术、构件技术、可视化技术、图形化技术与SCA、SDO等SOA标准技术完美结合起来，为客户构造SOA应用提供了从设计、开发、调试和部署，到运行、维护、管控和治理的全生命周期支持。

数字化转型背景下的金融交易业务中台实践

BIIP 功能概览

BIIP 从功能上可以划分为开发门户（IDE集成开发环境）, 服务运行平台（BIIP Server）,监控和管理门户(Gonvernor), 以及提供用户管理功能的业务门户 (coframe 框架)。

开发门户（IDE集成开发环境）是集面向构件应用的设计、开发、组装、调试、维护、部署、管理和发布于一体的集成开发环境，提供对SOA应用和服务全生命周期的开发、维护和管理。

服务运行平台（BIIP Server）是支撑中台应用和服务的运行环境，BIIP Server由SCA（Service Component Architecture）容器、构件运行环境、页面流引擎、逻辑流引擎、系统服务、基础服务等核心模块组成。EOS Server是一个面向SOA的基础设施，实现了SOA的核心编程模型SCA1.0、SDO2.1的标准规范。

监控和管理门户(Gonvernor)主要功能是以图形化的方式实现在中台系统运行时进行监控，以利于系统开发人员及运行管理人员进行系统调试与系统诊断。通过实时在线监控和管理工具，可以实现对应用系统各个层次进行监控和管理。用户只需通过WEB界面即可实时监控应用系统的各项运行参数，快速诊断和修正系统运行时的错误及异常，用更少的维护成本确保系统正常发挥作用。

业务门户 (coframe框架)提供了轻量级门户框架，帮助企业快速实施见效。

四、交易中台后期的发展方向

技术上向分布式微服务方向迁移

数字化转型背景下的金融交易业务中台实践

厚中台技术架构的目标就是需要去中心化

从厚中台的业务架构图可以看出，厚中台其实质上会成为一个金融企业某一类或者多类业务的业务逻辑核心，但集中化的业务架构存在引发“雪崩”效用的可能，所以技术就需要选择一个去中心化的底层架构来搭建厚中台应用。

微服务的优点

微服务业务功能简单，功能边界清晰，易于开发、理解和维护

每个服务可以由专门的开发团队开发，自由选择技术栈，如数据库、编程语言

服务间调用采用的api接口，只要接口不变，内部调整对其他微服务透明

微服务无状态部署，通过注册中心自动发现，可以新增或者移除服务实例，按需弹性伸缩，横向扩展很容易

单个微服务十分轻量，启停速度很快，且便于持续自动化部署

每个微服务都是独立部署，技术栈选择自由，所以可以独立演进

交易中台的业务方向

数字化转型背景下的金融交易业务中台实践

结合实际工作中的一些经验，厚中台以后业务发展往如下三个方向将大有可为

一、智能风控

大数据引入金融行业后，一个规则不再是简单的几个条件能够判定，而是需要接合大数据（主要是外部数据）跑分结果来综合进行判定，而外部数据在即时性、全面性上对内部数据进行极大的决断和支撑。

二、灵活定义

中台应用将由按需开发转向业务操作人员按需配置，厚中台深化后可将更多的业务逻辑进行固化，业务人员可自由实现规则编排预演后固化为中台规则。

三、业务逻辑剥离

业务逻辑剥离指的是核心业务逻辑剥离，而中台的方向是这些被剥离的业务逻辑集成。

总结：

总之，在当前IT系统更新升级频繁的时代，“中台”的上游核心层会更新升级、下游渠道层会更新升级，那在这瞬息万变的时代，何以安放金融的灵魂？这时“厚中台”将成为一家银行机构的IT资产沉淀、管理风格的最佳载体，是以在未来相当长一段时间内它将是企业信息化建设的核心。当然，“厚中台”的建立不是一蹴而就的，每个企业都应该基于实际情况打造自己独有的中台能力，在这个过程中，需要遵循适度原则，坚信适合自己的才是最好的。中台建设应该顺时而变、顺势而变、随需实践。

精选提问：

问1：按层次划分，应该是渠道-业务前台-业务中台-业务后台。本文是不是把业务前台和中台都划分到中台了。

答：这是全行级的中台系统，不只是针对某一个或者某几个系统，而是针对某几类业务中台，关注的是业务类型。将多个系统的中台共性抽取，统一管控。

问2：又有SOA，又有微服务，中台是微服务架构吗？是不是这样理解，今天讲的中台，是采用了普元的SOA产品，未来的发展方向，是中台将采用微服务架构？

答：是的。可能仍有部分城商行还是会在SOA上实施。微服务的兴起并不是表示就没有SOA的生存土壤，只有适合的才是最好的。各企业应该根据实际情况来决定和推进技术架构选型和升级。

数字化转型背景下的金融交易业务中台实践