20180124-结合个人银行账户分类管理通知谈需求如何落地

Posted by PaymentGroup on January 24, 2018

一、主题分享

1、前言

作为后端的产品很重要一项工作就是将需求落地。这项工作的标准化操作是使用UML工具。我就自已的经验结合一个虚拟的例子介绍一下这个过程。近日,人民银行下发了《关于改进个人银行账户分类管理有关事项的通知(银发〔2018〕16号)》,从开户、资金转入转出及限额等方面,都做了很多优化和改进,扩大了II、III类账户的应用范围。我就以此作为背景,分析执行该通知的要求需要做哪些工作。

说明一下我本人是支付公司的产品经理并不做银行系统,以下只是举个虚拟的例子说明一下。假设某家银行已有了一个直销银行的APP。针对该通知银行系统的前后台涉及哪些改动。
先介绍一下落地的流程:

  1. 分析通知中涉及的场景;
  2. 针对场景分析涉众及用例,我以持卡人为涉众进行分析;
  3. 分析每个用例的业务流程,确定业务流程中人与系统的互动关系;
  4. 根据人与系统交互与系统之间的调用确定系统改造的功能点;

2、解读通知分析场景

2.1通知中开户相关的规定

(一) 2018年6月底前,国有商业银行、股份制商业银行等银行业金融机构(以下简称银行)应当实现在本银行柜面和网上银行、手机银行、直销银行、远程视频柜员机、智能柜员机等电子渠道办理个人Ⅱ、Ⅲ类户开立等业务。2018年12月底前,其他银行应当实现上述要求。

分析:这是一个开户的大用例,还应该包含不同场景下开户的子用例

(二) 个人通过采用数字证书或电子签名等安全可靠验证方式登录电子渠道开立Ⅱ、Ⅲ类户时,如绑定本人本银行Ⅰ类银行结算账户(以下简称Ⅰ类户)或者信用卡账户开立的,且确认个人身份资料或信息未发生变化的,开立Ⅱ、Ⅲ类户时无需个人填写身份信息、出示身份证件等。

分析:这是一个业务规则,但如果该消费者之前开立Ⅱ、Ⅲ类户未绑定Ⅰ类银行结算账户或者信用卡账户就需要一个独立的绑卡用例了。作为产品可能需要调研一下系统中是否有这样的用户。

(三) 银行在为个人开立Ⅰ类户时,应当在尊重个人意愿的前提下,积极主动引导个人同时开立Ⅱ、Ⅲ类户。

分析:线上产品前端要优化流程提示用户,涉及开通I类户用例;柜面服务时要考虑如何引导业务操作,这不一定是系统功能,但产品可能需要考虑业务流程设计及话术;

(四) 银行为已经本银行面对面核实身份且留存有效身份证件复印件、影印件或者影像等资料的个人开立Ⅱ、Ⅲ类户时,如个人身份证件未发生变化的,可复用已有留存资料,不需重复留存身份证件复印件、影印件或者影像等。

分析:线上APP产品前端要简化流程;

(五) 银行为个人开立Ⅲ类户时,应当按照账户实名制原则通过绑定账户验证开户人身份,当同一个人在本银行所有Ⅲ类户资金双边收付金额累计达到5万元(含)以上时,应当要求个人在7日内提供有效身份证件,并留存身份证件复印件、影印件或影像,登记个人职业、住所地或者工作单位地址、证件有效期等其他身份基本信息。个人在7日内未按要求提供有效身份证件、登记身份信息的,银行应当中止该账户所有业务。

分析:这是一个由监管要求引发的用例,需要消费者配合提供材料。

(六) 自本通知印发之日起,同一银行法人为同一个人开立Ⅱ类户、Ⅲ类户的数量原则上分别不得超过5个。

分析:开户的规则;

2.2 Ⅱ、Ⅲ类户使用规定

(一) 银行应当基于个人银行账户分类管理制度开展业务创新,打造多元化非现金支付方式,提升便民支付水平。积极引导个人使用Ⅱ、Ⅲ类户替代Ⅰ类户用于网络支付和移动支付业务,利用Ⅱ、Ⅲ类户办理日常消费、缴纳公共事业费、向支付账户充值等业务。

