近年来，随着普惠金融实践的不断深化，随着信贷业务线上化的不断发展，个人信贷业务的运营模式也在出现一些变化，对数字化自动化的审核审批及贷后管理模式的探索越来越受重视。在个人信贷业务的自动化运营与决策中，人行个人征信报告的数字化应用起着关键作用，因此，目前的发展趋势也对人行个人征信报告的数字化应用不断地提出了新的管理要求。
为了保护借款人作为个人消费者的合法权益，保护借款人的个人隐私和个人信息安全，规范和监督商业银行等金融机构之间公平合理的市场竞争，政府与人行对于金融机构在开展信贷业务中使用个人征信报告历来有着非常严格的监管要求。各家金融机构在传统的信贷业务运营中对此已熟悉和很好规范了。然而当个人信贷业务开始走向全程数字化自动化运营模式的时候，面对人行个人征信报告的采集、整理、使用、记录和储存等环节的管理中如何确保依旧很好满足各类监管要求，则是一个新的课题。笔者就此试图做一些探讨性讨论。
1，个人征信信息自动化应用须为一个独立的子系统
目前商业银行在开展信贷业务自动化运营中，尤其是在开展线上贷款业务自动化运营中，较多是需要另外建设一套有别与传统信贷业务系统的独立的业务平台或系统群。其中，个人征信信息的自动化应用与管理，往往是整套平台中的一个功能模块，从对业务综合管理和满足监管对使用个人征信报告的要求的角度来说，理想的状态这个模块最好是一个自我独立运维管理的子系统。
个人征信信息自动化应用子系统，一般是指面向信贷业务自动化运营的贷前审核审批及贷后预警管理中，应用人行个人征信报告的各项相关环节所需的自动化实时或跑批的流程，包括对人行个人征信报告的自动化查询流程控制、数字化解析、自动化决策征信信息调用管理、征信报告查询记录与客户授权与征信信息储存管理、以及对于自动化查询用户的管理等各项功能。这个系统最核心的功能就是自动化查询人行个人征信报告，因此也可以称为个人征信报告自动化查询系统。
而诸如贷后个人征信上报、客户征信异议处理等功能则不应在该子系统内。另外，对于从其他各类第三方数据服务机构获取客户个人信息的相关管理，因为管理要求的不一样，也是不属于这个子系统而是由其他专门的系统模块处理。
在整体设计上将这一模块考虑成独立的子系统，而不是与整个的业务自动化运营置于同一个直连系统内，首先是从开发或引进的角度，这一系统功能有其特殊的满足重点管控的要求，需要提供产品的服务商具备相关经验也是考虑的重要因素，因此很大可能性是在建设整个自动化信贷业务平台中，这一子系统的开发商与平台其他功能的开发商不是一家。
从系统操作权限管理的角度，该系统的一般用户首先就是人行个人征信报告的查询员，同时也往往是整个自动化信贷业务平台其他功能模块的用户。而对于人行个人征信报告的查询员，不仅在密码管理方面而且在信息管理权限方面要求甚高。作为子系统单独管理有利于对于用户权限实现强化管理。
2、个人征信报告自动化查询流程控制
目前人行征信中心对银行等金融机构开放的个人征信报告查询方式，分别有数据库直连和网页界面查询两种。除了少数几家大银行是具有数据库直连的资格，大多数中小金融机构目前都只是以网页界面查询的方式。不管是何种方式，实质上对于每个个人客户征信报告的查询都是逐个依次发起和完成的。自动化的查询只是将原先由人工操作的逐个依次处理的过程，实现由系统程序驱动和控制。
由人工操作的每一笔查询，都需要金融机构内有资格且已在人行征信中心完成注册的查询员，通过登录和密码验证步骤才能发起。当人工操作变为系统程序自动化驱动之后，本质上这个步骤没有被省略掉，而只是由系统在发起每一笔查询时候模拟查询员的登录和密码验证完成一系列操作。
尤其是对于通过网页界面查询的模式，人行征信中心严密监控着金融机构发起个人征信报告查询请求的频率，一旦发现某个入口在短时间内产生了超过常规量的查询请求，则会立即中断查询入口。所以当整个信贷业务模式转为全程自动化之后，金融机构在个人征信报告自动化查询请求发起环节的程序设计上，须做到适度控制查询请求发起的频率和速度。如果业务发展的确会有大量查询请求发生的话，金融机构须首先与人行征信中心沟通，开立批量查询的白名单。
人行征信中心不容许不合理地多次频繁查询单一客户的个人征信报告，所以个人征信报告自动化查询系统须严格控制对于单一客户所发起的查询请求次数。在这方面系统设计必须注意几件事。
第一，要防止由于中间连接故障从而造成的对于单一客户的反复自动化发起查询请求，尤其要注意到本地系统视为查询请求连接失败从而重新发起，而人行征信中心却记录为查询请求已接受的一类技术故障场景。
第二，系统须具备异常预警及处理机制。当与人行征信中心的连接出现故障、查询超时等异常情况发生时，系统须能及时判断并向后台运行监测人员提示预警，同时对正在进行的查询任务进行暂停处理，待技术故障解决后恢复。
第三，要防止因为个人客户在整个自动化业务平台的客户端短期内自助发起多次贷款申请，从而造成的对人行征信报告的多次查询请求；也要防止在已有客户信息无任何变化情况下业务平台的自动化贷后管理流程所触发的对单一客户贷后检查征信查询的多次请求。对于这些场景，系统中需配置一定的策略，做到对于单一客户在一定的期限内一定的条件下不再重复查询其人行个人征信报告。
3，查询人员的用户和密码管理
金融机构对于人行个人征信进行查询时是以本机构有资格的查询员进行查询的，所有查询员都必须在人行征信中心完成实名制登记并且获得初始密码。个人征信报告自动化查询系统本质上是在模拟查询员进行查询，因此必须在该系统中将实名制查询员的身份嵌入自动化流程配置中。
由于目前传统金融机构一般都有以传统方式进行个人征信报告查询的前置，并要求通过统一接口向人行征信中心发起查询请求，同时传统的征信报告查询前置也设置有对于查询员资格管理严格的分级复核流程，所以用于个人征信报告自动化查询系统中配置的实名制查询员的初始注册过程，最好也依旧由传统征信报告查询前置予以处理，待查询员完成注册获得初始密码后，再在个人征信报告自动化查询流程中予以配置。这样做能够更好地满足人行征信中心关于金融机构对于征信报告查询员资格的管理要求，包括对于查询员资格的批准、复核、暂停和删除等。
人行征信中心是要求金融机构查询员定期修改登录密码。因此征信报告自动化查询系统最好能够支持对嵌入在自动化查询流程中的实名制查询员，实现初始配置后即刻以及以后的定期联机人行征信中心自动修改用户密码，并在本地加密保存系统自动修改后的密码的功能。这样做既方便了查询员本人不需要经常去修改密码，同时也加强了查询员用户的人行征信中心查询登录密码的保护。此时查询员本人已经是不知道在征信报告自动化查询流程中由系统所使用的密码，因此也无法在其他渠道用此密码登录查询，以保证了为个人征信报告自动化查询系统所配置的实名制查询员只能是作用于该自动化查询系统。
征信报告自动化查询系统还应具备自我管理功能，阻止系统的超级用户管理员自己能够成为人行征信查询员并被配置于自动化征信报告查询流程中。
4、征信查询的台账和征信报告的存储
个人征信报告自动化查询系统在收到征信报告查询请求后，必须先自动完成查询登记，再联机人行征信中心完成个人征信报告的查询获取。系统须登记查询请求方、查询请求时间、被查询客户基本信息、客户授权记录、查询原因、针对贷款产品、查询需使用的查询用户账号等相关信息，并查询请求返回之后，完整记录下系统查询编号、查询完成时间、查询连接结果、征信报告编号、异常处理结果等细节。所有记录将生成电子台帐保存以备日后检查、审计等相关工作使用。
征信报告自动化查询系统应设有客户征信授权记录的完整存储功能。对于依靠线下纸质获取客户授权的，应有纸质图像扫描件的存储功能。对于依靠线下电子方式获取客户授权的，应有电子授权所有相关文档及痕迹的存储功能。
通过自动化查询获取的个人征信报告，如果是XML文件，须编号后予以存储，并向下游系统提供文件编号，以便必要时候有权限的业务人员可以通过下游系统进行调取阅读。文件编号最好另外由系统生成，而非直接采用人行征信中心返回的征信报告编号。
根据人行征信中心的管理要求，存储在系统内的个人征信报告的XML文件的存储，须定期移出系统处理为离线存储的电子档案。系统须按时发出定期处理的信号，并自动化对未按时做处理处理的情况提供报警。
5、个人征信报告的解析
如果金融机构通过查询所获取的个人征信报告是XML文件格式，则个人征信报告自动化查询系统须跟进配备对于XML文件的解析功能，通过解析导出可供信贷业务自动化审核审批模块使用的纯数据格式。
系统要实现对于个人征信报告所有字段的全解析，而不是仅仅围绕当前业务的审核审批策略进行解析。系统也应该具备如果人行个人征信中心提供的查询页面发生变化从而能够方便地修改解析逻辑的功能。
解析后的电子信息须在系统自己的数据库中存储，并与征信报告XML文件的编号予以对应。金融机构可考虑将解析结果分为全部结果存储和部分主要数据单独存储的方法，以便对于全部结果的电子化存储的管理，满足与XML文件存储须定期移出系统处理为离线存储的电子档案所相同的要求。
金融机构不适合在个人征信报告自动化查询系统中，直接利用个人征信报告的电子化存储数据部署信贷业务的贷前审核审批和贷后预警管理策略和评分。相关的策略和评分模块须另外部署并通过自动化流程调度管理来调用在本系统中存储的个人征信报告信息。
联系客服
