CN111145030A - 一种可配置化的统一管理平台及方法 - Google Patents

Abstract

本发明公开了一种可配置化的统一管理平台及方法，包括：S1，基金成立，用户在***中维护基金基础信息、合同信息、资金账号信息；S2，基金销售，对接基金销售***，获取当日基金销售数据，根据销售数据计算相关投资者持有份额和基金业绩报酬；S3，数据归集，根据S1中提供的基本信息，对接不同券商通道的PB***，获取产品相关的资金数据、交易数据、持仓数据；S4，集中交易，根据S3中获取的基金资金头寸信息，在***中进行集中下单，下达的指令直接对接不同券商通道的PB***，实现集中交易。本发明提供了在一种多通道PB***运作模式下针对公司层面的统一监控、统一交易和统一管理平台，解决了金融行业各家公司普遍存在的信息孤岛问题。

Description

一种可配置化的统一管理平台及方法

技术领域

本发明涉及交易和管理技术领域，更为具体地，涉及一种可配置化的统一管理平台及方法。

背景技术

中国基金行业从90年代至今已经有近百家公司，发行上千只基金产品。在基金行业快速发展的同时，相关规范逐渐成熟，各家公司也逐步建设起各种配套***，完善公司内部基金管理和交易流程。由于基金管理涉及众多，基金成立、基金销售、基金运营、基金交易等各方面都需要相关的功能来为业务提供支持，就造成了公司内部***越来越多，不同的***之间由于连通性问题会形成信息孤岛，导致***数据冗杂，不利于管理。且新增的业务需求还将继续引进新的***，最终导致***众多，维护成本不断增高。

连通不同***之间的数据，对于技术部门来说开发成本过高。因此，金融行业的公司急需方案来解决此类信息孤岛的继续发展。

发明内容

本发明的目的在于克服现有技术的不足，提供一种可配置化的统一管理平台及方法，提供了在一种多通道PB***运作模式下针对公司层面的统一监控、统一交易和统一管理平台，解决金融行业各家公司普遍存在的信息孤岛问题。

本发明的目的是通过以下技术方案来实现的：

一种可配置化的统一管理平台，

S1，基金成立，用户在***中维护基金基础信息、合同信息、资金账号信息；

S2，基金销售，对接基金销售***，获取当日基金销售数据，根据销售数据计算相关投资者持有份额和基金业绩报酬；

S3，数据归集，根据S1中提供的基本信息，对接不同券商通道的PB***，获取产品相关的资金数据、交易数据、持仓数据；

S4，集中交易，根据S3中获取的基金资金头寸信息，在***中进行集中下单，下达的指令直接对接不同券商通道的PB***，实现集中交易；

S5，联合风控，根据S3中获取的基金头寸信息，在公司层面进行联合风控；和/或实时监控基金的风控违规情况；根据S4下达的指令，在公司和基金层面对下达的指令进行事先风险预算；

S6，预估值，根据S2和S3中提供的基金销售数据和交易数据，针对基金进行T+0准实时预估值；

S7，基金运营，根据S5和S6给出的基金风控结果和净值结果作为参考，依据基金合同信息进行相应处置操作；

S8，基金绩效分析，根据S3中获取到的基金头寸信息和S6***处理后生成的估值表信息；每周、每月对基金的绩效成果进行分析，生成针对基金层面的绩效分析报告；

S9，客户服务管理，针对S6生成的每日净值信息和S8生成的基金绩效分析报告信息，由***内置的邮件***，定时发送给相关投资者或者资方。

一种可配置化的统一管理平台运行方法，执行步骤S1～S9。

本发明的有益效果是：

(1)本发明提供了在一种多通道PB***运作模式下针对公司层面的统一监控、统一交易和统一管理平台，解决金融行业各家公司普遍存在的信息孤岛问题。具体的，功能点覆盖全面，基本覆盖了基金整个生命周期中的各个***，包括基金生命周期管理***、投资者适当性管理***、TA***、估值***、投资交易***、风控管理***、绩效归因***、客户管理***。

(2)本发明是一个配置化***，上述各个功能点均是配置完成的，可以根据实际公司内部的使用情况选择部分模块使用。相比于传统的各个分散的***，本发明一定程度上减少了信息孤岛的产生。

(3)本发明构建了一种可配置化的统一管理平台，在完善内部功能模块的同时，优化***接口功能，可直接对接其他***数据库获取相关数据。也可以通过简便开发的形式，连通其他***。

(4)本发明内置工作流引擎，适配不同公司的多样化的内部管理流程。内置权限配置引擎，方便根据实际业务场景快速完成权限相关限制。内置BI引擎，可将***中扁平化的数据转换成可视化的图表。

(5)本发明可以实现根据用户不同需求来增加或减少功能模块，同时对于新增业务也可以实现快速适配，能有效减少由于***过多引起的信息孤岛的产生以及维护成本的增高。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明的功能架构图；

