零售信贷风险管理系统业务需求说明书分包二

1、零售信贷风控管理系统（分包二） 需求说明书 文件标识：九江银行零售信贷风控管理系统需求说明书 当前版本：1.0 作 者： 文件状态： 草稿 正式发布 正在修改 完成日期： 机构公开信息 版 本 历 史 版本/状态作者参与者完成日期备注 1.0创建 目目目 录录录 1.概述概述4 1.1 项目背景4 1.2 项目目标4 1.3 项目范围5 2. 业务功能需求业务功能需求5 2.1 功能需求清单5 2.2 风控管理6 2.2.1 信用评分6 2.2.2 政策规则引擎7 2.2.3 业务规则引擎7 2.2.4 风险分析7 2.2.5 授信审批流程7 2. 3 和其他系统的关系9 2.3.1 和行内其

2、他系统的关系9 2.3.2 和行外系统的关系9 3. 技术需求技术需求10 3.1 系统架构需求10 3.2 系统环境部署需求10 3.3 用户界面总体需求10 3.4 性能需求10 3.5 可靠性需求11 3.6 安全性需求11 3.6.1 网络安全11 3.6.2 应用系统安全11 3.7 容错性需求12 3.8 稳定性需求12 3.9 可扩展性需求12 3.10 服务需求12 3.10.1 建设与实施12 3.10.2 维护与支持14 3.10.3 培训与交接15 3.11 其他需求16 3.11.1 数据库使用安全16 3.12.2 数据备份与恢复16 1.概述概述 1.1 项目背景项

3、目背景 零售信贷业务是发展趋势，在我行传统信贷模式之下，无法满足个人客户需求，为有效 实现业务受理的快速化、业务办理的快速化，需搭建我行零售信贷风控管理系统，实现客户 的准入机制、制定评分卡。同时对第三方数据进行管理，设置好对接接口，防止过多的重复 开发。 1.2 项目目标项目目标 根据我行的规划，零售信贷风控管理系统项目将分为两步走，第一步将我行现有个人贷 款产品由线下向线上转移，实现线下线上相结合，简便贷款手续，优化贷款流程，集中化审 批，建立评分卡模型。预计在今年 6 月底完成开发上线，一期产品上线包括：公积金贷、按 揭贷两款产品，同时做好渠道端布局，实现各渠道入口的打通；第二步建立反欺

4、模型，优化 决策模型，减少操作风险和人力劳动强度。加强布局线上贷产品，拓宽我行产品渠道及客户 群体。 零售信贷风控管理系统建设的目标如下： 1.功能模块化功能模块化 搭建零售信贷风控管理系统的框架，后续通过增加功能模块，适应不同零售信贷产品的 线上运行。 2.产品配置化产品配置化 开发信贷产品不需做过多的开发，通过配置申请要件、受理规则、授信规则、放款规 则、核算规则和产品上架来发布新产品。 3.业务规则规范化业务规则规范化 细化各个业务环节的业务规则，形成业务规则库，不同的产品对应不同的业务规则实 例。 4.流程规范化流程规范化 设计若干标准流程、简易流程和自动流程，通过业务规则引擎自动触发

5、相应的业务流 程。 5.申请要件规范化申请要件规范化 将业务申请要件按影像树的形式组织，不同的产品对应不同的影像树模块，必须要件缺 少将无法提起业务。 6.关键风险点信息化关键风险点信息化 在身份认证方面应用人脸识别技术；在合同方面应用电子合同和电子签名；在反欺诈和 信用评分方面与 FinTech 公司合作。 7.业务处理智能化业务处理智能化 最终目标是实现线下线上的进件、审批、放款等业务处理环节中，根据规范流程、统一 业务规则以及合理的评判标准达到系统智能化，加快进件效率，减小操作风险，提高我行效 益。 1.3 项目范围项目范围 本次项目的范围为我行现有个人贷款产品的云平台实现，实现线上线下

