XX银行_高阶需求--征信系统_合并20171106

XX银行，总部设在XX，是XXX商业银行，为更好地支持业务快速发展需求，以及满足内地监管对于系统境内部署运作的要求，XX银行需尽快建立一套与未来业务发展战略匹配的IT系统。经过前期的XX银行IT新线咨询规划，XX银行形成了一个核心系统加五十多个外围系统的整体规划，计划18个月建设完成，目前正在按规划内容进行多项目群新线系统建设。征信系统作为XX银行新线系统建设中的业务系统，承担征信信息管理的功能。XX银行希望能通过本次招标选型，完成征信系统的实施建设，并要求投标方在实施阶段配合其他系统实施商进行征信系统的持续改进和维护。第一章 功能需求1 系统建设目标：通过本项目的实施，废弃企业征信数据报送从手工重复录入的方式，实现业务系统数据自动流转报送的方式，实现征信查询前置管理功能，实现征信数据集中管控、集中处理。 具体如下：1)解决分行手工在我行业务系统及人行系统两次手工录入不一致、错报漏报、报送不及时等操作风险，提高数据报送质量；2)减轻分行繁重的手工工作量、减少人力成本；3) 沉淀征信数据，建设征信集市。4)按照人行征信标准，对我行信贷业务进行及时、全面的监控。5） 通过安装征信查询前置系统，增设预警功能，加强分行征信用户使用管理，有效监控不合规情形。6）为实现征信数据集中管控、集中处理提供解决方案及系统建设。增加数据统计及数据核对功能。2 业务需求：2.1 业务范围：2.1.1 基础业务通过建设一个基于网络的、统一的征信报送和前置查询系统,实现系统化的日常数据对外报文报送和查询处理，使我行报送企业及个人人行征信数据规范化及流程化。2.1.2 特色业务l 综合个人征信与企业征信的统一管理平台。l 同时支持征信信息报送以及征信信息的查询，提供完整的征信数据服务。2.2 系统概述及定位：系统通过ODS（综合数据库）抽取核心、信贷、信用卡、国结、票据等业务源系统中的数据，分析企业征信、个人征信信息，生成报文和并上报；同时该系统作为全行征信前置，沉淀客户征信信息，建立征信数据集市，为其他外围系统的征信相关查询需求提供数据支撑。2.3 基本要求：1、通过ODS数据平台抽取数据，自动产生上报报文，经过校验、修正、补录、最后完成数据报送。2、接收人行反馈报文、反馈错误信息给业务部门、数据重报、历史报文管理。3、同时支持企业和个人征信（包含个贷、信用卡及季度考评）报文生成,实现征信数据的集中管控、集中处理。4、规范报文报送流程，增强报文报送准确性， 通过自动化提升报送时效性。5、覆盖征信所有业务，提供合理有效的征信业务功能，提升征信报送质量和处理效率。6、建立统一的征信接口，规范与外部征信环境的连接，包括但不限于核心系统，信贷管理系统，客户信息系统等。7、建立征信报送平台，该平台可以支撑人行征信的最新要求，并可以持续进行维护与升级。8、建设对公征信查询前置及个人征信的查询具体实施方案视供应商而定，方案如需要当前个人征信前置系统配合改造，则相关成本需纳入考量。功能，对接人行征信查询环境和银行信贷系统，解析保存征信信息，沉淀客户数据，交易通过后自动上报报文。9、为行内其他业务系统建立统一征信查询入口，提升业务处理效率10、提供数据统计及量化评分数据核对解决方案。11、支持9征信上报及查询的权限设置及管理。2.4 功能需求：Ø 企业及个人征信查询建设征信查询前置，对接企业和个人人行征信查询环境，解析保存征信信息，沉淀客户数据。 Ø 数据上报 根据ODS提供的各个业务系统数据资源，征信系统抽取出日常符合征信接口规范的交易数据进行加工处理，生成符合人行要求的征信报文，数据上报员可以将报文直接用于上报人行；如果征信系统在加工报文过程中发现业务系统的上报数据有异常，生成相关报表供总行或分行人员参考，数据上报员可以选择修正数据后整合报送，或者剔除异常数据后把其余正确数据正常报送，异常数据由原系统修改完成后次日进行报送；Ø 反馈报文处理接收人行反馈数据并导入征信系统，如反馈错误信息，则征信系统可以通知相应业务操作员根据权限进行提示，由其修改错误信息后，次日和正常业务数据同时进行上报，如此循环，完成征信数据的报送动作。Ø 数据核对按照人行要求完成征信数据与业务系统数据核对工作，利用自动化工具进行数据核对，节省人力，提高准确率。Ø 数据查询系统提供灵活的查询功能，包括：按照客户维度、业务类型维度进行查询、按照报文维度查询等。所有查询与统计结果，均可支持按照用户要求导出Excel文件的功能，便于总分行各部门的跟踪分析工作。Ø 数据维护异常情况下，提供增删改功能；Ø 提供相关修改跟踪记录；可以按照客户维度、业务类型维度或者报文维度进行维护。已报送报文仅能查询，未报送报文异常、紧急的情况下提供维护后进行报送的功能。报送数据原则上来源于业务系统，维护功能仅作为应急手段，需要有权人员进行授权才能使用。Ø 数据移植对我行在人行征信系统的已报送历史数据进行数据移植，使手工报送数据与接口报送数据可以有效衔接。Ø 报表功能可根据用户需求，在系统数据信息范围内提供相关报表。 提供人行量化评分数据核对方案。2.5 系统主要接口： 为了实现系统报送功能，需对接ODS导入业务系统数据信息作为基本信息，后续将根据实际开发需求确定，将相应增加或调整。需要从ODS接入的数据来源系统包括但不限于：核心系统、信贷系统、信用卡系统、票据系统、国结系统等系统。征信查询前置系统接入信贷系统。需要预留API接口，以便我行移动终端（PAD）查询个人征信。2.6 其他要求l 要求实现参数化。l 要求配备现场专职测试人员，负责协助业务人员完成测试案例的编写和业务功能测试。l 要求对运维人员进行全面培训。l 配合人行按照项目实施计划完成系统联调。第二章 非功能需求本章从架构总体要求展开，依次体现系统非功能性需求，包括整体性能、安全性、可用性、可扩展性、容错等模块具体要求。1.1 架构要求采用业内成熟SOA架构等先进架构理念，按照标准技术框架进行开发和部署，符合面向服务规范；具备架构高效性、先进性、安全性等非功能需求；满足对我行业务发展提供延续性支撑条件。1.2 安全性要求基本安全要求（其中粗体为加强需求）系统需满足银行相关监管部门安全要求，具备严密完整的安全体系。1.身份鉴别对登录的用户进行身份标识和鉴别，身份标识具有唯一性，鉴别信息具有复杂度要求并定期更换；提供并启用登录失败处理功能，多次登录失败后应采取必要的保护措施；用户首次登录时要求修改初始口令；用户身份鉴别信息丢失或失效时，采用鉴别信息重置或其他技术措施保证系统安全。对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别。2.访问控制应提供访问控制功能，对登录的用户分配账号和权限；访问控制的粒度应达到主体为用户级，客体为文件、数据库表级、记录或字段级；对敏感信息资源设置安全标记，并控制主体对有安全标记信息资源的访问。3.监控与审计涉及交易的系统满足对交易量、交易成功率、交易响应时间等监控。具备事件监控和响应机制；提供安全审计功能，审计覆盖到每个用户，记录用户的重要行为和应用系统异常情况。审计记录包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；对审计进程进行保护，防止未经授权的中断；审计记录产生时的时间由系统范围内唯一确定的时钟产生，以确保审计分析的正确性。4.软件容错应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求；在故障发生时，应能够继续提供一部分功能，确保能够实施必要的措施。应提供自动保护功能，当故障发生时自动保护当前所有状态，保证系统能够进行恢复。5.资源控制当通信双方中的一方在一段时间内未作任何响应，另一方能够自动结束会话；能够对系统的最大并发会话连接数进行限制；能够对单个账号的多重并发会话进行限制。对并发进程的每个进程占用的资源分配最大限额。6.数据安全满足数据网络传输不被窃听及篡改；满足数据移植性及无差错运行；采用校验码技术或加解密技术保证重要数据在传输过程中的完整性。采用校验码技术或加解密技术保证重要数据在存储过程中的完整性。7.剩余信息保护保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除。保证存有敏感数据的存储空间被释放或重新分配前得到完全清除。.合规性系统内各类通讯接口、加密实现方式需遵循银行业相关监管部门的要求；系统开发全生命周期需符合行内相关安全合规内容；系统具备行业内通用的系统保密性及系统完整性特性；1.3 扩展性要求采用开放的系统架构，减少系统耦合性，提高系统复用性；遵循业内成熟的、通用的技术标准、规范和协议；满足系统组件化设计；满足动态加载新增组件的方式实现系统扩展；1.4 稳定性要求符合行业内通用稳定性要求。具备应用系统、中间件及数据库设计稳定性策略；确保系统各组成模块不存在单点故障风险；1.5 可靠性要求系统可靠性需符合银行相关监管部门的要求；系统应能可靠、稳定地运行；全年系统可用率应大于99.5%（计划外停机除外）；系统需支持集群、主备等系统可靠性方案；系统复原时间目标RTO<7天；1.6 性能要求系统需符合银行同业内提供的性能水平。并发用户支持不小于50人；系统用户支持不小于200人；核心部分日批处理时间需小于60分钟；日终批处理接口文件及报表处理时间需小于30分钟；平均页面响应时间不超过2秒。1.7 维护性要求【总体要求】系统需具备较强的可维护性要求，符合行业内相应水平；【具体要求】系统应有完善的数据备份和恢复机制，备份过程应不影响系统服务；系统应有灵活和可配置的自动化清理机制，可通过配置支持多种数据清理策略；具备完善的在线修改配置信息，而不中断业务的设计机制;具备完善的系统备份、恢复和清理机制;需提供开放的应用、交易、日志和系统监控接口，可供其他系统使用；需提供系统运维管理、参数管理等功能的前端界面，维护人员角色和权限管理方案；需提供单笔维护和批量维护工具支持，对操作过程有日志记载，并支持误操作下的恢复机制；需提供系统更新升级方案，说明不间断升级的条件；系统应支持在不中断应用服务的情况下进行程序更新，支持应用的灰度发布。1.8 审计要求【总体要求】符合行业内通用审计要求条件；【具体要求】具备操作日志及访问日志相关内容，满足行内审计追踪的需求；系统日志采用行业内标准的日志格式来定义；具备完善的审计追踪机制方案。1.9 容错性要求【总体要求】系统需具备业内通用容错性要求条件；【具体要求】具备应用错误捕获及保护机制；具备数据库集群或双机热备容错机制；1.10 系统移植性要求【整体要求】应用软件对多种第三方硬件及软件的无依赖性设计。【具体要求】支持主流的大型关系型数据库Oracle，DB2等；支持主流的中间件产品IBM WAS, Oracle Weblogic，Jboss等；支持主流操作系统AIX，LINUX等；支持主流硬件平台包括IBM、HP小机及X86 PC Server等；1.11 数据移植要求【整体要求】采用业内成熟的数据迁移技术、方法，科学有效地实现数据迁移内容。【具体要求】具备数据迁入的完整性、正确性、高效性成熟方案；数据迁入的效率必须满足我行对系统迁移窗口的