账户中心 – 银行业务中台设计
閱讀本文約花費: 21 (分鐘)
本文主要介绍基于业务中台思想下的一种银行账户能力设计模式,在文中称之为“账户中心”。 |
账户能力是银行最基础的核心能力,银行所提供绝的大部分金融服务和金融产品都需要基于银行账户,因此也通常将账户能力落地的系统称为“银行核心系统”。
一、核心设计思想
账户中心的核心设计思想可以总结为:产品与账户分离、介质与账户分离、账户与账户分离。要理解账户中心的设计模式,必须先要理解并接受这3个设计思想,以下将逐一进行详细说明。
产品与账户分离
首先要先搞清楚产品和账户的区别,以下以购买银行理财产品来说明产品和账户的关系:
上图简要说明了客户购买理财产品、期间理财收益结算、赎回理财产品的流程:
在购买流程中,银行从客户个人账户(储蓄卡)上扣除了购买资金,按照对应的理财产品规则换算出可购买的理财份额,并将份额存入客户的理财分户中;
银行在产品运作期间,将按理财产品规则对客户持有的理财份额进行计算,将投资收益换算增加的理财份额存入理财分户(或换算为收益资金直接存入个人账户);
在赎回流程中,银行从客户理财分户取出产品份额,根据理财产品规则换算出对应的资金(以及对应的收益),将资金存入客户个人账户中。
上面的示例中,个人账户、理财分户是我们所指的账户,理财产品规则就是我们所指的产品。我们可以简单总结一下这两个概念:账户指用于登记及管理某一事物所留存数量的特殊账号;产品特指控制某一事物留存数量变化操作对应的运营规则。可以用更直白的话来理解:账户是用于管理当前持有数量的,例如资金余额、理财份额、黄金数量等;产品是控制数量变化的操作规则,例如对某一产品的购买、赎回、计息、分红等操作规则。
说明了账户和产品的概念,我们来说一下为什么要进行账户与产品分离。传统银行系统设计大多将账户和产品强绑定在一起设计和实施,以上面理财的例子来看,在理财管理系统上会将理财分户(账户)和理财产品规则(产品)视为一个整体,两部分功能无法独立运行,例如理财产品的规则无法作用在理财管理系统外部实现的其他账户上。更为极端的例子是客户在银行里的结算账号,例如上面例子中的个人账号,实际上这个账号也对应着一个活期产品规则,每个季度进行活期利息的结算处理,如下图:
传统银行的账户和产品整体设计模式会造成一定的重复建设,例如银行核心系统中需要有账户的设计,在其他产品系统(例如理财管理系统)上也需要有产品分户的设计;此外产品和账户整合的设计也不利于同一产品规则在其他账户上的扩展应用,例如无法将传统核心系统上I类户(普通结算账户)的活期及定期产品规则应用在互联网核心的II、III类户(电子账户)上,同样的规则需要在两个系统上分别实现。
产品与账户分离的思路是将银行的所有账户能力集中在账户中心管理并进行标准化输出,产品系统只需要保留具体的产品运营规则,如下图:
账户中心归集了所有账户的基础能力,产品系统只需要实现具体金融产品的运营规则,利用账户中心对产品账户进行操作,这样一方面可以避免账户能力的重复建设,同时也可以支持产品规则应用在多类账户上,快速实现产品创新。
介质与账户分离
一般的银行客户常说”我银行卡里有多少钱”,实际上这里有一些概念上混淆,客户分不清楚,但对于银行家来说应该弄清楚这里面的真实概念。“有多少钱“实际上是指账户里的资金余额,而”银行卡“实际上是银行提供给客户的一个带号码的凭证,那么”银行卡“一定等同于”账户“吗?有的银行系统确实是按“银行卡“=”账户“的方式进行设计的,也就是客户的账户号码和银行卡号是一致的,所以客户来银行网点”开户“有时候也叫”开卡“。但这样的设计模式在支持一些特殊业务场景会存在问题,比如客户要求银行同时提供银行卡和存折,又或者客户要求提供附属卡给自己家人使用,又或者在客户银行卡丢失后需要换新银行卡的时候要保证原交易记录不会丢失等。
实际上把“银行卡“与”账户“等同的设计模式已经过时,大部分银行的系统内部已经开始使用客户内部账号关联银行卡的方式进行开户处理,内部账户从开户后一直不变,而关联的银行卡可以按需要进行变更。这实际上就是”介质与账户分离“的思想,只是在概念上并没有说清楚,同时在实现上也并不彻底,比如说不支持一个账户多银行卡的情况。
在这里我们提出介质的明确概念:介质是由银行提供给客户,用于证明客户身份的凭证。介质既可以是实际物品也可以是电子文件(例如银行卡和电子证书),既可以在粗的层面上作为客户的身份证明,也可以从更细角度作为某个账号的证明。介质本身不具备金融属性,真正具备金融属性的是介质所绑定的账户。
而“介质与账户分离“实际上就是将账户和介质的直接关系解耦掉,把原来”等同“的关系变成”绑定“的关系,即通过将介质绑定到指定账户上,来间接让介质与账户形成映射关系。
如上图所示,在账户未绑定介质的情况下,客户可以直接使用账号进行资金操作,而当账号同时绑定了银行卡和存在,则通过账号、卡号、存折号都可以对同一个账户进行资金操作,更换银行卡只要变更介质绑定关系即可。
账户与账户分离
在实际的账户应用场景中,一个账户或多或少都会与其他账户有一些对应关系,例如一个集团母公司账户和子公司账户的上下层级关系,或者P2P的公司托管账户和客户虚账户之间的关系等。
集团账户关系示例
部分银行系统在设计账户模式的时候会直接定义好账户之间的层级,但由于不同场景的账户关系多种多样,并没有一种通用的层级关系可以支持所有的场景。因此在账户中心的设计上我们提出“账户与账户分离“的思想,即不在账户结构设计上直接限定账户与账户之间的层级关系,所有账户并无结构上的层级差异,账户之间的关系通过签订“关系合约”进行体现,进而通过不同的关系合约类型形成对各种账户关系场景的支持。基于这种设计思想来简化账户模型,同时可以灵活地支持各种不同账户关联关系的扩展。
以上面的集团账户为例,从账户结构角度看,总公司账户、子公司账户、孙公司账户在开立后并无任何关联关系,都是作为独立的账户使用;但可以通过对总公司账户、子公司账户之间签订“集团关系合约”的方式,让账户之间形成上下级的关系。
二、账户中心设计
全类型账户支持
账户中心需全面支持各类账户的管理和服务能力,包括:
传统账户:传统类型的实体账户,包括结算账户(I、II、III类户及对公结算户)、定期账户、保证金账户、外币账户、储蓄账户、银行内部户等;
产品账户:用于管理产品持仓的账户,例如智能存款产品户、贷款产品户、理财产品户、场景红包户、积分户等;
台账账户:用于向第三方输出台账管理能力的虚拟账户,例如绑定结算账户的会员账户、P2P账户、优惠卷等;
影子账户:用于展示我行代理第三方机构产品客户持有梳理的账户,需与第三方机构同步持仓信息,例如基金账户、代销理财账户、贵金属账户、保险账户等。
账户基本模型
账户中心定义了统一全行的账户模型,便于所有账户处理按照一套模型规则处理,以及将现有账户系统按模型接入账户体系,基本模型设计如下:
账户基本模型定义了账户的基本数据结构,包括:
基本信息:定义了所有账户的公共属性,例如账号、账户类型、开户时间、所属客户等信息;
账单信息:定义了账户的账单(也可以叫交易)属性,例如交易时间、交易金额、交易对手、交易码、交易附言等;
冻结/止付信息:定义了账户的冻结/止付状态,例如冻结编号、冻结金额等;
余额信息:定义了账户的余额信息,例如币种、余额、单位等;
扩展信息:用于存放不同类型账号的特殊属性,例如II类户的绑卡信息;
合约关系:使用合约的方式登记账户与账户之间的关系,例如集团关系、资金流转关系等,在账户关系支持中有详细说明;
介质绑定:登记账户与介质的绑定关系,便于基于介质来进行账户的操作。
此外,账户基本模型也将账户的业务处理抽象为一套标准化接口,包括开户、销户、记账(存/取/冲正)、冻结解冻/止付解止、挂失、查询、信息变更。外部系统对所有账户的处理均只需要按照这套标准接口操作账户,可以大大简化账户操作的复杂度。
账户关系支持
通过合约签订形成各类账户的关系,并进行资金流向的管理,根据需要可以通过开发新的合约类型来扩展支持各种各样的账户关系管理。主要的合约类型包括:
资金流转合约:进行账户之间的资金流向限定,即限制账户资金只能向签订了合约的账户转入
虚拟子账户合约:账户上实下虚,将结算户与虚拟户结合形成类似会员卡性质的资金台账管理,虚拟户的动账联动执行结算户的动账
虚户资金归集合约:账户上虚下实,将多个结算户资金归集到一个虚拟户统一展示,结算账户的动账联动执行虚拟户的动账
资金归集合约:将多个产品户与结算账户关联,通过产品户控制结算账户的资金用途,产品户的动账联动执行结算户的动账
集团账户合约:通过合约将集团公司之间的账户关系关联起来,供业务应用进行集团账户的操作和管理
账户基础功能
账户中心还需要实现对所有账户通用的基础功能,以支持各类复杂的银行业务处理,这类功能可以随着对账户能力的需求进行扩展:
A. 限额管理
按各个维度管理指定账户的入账、出账限额,应支持多维度组合限额,以及支持多限额共同生效。组合限额可支持的维度如下:
客户:按客户汇总所有账户操作
产品:指定产品
资金进出:入账、出账
累计类型:单笔、日累计、月累计、年累计
交易类型(按交易码):所有、取现、贷款放款、绑定卡转账、同名转账…
交易对手:指定对手
B. 合约管理
根据不同的合约类型,自动实现资金的联动处理(具体见“合约类型支持”章节),例如虚拟子账户合约,当操作子账户资金时同时联动执行结算账户的资金操作。
C. 智能路由
由于账户中心可能由多个现有的账户系统接入实现账户服务功能,通过智能路由可自动根据所提供的介质号找到账号,以及根据账号找到实际的账户系统执行账户操作,简化外围执行账户操作的难度。
此外,智能路由支持介质状态及账户状态的检测,只有状态正常才可执行资金操作。
D. 动账信息推送
根据动账通知签约信息,在账户发生动账时自动将动账提醒信息推送至签约渠道中(短信/微信/…)。
E. 睡眠户管理
根据所设置的睡眠户定义规则每天批量检测存在的睡眠户,并按行内要求执行睡眠户的处理(例如发睡眠户提醒短信到客户手机号码)。
F. 同步/异步事务支持
需支持账务处理的事务控制,在涉及多个账户的记账操作时(可能涉及多个接入的账户系统),支持整体的事务控制,保证多个账户的记账同时成功或同时失败。
同步事务:多账户的记账在同一个接口交互中提交,需平台基于冲正机制控制账务事务;
异步事务:多账户的记账分多次接口交互中提交(通过事务标识关联),由平台控制保证出错后冲回原记账交易。
G. 缓存记账
需支持两种形式的缓存记账:
在具体记账系统日切停机维护期间,支持缓存交易待开机后执行记账处理;
对账务进行预校验,校验通过后直接返回记账成功的结果,而实际记账待指定时间汇总批量处理(热点账户处理支持)。
已有账户系统整合
在理想状态下应该将银行所有的账户都落地在账户中心,其他系统只需要利用账户中心操作所需的账户即可,但现实状况是银行内部已完成建设的系统本身已落地了部分账户(例如传统核心系统),或者所采购的新系统不支持使用外接的账户处理(例如理财销售系统)。出于银行IT建设成本的考虑,应考虑直接将已有系统的账户能力接入账户中心,由账户中心统一对外提供标准的账户能力,可以避免由于数据迁移及系统改造所耗费的大量成本。
如上图所示,在账户中心中开发与不同系统对接的适配器,将已有系统的账户能力接入到账户中心中,外围系统在使用账户时无需判断具体账户是来源于哪个系统,只需对接账户中心并按标准服务接口使用即可,账户中心自动根据账户路由访问对应的系统完成实际的账户处理。
三、账户中心对传统银行的意义
目前大部分商业银行都采用了双核心方案开展业务,以零售业务为例,传统核心支持个人I类户的账户管理,互联网核心支持个人II、III类户(电子账户)的账户管理。双核心体系存在的主要问题包括:
(1)外围产品系统如果需要支持全账户购买,需要分别对接两个核心系统,且存在接口标准不一样的情况,接入复杂度高;
(2)一般银行卡管理功能在传统核心上,II、III类户配卡后,银行卡的使用需要先在传统核心确认是否I类户后,再实际调用对应核心系统的记账处理;
(3)两个核心系统上的存贷产品只能支持自身系统的账户购买,即I类户只能购买传统核心上的存贷产品,II、III类户只能购买互金核心上的存贷产品;两个核心产品无法打通,即使是同一规则的标准产品(例如活期、定期)也需要实现两次。
通过账户中心可以将双核心的账户体系进行融合,将双核心账户接入账户中心后,外围产品系统只需面对账户中心一个系统,因此只需要对接一次即可支持全类型账户购买(其他存量账户也可以用这种模式接入);账户中心直接登记账户绑定的介质,对银行卡的记账操作无需外围系统判断账户属于哪个核心;此外,两个核心自身也可以进行产品与账户分离的改造,产品运营直接使用账户中心操作账户,实现双核心产品的相互打通(注:完整的方案需要业务中台的交易中心支持)。