6、相结合，并简化 贷款手续，使贷款更方便，用户体验更好；优化贷款流程，使贷款流程标准化、可配置化， 减少系统建设工作量，并方便增加新的产品；最终达到产品的灵活配置与发布、风控流程与 模型的灵活建立、审批人员绩效的统计分析等。 第一期上线产品为按揭贷款产品（包含一手商品房，一手商铺）进行线上化处理、公积 金贷款产品半线上处理并实现业务贷款额度的循环、自动提额功能，之后新增线上化产品及 其他个人产品时，则按照产品添加、流程配置的模式，进行组件化配置，减少对系统的修改， 迅速实现产品发布。 2. 业务功能需求业务功能需求 2.1 功能需求清单功能需求清单 功能清单列表： 功能需求功能需求描述描述 后台

7、管理功能需求后台管理功能需求 模型管理 模型分为规则、评分卡两大类，规则可以创建：贷前规则、贷 中规则、贷后规则，评分卡可以创建申请评分卡、行为评分卡、 催收评分卡。新增规则、规则查看、规则发布、规则下架、规 则删除；新增评分卡、修改评分卡、删除评分卡、评分卡发布、 评分卡下架；各规则和评分卡修改、新增等均实现较为简易操 作，让业务人员可以进行编写。 指标管理 主要是各类数据源的初始化指标管理，包括系统内部指标，包 括芝麻信用、人行、同盾、白骑士、face+等。新增指标需要 通过初始化脚本执行。查看、查询指标。系统必须提供指标对 接接口，实现指标对接的简易化。 风控等级管理 风控等级主要是提供

8、一个基于评分卡的额度建议规则。具体额 度规则需要由风险决策引擎给出。新增、查看、删除、下架、 发布。 风控管理风控管理 外部名单管理 定义各类名单和名单来源、入库原因等。名单库类型包括：黑、 白、灰、红四种。名单类型：手机号、身份证号、支付宝 ID、 设备 ID、IP、邮箱、QQ、微信、地址，可以扩展。新增名单库、 查看、撤销出库、出库审核、批量导入。系统必须提供各类数 据对接接口，实现数据对接的简易化。 和其它系统关系和其它系统关系 行内系统 接入行内系统，包括：现有信贷系统（高伟达）【CRMS】、企 业服务总线系统【ESB】、统一用户认证【IAM】、操作数据存 储系统【ODS】、企业客户信

9、息工厂【ECIF】、影像系统、电 子印章、文件传输平台【GTP】、人力资源系统【HRMS】、核 心系统【CS】、短信平台等。 行外系统 外欺诈数据平台、三要素认证数据、公检法等第三方获取数据 （第三方数据的接入必须进行标准化接口设置，以便后期数据 获取）。 大数据源（风控模型和决策模型使用）大数据源（风控模型和决策模型使用） 人行征信人行征信 1.与我行直接查询人行征信接口对接；2.进行人行征信数据解 析，运用到评分与决策中。 第三方大数据源接第三方大数据源接 口口 预留第三方大数据源接入的规范接口。 以下将逐节介绍各个模块的业务需求。 2.2 风控管理风控管理 风控（授信）管理包含信用评分，

10、政策规则和业务规则引擎，授信审批流程等功能。此 部分是零售信贷风控管理系统中最重要的功能，信贷云平台的自动化评级和高效率授信是系 统的重要需求。在进行风控管理时，可以提供前期人工判断与系统判断的对照功能，有效实 现业务数据的匹配与比对。 2.2.1 信用评分信用评分 信用评分包含两部分：1.对客户信息使用评分卡模型进行信用评分。2.根据信用评分的 准入规则进行准入判断，是对客户进行授信的基础。 1.信用评分 信用评分的输入是客户的资产信息，人行的个人征信信息，本行的信用信息，如果没有 本行的信用信息，必要时可引入第三方征信信息。其中，以客户的资产信息，人行的征信信 息和本行的信用信息为主，第三

