我国人口大概14亿，按照信贷渗透率为80%来算，零售金融市场的大盘子在11.2亿人左右。除去银行系和互联网系已经完成的授信客户，大概还有接近3亿人的增量盘子可供挖掘。这个就是我在《漫话零售金融（一）：行业逻辑与职业机会》中所说的A型市场，也是未来各类玩家争夺的重点。本篇梳理银行在零售市场拓展中的优劣势，以及银行面对未来的激烈竞争在系统、数据和业务架构上应该做哪些转型，才能突出重围，获得新生。

一、银行的困境

长期以来，我国银行业都是市场化程度比较低的行业之一。在过去40年中，银行主要依赖套利来进行盈利，也就是我们俗称的“躺着挣钱”。见过套利操作的亲肯定会惊讶于这个世界上还有如此迅速的挣钱方式，但恰恰是因为习惯了赚快钱，银行在产品设计上基本都是模仿，看看同业在做啥，比者做就能挣钱。所以银行在过去并没有培养自己的核心业务产品创新能力以及最最重要的基础客群。

1.1 业务模式转型的背景

从15年最初的5家民营银行成立，到2020年对万事达取得了清算牌照，金融市场逐渐在开放，套利空间越来越小。而银行通过购买国外昂贵解决方案所构建的数字资产服务优势，在各类互联网平台的冲击下受到了很大的影响。互联网通过场景服务掌握了海量的用户入口，在用户获取、数据积累方面的速度大大超过银行。同时，大型企业基于自身的议价能力，将控制沿产业链进行延伸，进而形成自有的金融服务生态，抓住金融领域开放的大环境将自己从银行的客户变成了银行的对手，比如阿里小贷，京东的“京小贷”，链家的“贝用金”等等。因为他们对产业生态运营的各个环节比银行更加了解，定价更精准，风控成本更低，所以在生态内提供金融服务比银行更有优势。以上种种，让银行在业务拓展、客户拓展方面陷入困境。

个人客户业务服务模式也在变动。过去银行专注于服务高端客户，服务渠道主要是依托线下网点或者是电话渠道的人工服务。而在互联网时代，银行长期不关注的长尾零售客户可以通过互联网获得了在线的智能服务，曾经依靠的高净值客户规模在逐渐凋零，而增量市场有没有及时抓住，这就导致银行客户出现断层的尴尬。

1.2 IT架构转型的背景

由于银行的IT架构所服务的模式是依赖于传统业务模型。因此在过去20年，我国银行业一直是在用“IOE”解决方案，也就是IBM的主机，Oracle的数据库和EMC的存储技术。这种解决方案是高度定制化的商业产品，昂贵但是稳定，能够帮助银行快速搭建核心账户系统和服务网络，进而为银行高端客户提供稳定的金融服务。而一旦业务模式发生变化，服务客群从高端变为普惠，则IOE架构的缺点就暴露了出来。虽然IBM单机能力强大，但是拓展性差；虽然关系型数据库稳定，但是面临海量的互联网非结构化、半结构化数据，也显得捉襟见肘。最重要的，新的客群产生了新的金融需求，满足新的金融需求会出现更多的新的金融产品，多种产品部署在一起导致运维困难，迭代速度变慢，这也是银行这些年IT架构遭遇的挑战。

1.3 数据体系转型的背景

最后说一下数据架构，因为银行系在之前没有精准营销的需求，因此大部分银行在数据资产管理方面都并不重视，在基层人员对数据的应用方面缺乏服务支持。具体来说，对于各类渠道各个环节的数据采集存在缺失情况；更新通常采用日终或者日间批量的形式，缺少实时数据采集和应用方法；数据的应用门槛比较高，使用SAS等商业软件的门槛无法被一线营销运营人员接受。这些点的产生，是因为银行过去的科技诉求是“控制风险为主”，同时基于E-R模型搭建的关系型数据库对数据的要求是“采集可以少，可以慢，但一定要准”。在互联网时代，数据就是资产，拥有独特的数据，就可以获得独有的价值，才会加强企业的核心竞争力，因此数据的采集不仅要多，要全，还要快，能被业务应用。这样才能发挥数据的作用。