图2为本发明中后台配置管理页面；

图3为本发明的工作流引擎；

图4为本发明的权限配置页面；

图5为本发明的集中交易展示图；

图6为本发明的联合风控展示图；

图7为本发明的预估值结果展示图；

图8为本发明的产品生命周期概览图；

图9为本发明的日历提醒展示图；

图10为本发明的绩效报告展示图。

具体实施方式

下面结合附图进一步详细描述本发明的技术方案，但本发明的保护范围不局限于以下所述。本说明书中公开的所有特征，或隐含公开的所有方法或过程中的步骤，除了互相排斥的特征和/或步骤以外，均可以以任何方式组合。

本说明书(包括任何附加权利要求、摘要和附图)中公开的任一特征，除非特别叙述，均可被其他等效或具有类似目的的替代特征加以替换。即，除非特别叙述，每个特征只是一系列等效或类似特征中的一个例子而已。

下面将详细描述本发明的具体实施例，应当注意，这里描述的实施例只用于举例说明，并不用于限制本发明。在以下描述中，为了提供对本发明的透彻理解，阐述了大量特定细节。然而，对于本领域普通技术人员显而易见的是：不必采用这些特定细节来实行本发明。在其他实例中，为了避免混淆本发明，未具体描述公知的电路，软件或方法。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在对实施例进行描述之前，需要对一些必要的术语进行解释。例如：

若本申请中出现使用“第一”、“第二”等术语来描述各种元件，但是这些元件不应当由这些术语所限制。这些术语仅用来区分一个元件和另一个元件。因此，下文所讨论的“第一”元件也可以被称为“第二”元件而不偏离本发明的教导。应当理解的是，若提及一元件“连接”或者“联接”到另一元件时，其可以直接地连接或直接地联接到另一元件或者也可以存在中间元件。相反地，当提及一元件“直接地连接”或“直接地联接”到另一元件时，则不存在中间元件。

在本申请中出现的各种术语仅仅用于描述具体的实施方式的目的而无意作为对本发明的限定，除非上下文另外清楚地指出，否则单数形式意图也包括复数形式。

当在本说明书中使用术语“包括”和/或“包括有”时，这些术语指明了所述特征、整体、步骤、操作、元件和/或部件的存在，但是也不排除一个以上其他特征、整体、步骤、操作、元件、部件和/或其群组的存在和/或附加。

如图1～10所示，一种可配置化的统一管理平台，包括：

S1，基金成立，用户在***中维护基金基础信息、合同信息、资金账号信息；

S2，基金销售，对接基金销售***，获取当日基金销售数据，根据销售数据计算相关投资者持有份额和基金业绩报酬；

S3，数据归集，根据S1中提供的基本信息，对接不同券商通道的PB***，获取产品相关的资金数据、交易数据、持仓数据；

S4，集中交易，根据S3中获取的基金资金头寸信息，在***中进行集中下单，下达的指令直接对接不同券商通道的PB***，实现集中交易；

S5，联合风控，根据S3中获取的基金头寸信息，在公司层面进行联合风控；和/或实时监控基金的风控违规情况；根据S4下达的指令，在公司和基金层面对下达的指令进行事先风险预算；

S6，预估值，根据S2和S3中提供的基金销售数据和交易数据，针对基金进行T+0准实时预估值；

S7，基金运营，根据S5和S6给出的基金风控结果和净值结果作为参考，依据基金合同信息进行相应处置操作；

S8，基金绩效分析，根据S3中获取到的基金头寸信息和S6***处理后生成的估值表信息；每周、每月对基金的绩效成果进行分析，生成针对基金层面的绩效分析报告；

S9，客户服务管理，针对S6生成的每日净值信息和S8生成的基金绩效分析报告信息，由***内置的邮件***，定时发送给相关投资者或者资方。

一种可配置化的统一管理平台运行方法，执行步骤S1～S9。

实施例一

如图1～10所示，一种可配置化的统一管理平台，

S1，基金成立，用户在***中维护基金基础信息、合同信息、资金账号信息；

S2，基金销售，对接基金销售***，获取当日基金销售数据，根据销售数据计算相关投资者持有份额和基金业绩报酬；

S3，数据归集，根据S1中提供的基本信息，对接不同券商通道的PB***，获取产品相关的资金数据、交易数据、持仓数据；

S4，集中交易，根据S3中获取的基金资金头寸信息，在***中进行集中下单，下达的指令直接对接不同券商通道的PB***，实现集中交易；

S5，联合风控，根据S3中获取的基金头寸信息，在公司层面进行联合风控；和/或实时监控基金的风控违规情况；根据S4下达的指令，在公司和基金层面对下达的指令进行事先风险预算；

S6，预估值，根据S2和S3中提供的基金销售数据和交易数据，针对基金进行T+0准实时预估值；

