最近参加一个展会，有非洲的银行在会上提出一个问题问嘉宾：

“银行mobile banking和钱包APP有什么区别？”

其实这个问题还可以再尖锐一点，“为什么银行的APP总是做不好？”

或者再延伸一点“为什么有些银行要做2个APP?”

记得我以前就跟非洲的银行聊过这个问题。

因为本质上传统上银行的商业逻辑和互联网APP的商业逻辑和运营逻辑完全不一样，其次是技术上支撑不一样。

传统银行的模式是在各个城镇开个网点，有需要的时候用户来我网点排队处理业务，但如果用户没需要，用户就不会去银行，无事不登三宝殿。

基于这个基础商业逻辑，银行的mobile Banking开发出来的APP也是同样逻辑，就是把线下业务搬到这个APP上，业务逻辑和流程依然遵从传统模式的流程，转账可能都需要按银行的原来的工作时间，在早期甚至都不敢保证7*24小时在线，所有的业务业务都是原始流程往互联网的延伸一点点。

正是这个由网点向线上延伸的逻辑下，APP的功能其实只需要几项基本功能，那反向思考下来，银行其实不一定非要APP，用户习惯用什么，就可以用什么来承载这几项功能，所以中国的银行提供微信的入口，让用户直接在微信小程序里使用银行服务，印度和非洲国家的银行有whatsapp银行接口，用户可以在Whatsapp里使用银行基本服务，当然还有USSD和短信银行业务，这都是传统业务逻辑下的自然延伸。

但是，互联网原生金融APP就完全不一样，作为互联网原生APP，深知互联网的玩法就是抓眼球，搞活跃，搞流量，不是等人上门，而是要吸引人来。

不是让客户有需求的时候来再来用这个APP，而是需要让客户闲着没事就来这里看看有没有好玩的，好用的业务，有没有新功能，有没有优惠，有没有小便宜可以占。

所以互联网原生APP的基本考核指标是MAU，DAU以及衍生出来的各种指标。从抓流量的角度去对比一个mobile banking的APP和一个原生支付APP，哪个银行能竞争得过？

这就引出第二个原因，技术投入多寡。

银行传统上以采购第三方的技术为主，而互联网公司技术多以自有团队为主。形成的结果就是同样一个需求，比如计划一个新营销活动需要开发点新玩法，传统银行需要调研，需要招标，评标，最后采购，一套流程下来得大半年，而且团队为了尽量减少自己的责任，前期需求描述得很大，导致供应商报价很高，然后自然要很多高层决策，整个流程人为加大复杂度。

而互联网公司则是拉个三五人团队直接先跑个MVP试试看，一个月就出版本了。这种时间差距就让互联网公司总是跑在前面。

所以中国的银行为了解决这个问题，最后都变成了按人力采购技术外包团队，相当于自己养了个随时可以裁撤的技术团队，只要有需求，就先干起来，减少各种流程带来的阻力。

当然了，这种外包团队多是做一些业务中前层的开发，底层或者后台还是会用一些大公司稳定的系统。

银行会招聘一些自有核心运营和产品设计员工，定营销策略，分析需求，搭配外包技术团队来开发需求和快速交付。自有员工是必需的而且是经验丰富的，要有运营经验，产品设计经验以及团队管理经验，来主导整个进度，指挥外包团队，千万不要成为甩手掌柜，只是扔个一句话描述的需求，这样外包团队不知道该实现什么，最后变成双方扯皮互相推卸责任。总的来讲技术团队这一块可以通过外包做一些弥补。

这就引出第三个问题，后台系统的稳定性和开放性。稳定性和开放性是一组矛盾，系统越开放就越不稳定，想稳定就不要开放太多接口。

传统银行核心为了稳定，尽量做成了封闭的系统，功能上尽量简单，但显然这不适合前面说的互联网时代的竞争。

所以就出现了两种做法：

1，新的开放银行核心+银行APP，这样的银行很多，用新的更具开放性的银行核心替换掉旧系统，在新核心上直接提供比以前更多的接口来适配互联网。

2，在旧核心之外另起一套轻核心/钱包+APP，像南非FNB，缅甸KBZ，摩洛哥Wafa都是这样的，因为以前的核心改造起来太难了（不仅仅是技术问题，可能要涉及大量组织的变动，这才是最难的），不如另起炉灶。

因此回答前面的问题其实很清楚了，要想竞争，从对APP的理解，到营销，到技术都需要做整体的改造和变化才行。