11、方征信信息为辅。 信用评分的模型是信用评分卡模型，信用评分卡模型分为申请评分卡（Application Score Card，即 A 卡），行为评分卡（Behavior Score Card，即 B 卡），催收评分卡（Collection Score Card，即 C 卡）。 申请评分卡用于申请场合，行为评分卡用于续贷场合，催收评分卡用于对于不良贷款的 催收环节，而且和银行的催收政策结合紧密。不同的评分卡输入参数不同，对于申请评分卡， 不同信贷产品的风险考察的重点不同，输入指标也略有差异。 评分卡模型在不同的历史数据条件下，模型也不一样。 最初银行没有充足的历史数据或经验不足时，根据业务风险专

12、家选定指标和指标的权重 占比，进行评分。 当银行积累足够历史数据并建立大数据平台后，可进行大数据技术对指标进行提取，采 用逻辑回归等技术建立评分卡模型，计算信用违约概率，并和历史数据进行比对，反复测试， 得到适合的输入指标和模型来进行信用违约概率，并依据相应公式转换为信用评分（跟芝麻 信用评分相似），并且隔一段时间再进行测试模型的适用性。 2.评分准入判断 在进行信用评分之前，需要对征信报告进行连三累六、失信人的初步判断，若是则拒贷。 在得到信用评分之后根据信用准入规则，进行信用等级判断和准入判断。对于符合高信 用等级条件的可在授信时获得高额度授信或者利率折扣的优惠等。 2.2.2 政策规则引

13、擎政策规则引擎 对于各信贷产品的政策规则，采用规则配置，引擎自动计算的方式，出具符合不符合判 定结果。规则引擎在授信审批条件时计算，位于授信审批流程中需要审查 check 的相应节点。 它可以减少人为审核操作，大大提高授信审核的速度。 2.2.3 业务规则引擎业务规则引擎 对于各信贷产品的政策规则，采用规则配置，引擎自动计算的方式，出具符合不符合判 定结果。规则引擎在授信审批条件时计算，位于授信审批流程中需要审查 check 的相应节点。 减少人为审核操作，大大提高授信审核的速度。 2.2.4 风险分析风险分析 申请分析：系统支持业务统计功能（申请人数，通过人数，通过率，放款金额等); 具备

14、规则合理性分析，模型稳定性分析以及提供数据面板；具备人群分析能力包含年龄。性别， 地域，时段，申请次数等；具备对渠道评估的能力；具备风险预警能力，准确包含人群特征 变化，评价变化等分析。 贷中分析：系统支持通过客户贷中行为分析，包括还款行为、还款金额，定期进行征信 查询，外部大数据黑名单查询等，对客户给出提额控额冻额等意见。 贷后分析：系统支持贷后管理；业务分析（包含总订单量，预期收益等统计），逾期分 析(包含月度统计，分期统计，逾期转化率，催收效率，高危渠道等统计)，规则调优(流程优 化，坏账定义，数据集选择等)，模型评估（包含流程选择，模型选择，数据集选择，坏账定 义，KSAUC 的性能评

15、估）以及产品优化(利率对利益的影响，期数对收益的影响，金额对 收益的影响等) BI 分析：系统支持模型预测，包含对新增贷款，贷款收益支出，KPI 的预测 2.2.5 授信审批流程授信审批流程 授信审批流程包含标准审批流程，绿色通道流程和自动审批流程。 授信审批流程在产品设置时就已经设置完毕，此处根据流转信息，岗位等进行审批流转 即可。 授信流程建议采用免费的审批流工具，对相应的流程、岗位、审核事项进行配置。 按揭贷款授信流程和处理要点 按揭贷款是本期优先上线的产品，以按揭贷款产品为例说明信贷审批流程和业务处理要 点。 例如对于房屋按揭贷款的评分卡指标的建议： 住房贷款申请评分卡，收集资料：客户

