大大数据智能催收平台需求分析报告设计书Word文件下载.docx
《大大数据智能催收平台需求分析报告设计书Word文件下载.docx》由会员分享，可在线阅读，更多相关《大大数据智能催收平台需求分析报告设计书Word文件下载.docx（13页珍藏版）》请在冰点文库上搜索。
随着传统金融机构、网贷、民间借贷等不良贷款双升成为常态，传统催收平台已无法满足，互联网金融大数据智能催收平台应运而生。
与传统催收平台相比，没有地域限制，清收成本低、效率高，以及整合线上线下资源、拥有智能化信息匹配系统、大数据失联信息修复等，互联网金融催收平台具有较为明显的优势，但这一切并没有看起来那么美。
法律风险以及征信体系的不完善，是当前互联网催收平台普遍面临的困惑和挑战。
“互联网+不良资产处置”的模式没有经验可以借鉴，未来发展需要逐步摸索。
由于缺少相应的法律法规，催收合规性亟待解决。
第二章平台目标
二.1总体目标
大数据智能催收平台依托大数据技术以及多维数据源，将大数据增值产品集成到智能催收管理系统中，为资产方、处置方在贷后个人不良资产管理运营中遇到的各类痛点提供高效的解决方案。
同时将不断探索、尝试为提升金融行业整体运营管理水平而努力，最终打造一个法律风险以及征信体系的完善及法律法规合规“互联网+不良资产处置”的模式大数据智能催收平台。
二.2整体业务架构图
二.3总体规划
整个平台建设大致分为三期进行：
一期：
建立大数据催收管理系统
对于平台上的业务出现逾期，可以依托该系统进行催收管理，同时也可以对外承接一些不良资产催收业务。
系统主要实现系统管理、案件管理、催收管理、数据报表等功能，并呈现在PC和微信端。
二期：
不良资产风险深度智能定价
平台对接并依托大数据及人工智能等先进技术，建立债务人知识图谱及人物画像，精确勾勒债务人还款能力与意愿，对债务人的还款可能性进行综合评估，得出催收评分，从而进行不良资产风险定价。
三期：
打造一个“互联网+不良资产”智能处置Saas平台
整合不良资产方和处置方，在平台上不良资产方可以发布债务信息，处置方可以挑选债务去处置。
平台可以用最新式的“催收模型”对资产包进行拆分，再分派给合适的处置方，进行资源的深度优化配置。
第三章一期建设内容
三.1系统管理模块
系统管理模块功能结构图如下：
三.1.1账户权限
包括：
组分类管理、角色管理、用户管理、权限管理、操作日志。
三.1.2参数配置
费用设置、标准代码维护。
三.1.3策略配置
客户分类策略、案件状态策略、跟踪分案策略、外呼策略、委外策略、自动短信策略。
三.2案件管理模块
三.2.1案件管理
案件用户维护、案件信息录入、案件信息导入、案件信息查询、案件信息下载、案件信息审核、还款计划的导入。
三.2.2分案管理
主管分案
三.2.3抵押物管理
贷款抵押物查询，贷款抵押物信息管理
三.2.4还款管理
还款查询、还款趋势图
三.3催收管理模块
催收管理模块功能结构图如下：
三.3.1综合管理
案件手工设置处理渠道、综合查询、催记查询。
三.3.2外呼管理
外呼记录、外呼查询、外呼统计。
三.3.3短息管理
短息记录、短息案件查询。
三.3.4外访管理
外访申请、外访审核、外访记录、外访统计查询
三.3.5法务管理
法务申请、法务审核、法务记录、法务统计查询
三.3.6委外管理
委外申请、委外审核、委外记录、委外统计查询、委外机构管理。
三.3.7对账管理
手动逾期还款对账、批量逾期还款对账、不良资产处置核对
三.4数据报表模块
数据报表模块功能结构图如下：
三.4.1综合报表
催收方式综合分析报表、我参与完成的催收报表。
三.4.2催收业绩报表
催收业绩报表、个人催收业绩报表。
三.4.3内催报表
外呼报表、短信报表、外访报表、法务报表。
三.4.4委外报表
委外报表。
第四章技术环境
四.1架构与硬件
四.1.1技术架构
架构图：
系统采用WEB/JAVA开发模式，整体框架采用优秀的SpringBoot和SpringCloud等系列成熟框架。
团队使用Maven与Git等进行项目管理与协作开发。
我们的技术团队对于这种开发模式有着多年的开发经验，尤其是近年来专注于此领域的体系化和产品化的研发工作，从而形成了WEB方式信息开发全方位的工具产品线。
功能强大的产品方案加上成熟的系统实施使我们可以在短时间内迅速地完成系统的基本功能，并能根据用户的要求快速开发新的功能。
技术列表如下：
需求名称
详细要求
开发语言：
Java
系统架构：
Maven+SpringBoot/SpringCloud+mybatis
缓存
Redis
UI样式
待定
WEB服务器：
tomcat7.0以上
四.2系统扩展性
四.2.1系统建设扩展性
本项目采用SOA分布式开发模式的SpringBoot和SpringCloud微服务组件搭建，面向服务架构SOA以其独特的优势越来越受到企业的重视，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/WebService技术之后的自然延伸。
四.2.1.1SOA架构开发优点
●更易维护
业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。
建立在以SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的接口，只需要调整业务服务流程或者修改操作即可，整个应用系统也更容易被维护。
●更高的可用性
该特点是在于服务提供者和服务使用者的松散耦合关系上得以发挥与体现。
使用者无须了解提供者的具休实现细节。
●更好的伸缩性
依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。
使得服务提供者可以互相彼此独立地进行调整，以满足新的服务需求。
四.2.2数据库扩展
弹性扩展，实现100%资源利用率，可按需升级实例的内存、磁盘空间大小，提升业务处理能力；
单实例最大支持20000IOPS，2TB存储空间。
阿里云的RDSforMySQL支持挂载只读实例，扩展读取能力；
每个只读实例拥有独立的链接地址，可由应用端控制压力分配。
四.3安全方案
四.3.1使用安全
系统使用上的安全性是整个信息系统安全性中重要的一环，安全性再高的系统，如果在使用上没有严格管理，那么其安全性将失去意义。
因此，在系统的使用上，应该建立一套严密的用户登记制度，不同职责和权限的用户只能使用相应的系统程序和数据，并在系统中建立完善的日志记录，高等级的系统密码经常更换等等；
通过采取一系列的与系统相配合的管理措施，防止系统数据使用上的混乱和外泄。
一旦出现泄密现象，则系统可以快速地追查出有关人员。
保障系统运行安全性，防止黑客注入，以及钓鱼网站注入，通过第三方安全检测机构的安全检测。
保障银行支付过程中的数据传输安全性以及用户密码的安全性。
使用国际化标准传输协议对传输数据进行加密，使用先进的加密算法对系统内敏感数据进行加密。
总之，只有在系统的设计中充分分析了上面所述的各个方面的安全可预测了各种情况的发生以及应付办法，建成的系统才是真正安全可靠的。
四.3.2网络安全
网络设备及其线路等，是系统的另一个需要确保正常动作的部分。
因此，在网络设备上的选型只能是目前市面上的主流的名牌产品，在保证高可靠性的前提下，对关键设备，如中心路由器留有备份，以在出现故障时随时更换。
其相关部分，如电源设计，也必须有相应的备份。
网络产品本身应至少具有密码保护的功能，同时具有对网段进行逻辑划分子网段的功能，从网络层防止对主机系统的非法访问。
在线路上，除了主干线路外，预留拨号线路，保证各网点能在营业期间保持和中心的可靠连接。
四.3.3安全扫描策略
漏洞扫描能够模拟黑客的行为，对系统设置进行攻击测试，以帮助程序员在黑客攻击之前，找出系统中存在的漏洞。
漏洞扫描工具说明
采用Web
Vulnerability
Scanner
（WVS）
和IBMRationalAppScan使用详细说明-软件工具-红黑联盟作为安全扫描工具，它可以通过检查SQL注入攻击漏洞、跨站式脚本攻击漏洞或者其他漏洞等来检测Web应用程序是否存在安全隐患。
WVS通过抓取网站站点结构和模拟比较流行的攻击方式，像跨站式脚本攻击和SQL注入等攻击方式对整个网络站点进行安全扫描，能够在攻击者攻击之前扫描出在表单、安全区域和网络应用方面的问题。
他不仅可以支持创建和定制问题扫描检查，并且支持现在所有主要的网络技术。
四.3.4压力测试评估
通过模拟一定量的虚拟访问用户数，对网站进行压力测试，评估网站系统能提供的最大服务级别，进而确定系统可能存在的瓶颈。
LoadRunner是一种预测系统行为和性能的工业级标准性能测试负载测试工具。
通过以模拟大量用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个系统架构进行测试。
压力测试结果说明通过设计不同的测试场景，完成对系统的压力测试，如以下关键流程：
1、通过测试，检验用户进行注册的操作时，系统最多可以接受的用户并发操作。
找到在系统资源运行正常，事物平均响应时间。
2、通过测试，检验用户进行订单提交操作时，系统最多可以接受在多少的用户进行并发操作，并确认事物平均响应时间。
四.4系统性能
电商交易系统是业务运行的核心，系统的运行必须以能够及时地满足日常操作及数据查询的要求，因此系统的运行性能要求主要是指操作响应时间以及日终批处理时间。
四.4.1操作相应时间
业务操作处理要求提交后处理结果响应不得高于2秒。
系统查询的时间响应：
一般功能要求在5秒种之内完成。
四.4.2数据处理时间
系统日终批处理，主要是对日常记录的交易进行各种帐务处理以及在翻盘时对各种需要自动处理的业务进行执行。
基于系统的数据规模，我们认为，交易系统的数据批处理时间应该在1小时之内完成。
四.5备份管理
备份管理的设计基于以下四个原则：
●对给定时间点能进行完整的数据恢复
●使数据丢失的影响降到最小
●使数据备份的处理过程尽可能高效
●遵循企业现有的备份与恢复标准
四.5.1备份策略
按内容划分，备份包括对操作系统的备份、对应用程序和配置的备份、对数据的备份，我们既可以分别备份不同的内容，又可以同时备份所有的内容。
在各种备份的内容中，操作系统和应用程序及配置发生变化的频率很低，数据变化的频率很高，因此对不同的内容分开备份，可以减少备份的时间，方便恢复操作。
按工作进行的周期分，备份包括日常备份、硬件升级更换的备份、增加节点的备份和用户定制备份等。
在各种周期的备份中，日常备份最为重要，在各种备份的内容中，数据是核心内容，因此，备份策略的核心是日常数据备份。
日常数据备份的方式通常可分为增量备份、全备份和完全备份，具体描述如下：
Ø
增量备份
增量备份是指对所选定的对象，在前一次备份的基础上只对变化的部分进行备份，恢复时则需要一个全备份和此后的每次的增量备份才能对所选定的对象进行恢复，这是一种在OLTP系统中经常采用的备份方式。
全备份
全备份是指对所选定对象进行完整备份，恢复时，可以仅依靠这一个备份就能对所选定的对象进行恢复。
通常，全备份意味着不是对整个系统，而是对系统中特定的一部分对象进行备份。
完全备份
完全备份是指对一个系统中的所有对象进行完整备份，恢复时，可以仅依靠这一个备份就把整个系统或系统中的指定的对象进行恢复。
四.5.2备份方案
按照正常的交易系统的数据安全性要求，交易系统应该采用双机热备方案，即两台同样配置的机器一主一备同时运行，保证在主服务器出现故障时备机能够马上接管运行。
升级会员 