分析:APP端如何引导需要很好的交互设计。如消费者怎么知道自己有Ⅱ、Ⅲ类户?Ⅱ、Ⅲ类户没有实体卡且账户号很长,如何在第三方平台上绑定时填写?

(二) Ⅱ、Ⅲ类户可以通过基于主机卡模拟(HCE)、手机安全单元(SE)、支付标记化(Tokenization)等技术的移动支付工具进行小额取现,取现额度应当在遵守Ⅱ、Ⅲ类户出金总限额规定的前提下,由银行根据客户风险等级和交易情况自行设定。

分析:根据前端的支付场景考虑选用什么样的技术比较适合。

(三) Ⅲ类户任一时点账户余额不得超过2000元。

分析:账户业务规则;收款、充值场景中超过2000元该如何处理?
充值场景可以考虑自动计算充值金额避免超限也提高用户体验。收款场景下如何保证收款成功?收款时如果超限收款金额自动进入绑定的账户。查询展示时要如何显示才不会让持卡人查询到且感觉不奇怪。

(四) 银行通过电子渠道非面对面为个人新开立Ⅲ类户后,通过绑定账户转入资金验证的,可以接收非绑定账户小额转入资金;消费和缴费支付、非绑定账户资金转出等出金日累计限额合计为2000元,年累计限额合计为5万元。本通知印发之日前,银行非面对面为个人开立的Ⅲ类户,个人已通过绑定账户向该Ⅲ类户转入资金的,经本人同意后,银行可为该Ⅲ类户开通非绑定账户入金功能,账户限额按本通知管理。经银行面对面核实身份新开立的Ⅲ类户,消费和缴费支付、非绑定账户资金转出等出金日累计限额合计调整为2000元,年累计限额合计调整为5万元。
本通知印发之日前经银行面对面核实身份开立的Ⅲ类户,可按照原限额管理。同一家银行通过电子渠道非面对面方式为同一个人只能开立一个允许非绑定账户入金的Ⅲ类户。

分析:新开III类户如绑定I类户或面对面方式开户,日出款2000,年累计50000元。非面对面方式只能开一个可收款的III类户。

(五) 银行可以向Ⅲ类户发放本银行小额消费贷款资金并通过Ⅲ类户还款,Ⅲ类户不得透支。发放贷款和贷款资金归还,应当遵守Ⅲ类户余额限制规定,但贷款资金归还不受出金限额控制。

分析:涉及消费贷款申请、还款两个用例;结合APP的支付场景(APP内消费、APP外部线上、线下消费)打通消费与信贷业务。还款考虑III类账户不够时,是否从绑定账户扣款。

(六) 银行为个人非面对面开立的Ⅱ、Ⅲ类户向本人同名支付账户充值的,充值资金可提回Ⅱ、Ⅲ类户,但提现金额不得超过该Ⅱ、Ⅲ类户向支付账户的原充值金额。除充值资金提回外,支付账户不得向Ⅱ、Ⅲ类户入金,但允许非绑定账户入金的Ⅱ、Ⅲ类户除外。

分析:涉及充值、提现用例。III类账户分两种:消费型(只用于小额支付),收款型(可用于小额收款;必须面对面开立);

2.3 其他要求

(一) 银行应当充分认识个人银行账户分类管理制度对改进个人银行业务的意义,创新账户产品,优化业务流程,提升客户体验,切实引导个人通过账户分类管理制度保护账户资金和信息安全。

(二) 人民银行分支机构应当指导、督促辖区内银行加快系统改造,积极推动Ⅱ、Ⅲ类户业务发展,全面落实个人银行账户分类管理制度。

(三) 人民银行分支机构、银行应当加强个人银行账户分类管理制度宣传。通过线上、线下各种渠道和营销活动引导个人开立和使用Ⅱ、Ⅲ类户,加强Ⅱ、Ⅲ类户对于保护银行账户资金和信息安全宣传教育,培养使用Ⅱ、Ⅲ类户习惯,提高个人对Ⅱ、Ⅲ类户的认知度和接受度。

