一种面向多渠道商的金融产品销售开放业务平台的制作方法

本发明涉及一个面向多渠道商的金融产品销售开放业务平台。

背景技术：

国内互联网金融门户发展分为两部分：一、传统金融机构采用信息化技术向互联网方向发展；二、互联网企业涉足金融产业。互联网金融门户通过与单家或多家金融机构对接，支持金融产品的定义和销售服务。不同平台销售的金融产品种类不一，有单一种类金融产品、种类金融产品和金融产品衍生品等。例如：某聚宝平台，致力于向用户提供简单的理财服务。该平台通过与多家金融机构对接，汇聚了基金、债券、股票等多种金融产品，支持其产品定义、交易整合、对账监控等服务，并提供财经资讯、市场行情等服务，直接向用户提供理财产品的交易、咨询服务。

不论是向互联网方向发展的传统金融机构的平台（如平安陆金所等），还是涉足金融产业的互联网企业（如蚂蚁聚宝等），目前均是提供单向接口来对接金融机构，并不提供开放平台至前端销售渠道。

技术实现要素：

本发明的目的在于提供一种面向多渠道商的金融产品销售开放业务平台，支持互联网金融产品销售渠道商对提供销售金融产品平台的需求，可满足对不同销售渠道商的接入，通过对接口作统一化管理，使得金融云平台的系统能够向多个金融产品销售端提供更优质、标准的服务。

为了达到上述目的，本发明的技术方案是提供一种面向多渠道商的金融产品销售开放业务平台，其中包含Open API接口网关，其开放与所提供的服务相应的API，使渠道商的前端得以接入；所述Open API接口网关从接入的渠道商的前端进行信息收集，接受前端发送的请求，并通过与金融云平台交互获取与服务相关的数据反馈给前端。

可选地，所述Open API接口网关通过产品引擎、交易引擎、规则引擎和流程引擎，对服务相关的产品、合同、账户、客户进行管理；

所述产品引擎支持对产品结构和规则的配置及产品组合定义；

所述规则引擎支持对业务规则的配置；

所述交易引擎支持多方分布式交易的执行和数据一致性管理；

所述流程引擎支持交易流程的配置和执行。

可选地，所述Open API接口网关的接口服务调用基于互联网，实现产品API、合同API、客户API、交易API和报表API；

所述Open API接口网关提供不同的API 调用日志存储引擎，并基于交易日志数据来提供面向不同性能指标的Dashboard分析，并支持用户自定义的预警条件配置和触发。

可选地，对Open API接口网关的所有接口调用采用HTTPS协议；

所述渠道商的前端在进行接口调用时，提供在应用开通时获得的唯一AppId和AppSecret作为请求的HTTP Header，以获得与当前会话相应的AccessToken来进行API访问。

可选地，所述前端是基于Web访问或基于Android/IOS的移动应用访问的客户端。

可选地，所述Open API接口网关统一管理所有API的安全性需求、服务水平需求以及适配不同通信协议/报文格式的需求。

可选地，所述Open API接口网关采用RESTful风格定义，请求和应答报文使用JSON格式，用户身份验证采用OAuth2方案，并遵循HTTP方法语义和错误状态码。

可选地，所述Open API接口网关与金融云平台的交易系统或业务系统之间，采用分布式调用或消息队列方式交互，且通过所述交易系统或业务系统提供的调用接口模型来定义。

与现有最好技术相比，本发明的优点在于：

1、针对市场上现有的单向接入前端销售的平台缺陷（如某聚宝为单向对接金融机构并不提供开放平台至前端），本发明的开放业务平台设计为前端开放平台，平台前端支持业务领先，拥有统一的标准化接口，可以灵活对接各种渠道商，减小渠道商基础设施投入，实现资源共享，减少运营成本。

2、金融产品模型支持种类领先。为解决目前已有互联网金融门户对金融产品种类的支持比较薄弱的问题，本发明的开放业务平台支持金融产品的完全可配置，基于一套完善的金融产品建模理论和系统配置模型，可满足渠道商多种金融产品以及复杂的金融衍生品的需求，包括：第三方支付产品、货币基金、股票基金、保险产品、个人信贷产品、债权产品、股权众筹产品、股票垫资类产品、基于以上产品的组合产品、以及基于以上产品的衍生产品。

附图说明

图1是本发明所述面向多渠道商的金融产品销售开放业务平台的示意图；

图2是适用本发明所述开放业务平台的一个示例的示意图。

具体实施方式

本发明提供一种面向多渠道商的金融产品销售开放业务平台，包含连接销售渠道商前端设备及金融云平台的一个标准化的Open API（开放平台）接口网关，将金融云平台系统所提供的服务封装为一系列API开放出去，支持不同渠道和设备的快速接入。