S7，基金运营，根据S5和S6给出的基金风控结果和净值结果作为参考，依据基金合同信息进行相应处置操作；

S8，基金绩效分析，根据S3中获取到的基金头寸信息和S6***处理后生成的估值表信息；每周、每月对基金的绩效成果进行分析，生成针对基金层面的绩效分析报告；

S9，客户服务管理，针对S6生成的每日净值信息和S8生成的基金绩效分析报告信息，由***内置的邮件***，定时发送给相关投资者或者资方。

如图1所示，一种可配置化的统一管理平台，可以设置有生命周期管理模块、基础信息管理模块、风控管理模块、估值管理模块、投前投后分析模块、投资交易模块。这些模块以数据归集的头寸数据和行情资讯数据为基础运行。

本实施例中，金融综合管理***以对接多通道PB***的数据归集为基础，结合三方资讯数据库和手工维护的基础业务数据，为投中投资交易管理模块、风控模块、估值模块提供数据。投资交易模块，包含指令流转模块、投资交易模块、资产单元模块，满足投资者不同方面的需求。

在本实施例中，支持对接三方基金数据库进行投前基金筛选，为fof基金筛选出合格的子基金，同时支持事后对子基金和母基金的绩效分析。本实施例具有灵活多样的管理功能配置、以及快速便捷的多账户、多标的(大容量篮子)交易功能、和安全可靠的多维度实时异常交易风控功能；同时，通过国际标准的FIX协议连接方式，可兼容迅投等多种PB及资管***，支持多种比例下单模式、批量委托等功能，对于中等及以上规模的金融投资机构有极高的便捷性、可靠性、经济适用性，可全方位满足大部分机构客户的交易执行需求。

为了保障数据的安全性和业务的连续性，设有灾备方案，该灾备方案基于统一存储(内存数据库redis+物理数据库mysql)复制技术，搭配稳定的keepalived服务+监控服务实现以下目标：

1.主备服务器redis数据库实时同步；

2.主备服务器mysql数据库实时同步；

3.交易服务在出现故障后能够自动切换到备机；

本实施例为提供灵活的扩展和定制功能，实现了如下特性：

1.功能灵活可配置，以及后台强大的模型算法能够实现不同模块，不同表之间的数据自动关联。通过数据自动关联，能够实现数据在不同模块不同表之间的穿透，只需要在一张表里操作，就能看到所有关联该表的数据。模型算法是根据计算机科学-图论里的拓扑排序理论衍生而来，完美适配该***，能够支撑***高效快速更新展示数据。

2.***能够满足各项业务(不同岗位、不同用户)的工作流程，具备多人协作能力；能够按照多种维度进行数据统计、查询、排序、筛选、导入导出，支持生成报告；以灵活的产品需求模板设置、审批流程设置等技术手段，适应多变的业务模式；具有较高扩展性与需求响应速度，以满足快速变化的市场需要与监管要求。

3.***开放高效、稳定、全面的外部接口服务，可通过https交互协议访问所有对外开放的接口，每个接口支持用户登录、权限验证。***有成熟、完整的外部脚本嵌套服务、支持后续拓展业务、特定是时间处理策略灵活、无差别嵌入***。

具体测试报告

下面将结合在国内主流券商的具体测试实例，对本实施例技术方案进行清楚、完整地验证。

测试内容及数据

1.测试机器配置参数

2.性能测试指标和结果

本次性能测试考察了如下2个指标：

(1)***能够支撑的在线用户数

(2)在存量数据很大的情况下，大量用户同时操作时，***的并发处理能力

针对上述2种指标，测试方法和结果分别如下：

(1)***能够支撑的在线用户数。

测试方法：保持多用户同时在线，然后测试所有在线用户同时访问***数据时，***内部对该请求的处理时间。对于每种测试样例，测试1000次，每次http请求的RTT(round-trip time)里网络时间平均在100ms-150ms区间，***内部处理时间的测试结果如下：

在线用户数	吞吐率(reqs/s)	单请求***内部处理时间(s)
			200	869	0.023
600	800	0.025
			1000	555	0.036
2000	364	0.055
			5000	224	0.089

从上面的测试结果可以看出，同时在线用户数量达到5000的情况下，这5000个用户同时去访问表里的数据，每个请求的在***内部的平均处理时间控制在90ms以内，如果算上http请求的网络时间，平均耗时会控制在200-300ms的范围。在实际使用过程中，我们可以通过垂直扩展，比如在加强***硬件配置的同时增加nginx worker以及各个服务模块的worker数量来成比例扩大***的负载能力，或者通过分布式部署来解决单机器的性能瓶颈。此外，我们***有完备的数据cache机制，如果数据请求命中cache的话，单个请求在***内部的数据处理时间在5ms以内。