(四) 银行应当加强对Ⅱ、Ⅲ类户异常开立和可疑交易的监测,对于个人存在异常开户和可疑交易行为的,应当严格按照《中国人民银行关于加强支付结算管理防范电信网络新型违法犯罪有关事项的通知》(银发〔2016〕261号)、《中国人民银行关于加强开户管理及可疑交易报告后续控制措施的通知》(银发〔2017〕117号)等制度规定,采取拒绝开户或暂停账户非柜面业务等措施。

分析:涉及风控、反洗钱系统改造;

(五) 银行应当严格落实《中国人民银行金融消费者权益保护实施办法》(银发〔2016〕314号文印发)、《中国人民银行关于银行业金融机构做好个人金融信息保护工作的通知》(银发〔2011〕17号)、《中国人民银行关于进一步加强银行卡风险管理的通知》(银发〔2016〕170号)等制度要求,加强Ⅱ、Ⅲ类户和绑定账户信息安全管理,确保信息安全,防止信息泄露和滥用。

3、用例分析

所谓用例就是站在一个业务相关涉众的角度所需要完成的一个独立的任务。

20180122_001

我就站在持卡人的角色首先看到的是II类III类开户用例。这个用例因为涉及APP、PC、柜员机等场景,每个场景都可以是一个子用例。我们假设只考虑在直销银行的APP上远程开通II类或III类时账户。

以下是几个简化的用例分析:

使用场景: 开通III类账户

功能说明: 持卡人在APP上开通III类账户

执 行 者: 持卡人

前置条件:

  1. 持卡人已登录银行APP;
  2. 持卡人已开通的III类账户不足5个;
  3. 持卡人已开通了I、II类账户或信用卡账户;

后置条件:

  1. 持卡人新增一个III类账户;

主事件流:
1.如果持卡人已有I类账户则自动提示可以用于绑定的I类账户、信用卡账户、II类账户;
2.如果用户选择绑定I类账户或信用卡账户则不需要另外传个人信息,否则就需要上传个人信息;
3.发送短信验证是本人操作,如果验证通过则开通III类账户。
4.账户绑定。

分支事件流:

  1. 如果持卡人未开通I类账户,则要上传个人信息;
  2. 从绑定账户转入小额资金用于验证;
  3. 新用户需要将持卡人信息记入会员系统。

业务规则:

  1. 如果绑定I类账户则日限额2000元,年累计50000元;
  2. 如果绑定I类账户可以收款;
  3. 如果未绑定I类账户不可以收款;
  4. 个人通过采用数字证书或电子签名等安全可靠验证方式登录电子渠道开立Ⅱ、Ⅲ类户。
  5. 一个持卡人只能开通一个非绑定III类账户;一个持卡人的III类账户不超过5个;

涉及实体: 会员、账户


使用场景: 绑定I类账户

功能说明: 持卡人在APP上将III类账户与I类账户绑定

执 行 者: 持卡人

前置条件:

  1. 持卡人已登录银行APP;
  2. 持卡人有I类账户及III类账户且两者未绑定;

后置条件:

  1. 持卡人I类账户与III类账户绑定;

主事件流:
1.持卡人选择I类账户与某一个III类账户,操作绑定;
2.判断场景是否需要发短信验证本人操作;
3.如需要则发送验证码进行验证;
4.验证通过则解绑之前的II类账户然后绑定I类账户;

分支事件流:

  1. 如果持卡人没有非绑定账户入金的Ⅲ类户,则提示是否需要开通收款功能,开通此功能。
  2. I类账户、III类账户个人信息合并;

业务规则:

  1. 绑定后III类账户则日限额2000元,年累计50000元;

涉及实体: 会员、账户


使用场景: 小额消费贷款申请

功能说明: 持卡人在APP上指定消费场景支付时可以选择小额消费贷款。将消费贷款包装成支付方式。

执行者: 持卡人

前置条件:

  1. 持卡人已登录银行APP;
  2. 持卡人有III类账户;
  3. 符合小额消费贷申请条件;

后置条件:

  1. 向III类账户转入消费贷款金额;
  2. 从III类账户支付订单金额;

主事件流:
1.商户生成一笔订单,APP拉起收银台计算该场景、订单、持卡人是否可以使用消费贷款。
2.计算贷款剩余额度是否足以支付订单,且贷款金额+III类账户余额是否<=2000元;
3.如果可以显示“消费贷款”作为一种支付工具;
4.持卡人选择消费贷款支付;放贷资金进入III类账户,再用于支付订单。
5.累计该III类账户日限额,年累计限额,及剩余小额贷款额度;