通过定义基于RESTful风格的Open API，支持基于Swagger的接口规范定义和导入导出，以灵活地接入各种渠道商的前端，包括但不限于IOS/Android、PC、TV、Watch等设备，对前端产品列表、用户信息、订单合同等信息进行收集，以及发送金融产品数据、金融机构做出的相应反馈给前端。所述Open API采用轻量级的RESTful风格定义，请求和应答报文使用JSON格式，用户身份验证采用OAuth2方案。RESTful接口定义对各种设备的接入比较友好，对开发工具和环境的兼容性高，可以实现快速方便地接入本发明的开放业务平台。

客户端通过标准接口的Open API访问平台，所述接口不仅为客户提供基于Web的访问方式，同时提供了基于Android/IOS的移动应用访问方式，Open API通过调用产品模版、金融服务合同等，以及通过访问数据库来提供服务。横向技术层面，Open API运用JDBC，Hibernate等技术访问MySQL、Cassandra等数据库，并依靠产品引擎、交易引擎、规则引擎和流程引擎等组件来实现自身功能，支持不同的产品结构和产品定义，处理复杂的规则配置和执行。

所述的产品引擎、规则引擎、交易引擎、流程引擎，基于特定设计的基础软件组件实现，用来对产品、合同、账户、客户进行管理，提供适合金融服务交易的基础技术架构支持。其中，产品引擎能够支持产品结构和规则的配置和灵活的产品组合定义；规则引擎支持对接口调用规则、交易规则等业务规则的配置，通过对决策表、费率表、规则流、规则适用条件等进行配置，可以灵活地定义产品、交易、市场营销等业务规则；交易引擎支持多方分布式交易的高性能执行和数据一致性管理，可以对交易进行实时监控、异常处理、回滚、重新执行等。流程引擎支持复杂交易流程的配置和执行，其中交易流程的配置支持XML格式，提供基本原子交易的属性配置和交易流程的条件控制、并发控制、异常控制等能力。

如图2所示的一个示例中，客户端App提交支付请求，Open API接受支付请求，发送给金融云平台的业务处理系统处理支付交易后，反馈信息给客户端以确认支付结果，对支付结果认可的则通过客户端提交出单请求，通过Open API接受出单请求，交由业务处理系统生成合同。

接口服务调用基于互联网，实现产品API、合同API、客户API、交易API和报表API等。接口网关Open API统一管理所有API的安全性需求，服务水平需求（SLA）以及适配各个业务合作伙伴系统的不同通信协议/报文格式的需求。所有接口调用采用HTTPS协议，确保数据在互联网传输的安全性。不同的渠道商前端接入应用，都会在应用开通的时候获得唯一的AppId（UUID）和AppSecret（20位字母和数字的随机字符串），所有的接口调用需要提供对应的AppId和AppSecret作为请求的HTTP Header（HTTP头部），并通过获得AccessToken（访问令牌）进行后续的API访问。AccessToken的生命周期管理服务，由独立的Redis集群提供，客户每次登录系统，开放平台接口服务会申请独立的会话AccessToken，并返回接口调用端，接口调用端需要保存此AccessToken，并在后续的接口调用中通过HTTP Header提供此AccessToken。支持接口的SLA定义以及接口不可用情况下的降级处理和自动报警和恢复。根据各个金融机构对不同产品的交易流程的配置，系统如果检测到某个金融机构的接口不可用，可以自动切换到交易的暂存和转发模式，保证前端用户的体验。接口回复后，系统自动重发所有暂存的交易。

Open API采用REST风格和JSON数据规范，并严格遵循HTTP方法语义和错误状态码。接口网关提供不同的API 调用日志存储引擎（MySQL，Cassandra，HBase）。基于完善的交易日志数据，平台可以提供面向不同性能指标的Dashboard分析功能，如交易吞吐量、交易延时、错误率等，并支持用户自定义的预警条件配置和触发。API同时解决了业务逻辑实现互相依赖的问题，不依赖任何其他业务系统Jar包实现，能够提供服务接口、DTO以及message定义。API中的DTO不带入所属module/project中，module/project提供API定义的接口实现。

开放平台和具体交易系统/业务系统之间的交互采用分布式调用（RPC）或消息队列方式，保证各个系统之间在调用时序，数据库事务，实现平台之间的松耦合，开放平台只需要依赖交易系统/业务系统提供的调用接口模型定义，而不用依赖其具体实现的Jar包。接入层遵循HTTPS标准保障数据的安全传输，应用了轻量级的Nginx服务器、NLB服务和CDN，提高服务响应速度。本发明的开放业务平台既可以用于支持多金融机构租户的公有云部署方案，也可以用于针对单个金融机构自身多销售渠道支持的私有云部署方案。

尽管本发明的内容已经通过上述优选实施例作了详细介绍，但应当认识到上述的描述不应被认为是对本发明的限制。在本领域技术人员阅读了上述内容后，对于本发明的多种修改和替代都将是显而易见的。因此，本发明的保护范围应由所附的权利要求来限定。