(2)在存量数据很大的情况下，大量用户同时操作时，***的负载能力。

测试方法：对于这个指标，我们根据平安的实际业务场景，考察了单表的数据存量在500w 条、1000w条的情况下，500个用户和1000个用户同时去对表数据做增删改的处理能力。对于每种测试样例，测试1000次，每次http请求的RTT(round-trip time)里网络时间平均在100ms-150ms区间，***内部处理时间的

测试结果如下：

操作	吞吐率(reqs/s)	单请求***内部处理时间(s)
			增加数据	138	0.1161
删除数据	792	0.0202
			更改数据	145	0.1103

(a)存量数据500w，并发用户数500

操作	吞吐率(reqs/s)	单请求***内部处理时间(s)
			增加数据	138	0.1162
删除数据	780	0.0205
			更改数据	145	0.1105

(b)存量数据500w，并发用户数1000

操作	吞吐率(reqs/s)	单请求***内部处理时间(s)
			增加数据	138	0.1163
删除数据	776	0.0206
			更改数据	144	0.1108

(c)存量数据1000w，并发用户数500

操作	吞吐率(reqs/s)	单请求***内部处理时间(s)
			增加数据	137	0.1167
删除数据	784	0.0204
			更改数据	144	0.1111

(d)存量数据1000w，并发用户数1000

从上面的测试结果可以看出，在单表数据存量达到1000w条的情况下，1000个用户同时做增删改，平均来看，单个请求在***内部的处理时间控制在120ms以内，算上http请求的网络时间，平均耗时在200-300ms，基本不会影响***的处理速度，这是因为我们的数据引擎在对数据更新过程中，会去自动识别最优的计算路径，做到最小化的增量计算。而且我们测试环境是虚拟机环境，单机部署。如果垂直扩展加强***硬件配置或者部署多个数据引擎，是可以大幅提升***的并发处理能力的。此外，我们***也支持对单表数据分库存储或者水平扩容或者固化历史数据，因此数据存量基本不会影响***的处理效率。

测试结论

在虚拟机上部署的单机版本***可以承载同时在线用户数量达到5000，而且5000个在线用户同时访问***数据时，平均来看，单个请求的处理耗时控制在90ms以内。此外，***存量数据并不会影响***的处理效率，在单表数据存量达到1000w条的情况下，1000个在线用户并发对表数据做增删改，平均每个请求的***内部处理耗时都控制在120ms以内。

在本实施例中的其余技术特征，本领域技术人员均可以根据实际情况进行灵活选用和以满足不同的具体实际需求。然而，对于本领域普通技术人员显而易见的是：不必采用这些特定细节来实现本发明。在其他实例中，为了避免混淆本发明，未具体描述公知的算法，方法或***等，均在本发明的权利要求书请求保护的技术方案限定技术保护范围之内。

对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某一些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和单元并不一定是本申请所必须的。

本领域技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法实现所描述的功能，但是这种实现不应超出本发明的范围。

所揭露的***、模块和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例，仅仅是示意性的，例如，所述单元的划分，可以仅仅是一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以说通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述分立部件说明的单元可以是或者也可以不收物理上分开的，作为单元显示的部件可以是或者可以不收物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例的方案的目的。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以理解实现上述实施例的方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、 ROM、RAM等。

以上所述仅是本发明的优选实施方式，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。

Claims (2)

1.一种可配置化的统一管理平台，包括：

S1，基金成立，用户在***中维护基金基础信息、合同信息、资金账号信息；

S2，基金销售，对接基金销售***，获取当日基金销售数据，根据销售数据计算相关投资者持有份额和基金业绩报酬；

S3，数据归集，根据S1中提供的基本信息，对接不同券商通道的PB***，获取产品相关的资金数据、交易数据、持仓数据；

S4，集中交易，根据S3中获取的基金资金头寸信息，在***中进行集中下单，下达的指令直接对接不同券商通道的PB***，实现集中交易；

S5，联合风控，根据S3中获取的基金头寸信息，在公司层面进行联合风控；和/或实时监控基金的风控违规情况；根据S4下达的指令，在公司和基金层面对下达的指令进行事先风险预算；

S6，预估值，根据S2和S3中提供的基金销售数据和交易数据，针对基金进行T+0准实时预估值；

S7，基金运营，根据S5和S6给出的基金风控结果和净值结果作为参考，依据基金合同信息进行相应处置操作；

S8，基金绩效分析，根据S3中获取到的基金头寸信息和S6***处理后生成的估值表信息；每周、每月对基金的绩效成果进行分析，生成针对基金层面的绩效分析报告；

S9，客户服务管理，针对S6生成的每日净值信息和S8生成的基金绩效分析报告信息，由***内置的邮件***，定时发送给相关投资者或者资方。

2.一种可配置化的统一管理平台运行方法，其特征在于，执行步骤S1～S9。

Images