分支事件流:

  1. 如果支付失败则贷款资金自动还款;
  2. 如果发生退款贷款资金自动还款;

业务规则:

  1. 消费贷款仅用于消费支付,不做现金贷;

涉及实体: 会员、账户、贷款、还款


使用场景: 小额收款

功能说明: 持卡人在APP上从(外部)非绑定的账户中收取小额资金;

执 行 者: 持卡人(收款的场景比较多,我这里假设是持卡人打开APP通过线下面对面收款的场景)

前置条件:

  1. 持卡人已登录银行APP打开收款功能;
  2. 持卡人有III类账户;
  3. 符合小额消费贷申请条件;

后置条件:

  1. III类账户增加一笔转入金额;
  2. 或III类账户绑定的账户收到一笔转入金额;

主事件流:
1.收款人打开APP中的收款码,付款人也打开APP扫码付款;
2.判断付款金额是否<200元(假设小额定义为200元),且收款人有III类账户,累计收款金额后余额不超过2000元,则入款进入III类账户;
3.否则收款金额直接计入绑定账户;

分支事件流: 大于200元的资金走转账流程;

业务规则:

  1. 任一时刻III类账户余额不超过2000元;
  2. 日累计、年累计不超过限额;

涉及实体: 会员、账户

4、流程分析

基于上面的用例进一步使用UML的时序图来分析用例的整个流程。
所谓流程就是完成一个用例所需的各种角色(包括人员、系统)相互配合的步骤。每一个步骤是一个任务,一个任务也可以拆分成子任务。越是后端的系统任务越细致。这里的难点是要了解后端系统是如何划分的?且每个系统的职责是什么?系统的定位与职责决定了系统间的调用关系。 举个例子:判断该会员是否可以开通III类账户应该放在会员系统还是账户系统。从两方面考虑:

  1. 会员系统与账户系统的定位。会员系统是否只是管理会员的基本信息?会员的权限、功能是放在会员系统还是各业务系统;
  2. 开通账户的这个功能需要哪些信息与前提条件?这些信息都在哪些子系统中,由谁来调用组合最合理。

开户流程方案一:

20180122_002

开户流程方案二:

20180122_003

两种方案没有对错,只是哪一种更适合。有些公司甚至没有会员系统或者会员与账户系统是一体的。所以这里的划分不是绝对的。

下面再介绍一下交易流程
这里的重点是通过收银台来承前启后,组织管理整个交易流程。
收银台的主要作用是获取会员、订单、商户、支付场景等信息。根据业务规则计算该笔交易可以使用哪些支付工具,如:余额支付、快捷支付、扫码支付或者是消费贷款等。此外有哪些营销工具可以使用,如:积分、优惠券等。有些复杂的场景支付工具、营销工具之间是要互斥的。然后消费者根据系统展示的可用支付工具选择一种或多种进行支付。
这里我假定消费者选择的消费分期,则由收银台(或会员系统)调用消费信贷系统发起消费信贷申请。审核通过则放贷入III类账户。返回收银台放贷结果。收银台再调用账户支付进行支付交易。

20180122_004

上图也只是一个简化的流程,将通用的支付流程涉及的功能系统做了简要的说明。实际要根据各公司系统划分调整流程。

5、系统功能点设计

    这个阶段就要查看上图中每条竖的虚线,有几个指向的箭头,每个箭头代表一个任务(调用)。需要分析该调用涉及的入参、出参。当只是从业务角度来考虑参数设计。另外涉及的业务逻辑也要作说明,但不需要考虑系统逻辑,那个由开发做详设时才需要。另外一些公司每个子系统都有产品或开发leader来负责,通常更细节的逻辑也是交由他们来设计的。

举例说明

业务场景:III类账户放贷入款;

参数中文名称 是否必须 说明
消费分期放款ID Y  
入款III类账户ID    
入款金额    
入款时间    

返回参数

参数中文名称 是否必须 说明
应答返回码 必须  
应答描述 必须  
消费分期放款ID    
入款III类账户ID    
入款金额    
入款时间    
入款状态    