16、基本信息、贷款基本信息、人行征信信息、客户 关系信息等。 客户基本信息：学历，工作行业，年龄等信息。 贷款基本信息：首付款比例，房屋类型等信息。 人行征信信息：借款人、配偶的人行征信信息。 客户关系信息：是否银行 VIP，客户定期账户，活期账户，银行卡等信息。 此部分评分模型、输入指标和输入评分范围，信用评分准入规则需要九江银行详细提供。此部分评分模型、输入指标和输入评分范围，信用评分准入规则需要九江银行详细提供。 1.授信时规则引擎计算的内容授信时规则引擎计算的内容 a.征信查询日期不早于征信授权日期。 b.首付款比例 check：例如纯商用比例不得低于 X%，商住两用 X 年的，首付比例不

17、低 于 X%，产权为 X 年的，首付比例不低于 X%。 c.每月总还款额 check：省内省内县域 X 元，三、四线城市 X 元，归属二线城市的省 会城市及二线城市 X 元，一线城市（北上广）X 元。 d.全国前 100 强开发商 check。 e.贷款金额、利率信息及止期 check：客户年龄+贷款期限不超过法定退休年龄，否则 需上报总行/分行授信部审批。 2.授信审核内容：授信审核内容： 审核内容如下： a. 借款人及配偶主体资料（身份证，户口簿，结婚证，收入证明，征信查询授权书， 个人征信报告等）齐全，且已进行了真实性和一致性核准。 b.申请信息（购房合同，首付款凭证，担保信息）齐全，且

18、已进行了真实性和一致性 核准。 c. 个人信用评分，符合准入标准。 d.授信的业务和政策合规性通过。 e. 授信额度，期限，还款计划等借款电子合同和担保电子合同信息。 3.授信审批流程授信审批流程 授信流程通常 3 级审批，提交者(支行)授信审批普通岗(分支行) 授信审批岗(总行) 授信审批岗。若有(支行)独立审批派驻官时再由独立审批派驻官进行审批。同时审批流程的 设置可以进行灵活变动，支持多级审批中心形式及部分审批环节的删减与增加。 实际授信审批流程需要九江银行提供。包括绿色通道流程和自动授信流程。实际授信审批流程需要九江银行提供。包括绿色通道流程和自动授信流程。 2. 3 和其他系统的关系

19、和其他系统的关系 2.3.1 和行内其他系统的关系和行内其他系统的关系 和行内主要系统关系的如下表所示： 行内系统行内系统连接方式连接方式使用场合使用场合 核心系统ESB 服务客户信息一致性传递 信贷系统（如需）ESB 服务贷款信息传递 银行卡系统ESB 服务开卡 支付系统支付前置系统-暂定他行卡放款、还款、扣款等 申请渠道（官网、手机银行、 APP、微信银行、网银等） 电子渠道系统业务申请，查看。 通知渠道（短信，邮件，微信、 电话等） 电子渠道前置系统业务申请，信息通知 数据仓库文件批处理零售信贷数据传送 产品定价系统（如有）定价核算服务产品的盈利核算定价服务 信用风险评级系统（如有）信用

20、评分服务信用评分卡模型评分 大数据平台的客户画像系统客户关系图谱服务客户和开发商关系判断等 人脸识别系统人脸识别/人像识别服务真人识别，人像一致识别 人工客户/智能客服系统在线客服申请咨询和答疑 2.3.2 和行外系统的关系和行外系统的关系 和行外系统连接的主要需求如下表所示： 行外系统行外系统连接方式连接方式使用场合使用场合 公安系统联网（服务接口）客户身份证核实 人行个人征信系统联网（服务接口）个人征信查询 第三方的征信（如需）联网（服务接口）个人征信查询 第三方的(电信)反欺诈系统反欺诈服务反欺诈 第三方的失联修复系统失联修复服务失联修复 房管局系统爬取（如实现困难，可不考虑）查询房管局

