CN109670938A - 征信数据合并上报的方法和*** - Google Patents
征信数据合并上报的方法和*** Download PDFInfo
- Publication number
- CN109670938A CN109670938A CN201811176641.7A CN201811176641A CN109670938A CN 109670938 A CN109670938 A CN 109670938A CN 201811176641 A CN201811176641 A CN 201811176641A CN 109670938 A CN109670938 A CN 109670938A
- Authority
- CN
- China
- Prior art keywords
- user
- loan
- credit
- data
- report
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/03—Credit; Loans; Processing thereof
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本发明提供一种征信数据合并上报的方法,包括:在同一个上报周期内,按照一预设的采集周期从信贷***的数据库中自动抽取所有用户的信贷数据;响应于任意一个用户处于报送日,从该用户的信贷数据中提取出贷款信息,根据预设的规则合并贷款信息,将用户名下所有未结清和/或当前上报周期内结清的贷款信息合并成一条贷款信息,经处理后的信贷数据只包括一条征信报送记录;将所述处理后的信贷数据转换成征信报文,校验后加密发送至人行征信***。本发明有效减少了用户的征信记录,提高了用户体验,也加快了每天征信处理速度,有效减少了时间成本与人力成本。
Description
技术领域
本发明涉及消费金融领域,具体而言涉及一种征信数据合并上报的方法和 ***。
背景技术
根据监管要求,消费金融公司向借款人发放的贷款需要向人行上报征信数 据。在现有的技术方案中,公司采用的是单笔贷款的模式,客户每次消费行为 均会形成新的贷款。每一笔贷款在未结清之前,每月均会单独的上报征信。
这种上报方法存在一些缺点,例如,随着公司业务的扩大,以及消费贷款 本身具有的“小额高频”的特征,采用单笔上报的模式会给客户带来大量的征 信记录,并且每个月都在以较快的速度增长,一方面,使得客户在查询征信报 告时用户体验很差,进而产生诸多负面影响,另一方面,越来越多的征信记录, 也使得每天征信处理时要耗费许多时间。
发明内容
本发明目的在于提供一种征信数据合并上报的方法和***,为每个客户设 立一个合并贷款账号,将用户名下所有还未结清或者当月结清的贷款信息合并 为一条贷款信息,为每个客户设定报送日,定期自动上报合并贷款信息。
为达成上述目的,本发明提出一种征信数据合并上报的方法,所述方法包 括以下步骤:
设置一上报周期,在一个上报周期内,所有用户均将发送至少一次征信报 文至人行征信***,同时为每个用户设置一独有的上报征信数据至人行征信系 统的报送日;
在同一个上报周期内,按照一预设的采集周期从信贷***的数据库中自动 抽取所有用户的信贷数据,抽取的信贷数据至少包括用户贷款数据、用户还款 计划、用户还款数据;
响应于任意一个用户处于报送日,从该用户的信贷数据中提取出贷款信息, 根据预设的规则合并贷款信息,将用户名下所有未结清和/或当前上报周期内结 清的贷款信息合并成一条贷款信息,经处理后的信贷数据只包括一条征信报送 记录;
将所述处理后的信贷数据转换成征信报文,校验后加密发送至人行征信系 统。
进一步的,所述方法还包括:
在一个上报周期内,按照一预设的采集周期从信贷***的数据库中自动抽 取所有用户的信贷数据,逐一提取用户的贷款信息,判断用户是否处于报送日:
1)响应于任意一个用户在本次采集周期内获取至少一笔贷款、并且在该采 集周期之前无贷款或者贷款已全部结清,将当前时刻所处的日期作为该用户在 这一上报周期的报送日;
2)响应于任意一个用户在本次采集周期之前存在未结清的贷款,将用户在 本次上报周期内的所有未结清贷款中还款日最晚的一天定义成最晚计划还款 日,采用该最晚计划还款日、和/或在本次上报周期内的实际还清日作为该用户 在本次上报周期的报送日,该实际还清日不晚于该用户的最晚计划还款日。
进一步的,所述方法还包括:
将一用户的每笔贷款数据分别存储至一单笔贷款账户内,一个单笔贷款账 户对应该用户的其中一笔贷款;
为所述用户建立一合并贷款账户,将经合并处理后的信贷数据存储至该合 并贷款账户,同时创建该用户的合并贷款账户与其所有单笔贷款账户的映射关 系,以从合并贷款账户中直接链接至对应的单笔贷款账户。
进一步的,所述方法还包括:
响应于任意一个用户名下的贷款全部撤销,将该用户的信贷数据标记为待 补偿数据。
进一步的,所述方法还包括:
响应于任意一个用户在其名下贷款全部结清后又新申请了新的贷款,调取 该用户的待补偿数据,并且按报送周期将这期间的征信记录补全,结合新的贷 款信息,生成新的征信数据。
进一步的,所述方法还包括:
定期提取在本次上报周期之前的两个上报周期的报送结果,如果第一个上 报周期有报送且用户状态非结清或者核销、第二个上报周期没有报送,对该用 户进行漏报判断。
进一步的,所述方法还包括:
根据用户的还款能力为每笔贷款设定风险等级,按风险等级从小到大的顺 序分别设定成正常、关注、次级、可疑以及损失;
选取用户名下风险等级最高的贷款的风险等级作为合并后征信数据的风险 等级。
进一步的,所述方法还包括:
为用户账户中的每笔贷款标定一还款状态,还款状态至少包括正常还款、 结清、逾期、核销;
如果用户有逾期或核销的贷款,选取逾期情况最严重的一笔的状态作为合 并贷款账户的还款状态,如果客户名下所有贷款全部是结清状态,将合并贷款 账户的还款状态设定成结清,否则将合并贷款账户的还款状态设定成正常状态。
进一步的,所述方法还包括:
统计每个用户发送征信报文的总次数和贷款总金额、以及所有征信报文中 逾期总次数和逾期总金额:
1)响应于任意一个用户的逾期次数超过一设定的逾期次数阈值、或者逾期 金额超过一设定的逾期金额阈值,将该用户的信息存储至一黑名单数据库;
2)响应于任意一个无逾期记录的用户发送征信报文的总次数超出一设定的 发送次数阈值、或者贷款总金额超出一设定的贷款金额阈值,将该用户的信息 存储至一白名单数据库。
在前述方法的基础上,本发明提及一种征信数据合并上报的***,所述系 统包括:
用于设置一上报周期和为每个用户设置一独有的上报征信数据至人行征信 ***的报送日的模块;
数据抽取模块,用于在同一个上报周期内,按照一预设的采集周期从信贷 ***的数据库中自动抽取所有用户的信贷数据的模块,抽取的信贷数据至少包 括用户贷款数据、用户还款计划、用户还款数据;
数据合并模块,用于响应于任意一个用户处于报送日,从该用户的信贷数 据中提取出贷款信息,根据预设的规则合并贷款信息,将用户名下所有未结清 和/或当前上报周期内结清的贷款信息合并成一条贷款信息的模块,经处理后的 信贷数据只包括一条征信报送记录;
发送模块,用于将所述处理后的信贷数据转换成征信报文,校验后加密发 送至人行征信***的模块。
由以上本发明的技术方案,与现有相比,其显著的有益效果在于,
1)每个客户在当月有多笔贷款时,只会产生一条征信记录,使得客户自己 的征信报告信息更加简洁明了,有效减少了用户之前在查询征信报告时,面对 大量征信记录无法有效提取有用信息从而产生的负面影响,提高了用户体验。
2)由于在大部分情况下每个客户每月只有一条征信记录,使得每日征信报 送的数据量大为减少,提高了每天征信处理的速度,也有效减少了机器成本的 开支。
3)具有自检设置,避免漏报,另外,对于已结清贷款的用户,实时更新其 状态,不占用运算资源。
应当理解,前述构思以及在下面更加详细地描述的额外构思的所有组合只 要在这样的构思不相互矛盾的情况下都可以被视为本公开的发明主题的一部 分。另外,所要求保护的主题的所有组合都被视为本公开的发明主题的一部分。
结合附图从下面的描述中可以更加全面地理解本发明教导的前述和其他方 面、实施例和特征。本发明的其他附加方面例如示例性实施方式的特征和/或有 益效果将在下面的描述中显见,或通过根据本发明教导的具体实施方式的实践 中得知。
附图说明
附图不意在按比例绘制。在附图中,在各个图中示出的每个相同或近似相 同的组成部分可以用相同的标号表示。为了清晰起见,在每个图中,并非每个 组成部分均被标记。现在,将通过例子并参考附图来描述本发明的各个方面的 实施例,其中:
图1是本发明的征信数据合并的方法流程图。
图2是本发明的征信数据合并的分步方法流程图。
图3是本发明的征信数据合并的***结构示意图。
图4是本发明的数据抽取模块的工作流程示意图。
图5是本发明的合并贷款账户和单笔贷款账户之间的映射关系示意图。
图6是本发明的撤销待删除数据的方法示意图。
图7是本发明的漏报判断的方法示意图。
图8是本发明的用户评定的方法示意图。
具体实施方式
为了更了解本发明的技术内容,特举具体实施例并配合所附图式说明如下。
在本公开中参照附图来描述本发明的各方面,附图中示出了许多说明的实 施例。本公开的实施例不必定意在包括本发明的所有方面。应当理解,上面介 绍的多种构思和实施例,以及下面更加详细地描述的那些构思和实施方式可以 以很多方式中任意一种来实施,这是因为本发明所公开的构思和实施例并不限 于任何实施方式。另外,本发明公开的一些方面可以单独使用,或者与本发明 公开的其他方面的任何适当组合来使用。
结合图1,本发明的目的是提出一种征信数据合并上报的方法,所述方法包 括以下步骤:
S1:设置一上报周期,在一个上报周期内,所有用户均将发送至少一次征 信报文至人行征信***,同时为每个用户设置一独有的上报征信数据至人行征 信***的报送日。
S2:在同一个上报周期内,按照一预设的采集周期从信贷***的数据库中 自动抽取所有用户的信贷数据,抽取的信贷数据至少包括用户贷款数据、用户 还款计划、用户还款数据。
S3:响应于任意一个用户处于报送日,从该用户的信贷数据中提取出贷款 信息,根据预设的规则合并贷款信息,将用户名下所有未结清和/或当前上报周 期内结清的贷款信息合并成一条贷款信息,经处理后的信贷数据只包括一条征 信报送记录。
S4:将所述处理后的信贷数据转换成征信报文,校验后加密发送至人行征 信***。
步骤S1中,报送日可以设定为固定的一天,例如每个月的月末,也可以是 一动态日期。
例如,在本申请中,假设上报周期被设定成一个月,采集周期被设定成每 天,后续部分提到的上报周期和采集周期均如此。
1)如果一个用户在本次采集周期内获取至少一笔贷款、并且在该采集周期 之前无贷款或者贷款已全部结清,将当前时刻所处的日期作为该用户在这一上 报周期的报送日。
2)如果一个用户在本次采集周期之前存在未结清的贷款,将用户在本次上 报周期内的所有未结清贷款中还款日最晚的一天定义成最晚计划还款日,采用 该最晚计划还款日、和/或在本次上报周期内的实际还清日作为该用户在本次上 报周期的报送日,该实际还清日不晚于该用户的最晚计划还款日。
在实际应用中,可以通过定期扫描还款计划和放款数据来实时确认当前时 刻是否为用户的报送日,以报送日选取最晚计划还款日为例,对于当天需要发 送征信报告的用户的确认步骤如下:
步骤S101:遍历未全部结清的客户名下所有贷款的还款计划,获取到该客 户在当月多笔贷款中还款日最晚的一天,作为该客户贷款合并后的报送日,如 果只有一笔贷款的话,则取这一笔贷款的还款日。
步骤S102:开始准备放款日报送的数据,遍历所有在当天放款的贷款数据, 如果一个客户只有此类数据的话,则会在当天报送。
步骤S103:遍历所有需要报送的客户,根据步骤1中得到的报送日和当前 日期,获取报送日在当日的客户。
步骤S2中,信贷数据的抽取方法包括以下步骤:
步骤S201:从信贷核心***中,遍历当天的交易数据,获取以下类型的数 据:用户在当天放款的数据、用户在还款日时的还款数据、用户在全部结清时 的还款数据、用户每一笔贷款的还款计划。
步骤S202:将这些数据进行初步的处理,获取每一笔贷款交易中征信所需 的数据,包括账户状态、实还金额、应还金额、逾期金额等,上述字段都是征 信上报中较为关键的字段。
以上所述的便是源数据抽取的过程,将信贷核心***的数据抽取到征信系 统,作为下一步骤征信数据合并的基础。
步骤S3中,依据步骤S2所述报送日在当日的客户,获取该客户在数据抽 取模块中获得的所有贷款数据,根据预设的规则合并贷款信息,进行贷款合并。
结合图2,在一些例子中,根据预设的合并规则,合并的主要步骤包括以下 几条:
S01:生成客户报送日。
S02:开户日贷款当天报送。
S03:提取报送日在当天的数据。
S04:根据步骤S2中获取到的用户贷款,遍历所有贷款,得到贷款结束日 最晚的一笔贷款,将该笔贷款的结束日作为合并贷款的结束日。
S05:遍历客户所有贷款,检查是否结清,如果全部已结清,则判断该客户 贷款状态为结清。
S06:遍历客户名下所有的逾期贷款,获取到客户逾期期数最大的一笔贷款, 将这笔贷款的逾期期数作为合并后贷款的逾期期数。
遍历客户名下所有的逾期贷款,获取到逾期金额并进行累加,作为合并后 贷款的逾期金额。
S07:根据数据抽取获得的贷款信息,遍历客户名下的所有贷款,如果该笔 贷款还未到期,则从还款计划中取得还款日再上次报送日到这次报送日之间贷 款期数对应的应还金额;如果贷款已到期,则取得贷款的所有应还金额,将两 次得到的应还金额相加,得到合并后贷款的应还金额。
根据数据抽取获得的贷款信息,遍历客户名下的所有贷款,获得贷款还款 时间在上个报送日到本次报送日之间的实际还款金额,累加后得到合并后贷款 的实还金额。
S09:遍历客户名下所有的逾期贷款,根据贷款的逾期天数和逾期金额,分 别取得贷款逾期31-60天本金、逾期61-90天本金、逾期91-180天本金以及逾 期180天以上本金。
S10:保存客户的合并贷款信息。
在另一些实施例中,为用户账户中的每笔贷款标定一还款状态,还款状态 至少包括正常还款、结清、逾期、核销。
如果用户有逾期或核销的贷款,选取逾期情况最严重的一笔的状态作为合 并贷款账户的还款状态,如果客户名下所有贷款全部是结清状态,将合并贷款 账户的还款状态设定成结清,否则将合并贷款账户的还款状态设定成正常状态。
在将多笔贷款合并成一笔之后,数据库中会保存每个客户和对应的账户状 态,用于下一次的合并;对于账户状态是核销的数据,除非用户再次发生还款, 否则不再对客户的贷款数据进行处理。而对于账户状态是正常或者逾期的客户, 每月至少进行一次合并处理。
这样可以快速查看到用户的贷款情况。
步骤S4中,在得到最终的合并后贷款数据后,由数据发送模块生成报文文 件,并对征信报文进行校验以及加密处理,在加密完成后,调用人行征信的服 务接口,将包括有客户的合并贷款数据的征信报文发送给人行征信***。
至此,征信的存量合并工作已全部完成。
结合图3,在前述方法的基础上,本发明还提及一种征信数据合并上报的系 统,所述***包括以下模块:用于设置一上报周期和为每个用户设置一独有的 上报征信数据至人行征信***的报送日的模块、数据抽取模块、数据合并模块、 发送模块。
所述数据抽取模块用于在同一个上报周期内,按照一预设的采集周期从信 贷***的数据库中自动抽取所有用户的信贷数据,抽取的信贷数据至少包括用 户贷款数据、用户还款计划、用户还款数据。
所述数据合并模块用于响应于任意一个用户处于报送日,从该用户的信贷 数据中提取出贷款信息,根据预设的规则合并贷款信息,将用户名下所有未结 清和/或当前上报周期内结清的贷款信息合并成一条贷款信息,经处理后的信贷 数据只包括一条征信报送记录。
所述发送模块用于将所述处理后的信贷数据转换成征信报文,校验后加密 发送至人行征信***。
图4为数据抽取模块的工作流程。数据抽取模块抽取三类数据,进行一定 处理后,生成了征信基础数据,为之后的数据合并做准备。
在将征信数据上报之后,用户即使有多次贷款,在查询自己的征信记录时, 也只会看到一条贷款的征信记录,因此可以高效率的看到自己的征信信息;此 外,本方法在合并贷款的同时,也保留了合并后贷款与单笔贷款账号的映射关 系,征信***也提供了查询模块,客户在查询模块可以了解到单笔贷款的具体 信息。
结合图5,所述方法还包括:
将一用户的每笔贷款数据分别存储至一单笔贷款账户内,一个单笔贷款账 户对应该用户的其中一笔贷款。
为所述用户建立一合并贷款账户,将经合并处理后的信贷数据存储至该合 并贷款账户,同时创建该用户的合并贷款账户与其所有单笔贷款账户的映射关 系,以从合并贷款账户中直接链接至对应的单笔贷款账户。
在图5所示的数据查询模块中,可以很便捷的根据客户的唯一标识获取合 并后的贷款业务号,根据此业务号便可以获得合并后贷款的报送记录。
同时,如果客户想知道某一笔贷款的逾期情况或者还款情况等信息,征信 ***也保留了客户合并后贷款业务号与单笔业务号的映射关系,可以根据此映 射关系快捷地查询到具体单笔贷款账号;有了单笔贷款账号后,也可以很方便 的获取到单笔贷款的具体信息。
对于一个客户在其名下贷款全部结清后,过了一段时间(超过1个月)又有新 贷款,有可能出现贷款的征信记录不连续的异常情况,这时会有一个补偿机制, 补全两次报送中间月份的征信记录,以保证客户在非结清或核销的情况下,每 个月都有征信上报记录。
所述方法还包括:
如果任意一个用户名下的贷款全部撤销,将该用户的信贷数据标记为待补 偿数据。而如果任意一个用户在其名下贷款全部结清后又新申请了新的贷款, 调取该用户的待补偿数据,并且按报送周期将这期间的征信记录补全,结合新 的贷款信息,生成新的征信数据。
这一功能在征信数据合并上报的***中,由撤销贷款删除模块完成,可以 将撤销贷款删除模块设定成每天定时执行。
结合图6,征信合并***对于撤销贷款的补偿处理模块,检测出已经上报但 是之后撤销的贷款,标记为撤销待删除数据,通过生成删除报文将人行记录删 除。
对于在该月准备上报或者已上报的记录,该模块会筛选出名下贷款全部撤 销、或者是先结清了一笔之后又撤销的客户数据,这两种数据因为在数据库中 的结构不同,因此需要分别筛选,之后再一并标记为待补偿数据。
筛选结束后,会将这批数据去人行进行删除,之后也不再上报。
所述方法还包括:
定期提取在本次上报周期之前的两个上报周期的报送结果,如果第一个上 报周期有报送且用户状态非结清或者核销、第二个上报周期没有报送,对该用 户进行漏报判断。
图7展示了漏报判断的处理流程,一个客户在贷款处于非最终状态(结清或 核销)时,应该每月都会上报;如果有客户不满足这个条件,就会标记为漏报异 常数据,需要检查原因并补充上报。
这一功能在征信数据合并上报的***中,由异常分析模块定期执行,例如 每天执行,扫描异常数据。
该模块首先提取所有在上上个月有过报送并且报送状态不是结清或核销的 客户,检查这些客户在上月是否有过报送,如果没有报送的话,还要考虑另外 两种特殊情况,一种是是否加入了免报名单,该名单中记录了因为账户盗用或 其他原因而不应上报的数据;还有一种就是客户的贷款发生了撤销。在排除上 述两种情况后,余下的数据都会标记为漏报异常数据。
对于该模块检测出的漏报数据,会检查原因并重新补充上报。
征信数据除了为用户、人行服务之外,最重要的是为信贷公司提供决策咨 询服务。在此基础上,所述方法还包括:
根据用户的还款能力为每笔贷款设定风险等级,按风险等级从小到大的顺 序分别设定成正常、关注、次级、可疑以及损失。
选取用户名下风险等级最高的贷款的风险等级作为合并后征信数据的风险 等级。
根据每笔贷款在当月的不同还款情况,包括正常还款、结清、逾期、核销 等,会给贷款设置不同的账户状态和24月还款状态。遍历客户名下所有贷款, 如果该客户有逾期或核销的贷款,则取逾期情况最严重的一笔的状态作为合并 后的账户状态和24月还款状态;如果客户名下所有贷款全部是结清状态,则状 态取结清;否则就报送正常状态。
在图8所示的征信数据分析模块中,会根据客户的征信报送记录筛选不同 类型的客户。
对于有过逾期记录的客户,会根据客户的逾期次数和逾期金额来判断客户 的还款能力,这两者只要有一项超过设定的阈值,则会认为该客户的还款能力 较差,在客户下次贷款审批时会建议审批不通过,或者降低客户的额度。
而对于没有逾期记录的客户,如果客户的征信报送次数较多(表名用贷时间 长)或者贷款金额较大,则说明该客户信用水平和还款能力较高,运营人员可以 优先向这些客户推荐消费金融产品。
进一步的,本发明还提及了一种征信数据分析方法,对用户进行评定,为 运营人员提供数据支持。具体的,所述方法还包括:
统计每个用户发送征信报文的总次数和贷款总金额、以及所有征信报文中 逾期总次数和逾期总金额。
1)响应于任意一个用户的逾期次数超过一设定的逾期次数阈值、或者逾期 金额超过一设定的逾期金额阈值,将该用户的信息存储至一黑名单数据库。
2)响应于任意一个无逾期记录的用户发送征信报文的总次数超出一设定的 发送次数阈值、或者贷款总金额超出一设定的贷款金额阈值,将该用户的信息 存储至一白名单数据库。
具体实施例一
本方法的核心是如何将用户的多笔贷款可以合并为一笔上报,同时符合监 管要求;下面将结合附图和具体实施例一,对所申请专利的方法进行完整的描 述。
假设在通过数据抽取模块的处理后,得到了如下所示的征信基础数据:
贷款账号 | 账户状态 | 贷款余额 | 客户编号 | 拖欠期数 | 拖欠余额 | 五级分类 | 结清状态 | 结清日期 |
N201801 | 正常 | 300 | User01 | 0 | 0 | 1 | 未结清 | / |
N201802 | 逾期 | 1000 | User01 | 1 | 100 | 2 | 未结清 | / |
N201803 | 结清 | 0 | User01 | 0 | 0 | 1 | 未结清 | 2018/08/23 |
表1-账户信息表
贷款账号 | 期次 | 逾期标志 | 结清标志 | 当月应还 | 应还日期 | 当月实还 | 实还日期 |
N201801 | 1 | 未逾期 | 未结清 | 300 | 2018/07/15 | 300 | 2018/07/15 |
N201801 | 2 | 未逾期 | 未结清 | 300 | 2018/08/15 | 300 | 2018/08/15 |
N201801 | 3 | 未逾期 | 未结清 | 300 | 2018/09/15 | / | / |
表2-账户还款信息表
表1展示了每一笔贷款的基本信息,表2则展示了贷款每一期的应还情况 和实还情况。
在每日凌晨征信***开始执行后,将会根据表1和表2的数据,按照本发 明所述的征信数据合并方法,将表1中的展示的3笔贷款合并为1笔贷款进行 上报处理。
参考图2中的用户贷款合并上报方法,下面是详细步骤阐释:
S01:生成客户报送日。
这一步发生在每个月月初,客户的不同贷款,每个月还款日是不同的;在 客户正常还款时,如果该月有1笔还款日再15号,一笔还款日是20号,则征 信报送日则定在最晚的一天,即20号;有一种特殊情况是,在有至少一笔贷款 已经到期了且未还清时,那么这笔贷款在该月是没有还款日的,这时该客户的 报送日就会定在月末。
S02:开户日的贷款当天报送。
针对一名客户在当天有一笔或多笔新贷款,且每月没有其他贷款时,那么 就认为当天是客户的开户日;在这种情况下,会在这一天报送这名客户的征信 记录。
S03:提取报送日在当天的贷款。
遍历征信***中所有客户,根据报送日筛选数据,得到报送日在当天的客 户。后面的操作就是对这些客户名下的贷款进行的操作。
由于现在数据量较大,每天需要合并报送的客户人数较多,如果逐条合并 的话耗时会很长,因此在本发明中,采用分片的方法进行征信数据合并处理。
上述分片的方法,即在提取到需要征信数据合并的客户后,通过多个线程 同时合并多个客户,提高处理效率。
下面是代码片段-1,阐述了通过spring-batch框架进行分片处理的相关配置。
代码片段-1
S04:遍历客户所有贷款取得最晚的结束日。
因为是将多笔贷款合并为一笔,则客户的征信记录直观上是一笔贷款,理 论上征信报送的截止日期就是结束日最晚的那笔贷款的最后一期,这里之所以 强调理论上,是因为客户可能存在提前结清的可能性。因此为了正确显示合并 后贷款的结束日,合并后贷款的结束日就取结束日最晚的那笔贷款的结束日。
下面的代码片段-2阐述了取得合并后贷款结束日的相关方法。
代码片段-2
S05:遍历贷款是否结清。
只有当一个客户贷款全部结清时,才可以认为该客户的合并贷款可以结清, 这时会报送征信客户已结清,后面不再报送。因此需要遍历检查客户名下所有 贷款,只要有一笔未结清,则认为该客户未结清。
下面的代码片段-3展示了判断合并后贷款是否结清的相关方法。
代码片段-3
S06:遍历贷款取得逾期期数与逾期金额。
在获取合并后贷款逾期期数时,当客户名下有多笔逾期贷款,即使某一个 月有多笔贷款都逾期的情况,但是合并后的一笔贷款仍应是只有一期逾期,不 可能存在报送一期但是逾期多期的情况;不过逾期金额则没有该限制,用户所 有应还而未还的钱都应该是逾期的金额。
按照所述原因,逾期期数取多笔贷款中逾期期数最高的一笔,而逾期金额 取多笔贷款的累加。
下面的代码片段-4阐述了取得合并贷款逾期期数和逾期金额的方法。
代码片段-4
S07:遍历贷款获取贷款报送状态。
这里的报送状态分别包括五级分类状态、账户状态和24月还款状态。
五级分类表示贷款的质量水平,贷款质量越差,越表示该客户/贷款需要被 关注,因此合并贷款的五级分类也是取质量最差一笔贷款的五级分类。
账户状态分别有正常、逾期、结清和呆账,呆账是指贷款逾期180天以上。 因为只有所有贷款都结清才表示客户结清,所以在遍历客户贷款后,如果账户 状态都是结清,合并后的贷款账户状态才会标识未结清;当客户的多笔贷款中 有至少1笔贷款呆账时,则对于合并后的贷款,仍然存在逾期180天以上的情 况,所以合并后应该报送呆账;逾期和呆账同理,如果没有呆账只有逾期时, 合并后贷款的账户状态标识未逾期;其他情况下则报送正常。
24月还款状态与账户状态类似,不同之处在于逾期的情况下,按照不同的 逾期时间会细分为七种状态类型,另外就是对于呆账的状态,会细分为“逾期6 个月以上”和“核销”状态,核销状态即指将这笔贷款记为损失。因此在对该 字段进行合并时方法与账户状态类似,全部结清时报送结清,有核销时报送核 销,没有核销而有逾期时报送逾期,其他情况报送正常。
下面的代码片段-5展示了取得合并后贷款五级分类、账户状态以及24月还 款状态的方法。
代码片段-5
S08:计算客户的应还金额和实还金额。
客户合并后的贷款都是以按月还款的模式进行征信报送的,即使客户名下 贷款的还款周期不规律,只要客户的应还金额和实还金额在合并时仍然按月取 值,并且每次取值的时间段不发生重复,那么合并报送后的应还金额与实还金 额还是符合按月还款的报送模式的。
因此,在本部长合并征信数据的应还金额和实还金额时,遍历客户名下贷 款的还款计划和还款信息,获取应还时间在上次报送日到本次报送日之间的数 据,累加应还金额就可以得到合并后的应还金额;以及获取还款时间在上次报 送日到本次报送日之间的数据,累加还款金额得到合并后的实还金额。
对于贷款已到期却仍未结清的贷款,那么因为没有应还日,则应还金额则 取的是到期贷款所有应还而未还的金额,但是实还金额仍与未到期贷款的计算 方法相同。
S09:遍历贷款得到逾期本金。
征信数据上报要求报送逾期用户在不同时期的逾期本金,因此在该步骤中, 会遍历客户名下所有贷款的还款计划,对于从应还时间到当前时间天数间隔在 31-60天、并且没有全部还清的还款计划数据,将应还的本金减去已还的本金, 便可以得到逾期31-60天的本金;与之类似的,可以用同样的方法计算得到逾期 61-90天本金、逾期91-180天本金和逾期180天以上本金。
S10:到这一步时,一位客户名下多笔贷款已经成功的合并成一笔贷款,先 将合并后的数据保存,待所有客户全部合并完成后统一由发送模块生成征信报 文并发送。
在保存合并后贷款信息时,同时会保存客户最新的账户状态数据,用于下 一次合并时的数据筛选:对于账户状态为核销的用户,只有再次发生还款才会 对贷款进行合并处理;对于账户状态为结清的客户,会等到下次有新贷款时合 并报送;而其他状态的贷款,则是每月至少合并报送一次。
姓名 | 张三 | 业务账号 | M123456 |
开户时间 | 2018/3/1 | 结束时间 | 2018/9/15 |
额度 | 10000 | 还款频率 | 按月还款 |
结算_应还款日期 | 2018/8/15 | 最近一次还款时间 | 2018/8/15 |
本月应还金额 | 1200 | 本月实还金额 | 900 |
当前逾期期数 | 1 | 当前逾期金额 | 300 |
逾期31-60天本金 | 0 | 逾期61-90天本金 | 0 |
逾期91-180天本金 | 0 | 逾期180天以上本金 | 0 |
五级分类状态 | 关注 | 账户状态 | 逾期 |
24月还款状态 | 逾期 |
表3-征信报送表
在征信数据合并完成后,就可以得到如表3所示的征信报送数据。
从而,本发明提及一种征信数据合并上报的方法和***,为每个客户设立 一个合并贷款账号,将用户名下所有还未结清或者当月结清的贷款信息合并为 一条贷款信息,为每个客户设定报送日,定期自动上报合并贷款信息。利用该 方法,即使客户在当月有多笔未结清的贷款,也只有一条征信报送记录,相比 原方法有效减少了用户的征信记录,提高了用户体验,也加快了每天征信处理 速度,有效减少了时间成本与人力成本。
虽然本发明已以较佳实施例揭露如上,然其并非用以限定本发明。本发明 所属技术领域中具有通常知识者,在不脱离本发明的精神和范围内,当可作各 种的更动与润饰。因此,本发明的保护范围当视权利要求书所界定者为准。
Claims (10)
1.一种征信数据合并上报的方法,其特征在于,所述方法包括以下步骤:
设置一上报周期,在一个上报周期内,所有用户均将发送至少一次征信报文至人行征信***,同时为每个用户设置一独有的上报征信数据至人行征信***的报送日;
在同一个上报周期内,按照一预设的采集周期从信贷***的数据库中自动抽取所有用户的信贷数据,抽取的信贷数据至少包括用户贷款数据、用户还款计划、用户还款数据;
响应于任意一个用户处于报送日,从该用户的信贷数据中提取出贷款信息,根据预设的规则合并贷款信息,将用户名下所有未结清和/或当前上报周期内结清的贷款信息合并成一条贷款信息,经处理后的信贷数据只包括一条征信报送记录;
将所述处理后的信贷数据转换成征信报文,校验后加密发送至人行征信***。
2.根据权利要求1所述的征信数据合并上报的方法,其特征在于,所述方法还包括:
在一个上报周期内,按照一预设的采集周期从信贷***的数据库中自动抽取所有用户的信贷数据,逐一提取用户的贷款信息,判断用户是否处于报送日:
1)响应于任意一个用户在本次采集周期内获取至少一笔贷款、并且在该采集周期之前无贷款或者贷款已全部结清,将当前时刻所处的日期作为该用户在这一上报周期的报送日;
2)响应于任意一个用户在本次采集周期之前存在未结清的贷款,将用户在本次上报周期内的所有未结清贷款中还款日最晚的一天定义成最晚计划还款日,采用该最晚计划还款日、和/或在本次上报周期内的实际还清日作为该用户在本次上报周期的报送日,该实际还清日不晚于该用户的最晚计划还款日。
3.根据权利要求1所述的征信数据合并上报的方法,其特征在于,所述方法还包括:
将一用户的每笔贷款数据分别存储至一单笔贷款账户内,一个单笔贷款账户对应该用户的其中一笔贷款;
为所述用户建立一合并贷款账户,将经合并处理后的信贷数据存储至该合并贷款账户,同时创建该用户的合并贷款账户与其所有单笔贷款账户的映射关系,以从合并贷款账户中直接链接至对应的单笔贷款账户。
4.根据权利要求1所述的征信数据合并上报的方法,其特征在于,所述方法还包括:
响应于任意一个用户名下的贷款全部撤销,将该用户的信贷数据标记为待补偿数据。
5.根据权利要求者4所述的征信数据合并上报的方法,其特征在于,所述方法还包括:
响应于任意一个用户在其名下贷款全部结清后又新申请了新的贷款,调取该用户的待补偿数据,并且按报送周期将这期间的征信记录补全,结合新的贷款信息,生成新的征信数据。
6.根据权利要求1所述的征信数据合并上报的方法,其特征在于,所述方法还包括:
定期提取在本次上报周期之前的两个上报周期的报送结果,如果第一个上报周期有报送且用户状态非结清或者核销、第二个上报周期没有报送,对该用户进行漏报判断。
7.根据权利要求1所述的征信数据合并上报的方法,其特征在于,所述方法还包括:
根据用户的还款能力为每笔贷款设定风险等级,按风险等级从小到大的顺序分别设定成正常、关注、次级、可疑以及损失;
选取用户名下风险等级最高的贷款的风险等级作为合并后征信数据的风险等级。
8.根据权利要求3所述的征信数据合并上报的方法,其特征在于,所述方法还包括:
为用户账户中的每笔贷款标定一还款状态,还款状态至少包括正常还款、结清、逾期、核销;
如果用户有逾期或核销的贷款,选取逾期情况最严重的一笔的状态作为合并贷款账户的还款状态,如果客户名下所有贷款全部是结清状态,将合并贷款账户的还款状态设定成结清,否则将合并贷款账户的还款状态设定成正常状态。
9.根据权利要求1-8任意一项中所述的征信数据合并上报的方法,其特征在于,所述方法还包括:
统计每个用户发送征信报文的总次数和贷款总金额、以及所有征信报文中逾期总次数和逾期总金额:
1)响应于任意一个用户的逾期次数超过一设定的逾期次数阈值、或者逾期金额超过一设定的逾期金额阈值,将该用户的信息存储至一黑名单数据库;
2)响应于任意一个无逾期记录的用户发送征信报文的总次数超出一设定的发送次数阈值、或者贷款总金额超出一设定的贷款金额阈值,将该用户的信息存储至一白名单数据库。
10.一种征信数据合并上报的***,其特征在于,所述***包括:
用于设置一上报周期和为每个用户设置一独有的上报征信数据至人行征信***的报送日的模块;
数据抽取模块,用于在同一个上报周期内,按照一预设的采集周期从信贷***的数据库中自动抽取所有用户的信贷数据的模块,抽取的信贷数据至少包括用户贷款数据、用户还款计划、用户还款数据;
数据合并模块,用于响应于任意一个用户处于报送日,从该用户的信贷数据中提取出贷款信息,根据预设的规则合并贷款信息,将用户名下所有未结清和/或当前上报周期内结清的贷款信息合并成一条贷款信息的模块,经处理后的信贷数据只包括一条征信报送记录;
发送模块,用于将所述处理后的信贷数据转换成征信报文,校验后加密发送至人行征信***的模块。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811176641.7A CN109670938B (zh) | 2018-10-10 | 2018-10-10 | 征信数据合并上报的方法和*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811176641.7A CN109670938B (zh) | 2018-10-10 | 2018-10-10 | 征信数据合并上报的方法和*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109670938A true CN109670938A (zh) | 2019-04-23 |
CN109670938B CN109670938B (zh) | 2021-02-12 |
Family
ID=66142639
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811176641.7A Active CN109670938B (zh) | 2018-10-10 | 2018-10-10 | 征信数据合并上报的方法和*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109670938B (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110503544A (zh) * | 2019-07-05 | 2019-11-26 | 招联消费金融有限公司 | 征信数据报送方法、装置、***、计算机设备和存储介质 |
CN110609829A (zh) * | 2019-08-15 | 2019-12-24 | 上海新颜人工智能科技有限公司 | 交易数据的清洗还原方法及*** |
CN111861629A (zh) * | 2020-05-24 | 2020-10-30 | 上海维信荟智金融科技有限公司 | 征信数据处理方法及*** |
CN112016851A (zh) * | 2020-09-14 | 2020-12-01 | 支付宝(杭州)信息技术有限公司 | 用于信息披露的管理方法以及装置 |
CN112632169A (zh) * | 2020-12-29 | 2021-04-09 | 永辉云金科技有限公司 | 一种金融数据自动上报方法、装置及计算机设备 |
CN112785411A (zh) * | 2020-12-29 | 2021-05-11 | 平安消费金融有限公司 | 征信数据处理方法、***、设备及计算机可读存储介质 |
CN113344699A (zh) * | 2021-06-30 | 2021-09-03 | 重庆富民银行股份有限公司 | 一种征信数据循环报送***及方法 |
CN113468131A (zh) * | 2021-07-14 | 2021-10-01 | 上海通联金融服务有限公司 | 商户收单流水的批量处理及多维度存储方法 |
CN117579723A (zh) * | 2023-11-22 | 2024-02-20 | 东亚银行(中国)有限公司 | 一种报文解析方法以及*** |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101510294A (zh) * | 2009-04-01 | 2009-08-19 | 吉贝克信息技术(北京)有限公司 | 企业信用评级中多个业务的状态信息合并处理***和方法 |
CN103886502A (zh) * | 2014-04-14 | 2014-06-25 | 中国人民银行征信中心 | 个人信贷信用状况采集整合方法 |
CN106022657A (zh) * | 2016-06-24 | 2016-10-12 | 深圳前海征信中心股份有限公司 | 信用风险的监控方法及装置 |
CN106611372A (zh) * | 2016-12-27 | 2017-05-03 | 深圳微众税银信息服务有限公司 | 一种征信数据查询方法及*** |
CN107292444A (zh) * | 2017-06-28 | 2017-10-24 | 宁波三星医疗电气股份有限公司 | 一种预付费电能表***以及电能表预付费方法 |
CN107749031A (zh) * | 2017-11-29 | 2018-03-02 | 南京甄视智能科技有限公司 | 贷后风险控制***的自动更新方法、贷后风险控制*** |
-
2018
- 2018-10-10 CN CN201811176641.7A patent/CN109670938B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101510294A (zh) * | 2009-04-01 | 2009-08-19 | 吉贝克信息技术(北京)有限公司 | 企业信用评级中多个业务的状态信息合并处理***和方法 |
CN103886502A (zh) * | 2014-04-14 | 2014-06-25 | 中国人民银行征信中心 | 个人信贷信用状况采集整合方法 |
CN106022657A (zh) * | 2016-06-24 | 2016-10-12 | 深圳前海征信中心股份有限公司 | 信用风险的监控方法及装置 |
CN106611372A (zh) * | 2016-12-27 | 2017-05-03 | 深圳微众税银信息服务有限公司 | 一种征信数据查询方法及*** |
CN107292444A (zh) * | 2017-06-28 | 2017-10-24 | 宁波三星医疗电气股份有限公司 | 一种预付费电能表***以及电能表预付费方法 |
CN107749031A (zh) * | 2017-11-29 | 2018-03-02 | 南京甄视智能科技有限公司 | 贷后风险控制***的自动更新方法、贷后风险控制*** |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110503544A (zh) * | 2019-07-05 | 2019-11-26 | 招联消费金融有限公司 | 征信数据报送方法、装置、***、计算机设备和存储介质 |
CN110609829A (zh) * | 2019-08-15 | 2019-12-24 | 上海新颜人工智能科技有限公司 | 交易数据的清洗还原方法及*** |
CN110609829B (zh) * | 2019-08-15 | 2023-11-14 | 上海新颜人工智能科技有限公司 | 交易数据的清洗还原方法及*** |
CN111861629A (zh) * | 2020-05-24 | 2020-10-30 | 上海维信荟智金融科技有限公司 | 征信数据处理方法及*** |
CN112016851A (zh) * | 2020-09-14 | 2020-12-01 | 支付宝(杭州)信息技术有限公司 | 用于信息披露的管理方法以及装置 |
CN112016851B (zh) * | 2020-09-14 | 2022-11-08 | 支付宝(杭州)信息技术有限公司 | 用于信息披露的管理方法以及装置 |
CN112632169A (zh) * | 2020-12-29 | 2021-04-09 | 永辉云金科技有限公司 | 一种金融数据自动上报方法、装置及计算机设备 |
CN112785411A (zh) * | 2020-12-29 | 2021-05-11 | 平安消费金融有限公司 | 征信数据处理方法、***、设备及计算机可读存储介质 |
CN112785411B (zh) * | 2020-12-29 | 2024-07-12 | 平安消费金融有限公司 | 征信数据处理方法、***、设备及计算机可读存储介质 |
CN113344699A (zh) * | 2021-06-30 | 2021-09-03 | 重庆富民银行股份有限公司 | 一种征信数据循环报送***及方法 |
CN113468131A (zh) * | 2021-07-14 | 2021-10-01 | 上海通联金融服务有限公司 | 商户收单流水的批量处理及多维度存储方法 |
CN117579723A (zh) * | 2023-11-22 | 2024-02-20 | 东亚银行(中国)有限公司 | 一种报文解析方法以及*** |
Also Published As
Publication number | Publication date |
---|---|
CN109670938B (zh) | 2021-02-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109670938A (zh) | 征信数据合并上报的方法和*** | |
US8843939B2 (en) | Computer architecture and process for application processing engine | |
Kaka | Covid-19 and auditing | |
US20060041505A1 (en) | Fee-based message delivery system | |
US20150019303A1 (en) | Data quality integration | |
CN1831864A (zh) | 事务风险监控***以及管理服务器 | |
Mahmood et al. | Adaptive automated teller machines | |
Chu et al. | Incremental analysis of the reengineering of an outpatient billing process: an empirical study in a public hospital | |
CN111708897A (zh) | 目标信息确定方法、装置和设备 | |
US20110161215A1 (en) | Method and System for Tracking Billing Information | |
CN111652716B (zh) | 首贷户标签确定方法及装置 | |
CN109919667A (zh) | 一种用于识别企业ip的方法和装置 | |
WO2018205716A1 (zh) | 一种管理用户账号的方法及装置 | |
CN111752662A (zh) | 银行交易界面展示方法及装置 | |
KR101500832B1 (ko) | 원천징수 대행 방법 및 이를 실행하는 시스템 | |
CN117094764A (zh) | 银行积分处理方法及装置 | |
CN113962817B (zh) | 异常人员识别方法及装置、电子设备和存储介质 | |
CN115713406A (zh) | 一种基于图技术识别信贷资金违规问题的方法及装置 | |
US8484106B1 (en) | Opt-out payroll | |
CN114170741A (zh) | 交易效率监控方法、atm前置***和自助业务控管*** | |
CN107798593B (zh) | 财务数据的处理方法、装置、介质及电子设备 | |
CN111626703A (zh) | 基于条目式的记事记账计数计件项目管理*** | |
Bing | A study of state educational loan demand diversity and its influencing paths–An empirical analysis based on SEM model | |
Putri et al. | The Effect of Perceived of Ease, Perceived of Benefits and Perceived of Risk to Decisions on Use of Mobile Banking Students of the State University of Jakarta | |
CN115345728B (zh) | 一种结算计息结息的方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CP01 | Change in the name or title of a patent holder | ||
CP01 | Change in the name or title of a patent holder |
Address after: No.88, Huaihai Road, Qinhuai District, Nanjing City, Jiangsu Province, 210000 Patentee after: Nanyin Faba Consumer Finance Co.,Ltd. Address before: No.88, Huaihai Road, Qinhuai District, Nanjing City, Jiangsu Province, 210000 Patentee before: SUNING CONSUMER FINANCE Co.,Ltd. |