业务逻辑:

  • 入款金额+III类账户余额是否<=2000元;
  • 累计该III类账户日限额,年累计限额是否超过限额;
  • ……

需要考虑的问题:日限额、年累计限额放在哪里统计。这属于账户规则应该放在账户系统,但有些公司也可能会放在风控系統中,或者设计一个独立的限额累计模块。

至此后端落地的流程基本介绍完毕。当然我没有讲前端的APP设计,那部分由专业的UED来设计的交互与视觉。产品要考虑的是不同的交互可能会影响到后端的系统调用过程。总体上来讲产品经理可能需要把控的是整体业务流程包括系统之外的环节。当然这与每家公司对产品的要求有关。

6、补充

因为我是做支持的所以以支付行业背景介绍比较熟悉,另外刚好这份监管的文下来业内的人都在看比较容易沟通,就央行的文来看重点是推广二三类帐户。所以首先是要开户,这是一个很大的场景。需求落地先从场景开始。这通常是用户比较熟悉的地方。


二、Q&A

Q1:我个人的感觉,其实二三类账户就是类第三方支付账户,而且以后是不是归属网联?
A1:我们要从场景出发首先分析场景中的涉众。就是有利益关系的人,这里说的银行体系里的电子帐户,你看一下标题就知道了,央妈相信的还是银行,所以希望银行能推这件事。 是的,我们想方涉法玩出花来,不需要央妈推。
A2:看似相似,其实还是有很大区别的。等我周三给大家详细分析一下区别。主要在于金融能力上,支付机构毕竟只是中介。

第二条 本办法所称非金融机构支付服务,是指非金融机构在收付款人之间作为中介机构提供下列部分或全部货币资金转移服务:
(一)网络支付;
(二)预付卡的发行与受理;
(三)银行卡收单;
(四)中国人民银行确定的其他支付服务。

A2:相互配合行业才能进步
A3:各有特色,但是银行优势更大吧
A4:银行是这样的吧,一方面账户分级管理,毕竟每个人在一个银行只有一张实体卡了,最大权限的
A2:但他们太慢了,你看央妈要下个文推着他们走
A4:所以只有靠二三类账户来代替,二三类本身限额会保护原有一类实体账户在支付机构的风险。
A3:不是那么简单,玩法太多了
A4:恩,就是银行二三类的兴起,市场又来了一波
A3:大家对2,3类账户理解太浅层次
A4:那意思是弱非银,强银行?
A3:非银毕竟风险太大了,系统性风险
A4:突然觉得非银搞得不好,最后成了聚合支付的角色…… A2:但我的感觉是第四方在一些方面都比支付公司有优势
A3:支付宝,微信不是那么容易被打压的

Q2:二三类可以挂他行卡吧?
A1:可以

A2:银行也要赚钱,很多银行还不是去接支付宝和微信。想想以前银行的业务办理。
A3:央妈给了每家银行一个第三方支付功能,还玩不转。聚合是没有核心功能的,可替代性太强
A4:未来的事情不要太早下定论,一切都是看谁更用心
A5:那应该上升到一个卖服务的时代了
A4:嗯,对的,应该要有这种觉悟了
A6:要么有商户要么有用户才能活下去
A3:支付宝对场景的运营的重视程度怎么样,银行又投了多少精力和资源?完全不可比
A4:不要神话支付宝,也不要完全看不起银行,是的,每一步都是自己努力出来的。
A2:支付宝的钱还不是投资人的,只是支付宝的运营模式,机动性强于银行。这样细分,刷卡交易又受欢迎了。
A6:不太可能吧
A4:条码,刷卡任意选
A6:移动支付已经习惯了
A4:我是觉得nfc挺好用的,安全~
A2:刷大额嘛,是呀,银联这个NFC产品,推晚了,刷卡是指银行卡交易。
A6:几年前我曾想去做菜市场,用非接方式
A7:不是指刷银行卡的操作,nfc加指纹,比扫码操作方便。
A6:非接其实比扫码方便
A2:也安全,非接改造15年就开始要求了,现在大部分新机非接都是标配了
A8:非接老早就是标配啦,扫码都是标配了

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。