背景：2020年9月25日，浦发银行作为开放银行先行者，顺应以用户为中心、以数字技术为手段、以智能化为引领的发展趋势，在建设实践中不断迭代总结，并将相关成果在本系列蓝皮书中予以了呈现。这些成果包括新一代开放银行“全景银行”及其建设方案，例如“面向全用户、贯穿全时域、提供全服务、实现全智联”的顶层规划方法、基于场景孪生的技术规范体系及基于CARE模型的安全防护框架等，目标是探索建立科学、完整、规范的开放银行建设方法体系，构建形成开放银行长期稳健发展的核心动力。【原文链接】。
对于浦发银行推出的全景银行概念，我抱有极大的兴趣，找到蓝皮书原文，仔细研读一段时间。结合自己在开放银行领域的实践与思考，说一下自己的几个看法。
一、API模式虽然常见但远未成熟
蓝皮书中的观点，API，SDK等技术，已经非常成熟，并且在开放银行得到了广泛应用，目前已经进入精细化管理阶段。在我看来，开放银行只是初步应用API，SDK等技术，这些技术在开放银行的应用与设计远未达到成熟状态，仍然有很大的上升与成长空间。具体表现如下：
1、各个银行API自成体系，行业处于无标准的混战阶段。
各银行开放银行，乃至业界的其他非银行机构的开放平台也好，大家在API的规范定义方面，走的路子不尽相同，有的是往swagger的OpenAPI Specification上靠拢，有的借鉴REST，但是URL相对固定，用BODY中的字段来唯一标记API。至于BODY中对于数据的表现层次，更是五花八门。这里并不是说各种形态谁对谁错，而是说对于开放银行这样一个课题来讲，API在开放银行中的具体定义，到目前为止还未完成标准化过程。谈不上成熟，只能说，API相关的技术要素基本齐备。
2、API配套的支撑能力，困境依然存在，并未解除。
API定义形成行业规范，只是API技术形态中的第一步。在API对接的过程中，各个银行估计都遇到过测试环境与上线过程的折磨，如何解决测试环境不稳定问题？直接使用生产环境？还是使用沙箱模拟器来搞？如果使用生产环境，其合规与隔离如何做？如果使用沙箱技术，其案例覆盖度，业务模拟以及保真度等如何保证。这些问题的成熟解决方案以及大规模应用，还有相当的距离。这样基本的问题得不到解除，API技术方式就谈不上成熟，也无法带来因为API形式与标准的改变，而引起的技术对接效率飞升。
API配套能力，除了沙箱模拟器技术，还包括基于API生成产品SDK的支持工具。swagger为大家提供了一个很好的借鉴，但是否是开放银行所需要的API与SDK能力的终点？我认为不是。开放银行所定义的API以及基于API形态之上的产品、解决方案等业务形态，相关的代码示例与指引等，需要丰富的文档来支撑，而不仅仅是swagger当前的简单文档描述能力。
以阿里云为代表的其他行业先进开放平台，在SDK的生成方面依然在不停的演进，详情见：【Darabonba：支持任意 OpenAPI 网关的多语言 SDK 方案】。对于开放银行来讲，也是一样的。
从另外一个方面来讲，开放银行需要及时的采纳新兴的技术以及工程进展，为开放银行的技术与业务目标服务。
二、定制化对接依然不可避免
定制化对接的问题，看起来与开放银行格格不入，不是说好了标准API吗？怎么又定制化。银行希望使用标准API对接合作方，但是一些走的比较靠前的合作方，也希望用标准API来对接银行呀，到底谁是标准API呢？
这个问题，是不是只有小银行做开放银行会遇到，规模大一些的银行就不会有这个问题了？其实不是的，即使在走的比较靠前的股份制银行，面对头部的合作方时，有时也不得不做出让步，在API方面，业务流程，包括呈现方面，都会有不少定制化内容。
那这部分定制化内容，是不是开放银行的讨论范围？当然是了。开放银行首先是一种新的业务拓展与合作模式，标准API只是其代表技术与典型特征，但并没有必要非API不走，非API不过，日子还是要过的。那定制化对接，内调外的网关，包括双向报文工厂，都应该纳入到开放银行的技术范围中来。
对于标准化API的执着，对于非标准化API的平台化技术支撑能力，都会是开放银行技术人员不可避免的话题。只不过在公开讨论开放银行的场合，大家有意无意的把这块给淡化了。
三、开放银行多形态输出服务于最终目标
当前经常提到的API，SDK，H5，小程序等，是在当前阶段开放银行建设与业务拓展中，大家常用到的技术手段，本质反应了围绕开放银行的业务目标，开放银行技术多形态问题。这种技术上的多形态，在未来可能会继续演进。而不是仅仅停留在目前这个阶段，只是进一步拓展技术的应用场景而已。
如果我们希望开放银行服务客户与业务更加直接，将不可避免的更关心客户侧系统的建设，而开放银行所输出的金融能力将越来越越被淡化，这种淡化不是指银行侧的淡化，而是银行在客户侧的淡化。银行希望输出金融能力，需要熟悉客户侧的事情，熟悉客户所在的行业，客户所面临的非金融问题，客户的系统等等。这些客户侧的能力建设，只输出金融能力是不够的，往往需要银行自身或者联合合作伙伴，为客户行业量身定制行业解决方案，实现客户侧的能力建设，并嵌入银行的金融服务。
在蓝皮书的全景银行论述中，也有类似的论述，不过我这里所说的观点，认为，开放银行要做好自己的金融业务，要让自己无所不在，则可能会向着泛平台的方向演进，银行介入的非金融业务越多，则自己的金融业务才越有希望在各种场景中渗透与增长。
我期望有一天，当我们一起讨论银行的开放银行时，已经见不到银行的实体开放银行或者开放平台，而是见到一个个客户可以直接使用的行业解决方案（不再需要API对接等技术过程），直接服务于目标客户，而开放银行的金融服务化作春雨润万物。
四、银行能力的二次包装与创新任务艰巨
前面主要是在说开放银行的技术特性与形态问题，API也好，H5也好，最终提供给合作方的是银行的产品。那银行的产品，只要有一个开放平台，就可以直接开放出来了么？大多数情况不是这样的。银行内部的原始金融能力，其实不光银行，各个组织都一样，将自己的内部的原始能力直接对外开放，并不能给合作方带来便利，还极有可能因为内部文化与理念的对外冲突或者历史问题，造成合作方使用困惑。更好的方式，是将原始能力进行审查，修正，甚至于二次包装与设计，专门为对外输出与开放场景，提供一套全新设计的易于使用的能力接口。
那如何能力能够将二次包装与创新任务，快速有效的完成，就成为开放银行步入深水区必须要解决的问题。使用服务组合或者编排是不是就可以将内部能力快速封装了？不一定的，如果只要对内部能力进行组合，就能够输出新能力，这样的好事如果天天有，搞开放银行的产品和业务估计要睡觉笑醒，更多的时候，需要将内部的能力进行削减或者改变，去掉以前内部所必须的一些渠道特性等能力，然后再根据开放银行产品设计的需要，定制新的能力。这样的改变与定制，是在能力的原始输出部门完成的，外部的力量包括开放银行部门均无法代劳，那你说一个服务编排工具怎么能代替原始输出部门的系统改造呢？显然是无法替代的。
当然不是说服务编排工具无用，服务编排工具不仅有用，而且非常必要，因为开放银行进行快速的服务创新，最好能够让产品创新与代码实现在表达阶段就一致一起来。让业务流程既代码，是服务编排工具需要给开放银行提供的基础能力支撑。然后再搭配原始输出部门的能力改造，双管齐下，才能让二次包装与创新任务真正的步入快车道。这里就先不说各个部门是否配合的问题了，暂且认为非技术问题都已经摆平了。
五、第一曲线市场拓展正酣
蓝皮书为各个银行着想，希望通过蓝皮书指引大家在开放银行的道路上，开辟第二曲线。我的观点是，第一曲线刚刚起步不久，各家银行的平台建设第一阶段完成，进入平台升级与完善期，业务拓展正在平台建设完成后逐步放量和上升，第一曲线还没进入冲刺阶段呢，怎么就开始开辟第二曲线了。过早的谈论第二曲线，无异于始乱终弃。
六、全时域覆盖模式与用户金融服务诉求的冲突
从银行的角度来看，当然希望银行服务无处不在，但是如果真的站在用户视角，怎么会希望有银行服务随时随地出现呢？用户的心思，最好不需要你的时候，你一次也别出现，需要你的时候，在任何地方任何场景召之即来。不要在我看房产新闻的时候，给我展示一个贷款广告，可能我更需要的房产中介服务以及本地的房产格局分析以及置业建议。
写在最后：以上虽然从六个方面，说了一下我对于全景银行白皮书的几个不同看法。但对于全景银行的分析方法与策略，我还是比较赞同的，以及银行在开放银行后续的发展过程中，其价值定位有哪些模式，这些论述是很好的总结与主张，给蓝皮书点赞。开放银行的发展过程中，需要不断有新的观点来持续透彻的分析开放银行的业务与策略，但不要堆砌概念，也不要堆砌标准，君不见2008、2009年前后的SOA浪潮依然可以历历在目？