21、的房源状态，防止一 房多卖。 3. 技术需求技术需求 3.1 系统架构需求系统架构需求 系统整体架构科学实用，具有前瞻性。能支持今后业务产品创新，可方便添加和配置新 产品，并为零售信贷产品管理决策提供足够的信息支持，主要实现以下内容： 1、 统一布局，模块化思路开发，系统可分布式布署，实现微服务开发。定制开发九江 银行零售信贷风控管理系统。 2、 标准化和多渠道支持的通讯接口协议。 3、 统一的技术平台，具有清晰的和独立的软件层次，逻辑分层清晰，支持从数据库到 应用服务器的集群扩充部署。 4、 基于 SOA 架构模式。所有服务通过统一方式定义和发布到平台，支持行内的数据 标准规范，服务之间通过

22、平台上的消息总线以及统一的内部标准数据结构进行数据交互。 5、 完善的产品配置、信用评分卡配置、决策模型配的测试、部分反欺诈规则的配置测 试功能以及产品灰度发布能力，且具有先进的报表工具。 6、 完善的日志管理功能，提供多种日志级别，满足开发、维护的不同需求；可按项目 或交易等不同粒度配置日志级别、输出文件；可提供统一运维系统的日志监控。 7、 解决投产时需要暂停服务、重启服务，单点跑批的问题（如支持热发布和支持多节 点并行跑批，请提供具体解决方案）。 3.2 系统环境部署需求系统环境部署需求 投标公司须提供开发、测试、生产三套环境的部署方案，提供软件需求、硬件需求的具 体参数。 3.3 用户

23、界面总体需求用户界面总体需求 要求用户界面，大方美观，布局合理，符合本行对界面风格的要求。 3.4 性能需求性能需求 零售信贷风控管理系统涉及大量的信息访问模块，对并发性能的要求比较高。因此系统 的性能影响因素很多，系统建设要从网络负载、WEB 应用服务器性能和数据库服务性能和不 同 WEB 应用的处理方式等方面进行性能分析。 需提供 F5 或 Nginx 等硬件或软件的负载均衡策略。需满足至少 2000 人的同时访问和申 请，系统性能无明显下降等。 请各投标公司根据自身产品情况提供应用系统在性能方面的详细指标值： 1、简单页面响应及加载时间小于 2 秒，复杂数据统计及图表显示页面响应及加载时

24、间 小于 5 秒； 2、平均响应时间，关键交易的响应时间=100 豪秒，非关键交易的响应时间=200 毫秒； 3、峰值响应时间=200 豪秒；且在达到系统性能指标峰值要求的同时，系统处理能力还 留有足够的余量，CPU、内存等系统资源的使用率应低于 70%，达到平均值要求时，系统资源 使用率应低于 50%。保证系统在设计指标压力情况下的长期稳定运行。 3.5 可靠性需求可靠性需求 系统须稳定可靠，支持 7*24 小时不宕机，服务无故障，并且能与其他系统很好的对接。 3.6 安全性需求安全性需求 零售信贷风控管理系统是一个操作系统，且有部分功能面向互联网，所以系统安全必须 有保障。本系统需要考虑系

25、统及数据可能面临的以下安全威胁： （1）非人为因素：服务器意外断电、损坏、硬盘出错或损坏、网络中断等； （2）人为因素：操作失误、恶意攻击、病毒破坏等； （3）信息泄露、信息窃取、假冒、抵赖等； （4）系统软件安全漏洞。 3.6.1 网络安全网络安全 （1）外联系统网络安全：本系统与外联系统的数据传输网络安全，严格遵照执行商业 银行外联网络建设相关规范的安全要求，同时复用商业银行已有的互联网连接及安全控制措 施。 （2）服务器及客户端系统安全：为避免单点故障，应用服务器采用负载均衡，数据库 服务器采用 HA 配置。 （3）对于服务器操作系统，进行相应的安全配置维护管理，及时打补丁，安装反病毒

26、程序，定期杀毒，根据实际情况及时进行安全策略调整，定期进行数据备份。 3.6.2 应用系统安全应用系统安全 （1）用户访问安全 身份认证机制：使用统一认证系统作为统一入口，增强访问的安全性和管理控制的便捷 性； 角色和权限控制：系统用户划分为不同的用户组，同时将系统操作权限分割、细化，不 同的用户或用户组可以授予不同的操作权限，实现系统的数据访问安全。 操作权限：系统每个模块都有独自的操作权限，应支持系统用户的机构迁移和系统机构 的关键要素变更。 数据权限：用户登录统一采用 WEB 页面进行登录，在流程审批时，须严格遵守授权制度。 授权控制：从功能、机构和数据三个维度来控制一个用户的权限。 （

