零售信贷风控管理系统分包二.docx
《零售信贷风控管理系统分包二.docx》由会员分享，可在线阅读，更多相关《零售信贷风控管理系统分包二.docx（22页珍藏版）》请在冰点文库上搜索。
零售信贷风控管理系统分包二
零售信贷风控管理系统（分包二）
需求说明书
文件状态：
[]草稿
[√]正式发布
[]正在修改
文件标识：
九江银行零售信贷风控管理系统需求说明书
当前版本：
作者：
完成日期：
机构公开信息
版本历史
版本/状态
作者
参与者
完成日期
备注
创建
1.概述
项目背景
零售信贷业务是发展趋势，在我行传统信贷模式之下，无法满足个人客户需求，为有效实现业务受理的快速化、业务办理的快速化，需搭建我行零售信贷风控管理系统，实现客户的准入机制、制定评分卡。
同时对第三方数据进行管理，设置好对接接口，防止过多的重复开发。
项目目标
根据我行的规划，零售信贷风控管理系统项目将分为两步走，第一步将我行现有个人贷款产品由线下向线上转移，实现线下线上相结合，简便贷款手续，优化贷款流程，集中化审批，建立评分卡模型。
预计在今年6月底完成开发上线，一期产品上线包括：
公积金贷、按揭贷两款产品，同时做好渠道端布局，实现各渠道入口的打通；第二步建立反欺模型，优化决策模型，减少操作风险和人力劳动强度。
加强布局线上贷产品，拓宽我行产品渠道及客户群体。
零售信贷风控管理系统建设的目标如下：
1.功能模块化
2.
搭建零售信贷风控管理系统的框架，后续通过增加功能模块，适应不同零售信贷产品的线上运行。
3.产品配置化
4.
开发信贷产品不需做过多的开发，通过配置申请要件、受理规则、授信规则、放款规则、核算规则和产品上架来发布新产品。
5.业务规则规范化
6.
细化各个业务环节的业务规则，形成业务规则库，不同的产品对应不同的业务规则实例。
7.流程规范化
8.
设计若干标准流程、简易流程和自动流程，通过业务规则引擎自动触发相应的业务流程。
9.申请要件规范化
10.
将业务申请要件按影像树的形式组织，不同的产品对应不同的影像树模块，必须要件缺少将无法提起业务。
11.关键风险点信息化
12.
在身份认证方面应用人脸识别技术；在合同方面应用电子合同和电子签名；在反欺诈和信用评分方面与FinTech公司合作。
13.业务处理智能化
14.
最终目标是实现线下线上的进件、审批、放款等业务处理环节中，根据规范流程、统一业务规则以及合理的评判标准达到系统智能化，加快进件效率，减小操作风险，提高我行效益。
项目范围
本次项目的范围为我行现有个人贷款产品的云平台实现，实现线上线下相结合，并简化贷款手续，使贷款更方便，用户体验更好；优化贷款流程，使贷款流程标准化、可配置化，减少系统建设工作量，并方便增加新的产品；最终达到产品的灵活配置与发布、风控流程与模型的灵活建立、审批人员绩效的统计分析等。
第一期上线产品为按揭贷款产品（包含一手商品房，一手商铺）进行线上化处理、公积金贷款产品半线上处理并实现业务贷款额度的循环、自动提额功能，之后新增线上化产品及其他个人产品时，则按照产品添加、流程配置的模式，进行组件化配置，减少对系统的修改，迅速实现产品发布。
2.业务功能需求
功能需求清单
功能清单列表：
功能需求
描述
后台管理功能需求
风控管理
模型管理
模型分为规则、评分卡两大类，规则可以创建：
贷前规则、贷中规则、贷后规则，评分卡可以创建申请评分卡、行为评分卡、催收评分卡。
新增规则、规则查看、规则发布、规则下架、规则删除；新增评分卡、修改评分卡、删除评分卡、评分卡发布、评分卡下架；各规则和评分卡修改、新增等均实现较为简易操作，让业务人员可以进行编写。
指标管理
主要是各类数据源的初始化指标管理，包括系统内部指标，包括芝麻信用、人行、同盾、白骑士、face++等。
新增指标需要通过初始化脚本执行。
查看、查询指标。
系统必须提供指标对接接口，实现指标对接的简易化。
风控等级管理
风控等级主要是提供一个基于评分卡的额度建议规则。
具体额度规则需要由风险决策引擎给出。
新增、查看、删除、下架、发布。
外部名单管理
定义各类名单和名单来源、入库原因等。
名单库类型包括：
黑、白、灰、红四种。
名单类型：
手机号、身份证号、支付宝ID、设备ID、IP、邮箱、QQ、微信、地址，可以扩展。
新增名单库、查看、撤销出库、出库审核、批量导入。
系统必须提供各类数据对接接口，实现数据对接的简易化。
和其它系统关系
行内系统
接入行内系统，包括：
现有信贷系统（高伟达）【CRMS】、企业服务总线系统【ESB】、统一用户认证【IAM】、操作数据存储系统【ODS】、企业客户信息工厂【ECIF】、影像系统、电子印章、文件传输平台【GTP】、人力资源系统【HRMS】、核心系统【CS】、短信平台等。
行外系统
外欺诈数据平台、三要素认证数据、公检法等第三方获取数据（第三方数据的接入必须进行标准化接口设置，以便后期数据获取）。
大数据源（风控模型和决策模型使用）
人行征信
1.与我行直接查询人行征信接口对接；2.进行人行征信数据解析，运用到评分与决策中。
第三方大数据源接口
预留第三方大数据源接入的规范接口。
以下将逐节介绍各个模块的业务需求。
风控管理
风控（授信）管理包含信用评分，政策规则和业务规则引擎，授信审批流程等功能。
此部分是零售信贷风控管理系统中最重要的功能，信贷云平台的自动化评级和高效率授信是系统的重要需求。
在进行风控管理时，可以提供前期人工判断与系统判断的对照功能，有效实现业务数据的匹配与比对。
信用评分
信用评分包含两部分：
1.对客户信息使用评分卡模型进行信用评分。
2.根据信用评分的准入规则进行准入判断，是对客户进行授信的基础。
1.信用评分
2.
信用评分的输入是客户的资产信息，人行的个人征信信息，本行的信用信息，如果没有本行的信用信息，必要时可引入第三方征信信息。
其中，以客户的资产信息，人行的征信信息和本行的信用信息为主，第三方征信信息为辅。
信用评分的模型是信用评分卡模型，信用评分卡模型分为申请评分卡（ApplicationScoreCard，即A卡），行为评分卡（BehaviorScoreCard，即B卡），催收评分卡（CollectionScoreCard，即C卡）。
申请评分卡用于申请场合，行为评分卡用于续贷场合，催收评分卡用于对于不良贷款的催收环节，而且和银行的催收政策结合紧密。
不同的评分卡输入参数不同，对于申请评分卡，不同信贷产品的风险考察的重点不同，输入指标也略有差异。
评分卡模型在不同的历史数据条件下，模型也不一样。
最初银行没有充足的历史数据或经验不足时，根据业务风险专家选定指标和指标的权重占比，进行评分。
当银行积累足够历史数据并建立大数据平台后，可进行大数据技术对指标进行提取，采用逻辑回归等技术建立评分卡模型，计算信用违约概率，并和历史数据进行比对，反复测试，得到适合的输入指标和模型来进行信用违约概率，并依据相应公式转换为信用评分（跟芝麻信用评分相似），并且隔一段时间再进行测试模型的适用性。
3.评分准入判断
4.
在进行信用评分之前，需要对征信报告进行连三累六、失信人的初步判断，若是则拒贷。
在得到信用评分之后根据信用准入规则，进行信用等级判断和准入判断。
对于符合高信用等级条件的可在授信时获得高额度授信或者利率折扣的优惠等。
政策规则引擎
对于各信贷产品的政策规则，采用规则配置，引擎自动计算的方式，出具符合不符合判定结果。
规则引擎在授信审批条件时计算，位于授信审批流程中需要审查check的相应节点。
它可以减少人为审核操作，大大提高授信审核的速度。
业务规则引擎
对于各信贷产品的政策规则，采用规则配置，引擎自动计算的方式，出具符合不符合判定结果。
规则引擎在授信审批条件时计算，位于授信审批流程中需要审查check的相应节点。
减少人为审核操作，大大提高授信审核的速度。
风险分析
申请分析：
系统支持业务统计功能（申请人数，通过人数，通过率，放款金额等）;具备规则合理性分析，模型稳定性分析以及提供数据面板；具备人群分析能力包含年龄。
性别，地域，时段，申请次数等；具备对渠道评估的能力；具备风险预警能力，准确包含人群特征变化，评价变化等分析。
贷中分析：
系统支持通过客户贷中行为分析，包括还款行为、还款金额，定期进行征信查询，外部大数据黑名单查询等，对客户给出提额控额冻额等意见。
贷后分析：
系统支持贷后管理；业务分析（包含总订单量，预期收益等统计），逾期分析（包含月度统计，分期统计，逾期转化率，催收效率，高危渠道等统计），规则调优（流程优化，坏账定义，数据集选择等），模型评估（包含流程选择，模型选择，数据集选择，坏账定义，KS／AUC的性能评估）以及产品优化（利率对利益的影响，期数对收益的影响，金额对收益的影响等）
BI分析：
系统支持模型预测，包含对新增贷款，贷款收益支出，KPI的预测
授信审批流程
授信审批流程包含标准审批流程，绿色通道流程和自动审批流程。
授信审批流程在产品设置时就已经设置完毕，此处根据流转信息，岗位等进行审批流转即可。
授信流程建议采用免费的审批流工具，对相应的流程、岗位、审核事项进行配置。
按揭贷款授信流程和处理要点
按揭贷款是本期优先上线的产品，以按揭贷款产品为例说明信贷审批流程和业务处理要点。
例如对于房屋按揭贷款的评分卡指标的建议：
住房贷款申请评分卡，收集资料：
客户基本信息、贷款基本信息、人行征信信息、客户关系信息等。
客户基本信息：
学历，工作行业，年龄等信息。
贷款基本信息：
首付款比例，房屋类型等信息。
人行征信信息：
借款人、配偶的人行征信信息。
客户关系信息：
是否银行VIP，客户定期账户，活期账户，银行卡等信息。
此部分评分模型、输入指标和输入评分范围，信用评分准入规则需要九江银行详细提供。
1.授信时规则引擎计算的内容
2.
a.征信查询日期不早于征信授权日期。
b.
c.首付款比例check：
例如纯商用比例不得低于X%，商住两用X年的，首付比例不低于X%，产权为X年的，首付比例不低于X%。
d.
e.每月总还款额check：
省内省内县域X元，三、四线城市X元，归属二线城市的省会城市及二线城市X元，一线城市（北上广）X元。
f.
g.全国前100强开发商check。
h.
i.贷款金额、利率信息及止期check：
客户年龄+贷款期限不超过法定退休年龄，否则需上报总行/分行授信部审批。
j.
3.授信审核内容：
4.
审核内容如下：
a.借款人及配偶主体资料（身份证，户口簿，结婚证，收入证明，征信查询授权书，个人征信报告等）齐全，且已进行了真实性和一致性核准。
b.
c.申请信息（购房合同，首付款凭证，担保信息）齐全，且已进行了真实性和一致性核准。
d.
e.个人信用评分，符合准入标准。
f.
g.授信的业务和政策合规性通过。
h.
i.授信额度，期限，还款计划等借款电子合同和担保电子合同信息。
j.
5.授信审批流程
6.
授信流程通常3级审批，提交者?
（支行）授信审批普通岗?
（分支行）授信审批岗?
（总行）授信审批岗。
若有（支行）独立审批派驻官时再由独立审批派驻官进行审批。
同时审批流程的设置可以进行灵活变动，支持多级审批中心形式及部分审批环节的删减与增加。
实际授信审批流程需要九江银行提供。
包括绿色通道流程和自动授信流程。
2.3和其他系统的关系
和行内其他系统的关系
和行内主要系统关系的如下表所示：
行内系统
连接方式
使用场合
核心系统
ESB服务
客户信息一致性传递
信贷系统（如需）
ESB服务
贷款信息传递
银行卡系统
ESB服务
开卡
支付系统
支付前置系统--暂定
他行卡放款、还款、扣款等
申请渠道（官网、手机银行、APP、微信银行、网银等）
电子渠道系统
业务申请，查看。
通知渠道（短信，邮件，微信、电话等）
电子渠道前置系统
业务申请，信息通知
数据仓库
文件批处理
零售信贷数据传送
产品定价系统（如有）
定价核算服务
产品的盈利核算定价服务
信用风险评级系统（如有）
信用评分服务
信用评分卡模型评分
大数据平台的客户画像系统
客户关系图谱服务
客户和开发商关系判断等
人脸识别系统
人脸识别/人像识别服务
真人识别，人像一致识别
人工客户/智能客服系统
在线客服
申请咨询和答疑
和行外系统的关系
和行外系统连接的主要需求如下表所示：
行外系统
连接方式
使用场合
公安系统
联网（服务接口）
客户身份证核实
人行个人征信系统
联网（服务接口）
个人征信查询
第三方的征信（如需）
联网（服务接口）
个人征信查询
第三方的（电信）反欺诈系统
反欺诈服务
反欺诈
第三方的失联修复系统
失联修复服务
失联修复
房管局系统
爬取（如实现困难，可不考虑）
查询房管局的房源状态，防止一房多卖。
3.技术需求
系统架构需求
系统整体架构科学实用，具有前瞻性。
能支持今后业务产品创新，可方便添加和配置新产品，并为零售信贷产品管理决策提供足够的信息支持，主要实现以下内容：
1、统一布局，模块化思路开发，系统可分布式布署，实现微服务开发。
定制开发九江银行零售信贷风控管理系统。
2、标准化和多渠道支持的通讯接口协议。
3、统一的技术平台，具有清晰的和独立的软件层次，逻辑分层清晰，支持从数据库到应用服务器的集群扩充部署。
4、基于SOA架构模式。
所有服务通过统一方式定义和发布到平台，支持行内的数据标准规范，服务之间通过平台上的消息总线以及统一的内部标准数据结构进行数据交互。
5、完善的产品配置、信用评分卡配置、决策模型配的测试、部分反欺诈规则的配置测试功能以及产品灰度发布能力，且具有先进的报表工具。
6、完善的日志管理功能，提供多种日志级别，满足开发、维护的不同需求；可按项目或交易等不同粒度配置日志级别、输出文件；可提供统一运维系统的日志监控。
7、解决投产时需要暂停服务、重启服务，单点跑批的问题（如支持热发布和支持多节点并行跑批，请提供具体解决方案）。
系统环境部署需求
投标公司须提供开发、测试、生产三套环境的部署方案，提供软件需求、硬件需求的具体参数。
用户界面总体需求
要求用户界面，大方美观，布局合理，符合本行对界面风格的要求。
性能需求
零售信贷风控管理系统涉及大量的信息访问模块，对并发性能的要求比较高。
因此系统的性能影响因素很多，系统建设要从网络负载、WEB应用服务器性能和数据库服务性能和不同WEB应用的处理方式等方面进行性能分析。
需提供F5或Nginx等硬件或软件的负载均衡策略。
需满足至少2000人的同时访问和申请，系统性能无明显下降等。
请各投标公司根据自身产品情况提供应用系统在性能方面的详细指标值：
1、简单页面响应及加载时间小于2秒，复杂数据统计及图表显示页面响应及加载时间小于5秒；
2、平均响应时间，关键交易的响应时间<=100豪秒，非关键交易的响应时间<=200毫秒；
3、峰值响应时间<=200豪秒；且在达到系统性能指标峰值要求的同时，系统处理能力还留有足够的余量，CPU、内存等系统资源的使用率应低于70%，达到平均值要求时，系统资源使用率应低于50%。
保证系统在设计指标压力情况下的长期稳定运行。
可靠性需求
系统须稳定可靠，支持7*24小时不宕机，服务无故障，并且能与其他系统很好的对接。
安全性需求
零售信贷风控管理系统是一个操作系统，且有部分功能面向互联网，所以系统安全必须有保障。
本系统需要考虑系统及数据可能面临的以下安全威胁：
（1）非人为因素：
服务器意外断电、损坏、硬盘出错或损坏、网络中断等；
（2）人为因素：
操作失误、恶意攻击、病毒破坏等；
（3）信息泄露、信息窃取、假冒、抵赖等；
（4）系统软件安全漏洞。
网络安全
（1）外联系统网络安全：
本系统与外联系统的数据传输网络安全，严格遵照执行商业银行外联网络建设相关规范的安全要求，同时复用商业银行已有的互联网连接及安全控制措施。
（2）服务器及客户端系统安全：
为避免单点故障，应用服务器采用负载均衡，数据库服务器采用HA配置。
（3）对于服务器操作系统，进行相应的安全配置维护管理，及时打补丁，安装反病毒程序，定期杀毒，根据实际情况及时进行安全策略调整，定期进行数据备份。
应用系统安全
（1）用户访问安全
身份认证机制：
使用统一认证系统作为统一入口，增强访问的安全性和管理控制的便捷性；
角色和权限控制：
系统用户划分为不同的用户组，同时将系统操作权限分割、细化，不同的用户或用户组可以授予不同的操作权限，实现系统的数据访问安全。
操作权限：
系统每个模块都有独自的操作权限，应支持系统用户的机构迁移和系统机构的关键要素变更。
数据权限：
用户登录统一采用WEB页面进行登录，在流程审批时，须严格遵守授权制度。
授权控制：
从功能、机构和数据三个维度来控制一个用户的权限。
（2）数据传输安全
用户客户端与WEB、应用服务器间采用HTTPS协议，对数据传输过程进行加密。
容错性需求
由于零售信贷风控管理系统对时效性要求较高，在系统设计时需考虑提供相应机制，能保障整个系统有较高的可用性。
如：
1.防重复提交机制
2.
对于一些较复杂的操作场景（如贷款申请），可能会出现由于操作失误所导致请求重复提交，应提供机制，避免对单一功能的重复提交；
3.交易存储-重发机制
4.
系统要对于关键性交易（如贷款申请交易），一律采取先存储交易场景，再发送申请的机制，当交易失败时，可以视失败原因（例如，通讯失败）择机重发，或等待日终对账处理。
5.操作预防机制
6.
通过对用户操作时严格控制（如，控制数据长度、精度、范围、以及业务处理规则等），配合友好的提示，尽量将系统的错误处理前移，实现整个系统的预防性容错。
稳定性需求
系统应使用开放的架构、无单点故障、无瓶颈，并可支持线形扩展，能支持双活部署或提供实时热备方案。
可扩展性需求
系统的前台和后台在设计上是独立的，前端程序和后台程序都具备高可扩展性，可根据银行业务需求个性化定制功能，提供完整的数据接口，可供其他系统调用。
后台程序：
能根据银行各个外围系统的具体报文格式要求进行数据传送；
前台程序：
功能模块均需具备可扩展性。
服务需求
建设与实施
项目启动阶段
在该阶段，需完成项目立项、项目规划、需求分析与需求确认、系统设计等工作，为系统实现做好准备。
该阶段的工作成果包括：
#
工作成果名称
1.
项目总体计划
2.
项目实施工作任务说明书
3.
系统开发计划（含资源计划）
4.
需求规格说明书
5.
系统实现阶段
在该阶段，主要是完成代码编写和系统测试工作。
该阶段的工作成果包括：
#
工作成果名称
1.
系统架构说明书
2.
概要设计说明书
3.
详细设计说明书
4.
数据库设计说明书
5.
关键代码走查方案及报告
6.
单元测试报告
7.
SIT测试案例
8.
SIT测试报告
9.
UAT测试报告
系统上线阶段
在该阶段，最关键的活动是系统发布、试运行和系统上线活动。
该阶段的工作成果包括：
#
工作成果名称
1.
系统操作手册
2.
系统维护手册
3.
系统上线验证方案及应急预案
4.
系统上线业务验证方案
5.
业务验证案例
6.
项目上线方案及时序计划
7.
数据备份方案
8.
产品手册
9.
安装手册
10.
备份及恢复手册
验收交付阶段
该阶段是完成项目验收、确认《验收报告》、项目结项。
该阶段的工作成果包括：
#
工作成果名称
1.
应急预案
2.
验收报告
3.
验收问题追踪
4.
系统程序源代码
维护与支持
（1）从合同系统上线三个月后（即试运行期结束）且系统验收通过之日起，乙方应按照工作说明书约定的内容，向甲方提供12个月的合同系统免费缺陷修复维护支持服务。
（2）在上述免费产品维护服务期内，乙方将安排不低于2人常驻甲方现场，指导和协助甲方的相关业务和技术人员，提供系统运维服务与支持。
同时，乙方应提供离场支持。
在上述免费维护期内，乙方提供的服务如下：
不低于2人的常驻现场支持服务；
提供系统缺陷的修复；
提供性能优化服务；
（3）每周提供7*24小时的远程服务支持，支持方式包括：
电话、短信、电子邮件等等；
系统试运行期与免费维护期服务时限标准如下：
级别
描述
响应时间
留守技术人员到达现场时间
后援专家
解决时限
一级
系统崩溃,不能使用或效能严重削弱,系统的某个主要功能不能正常工作，对业务的正常运行造成重大影响
15分钟
60分钟到达
1小时响应；
必要时8小时到达
4小时内排除问题或给出彻底解决方案
24小时内排除问题或给出彻底解决方案。
故障排除后三天内提交分析报告
二级
系统的运行性能严重下降，或性能明显下降，对业务运作产生明显影响
1小时内
1小时到达
1小时响应；
必要时8小时到达
4小时内给出临时解决方案。
24小时内排除问题或给出彻底解决方案。
24小时内排除问题或给出彻底解决方案。
三级
系统的运作性能受损，但大部分业务仍可正常运行
2小时内
2小时到达
必要时12小时到达
8小时内排除问题或给出临时解决方案。
1周内排除问题或给出彻底解决方案。
四级
对系统安装或配置方面需要咨询或支援，很显然对业务运作几乎无影响，或根本没有影响。
2小时内
4小时到达
必要时48小时到达
2周内排除问题
培训与交接
乙方需确保在系统开发和建设中所提供的培训是全面而系统的，包含了系统应用软件和开发工具等培训内容。
乙方对下列人员进行相应培训，并提供教材：
系统开发人员
系统运维人员
系统管理员
最终用户
培训内容包括但不限于：
信用评分卡（A卡，B卡）开发和可靠性测试培训
规则引擎开发和可靠性测试培训
系统架构、数据架构、产品配置、业务流程、日常运维培训
其他需求
数据库使用安全
数据库管理严格按照数据访问范围分配用户权限，并采用视图访问机制屏蔽用户资料和机密信息。
数据备份与恢复
数据库运行在归档日志模式，满足我行对系统备份的要求。
一般性数据恢复首先确定恢复数据时点，从备份数据中先恢复全量备份，再恢复之后的增量备份。
对于灾难性恢复，则通过恢复最近一次的数据备份及源系统数据进行数据追补。
日常备份最小时间间隔不大于1天，以保障灾难发生时数据丢失小于24小时的恢复时间目标。
升级会员 