二、银行的突围

现有困境的产生，是因为中国的互联网演进是从C到B的，互联网公司通过采用“X86底成本硬件+分布式开源软件”把C端的互联网需求率先培育起来，让用户习惯于更快更好的体验，进而倒逼B端改革业务服务的方式和逻辑。

俗话说“置之死地而后生”，不管是主动改革还是被动改革，银行都应该开始行动来应对现有的困境。一下从业务模式、IT架构和数据体系三个方面描述对未来银行转型的路径预判。

2.1 业务模式转型

新的业务模式要从点拓展为面，依托每家银行的自身情况打造自己的业务特色。未来的银行应该充分发挥产业整合作用，不再将赢利点聚焦于供应链上某个高价值的客户，而是通过组合来为整个供应链和产业服务。在这个过程中，建立区域性的信用体系，进而降低自己的风险评估成本，打造自己产品的核心竞争力。对于金融产品的提供，不能过分迷信所谓的精准营销，而应该是将金融产品的整个生命周期纳入到客户服务体系中。以信用卡为例，发卡不是目的，还需要将用卡、卡片使用、权益管理、风险控制、额度调整、违约提醒等服务进行个性化的改造，打造零售的核心竞争力。

2.2 IT架构转型

IT架构的演进为业务转型提供了技术支撑，新一代IT架构要满足支持高并发、性能稳定、易迭代、易维护、符合监管性能标准的要求。传统银行的架构使用IOE架构，难以扩展、维护和支持高效迭代以及信息安全是主要缺点。近些年，大部分银行开始按照业务条线进行平台化改革，从原有的“集中式紧耦合”架构转变为“集中式松耦合”架构，将不同的业务条线拆至不同的平台，使用不同的语言进行开发和维护，平台间使用标准的消息总线进行交互。举个例子，比如核心主机使用COBOL，平台类的使用Java，两者互不影响。这中架构的调整可以有效的分散风险，降低业务间的耦合程度，提升迭代的速度。但也有一些缺点，就是不同平台间的资源无法进行调度，即使“A产品没人用，B产品抢不着”，也没有办法把A的资源调度给B进行处理，在资源成本上存在进一步优化的空间。

2.3 数据体系转型

所谓“数据驱动”是使用数据技术来更好的驱动业务，利用数据快速完成客户洞察、产品迭代和成本控制，打造更好的业务核心竞争力。所以，数据体系转型也是围绕业务转型来做的的。具体来说，银行系的数据体系转型是建立完整的数据资产和应用中台，做好客户、产品维度逻辑数据建模，提升数据与模型的一致性和易用性，建立满足监管要求的数据质量考核体系是数据体系转型的重点。首先关系型数据库要支持水平扩容（例如采用MPP架构），以应对未来大量数据的产生，同时增加图数据库和非关系型数据库，以应对越来越多的不同类型的数据存储。第二，数据库的检索效率要进行提高，传统数据仓库的检索效率无法支持接口快速查询的需求，因此采用检索速度更快、水平扩展更容易的宽表库（例如HBase）将更有利于支撑上层应用。第三，增加对流数据的支持，现在的流计算框架基本都是流批混合，比如Flink、Spark等，依托流计算框架配合上游信息采集工具（比如依托Flume+Kafka来进行互联网渠道日志采集，利用linux内置的loader来进行历史明细数据采集等）来实现跨平台的数据采集路径，不再批量数据加载，提升数据应用效率。第四，要支持数据进行标签化加工归集。最后，数据要能够被业务使用。比如工行所做的“牡丹云”数据中台，通过封装数据应用工具，让营销人员可以通过参数配置线上运用场景，极大的提升数据应用范围。

三、结语

就像《I，robot》电影中博士影像的一句台词：You Must Ask the Right Question。千万不要用战术勤奋来掩盖战略上的懒惰，找到问题是关键，解决方案在现在和未来都不是问题。

本文由 @无锋018 原创，转载请注明出处。内容中如果有数字或者内容上的纰漏，欢迎留言或者加微信“wufeng018”指出，对内容有不同见解也欢迎一起讨论进步。