27、2）数据传输安全 用户客户端与 WEB、应用服务器间采用 HTTPS 协议，对数据传输过程进行加密。 3.7 容错性需求容错性需求 由于零售信贷风控管理系统对时效性要求较高，在系统设计时需考虑提供相应机制，能 保障整个系统有较高的可用性。如： 1.防重复提交机制 对于一些较复杂的操作场景（如贷款申请），可能会出现由于操作失误所导致请求重复 提交，应提供机制，避免对单一功能的重复提交； 2.交易存储-重发机制 系统要对于关键性交易（如贷款申请交易），一律采取先存储交易场景，再发送申请的 机制，当交易失败时，可以视失败原因（例如，通讯失败）择机重发，或等待日终对账处理。 3.操作预防机制 通过对用

28、户操作时严格控制（如，控制数据长度、精度、范围、以及业务处理规则等）， 配合友好的提示，尽量将系统的错误处理前移，实现整个系统的预防性容错。 3.8 稳定性需求稳定性需求 系统应使用开放的架构、无单点故障、无瓶颈，并可支持线形扩展，能支持双活部署或 提供实时热备方案。 3.9 可扩展性需求可扩展性需求 系统的前台和后台在设计上是独立的，前端程序和后台程序都具备高可扩展性，可根据 银行业务需求个性化定制功能，提供完整的数据接口，可供其他系统调用。 后台程序：能根据银行各个外围系统的具体报文格式要求进行数据传送； 前台程序：功能模块均需具备可扩展性。 3.10 服务需求服务需求 3.10.1 建设

29、与实施建设与实施 项目启动阶段 在该阶段，需完成项目立项、项目规划、需求分析与需求确认、系统设计等工作，为系 统实现做好准备。 该阶段的工作成果包括： #工作成果名称工作成果名称 1.项目总体计划 2.项目实施工作任务说明书 3.系统开发计划（含资源计划） 4.需求规格说明书 5. 系统实现阶段 在该阶段，主要是完成代码编写和系统测试工作。 该阶段的工作成果包括： #工作成果名称工作成果名称 1. 系统架构说明书 2. 概要设计说明书 3. 详细设计说明书 4. 数据库设计说明书 5. 关键代码走查方案及报告 6. 单元测试报告 7. SIT 测试案例 8.

30、 SIT 测试报告 9. UAT 测试报告 系统上线阶段 在该阶段，最关键的活动是系统发布、试运行和系统上线活动。 该阶段的工作成果包括： #工作成果名称工作成果名称 1. 系统操作手册 2. 系统维护手册 3. 系统上线验证方案及应急预案 4. 系统上线业务验证方案 5. 业务验证案例 6. 项目上线方案及时序计划 7. 数据备份方案 8. 产品手册 9. 安装手册 10. 备份及恢复手册 验收交付阶段 该阶段是完成项目验收、确认验收报告、项目结项。 该阶段的工作成果包括： #工作成果名称工作成果名称 1. 应急预案 2. 验收报告 3. 验收问题追踪 4. 系统程序源代码 0.2 维护与支持维护与支持 （1）从合同系统上线三个月后(即试运行期结束)且系统验收通过之日起，乙方应按照 工作说明书约定的内容，向甲方提供 12 个月的合同系统免费缺陷修复维护支持服务。 （2）在上述免费产品维护服务期内，乙方将安排不低于 2 人常驻甲方现场，指导和协 助甲方的相关业务和技术人员，提供系统运维服务与支持。同时，乙方应提供离场支持。 在上述免费维护期内，乙方提供的服务如下： 不低于 2 人的常驻现场支持服务； 提供系统缺陷的修复； 提供性能优化服