CN104145290A - 用于小额信贷信用数据处理和报告的系统和方法 - Google Patents

Abstract

本发明提供了用于处理与小额信贷有关的信用数据并且基于处理过的小额信贷信用数据生成信用报告的系统和方法。在一些实施方案中，信用报告/评分生成系统130根据相关数据规则模块132A、显示规则模块132B以及其它相关报告格式信息生成小额信贷信用报告。支付状态可以针对支付网格中的每个条目进行确定，其可对应于支付间隔，例如像按日、按周或按月。信用报告可用可选选项生成，可选选项使得用户能够查看至少一个其它支付网格，所述至少一个其它支付网格具有对应于不同支付间隔的条目。

Description

用于小额信贷信用数据处理和报告的系统和方法

有限版权授权

本专利文件的公开的一部分包括受版权保护的材料。版权所有者不反对由任何人以专利文件或专利公开出现在美国专利与商标局专利文档或记录中的形式复制所述专利文件或专利公开，但是另外保留任何所有版权权利。

本公开的背景

本公开的领域

除了其它之外，本公开描述了用于处理从多个数据源接收到的小额信贷信用数据以及其它数据并且基于处理过的数据提供信用相关产品以及其它产品的系统和方法。

相关技术描述

小额信贷是由不同类型服务提供方向低收入的客户提供的如贷款、保险等等之类的金融服务的提供。小额信贷借方被约束成按照支付周期向债权人进行小额支付，这可要求按日或按周为间隔进行支付，替代更传统的按月支付周期。

信用数据可由征信局或类似实体维护。通过给定征信局维护的信用数据可以包括数百万或甚至数十亿顾客的账户数据，其中标识在数据中的每个顾客可以具有一个或多个账户。信用数据可以基于包括现有交易数据、新的交易数据、问询、公共记录数据(例如，破产申请)、地址数据改变等等的若干数据源。常见类型的信用数据是“交易行列数据(tradeline data)”(或者说是交易数据)。交易行列数据可以是授信方取得信用报告机构所维护的消费者信用历史记录的条目。交易行列描述消费者账户状态以及活动，并且可以包括申请人账户所在公司的名称、开户日期、信用限额、账户类型、账户余额、支付历史和/或其它数据。

例如，在美国，多个征信局是不断地从包括(例如)银行、债权人以及其它账户提供方的大量数据源接收数据。除了其它之外，征信局会使用数据以向消费者或企业提供信用报告、信用评分以及其它信用相关产品或服务。给定征信局的系统通常根据该局运营所在国家或地区的特定的法律和业务要求以及其顾客的需要进行定制，这可能已经过长时间段演进。

当前，典型征信局的系统不易适用于符合报告小额信贷数据需要。

附图简述

结合附图参考以下详细描述，可更好地理解前述方面以及许多伴随优点，因此同样将更易于了解所述方面以及优点，在附图中：

图1示出用于维护从各个数据源接收到的信用数据并且向消费者和订户提供小额信贷信用相关产品的说明性操作环境中的数据流的一个实施方案。

图2是示出接收、处理、分类、验证以及加载小额信贷信用数据的过程的流程图。

图3是示出针对小额信贷数据生成用户界面的过程的流程图。

图4示出用于处理信用数据的系统的一个实施方案。

图5是可以生成并呈现给用户的用户界面的说明性实施方案。所述用户界面示出信用报告的按月查看的一个实施方案。

图6是可以生成并呈现给用户的用户界面的说明性实施方案。所述用户界面示出信用报告的按日查看的一个实施方案。

图7是可以生成并呈现给用户的用户界面的说明性实施方案。所述用户界面示出信用报告的按周查看的一个实施方案。

图8是让用户来自定义用于信用报告的支付网格的用户界面的说明性实施方案。

图9是让用户设置用于特定账户的默认支付网格的用户界面的说明性实施方案。

具体实施方式

除了其它之外，典型征信局会不易适用于处理小额信贷数据需要的一个原因是典型传统征信局的计算系统可被配置成以按月为基础(如假定以30天支付周期)针对各种账户类型处理并且存储账户状态信息，即使维护给定账户的金融实体实际上会对账户户主强加不同支付义务。例如，假设小额信贷贷方会向给定借方强加按周支付义务。在特定月，假设借方欠了四笔$50.00付款，它们各自要在该月每周周末支付。假设借方实际上在该月仅仅进行两次支付，一次是在第一周的周末支付$25.00，并且一次是在第四周的周末支付$175.00。基于从贷方接收的信息，计算系统将会生成静态报告，指明借方已在给定的月按照协定付账，因为账户余额截至月末已被支付(截至月末，借方在该月的$200.00的总付款等于该月期间所欠$200.00的总余额)。这个按月报告条目将向报告的查看者提供误导信息，因为其将呈现的是借方已在该月期间按照协定进行支付，而实际上，借方在给定月较迟进行多次按周支付。因此，未来潜在贷方将被提供不准确的借方支付历史指示，这降低了尝试评估个体信用价值的贷方或债权人的信用报告的实用性。

许多技术问题在考虑到以下的情况时将被引起：实现信用报告系统，所述信用报告系统能以提供准确查看带有在账户和/或贷方之间不同的非传统支付义务和/或可变支付周期长度的账户的支付历史信息的方式来报告账户信息。例如，现有的征信局计算系统包括已经通过“硬编码”各种数据处理和数据存储特征来预配置用于特定功能性的遗留系统。因此，此类现有系统所生成的报告可能要求输入将以特定预期格式来从金融机构接收的数据，并且任何所生成的支付状态信息能以包含与从金融机构接收到的数据匹配的按月条目的静态报告输出。此类计算系统并未使用能够易于基于新的监管规则和/或业务需要进行更改或向其添加的灵活框架构建。此外，此类计算系统未配备成结合这样的规则来工作：所述规则可以响应于用户对特定数据格式化的改变的请求或对查看各种类型导出数据的请求而实时应用或以其它方式动态应用。

系统、方法、过程以及数据结构的各实施方案现将参照附图进行描述。也将描述表示其它实施方案的系统、方法、过程以及数据结构的变体。在本文中描述了系统、方法、过程以及数据结构的某些方面、优点以及新颖特征。应当理解，根据任何具体实施方案未必可以实现所有此类优点。因此，系统、方法、过程以及数据结构可以通过某种方式具体化或实行，这种方式实现如本文中所教导的一个优点或一组优点而未必实现如本文中可能教导或提出的其它优点。

一般来说，本公开的方面涉及使得维护信用数据的征信局或者其它实体能够接收、处理并且报告小额信贷信用数据的系统和方法。因为可以使用不同于传统信用报告中使用的通常支付周期的支付周期报告小额信贷信用数据，以及一个或多个以上提及的原因，所以传统信用报告系统并未经过良好调整来收集、处理或报告小额信贷信用数据。此外，征信局和其它实体可能需要基于不同报告需要调整信用账户支付间隔。根据本公开的方面，出于各种信用处理和报告的目的，可以使用若干不同支付间隔显示单个小额信贷信用账户。根据一些实施方案，征信局或其它实体可以使用一种以上的方法来基于支付间隔、报告周期、客户需要和/或其它准则确定小额信贷信用账户上的拖欠。

如本文中论述，本公开的方面包括信用报告系统。信用报告系统可以包括被配置成存储多个记录的数据库，其中所述多个记录可以包括与多个账户中的每个关联的信用数据。数据库可被配置成存储包括账户与多个支付间隔关联的支付状态信息的信用数据。信用报告系统也可包括可以被配置与数据库进行电子通信的信用报告生成系统。信用报告系统可以包括报告模块。报告模块可以被配置成接收标识应当生成信用报告的第一个体的报告请求指示。报告模块可进一步被配置成从数据库检索与个体关联的信用数据，其中检索到的信用数据可包括与个体的第一金融账户关联的支付状态信息。报告模块可以确定呈现检索到的信用数据的第一支付网格中的每个条目的支付状态。第一支付网格可以具有对应于第一支付间隔的条目。第一支付间隔可以包括按日、按周以及按月中的一个。报告模块可以确定呈现检索到的信用数据的第二支付网格中的每个条目的支付状态。第二支付网格可以具有对应于不同于第一支付间隔的第二支付间隔的条目。第二支付间隔可以包括按日、按周以及按月中的一个。信用报告生成系统也可包括用户界面模块，所述用户界面模块可以被配置成呈现包括可以具有对应于第一支付间隔的条目的第一支付网格的信用报告。信用报告可以包括至少一个可选选项，所述至少一个可选选项使得用户能够查看第二支付网格，所述第二支付网格具有对应于第二支付间隔的条目。响应于用户选择至少一个可选选项，用户界面模块可以呈现第二支付网格，所述第二支付网格具有对应于第二支付间隔的条目。

示例信用报告环境和数据流

图1示出用于维护从各个数据源接收到的小额信贷信用数据和其它数据并且向消费者和订户(如征信局操作人员，银行中的操作人员和决策者或做出信用和/或贷款相关决策的其它金融机构)提供信用相关产品的说明性操作环境100中的架构和总体数据流的一个实施方案。

数据供方102、104以及106可以包括传统借贷机构，如银行、信用社、大型企业和/或抵押公司。由于小额信贷信用数据的独特性，数据供方也可包括非传统的贷方，如个体、发薪日贷款提供方或小型企业。

如图所示，说明性操作环境100包括信息管理系统110和信用报告生成系统130。信息管理系统110从各种数据供方接收小额信贷信用数据。信用报告生成系统130与信息管理系统110通信以处理并且报告小额信贷信用数据。信用报告生成系统130也可以向订户(如征信局、贷方、各种账户或服务提供方和/或数据供方)提供信用报告和/或其它输出。

在某些实施方案中，信息管理系统110和信用报告生成系统130可由征信局或类似实体共同操作，以便接收、处理、维护和/或分析信用数据及与消费者和企业相关的其它类型数据，包括基于处理过的数据生成产品，如信用报告和信用评分。图1中示出的组件各自可以基于特定操作人员的具体需求来配置。在一些实施方案中，说明性操作环境100中示出的每个系统和/或模块可以负责实现某些特征，以便给定组件、系统和/或模块可与替换或修改过的组件、系统或模块调换，而不影响整个操作环境性能或不要求对其它组件、系统或模块进行改变。在一些实施方案中，征信局或类似实体能以与名称为“Systems and Methods for Large-Scale Credit Data Processing”的美国专利申请号13/546965中描述的方式类似的方式接收、加载、处理和/或存储数据，这个专利申请在此全文以引用的方式并入本文。说明性操作环境100中的各种组件以下更详细地描述，随后，描述图1中示出的总体数据流。

信息管理系统

在一些实施方案中，信息管理系统110可以被配置为加载并且处理从各个数据供方或数据源(包括小额信贷信用数据的源)接收的高容量的信用数据(包括小额信贷信用数据)。在一些实施方案中，来自多个源的信用数据可以并行处理并加载到数据库118，而不影响信用报告生成系统130的性能。信息管理系统110可以实现水平缩放，其中各种数据条目可以先于其它数据处理任务或与其它数据处理任务并行地来实时或接近于实时匹配个体标识符、企业标识符或其它实体标识符。

数据一致性可例如通过以下方式维持：将如交易、公共记录以及实体对象(如名称、地址和/或其它数据条目)之类的事务对象组合成带有灵活格式化要求的单个数据对象。在一些实施方案中，数据对象可存储在动态、长度可变对象结构之中。因此，信息管理系统110可以将数据组合和/或结合在一起，并且可以基于创建出的数据对象来以事务模式处理数据。例如，每个记录或数据条目可作为离散事务进行处理，其中事务各自可以独立地与其它事务并行处理，或者可与其它记录分批处理，这取决于实施方案。在一些实施方案中，信息管理系统可以提供适配框架，所述适配框架可以易于修改或扩展以接受并且处理不同类型数据，尤其是可能并非按月报告的小额信贷数据。例如，规则和/或定义可以相对特定数据类型、数据字段、数据源和/或其它数据元素或关联来识别或定义。

如图所示，信息管理系统110包括数据准备模块112、数据加载模块114、数据检索模块116以及数据库118。数据准备模块112可以准备待加载到数据库118中的接收到的数据。例如，数据准备模块112可以重新格式化数据、删除重复数据、解析数据、验证输入和/或分割数据。在其它实施方案中，数据准备模块112可以准备并且接收待加载到以下系统中的数据：主要数据系统或一般以可供用于生成信用报告、信用评分和/或利用存储数据的其它产品的形式来维护处理过的数据的其它处理系统。在其它实施方案中，信息管理系统110处理数据的此类维护和处理。

在一些实施方案中，小额信贷信用数据可以使用并非常规信用数据数据格式之一的格式从数据供方来报告给信息管理系统110。根据本发明的一些方面，数据准备模块112可以执行数据准备功能以便将从数据供方102、104以及106接收到的小额信贷信用数据转换成现有信用报告文件格式或新的文件格式。在一些实施方案中，数据准备模块112可以接收来自数据供方102的输入小额信贷信用数据文件，并且检测接收到的文档类型以及通常从数据供方接收的文档类型。例如，如果小额信贷信用数据供方102通常发送以特定电子数据表单文件格式的小额信贷信用数据，那么数据准备模块112可以检索配置成将接收到的电子数据表单文件转换成标准格式以进一步处理并加载的文件转换功能、规则集合或规范。在另一实例中，如果数据准备模块112第一次从数据供方106接收新的小额信贷信用数据文件，并且文件是以XML格式，那么数据准备模块112可以使用不同的解析和分析功能准备接收到的数据以进一步处理。

在另一实例中，数据准备模块112可以接收小额信贷数据文件并且分析所述文件以便确定如何将所述文件转换成现有信用数据报告格式之一，如消费者信用账户(CCA)或企业信用账户(BCA)通用信用报告格式或设计成适应非传统的信用数据的专有数据格式。在一些情况中，接收到的数据可能不以任何先前已知文件格式，并且处理此类小额信贷信用数据可能要求基于机器学习或人工智能的数据识别处理工具。此外，如果数据准备模块112确定存在需要定义以便捕获与小额信贷信用报告相关的信息的新字段，那么数据准备可以创建新的数据字段。在一些实施方案中，数据准备模块112可以被配置成处理各种输入文件格式并且适应小额信贷信用数据的独特特征，以使针对给定输入数据集合而存储的特定格式化和数据字段可取决于给定实例中接收的数据类型。

数据加载模块114可以在将数据存储到数据库118中时提取数据、加载数据、执行Δ操作(delta operation)、匹配数据、清理数据和/或执行加载验证。重新格式化数据可以包括将由数据准备模块112接收到并准备好的数据转换成能由本文所述各种组件存储并处理的数据字段。例如，数据能以一个或多个国家的规章制度所指定的格式作为标准信用数据格式由数据准备模块112接收并处理成为数据加载模块114可读出的文件格式。数据加载模块114可进一步重新格式化数据成为易于处理、存储并且进行信用报告的专有格式或其它通用格式。数据加载模块114可以执行匹配，所述匹配可以包括标识数据中的每个记录并将每个记录(直接或间接地)匹配唯一标识个体、企业或者其它实体。例如，如果小额信贷信用数据是与个体相关，并且提供了个体的社会保障号码、地址以及出生数据，那么数据加载模块114可将这些数据字段匹配信用数据的现有数据库，该数据库可以包含过去信用报告以及这个特定个体相关的其它记录。在一些实施方案中，如果匹配失败，那么数据加载模块114可以搜索其它数据库以看看可否使用替代地址找到接收到的数据中的个体等等。在一些实施方案中，如果针对个体定位先前所存储的记录而做出的努力已经全部失败，那么数据加载模块114可以返回错误并向数据供方提供反馈以对接收到的数据进行可能校正。在其它实施方案中，数据加载模块114可为新的个体创建数据记录，这可例如在接收针对先前未接受过传统贷款或其它信贷的个体的小额信贷信用数据的情况下发生。

如将了解，基于接收到的小额信贷信用数据的各种特征和对报告的不同需要，数据准备模块112和数据加载模块114可组合成单个模块和/或各自可以执行对特征的不同组合，这取决于实施方案。

根据某些实施方案，信息管理系统110可以执行小额信贷信用数据加载和/或处理以及数据质量控制。例如，当数据供方102、104以及106中的每个将数据发送到信息管理系统110以供处理并且存储时，信息管理系统110可以确定所述数据是否有效或其是否超出针对特定数据供方来建立的限定质量阈值。例如，在一些实施方案中，信息管理系统110可以确定从某个数据供方104接收的小额信贷信用数据质量较差。例如，重要字段(如借方的标识信息)可能丢失，以使信息管理系统110没有足够的信息来确信地将数据与账户或个体关联。在另一实例中，接收到的数据对于有意义的报告而言可能太过零散。在此类情况中，信息管理系统可以将数据标记为低质量的，或要求来自数据供方104的进一步输入。在一些实施方案中，信息管理系统110仍可存储低质量的小额信贷信用数据，从而任选地存储置信度指示符，所述置信度指示符指明数据应被信任用于确定信用评分或用于其它信用报告目的的程度(例如，低质量的数据可在某些计算中权重降低，或可完全不做考虑)。

在一些实施方案中，本公开的方面可以实现通常并不与征信局联合进行存储或报告的许多不同替代数据类型的处理和报告。因此，在一些此类实施方案中，多个数据格式可被接受并且重新格式化成为标准格式，以便待加载并使其可用于报告目的、评分目的和/或其它用途。在一些实施方案中，可被加载、处理、存储并报告的一些数据类型可以包括汽车数据、资产数据、保险数据、婚姻数据、出生数据、死亡数据、犯罪数据、交通数据、租赁数据、社交联网数据、许可证数据(如专门的许可证或渔业和狩猎许可证)、公共设施数据、宠物登记数据和/或政府叛徒数据。在一些实施方案中，各种类型接收到的数据可与信用数据分开存储，并且可以与共同或关联实体(如也与信用数据关联的个人和/或企业)关联。一旦这些替代数据类型被局限于个人，例如，它们就可用于生成一个或多个信用报告、评分和/或与个人相关的其它产品。举例而言，可能生成用于个体的信用报告或其它产品，包括与此人登记的汽车和船只有关的信息、局限于此人的保险政策(或以他们自己名义或在列为担保人时)、此人犯罪定罪历史、此人的租赁历史、与个体关联的财产信息、个人支付趋势以及与公共事业公司的支付历史和/或与个体所拥有的宠物有关的信息。系统可以包括用于包括作为信用报告过程的一部分的替代数据类型的特征，以及用于抑制或排除无法用于任何报告和/或无法在无必要权限的情况下来使用的替代数据类型的规则系统。

信用报告生成系统

在一个实施方案中，信用报告生成系统130通常可以使得如消费者150和订户152之类的用户能够定义利用小额信贷信用数据的自定义小额信贷信用报告。基于针对给定消费者或商品的产品规范，并考虑到信用报告/评分生成系统所维护的规则，信用报告/评分生成系统可以生成信用报告并将已生成的报告递送给消费者。在一些实施方案中，信用报告/评分生成系统可以使得大量客户能够进行同时访问并可基于给定征信局或其它操作人员的业务需要来线性缩放。

信用报告生成系统130可以允许用户自定义各种显示和报告选项，如对各种支付间隔的支付网格自定义、分配默认支付网格、选择一个以上的支付网格和/或以下进一步描述的其它选项。此灵活性允许贷方易于显示与小额信贷信用账户相关的信用报告并且相应作出借贷决策。它也允许借方(可以包括小企业主)基于非传统的贷款以及报告周期构建信用历史。信用报告生成系统130也可存储一个以上的规则集合以供确定某个特定时间段期间与小额信贷信用账户相关的拖欠状态。例如，根据小额信贷数据报告频繁程度，拖欠状态可在选择不同支付间隔时不同地确定。

如图1所示，信用报告/评分生成系统130包括规则模块132，所述规则模块132包括数据规则模块132A以及显示规则模块132B。规则模块132可在生成小额信贷信用报告、确定拖欠状态时和/或响应于来自用户的问询时检索并且应用存储在规则数据存储140中的规则数据。数据规则通常可以限定哪些数据类型、数据字段和/或数据群组(也被称为数据带)可供用于潜在地访问或包括在小额信贷信用报告之中，以及什么数据类型、数据字段和/或数据群组是要求的。

在一些实施方案中，数据规则也可通过信用报告生成系统的操作人员和/或通过请求信用报告的用户(例如像金融机构的操作人员)自定义以限定针对小额信贷信用数据如何计算拖欠计数器、哪些支付网格针对账户进行预先计算和/或哪个支付网格针对账户被设置为默认支付网格。拖欠计数器通常可以指示在给定时间段账户已多少次被报道为拖欠。在一些实施方案中，数据规则也可以自定义以允许局操作人员或其它实体建立规则用于限定什么级别的细节要包括在小额信贷信用报告中以及小额信贷信用报告的布局和结构。信用报告/评分生成系统130的规则模块132提供的灵活规则集合框架可以提供优于一些传统遗留信用报告系统的“硬编码”或以其它方式静态确定支付状态方法的一个或多个优点。例如，信用报告/评分生成系统130实现或应用的规则可以使得系统130所提供的各种功能能够基于相对最小规则添加或修改进行改变或调整，而非做出一些传统遗留信用报告系统可能会要求的大范围的系统改变。另外，规则模块132所实现的规则可以使得信用报告/评分生成系统130能够响应于从消费者接收到的请求而动态决定要包括在用户界面或报告中的支付状态或其它信息。在一些实施方案中，这些动态确定可以响应于用户与动态地生成的报告交互而实时或接近于实时做出，然而，传统信用报告系统通常存储稍后包括在提供给消费者的静态报告中的预处理的支付状态信息。

显示规则通常可以限定这些潜在可用数据类型、数据字段和/或数据带中的哪些可获取以相对特定账户进行显示，并且限定哪些支付网格将要针对特定账户显示。显示规则可在由征信局操作人员或其它实体问询时设置，可以跨越账户(如对银行所有用户)提前设置，可以针对特定订户或订户组(如小额信贷信用报告服务的银行订户，所述银行订户落在特定的顾客子集之中)提前设置。举例而言，银行的副经理可比银行抵押账户代表访问更多数据类型、数据字段和/或数据带。存储在规则数据存储140中的数据规则和/或显示规则可以包括根本规章制度或符合性规则(如与当在给定区域中提供信用数据时必须包括的数据字段有关的法律要求)、账户级别规则和/或用户级别规则。如将了解，存储在规则数据存储140中的根本规章制度或符合性规则可以基于征信局运营所在的给定管辖区域中的法律要求上的任何改变进行动态调整，以便使得新的或修改的报告功能可被引入。举例而言，根据一个实施方案，规则模块132可以提供对不同数据类型的访问。征信局操作人员或其它用户可对给定信用报告限定格式，其方法是选择任选的可用数据规则和显示规则的至少一个子集。征信局操作人员或其它用户也可限定将在信用报告上显示的一个或多个支付网格，其可包括或可不包括传统按月支付网格。征信局操作人员或其它用户也可使用所提供的用户界面限定特定支付间隔的长度。用户界面模块134可与规则模块132通信，以便确定特定区域、账户或用户类型的可用数据和/或所要求的数据。用户界面模块134另外可与报告模块136通信，以便确定可用报告选项，如支付网格、递送考虑等等。报告数据存储142可以存储小额信贷信用报告规范信息，包括账户特定产品、预定义的小额信贷信用报告模板、一个或多个先前定义的报告格式、活动模板、公共信用问询等等。

示例数据流

如上所述，图1示出说明性操作环境100的总体数据流的一个实施方案。说明性数据流开始于数据供方102、104以及106中的每个将小额信贷信用数据发送到信息管理系统110。来自每个数据供方的小额信贷信用数据可在不同时间接收，或可同时接收。如上讨论，小额信贷信用数据可以包括种类繁多的格式和类型。例如，从数据供方102接收的小额信贷信用数据可以包括按周为基础的支付状态信息(例如，每个账户在每周周末是当前到期还是逾期)，而从数据供方104接收的小额信贷信用数据可以包括基于10天支付周期的支付状态信息。信息管理系统110可能能够对各种格式和类型进行处理并且重新格式化。

在说明性数据流中，信息管理系统110并行预处理从各种数据供方接收到的小额信贷数据集合。以上更详细地描述以及以下参照图2描述数据的预处理以及处理(包括生成警告并且跟踪量度)。与数据加载和/或处理以及数据质量有关的量度可存储在数据库118和/或单独量度数据库中。信息管理系统110可以包括数据准备模块112，所述数据准备模块112可以重新格式化接收到的小额信贷信用数据、删除其中的重复数据并对接收到的小额信贷信用数据进行解析。信息管理系统110也可包括数据加载模块114，所述数据加载模块114可进一步处理小额信贷信用数据、使得数据匹配数据字段并且将数据加载到数据库中。信息管理系统110也可包括数据检索模块116，所述数据检索模块116可以用来查询现有数据库118并存储小额信贷信用数据。数据检索模块116也可用于至少部分基于用户和/或系统生成的查询来检索信用数据。在其它实施方案中，查询、存储和/或检索可由数据加载模块114处理。

在所示实施方案中，一旦信用报告/评分生成系统130接收小额信贷信用数据，所述信用报告/评分生成系统130就根据相关数据规则132A、显示规则132B以及其它相关报告格式信息生成小额信贷信用报告。可以建立各种规则以便允许小额信贷信用报告的灵活性。例如，对于每个小额信贷信用账户，可以关于如何确定拖欠、默认和/或可用支付隔、报告默认支付网格和/或其它规则来确定并且存储规则。随后，已生成的信用报告可被提供给一个或多个相关客户，如消费者150、订户152和/或数据供方106。以下更详细地讨论用于数据处理的说明性方法以及用于显示并且自定义信用报告的用户界面。

与传入数据文件有关的示例方法

图2是由用于接收并且处理信用数据和/或从各个数据源接收到的其它数据的信息管理系统110实现的方法200的一个实施方案的流程图。方法200开始于块202，其中信息管理系统110从一个或多个数据源或数据供方接收数据。如上讨论，接收到的小额信贷信用数据可以包括消费者数据、企业数据、账户历史、财务报表、公共记录、保险信息、车辆记录、租赁信息、财产信息、小额信贷数据和/或其它类型数据。接收到的数据可以包括(例如)通过金融实体或其它账户提供方提交给信息管理系统110的数据，所述数据将包括在许多消费者和/或企业(数据供方为其维护账户)的信用文件之中。在一些实施方案中，数据可以包括信息管理系统110特别从如公共记录数据源之类的一个或多个数据源请求到的数据。数据也可包括可直接地或间接地链接到或联系到消费者和/或企业的非信用数据。

例如，小额信贷信用数据可以包括支付方法，所述支付方法包括以非货币形式的支付。它也可以包括在一段时间内首先通过非货币物品进行并随后以货币支付替代的支付。例如，制造手工编织筐的小型企业是由一系列的小额信贷提供资金。支付通常按周进行。然而，在低价销售周期间，一些筐被用作支付方法，而在销售增加并且资金可用时，筐可返回给小型企业以作为对定期支付的交换。元数据可以与小额信贷信用数据相关联地存储，其包括用于小额信贷事务的特定用途(如帮助老人或伤残人员)以及长于特定账户或账户群组的通常情况的支付宽限期。在一些实施方案中，在生成信用报告时，信用报告生成系统可考虑到存储的元数据的至少一部分。在一些实施方案中，接收到的数据能以已知文件格式如CCA、BCA等等表示。在其它情况中，接收到的数据能以信用报告不常用的文件格式如纯文本、用户定义的文件格式等等表示。

方法200前进至块204，其中信息管理系统110处理从每个数据源或供方接收的数据。在一些实施方案中，信息管理系统110首先可将数据存储在本地缓存中。在一些其它实施方案中，信息管理系统110可将数据直接存储在如数据库118之类的数据库中。

块204处执行的数据处理可以包括处理数据以便定位标识个体、企业或其它实体的信息。数据处理可以包括计算个体、企业或与接收到的数据关联的其它实体的实际支付周期。数据处理可以包括为了报告和分析而基于接收到的数据中的实际支付周期选择适合于账户的支付间隔。例如，根据一个实施方案，如果从小额信贷借贷机构接收的数据表明，对于给定借方，实际支付周期大多数的时候为约每2至3天，那么可选择为那个账户的默认支付间隔的支付间隔可为每3天。在另一实例中，根据一个实施方案，如果根据接收到的信用数据来确定的实际支付周期是从4天至2周的任何点开始计算，那么信息管理系统110可以针对那个账户选择默认支付间隔为7天。

数据处理也可包括至少部分基于数据源、数据类型、支付间隔、元数据和/或其它接收到的信息将相关数据标识为小额信贷信用数据。例如，接收到的信用数据可以至少部分基于确定数据包括非传统的信用数据文件、用户定义的信用数据字段或数据类型、并非30天或按月的实际支付周期、将账户标识为小额信贷信用账户的元数据和/或其它指示符而确定为小额信贷信用数据。数据可以通过解析接收到的数据或通过解析与接收到的数据或数据文件关联的元数据找到。在一些情况中，某些贷方(如与特定区域中的低收入顾客工作的一些组织)可以被标记为潜在小额信贷信用数据提供方并且从此类供方所提供的数据可以被假定为与小额信贷相关的。

块204处执行的数据处理可以包括重新格式化数据，如将接收到的小额信贷信用数据从各种数据格式转换成单个通用或专用的格式。数据处理可以至少部分基于与频繁使用的格式有关的信息和存储在信息管理系统110中的处理例程实现。例如，如果信息管理系统110通常以某个方式或使用某个例程处理从数据供方接收的数据，那么从那个供方接收的数据可以首先使用那个例程进行处理。然而，在新的格式或未知格式和/或从新的供方接收的数据的情况中，信息管理系统110可以至少部分基于分析接收到的小额信贷信用数据文件内的标识出的数据字段和/或数据结构而来解析和/或变换数据。可以执行此类数据变换，例如，因为从某些数据供方、尤其是小型贷方接收的小额信贷数据可呈非传统的格式。

例如，根据一个实施方案，如果文件格式对于信息管理系统110而言是未知的，那么所述系统可以实现基于机器学习或人工智能的数据处理以便执行数据分析、分类和/或将数据匹配到数据字段之中。完成预处理后，信息管理系统110可以存储数据字段位置，并且随后准备数据以进一步处理。信息管理系统110也可使用与识别出的数据字段相关的信息来将接收到的数据从未知格式转换成一个或多个已知的格式。

在另一使用情况中，低质量的数据可从数据供方接收。质量可能较差，因为某些字段从数据中丢失和/或某时间段从数据中丢失。如果是这样的情况，那么信息管理系统110可以尝试定位丢失数据和/或确定丢失数据的缺省值。例如，如果数据供方并未报告借方地址，那么系统可以使用借方姓名、社会保障号码和/或其它识别信息搜索其它数据库来找出借方地址。在另一实例中，如果数据供方仅仅在存在如拖欠之类的问题时供应小额信贷信用数据，那么系统可以假定未报告的周期是无拖欠的周期并将它们标记为无拖欠的。

小额信贷信用数据也可包含用于信用报告的元数据，但是并不易于放入现有信用报告或数据存储类别中的一个中。在此类情况中，信息管理系统110可以对元数据和/或任选的数据字段执行另外分析，以便存储元数据其本身和/或至少部分基于元数据确定的另外信息。例如，元数据可指明某个小额信贷信用账户是与通过联合国的努力在某个区域中运作以向弱势女性提供工作技能的贷方关联。由于这种账户的特殊性，元数据可指明未支付或延迟支付长达6个月不应被记录为拖欠。元数据也可以指明仅前两年所预期的偿付是比行业惯例小的最低金额。

在另一实例中，元数据也可以指明支付有时能以非货币物品进行。例如，小额信贷账户的元数据指明通过产品如手工编织筐的支付是接受的。因此，可以更新信息管理系统110和相关数据库中的支付数据字段以及其它相关数据字段，以便包括非货币式支付信息。

在一些情况中，接收到的小额信贷信用数据中的至少一个子集可以非常类似于传统信用账户数据。例如，某些小额信贷实体可以具有按月支付周期以及类似于传统提供方的那些支付条款的其它支付条款。在此类情况中，接收到的小额信贷数据中的至少一些可被映射并且重新格式化成为现有CCA或BCA通用格式。在其它情况下，接收到的小额信贷信用数据可能无法轻易符合通常所接受的数据格式。在一些实施方案中，信息管理系统110能以输入格式处理并且存储非传统的数据，所述输入格式反映数据从数据供方接收时的格式。在其它实施方案中，信息管理系统110能以信息管理系统110专用格式处理并且存储非传统的数据，所述格式被设计成适应可能出现在不同数据供方的数据格式上的各种各样的支付条款和/或其它不一致性。

在块206处，信息管理系统110对块204处处理的数据分类并且删除重复。来自某些数据供方的小额信贷信用数据可比传统信用数据更倾向于具有重复，因为许多小额信贷数据供方并不具有那种可供用于大型贷方的数据质量控制或系统数据记录系统。在一些实施方案中，信息管理系统110可对数据分类，以便按照时间顺序清楚了解是否存在从所供应的数据中丢失的时间段。信息管理系统110也可以对数据分类，以便所述信息管理系统110可检测到，在某段时间内，对于某个账户，重复信用数据条目被包括在接收到的数据之中。在另一实例中，接收到的信用数据可以通过标识与账户有关的信息进行分类，并且重复条目可以酌情删除或标记为不需要保存的数据。

在一些实施方案中，重复条目可能并非完全重复，而是具有类似但不同的信息。信息管理系统110最初可以处理数据以便找出类似数据条目。随后，它可提交此类条目以进一步分析(如基于机器学习、数据挖掘或人工智能的方法)以标识包含不同但类似的信息的此类条目是否也仍应像重复条目那样处理。例如，各种小额信贷组织所报告的信用数据可能包含错误、错字或关于借方和/或借贷实体的不一致的标识信息。举例来说，在一个报告周期中，小额信贷组织可将借方标识为居住在洛杉矶市North Pine Street的John Smith先生。在另一报告周期中，所述组织可将相同借方标识为居住在罗兰岗N.Pine St.#343的John Smith Jr.博士。信息管理系统110可以基于姓名、地址、出生日期、社会保障号码和/或其它信息执行分析，以将两个条目标识为与相同借方关联。

在一些实施方案中，数据准备模块112可以重新格式化数据、删除重复数据并且解析数据。在一些其它实施方案中，数据加载模块114可以执行匹配和/或进一步数据分析以重新格式化数据、删除重复数据和/或解析数据。在一些实施方案中，删除重复也可包括数据加载模块114通过查询现有数据库118确定数据库中是否已经存在任何重复记录。例如，查询现有数据库后，可以发现，小额信贷贷方机构先前已经提交相同信用数据。

对于小额信贷信用数据，分类可以可替代地或另外地包括使用实际支付周期、支付日期、个体、企业或其它实体的名称来对接收到的小额信贷数据分类。例如，记录可以基于与特定企业实体或慈善项目相关的所有账户来分类。在另一实例中，数据可以使用出生日期、社会保障号码或与账户相关的其它标识信息来分类。在一些实施方案中，分类可以包括：一旦信息管理系统确定实际支付周期，就按照实际支付周期的长度来对小额信贷数据重新定序。在一些实施方案中，分类并且删除重复数据之后，当两个或多个完全重复数据记录标识出时，仅仅可以保留一个记录。在其它情况中，类似或重复的条目仍可存储，但不用于信用报告目的。在一些其它情况中，带有略微不同信息和/或不同元数据的重复小额信贷数据条目可被存储在系统中，但仅一个条目用于信用报告。在其它实施方案中，重复条目的元数据以及其它唯一方面可以被发送到信用报告生成系统130并且包括在信用报告中。

在块208处，信息管理系统验证接收到的小额信贷信用数据。在一些实施方案中，数据验证可以包括数据加载模块114从接收到的数据中提取相关数据字段。随后，数据加载模块114可以使用数据加载模块114查询现有数据库118，看看从接收到的数据解析的记录是否匹配已存储的数据。如果存在冲突，那么数据验证模块可以检查多个数据字段，以便确定是否存在匹配或者数据质量是否存在问题。例如，数据加载模块114可以检查小额信贷账户过去历史，看看所报告的支付金额是否是与先前支付周期大致一致。例如，如果先前已经报告账户具有$800的剩余余额，并且在实际支付周期中，进行$5,000的支付，那么接收到的小额信贷数据可能存在某种问题。在此类情况中，标记数据以进一步处理。在另一实例中，如果企业借贷实体先前在系统中被记录为属于在线广告行业并且位于本地企业孵化器中，那么示出其位置处于高端企业综合区的借贷实体地址可为数据质量控制信号。此情况中，可能存在地址或实体不匹配。在一些实施方案中，数据质量问题可以通过进行更多数据挖掘和校正步骤来解决。在一些其它实施方案中，问题可由信息管理系统110报告给数据供方以进行校正或进一步问询。

在块210处，信息管理系统将小额信贷信用数据加载到数据库118之中、建立新的实体以及关系和/或更新现有信息以及关联。例如，如果数据供方提供与小额信贷借贷目的有关的小额信贷数据以及与某些账户有关的特殊支付条款，那么数据库可进行更新以便添加与特殊支付条款有关的数据字段和/或元数据(如支付类型、非货币式支付选项等等)。在一些实施方案中，信息管理系统110可以相对数据库中已呈现的相关信息核实输入信用数据，以便确定是否需要存储新的实体以及关系。信息管理系统110可将新的小额信贷数据记录插入数据库中，或者基于新的数据更新现有记录。在一些实施方案中，关于现有信息以及关联的细节或更新可从新的数据标识并与现有记录相关联地存储。例如，如果小额信贷信用账户先前仅仅接受货币支付，但是最近开始接受非货币式支付，支付数据类型可能需要更新，以便货币支付和非货币式支付这两者都可存储。在一些实施方案中，如果使用非货币式支付，那么信息管理系统110也可生成非货币式支付的总现金值的粗略估算以实现计算拖欠的目的。

用于生成小额信贷信用数据的数据报告的示例方法

在一些实施方案中，信用报告/评分生成系统130可以使得用户(如操作人员、顾客或征信局的合作伙伴)能够定义包括小额信贷信用数据的自定义信用报告。基于来自给定用户(如消费者、小额信贷的债权人或有兴趣查看个体的包括关于小额信贷账户的信息的信用报告的实体)的规范，并考虑到信用报告生成系统的规则模块132所维护的规则，信用报告生成系统130可以生成小额信贷信用报告并向用户递送已生成的小额信贷信用报告。信用报告/评分生成系统130也可生成信用评分并向用户递送已生成的信用评分。

图3是示出信用报告生成系统130所实现的方法的一个实施方案的流程图，所述信用报告生成系统130用于生成包括与小额信贷数据关联的拖欠信息的自定义用户界面。方法300开始块302，其中信用报告/评分生成系统130确定第一支付间隔。第一支付间隔可为时间周期，如一天或多天、数周或者数月。它可用于生成信用报告中使用的支付网格。例如，5天的支付间隔可以用于生成带有以5天为增量的条目的支付网格。实际支付周期可不同于支付间隔。在一些实施方案中，信用报告/评分生成系统130通过查阅支付历史信息并且使用数据规则模块132A计算支付间隔而来确定第一支付间隔。例如，如果根据支付历史信息计算出的实际支付周期为约6至8天，那么第一支付间隔可选择为7天。使用那种7天支付间隔，就可生成7天支付网格。在一些实施方案中，信用报告生成系统130从征信局操作人员或来自另一信用查阅或报告实体的操作人员所提供的输入接收第一支付间隔。例如，操作人员可将第一支付间隔设置为任何数量的天、周或月，或可呈现某些预定间隔以供从中进行选择。

在块304处，信用报告生成系统130使用第一支付间隔生成支付网格。在一些实施方案中，可以通过信用报告生成系统130使用第一支付间隔预先生成支付网格并对其进行存储。在其它实施方案中，在接收对支付网格的请求时，可以使用第一支付间隔动态生成支付网格。以下所讨论的图5、图6以及图7提供带有不同支付网格的用户界面的实例。生成支付网格可以包括检索小额信贷信用信息并且确定支付网格中的每个条目的支付状态。如果可用，则支付的宽限期可以被包括在生成支付状态的进程中。在一些实施方案中，第一支付间隔可与小额信贷支付数据中提供的实际支付周期相同或很类似。例如，来自数据供方的小额信贷数据中提供的实际支付周期可以指明实际支付周期通常为每14天。因此，信用报告生成系统130以及在一些实施方案中数据规则模块132A可以基于实际支付周期确定第一支付间隔可为每14天。支付网格可以使用14天第一支付间隔生成。在此类情况中，信用报告生成系统130可以使用数据库118中的处理过的小额信贷信用数据生成支付网格。此实例中，由于实际支付周期可以匹配或很类似第一支付间隔，信用报告生成系统可以使用一些数据规则来计算支付状态和拖欠计数器。在一些实施方案中，数据规则可以指定如果支付迟了一天或多天、一周或多周或者一月或多月，那么支付状态可设置为“违约”。例如，在一些情况中，如果支付迟了甚至1天，那么信用报告生成系统130可以将支付状态设置为“违约”。在一些其它情况中，如果支付迟了或未进行超过第一支付间隔持续时间的一半，那么系统130可将特定时间段内的支付状态设置为“违约”。在一些情况中，如果支付迟了或未进行超过第一支付间隔持续时间的1/4，那么信用报告生成系统130可将特定时间段内的支付状态设置为“违约”。在一些情况中，信用报告生成系统130可以使用征信局或从事小额信贷信用报告和查阅以确定支付状态的另一实体的操作人员指定的时间段。

在一些实施方案中，第一支付间隔可以短于接收到的小额信贷信用数据中提供的实际支付周期。例如，第一支付间隔可为3天，而接收到的小额信贷信用数据中提供的实际支付周期可为每7天。在一些此类情况中，接收到的小额信贷信用数据无法以更短的第一支付间隔的更细化级别提供支付状态信息。根据某些实施方案，信用报告生成系统130可以使用比实际支付周期短的第一支付间隔生成支付网格。在一些实施方案中，信用报告生成系统130可以使用支付网格中的针对某个时间段的实际支付周期来生成的支付状态。

在以上给出的实例中，实际支付周期可为7天，并且第一支付间隔可为3天。对于支付网格中的2012年12月3日与2012年12月5日之间特定的时间段，信用报告生成系统130可以使用针对实际支付周期(例如，其可以是2012年12月1日与2012年12月7日)而确定的支付状态信息作为支付网格(2012年12月3日至2012年12月5日)中的此条目的支付状态。如果支付网格中的特定条目在一个实际支付周期中开始，并在下一实际支付周期中结束，那么在一些实施方案中，信用报告生成系统可以将支付状态设置为包括特定支付网格条目中的更多天的实际周期。例如，实际支付周期1中的支付状态可为“违约”，并且实际支付周期2中的支付状态可为“当前”，并且支付网格条目可以包括实际支付周期1中的2天以及实际支付周期2中的1天。此情况中，支付状态可设置为“违约”。如果支付网格条目包括来自实际支付周期1和实际支付周期2的相等天数，那么信用报告生成系统可以使用任一实际支付周期中的状态作为支付状态。在其它实施方案中，包括被报告为“违约”状态的实际支付周期中的至少一天的任何支付间隔也可以在已生成的支付网格中显示为违约状态。

在一些实施方案中，第一支付间隔可以长于接收到的小额信贷信用数据中提供的实际支付周期。例如，第一支付间隔可为30天。从数据供方接收的实际支付周期可为每7天。信用报告生成系统130首先可以确定给定支付间隔内的每个实际支付周期的支付状态。在一些实施方案中，使用第一支付间隔内的每个实际支付周期的支付状态信息，信用报告生成系统130可以通过找出大多数的支付状态确定支付状态。例如，如果支付状态在支付网格条目内的3实际支付周期为违约并且在支付网格条目内的1实际支付周期为当前，那么基于大多数的支付状态规则，这个特定30天周期的支付状态可设置为“违约”。

在一些实施方案中，信用报告生成系统130可以通过使用支付间隔中包含的最后一个实际支付周期的支付状态来确定支付状态。例如，在以上给出的实例中，实际支付周期可为每7天，并且第一支付间隔可为30天。信用报告生成系统130可以确定在此30天范围内的最后一个实际支付周期的支付状态是“当前”。因此，信用报告生成系统130可将整个时间段的支付状态设置为“当前”。在其它实施方案中，信用报告生成系统130可将包括被报告为处于违约的至少一个实际支付周期的任何支付间隔的状态认为是“违约”。在一些实施方案中，信用报告生成系统130也可被配置成至少部分基于支付网格中的一个或多个条目的支付状态生成经预测的未来支付趋势。

在块306处，信用报告/评分生成系统130使用不同于上述第一支付间隔的支付间隔生成一个或多个另外的支付网格。在一些实施方案中，支付网格通过信用报告生成系统130预先生成并且存储。在其它实施方案中，支付网格可以在其被请求时动态生成。

在一些实施方案中，另外的支付间隔可以包括短于第一支付间隔的一个或多个支付间隔和/或长于第一支付间隔的一个或多个支付间隔。例如，如果第一支付间隔为10天，那么另外的支付间隔可以包括7天支付间隔和一个月支付间隔。因此，另外的支付网格可以生成以包括7天支付间隔网格和一个月支付间隔网格。在一些实施方案中，另外的支付间隔各自可以长于第一支付间隔，或者各自可以短于第一支付间隔。

此外，在一些实施方案中，信用报告生成系统130可以自动选择一个或多个另外的支付间隔，以便生成另外的支付网格。信用报告生成系统130可以基于各种因素确定另外的支付间隔的长度，这取决于实施方案。例如，信用报告生成系统130可以基于接收到的小额信贷信用数据计算实际支付周期。如果实际支付周期与第一支付间隔不同，那么实际支付周期可被选择作为另外的支付间隔，并且可以使用这个另外的支付间隔生成支付网格。在一些实施方案中，信用报告生成系统130可以自动选择约为第一支付间隔持续时间的一半的支付间隔以及约为第一支付间隔持续时间的两倍的另一支付间隔，并且使用这些另外的支付间隔生成两个另外的支付网格。在一些实施方案中，信用报告生成系统130可从预定可接受的支付间隔列表随机选择短于第一支付间隔的支付间隔以及长于第一支付间隔的另一支付间隔，并且生成所得支付网格。另外，在一些实施方案中，信用报告生成系统130可以使用征信局的操作人员、来自金融机构的授权的操作人员和/或来自请求信用报告的用户的输入所提供的支付间隔以生成另外的支付网格。

在块308处，信用报告/评分生成系统130计算针对支付网格所生成的拖欠计数器。例如，数据规则模块132A可以接收请求以便确定拖欠状态和/或拖欠计数、与规则数据数据库140通信以检索用于确定拖欠状态和/或计数的规则集合并且基于规则计算拖欠次数。信用报告生成系统130可以包括位于信用报告生成系统生成的自定义用户界面上的已生成的支付网格内的拖欠计数器，如以下进一步讨论。支付网格内的拖欠计数器也可使用各种规则生成，这取决于支付间隔、实际支付周期和/或其它信息。例如，在一些实施方案中，拖欠计数器可以至少部分基于特定时间段内所报告的违约的数量生成，所报告的违约的数量可为最小值为零的整数(指明没有所报告的违约)。在一些实施方案中，如果数据在给定时间段内不可用，那么拖欠计数器可以显示“数据不可用”或类似消息。

在一些实施方案中，拖欠计数器可以计算特定时间段内已经出现多少次支付迟到或遗漏。例如，如果实际支付周期为3天，7天拖欠计数器可以基于7天拖欠计数器周期中包括的多少3天支付周期被设置为“违约”状态生成。在其它实施方案中，拖欠计数器可以基于特定时间段内最后一次所报告的支付状态生成。例如，如果实际支付周期为3天，可以生成7天拖欠计数器以便反应在7天周期期间迟了或遗漏多少支付。例如，对于2012年12月1日到2012年12月3日的实际支付周期，借方可能已在2012年12月5日进行迟到的支付。对于2012年12月4日至2012年12月6日之间的实际支付周期，借方在2012年12月6日按时支付。此情况中，由于7天周期结束，所有支付到期，因此，在一些实施方案中，可将拖欠计数器设置为0。然而，如果例如系统确定，即使进行迟到的支付，如果支付是在一些天/周/月后进行，那么迟到的支付仍可被记录作为拖欠的一次计数。在以上实例中，即使支付是在12月5日进行，但是由于它迟了2天(实际支付周期的2/3)，故系统可以基于系统所生成的和/或操作人员所提供的规则确定这个迟到的支付可被记录为拖欠的一次计数。

在一些实施方案中，拖欠计数器可以基于长于拖欠计数器中包括的时间段的实际支付周期生成。例如，如果实际支付周期为30天，并且拖欠计数器可以基于7天周期增量生成。在一些实施方案中，信用报告生成系统130可以确定在7天周期中是否存在任何拖欠。在以上给出的实例中，系统130可确定支付期限为2012年12月1日，并且在该实际支付周期(30天)内不进行支付，直至2012年12月4日。因此，信用报告生成系统130可以确定在2012年12月1日与2012年12月7日之间的7天拖欠计数器周期期间存在着一次拖欠计数。在另一实例中，如果支付期限为2012年12月1日，并且在该实支付周期(30天)内不进行支付，直至2012年12月15日，那么信用报告生成系统130可以确定在2012年12月1日与2012年12月7日之间的7天拖欠计数器中存在着拖欠的一次计数。系统130同样可以确定在2012年12月1日与2012年12月14日之间的14天拖欠计数器中存在着拖欠的一次计数。系统130可以确定的是，如果针对2012年12月1日与2012年12月21日之间的时间段生成21天拖欠计数器，那么并不存在拖欠，因为支付是在2012年12月15日进行。然而，在一些实施方案中，系统可以确定的是，即使进行支付，如果支付迟了给定天数/周数/月数，那么所述支付仍被算作拖欠的一次计数。在这种情况中，例如，可以生成21天拖欠计数器，并且系统130可以确定的是，由于支付迟了5天以上，例如，21天拖欠计数也为1。在一些实施方案中，当信用报告生成系统130计算支付状态时，它也可以考虑支付宽限期的可用性。例如，如果支付迟了30天并且15天的宽限期可用，那么在一些实施方案中，信用报告生成系统130可以考虑宽限期并且确定支付仅仅迟了15天。

在块310处，信用报告/评分生成系统130至少部分基于使用第一支付间隔已生成的支付网格生成用户界面。支付网格可以包括与支付状态、状态日期、余额、实际支付金额、所进行的最低支付、支付类型、最后一次支付日期、支付到期日期、现金预付数和/或其它信息有关的信息。用户界面可以包括用于显示使用一个或多个另外的支付间隔的支付网格的至少一个选项。例如，基于14天支付间隔的支付网格可呈现有用于请求基于7天支付间隔的另外的支付网格和/或基于30天支付间隔的另一支付网格的一个或多个可选选项。因此，所生成的用户界面可向用户提供用于显示支付网格和支付间隔的多个选项。

示例系统架构

图4是示出计算系统410与一个或多个数据源428和客户端432经由网络430通信的实施方案的框图。计算系统410可以用于实现本公开中描述的系统和方法。

计算系统410包括(例如)可为IBM、Macintosh或Linux/Unix兼容或为服务器或工作站的计算机。在一个实施方案中，例如，计算系统410包括服务器、台式计算机或便携式计算机。在一个实施方案中，示例性计算系统410包括一个或多个中央处理单元(“CPU”)420，所述CPU420各自可以包括常规或专有的微处理器。计算系统410进一步包括一个或多个存储器424(如用于临时存储信息的随机存取存储器(“RAM”)、用于永久存储信息的一个或多个只读存储器(“ROM”))，以及一个或多个大容量存储设备412(如硬件驱动器、磁盘、固态驱动器或光学介质存储设备)。通常，计算系统410的模块使用基于标准的总线系统418来连接到计算机上。在不同实施方案中，例如，可在外围组件互连(“PCI”)、微通道、小型计算机系统接口(“SCSI”)、工业标准架构(“ISA”)以及扩展ISA(“EISA”)架构中实现基于标准的总线系统。另外，计算系统410的组件和模块中提供的功能可组合成更少的组件和模块，或进一步分成另外的组件和模块。

计算系统410通常通过操作系统软件来控制和协调，所述操作系统软件如Windows XP、Windows Vista、Windows7、Windows8、Windows Server、Unix、Linux、SunOS、Solaris或其它可兼容的操作系统。在Macintosh系统中，操作系统可为任何可用操作系统，如MAC OS X。在其它实施方案中，计算系统410可由专有操作系统控制。除了其它之外，常规操作系统控制并调度要执行的计算机进程、执行存储器管理、提供文件系统、联网、I/O业务并且提供用户界面，如图形用户界面(“GUI”)。

示例性计算系统410可以包括一个或多个常用输入/输出(I/O)设备和接口422，如键盘、鼠标、触摸板以及打印机。在一个实施方案中，I/O设备和接口422包括允许向用户视觉呈现数据的一个或多个显示设备(如监视器)。更具体地，例如，显示设备提供GUI、应用软件数据以及多媒体演示的呈现。例如，计算系统410也可包括一个或多个多媒体设备416，如扬声器、视频卡、图形加速器以及麦克风。

在图4的实施方案中，I/O设备和接口422提供到各种外部设备的通信接口。在图4的实施方案中，计算系统410例如经由有线、无线或有线和无线的组合的通信链路426来电子耦接到网络430上，所述网络430包括LAN、WAN和/或因特网中的一个或多个。网络430经由有线或无线通信链路与各种计算设备和/或其它电子设备通信。

根据图4，信息通过网络430来从一个或多个数据源(包括例如数据源428)被提供给计算系统410。各数据源所供应的信息可以包括(例如)小额信贷信用数据、交易数据、其它信用数据、个人数据、公共记录数据、社交网络数据等等。除了图4中示出的设备之外，网络430可与其它数据源或其它计算设备通信。另外，数据源可包括一个或多个内部和/或外部数据源。在一些实施方案中，数据库或数据源中的一个或多个可以使用关系数据库(如Sybase、Oracle、CodeBase以及SQL Server)以及其它类型的数据库(例如像平面文件数据库、实体关系数据库以及面向对象的数据库、基于记录的数据库和/或非结构化的数据库)实现。

客户端系统432可以连接到网络430上并由用户来向计算系统410发送信息并从计算系统410接收信息。客户端系统432可为台式计算机、车载计算机、移动式计算机或如移动电话、智能电话、平板电脑或其它类似手持计算设备之类的任何其它移动设备。客户端系统432和/或数据源428可以包括与以上参考计算系统410所讨论的那些相同或类似的组件。

在图4的实施方案中，计算系统410也包括了处理和报告模块414，所述处理和报告模块414可以存储在大容量存储设备412中作为由CPU420执行的可执行软件代码。举例来说，这个模块可以包括组件(如软件组件、面向对象的软件组件、类组件以及任务组件)、进程、函数、属性、过程、子例程、程序代码段、驱动器、固件、微代码、电路、数据、数据库、数据结构、表、数组以及变量。在图4中示出的实施方案中，计算系统410被配置成执行处理和报告模块414，以便实现本文在其它地方描述的功能。例如，处理模块可以执行针对以上参照信息管理系统110和/或信用报告生成系统130所描述的各种模块中的任何模块来描述的方法，这取决于实施方案。

通常，本文所用字词“模块”是指硬件或固件中具体化的逻辑，或指可能具有进入点和离开点的以编程语言(如Java、Lua、C或C++)编写出的软件指令集合。软件模块可能被编译并链接到可执行程序、被安装在动态链接库中或者可用解释性的编程语言(如BASIC、Perl或Python)编写。应当了解，软件模块可从其它模块或从它们自身调用，和/或可响应于检测到的事件或中断来调用。配置成在计算设备上执行的软件模块可提供在计算机可读介质(如压缩盘、数字视频光盘、闪存驱动器或任何其它有形介质)上。此类软件代码可以部分或完全地存储在执行计算设备(如计算系统410)的存储器设备上，以供计算设备执行。软件指令可在固件(如EPROM)中嵌入。还将了解，硬件模块可由所连接的逻辑单元(如门和触发器)组成，和/或可由可编程的单元(如可编程门阵列或处理器)组成。本文所述模块优选地实现为软件模块，但也能以硬件或固件来表示。通常，本文所述模块是指逻辑模块，所述逻辑模块可与其它模块组合或分割成子模块而不管它们的物理组织或存储如何。

在一些实施方案中，本文所述的一个或多个计算系统、数据存储和/或模块可以使用一个或多个开源项目或其它现有平台实现。例如，本文所述的一个或多个计算系统、数据存储和/或模块可以部分通过利用与以下项中的一个或多个相关的技术实现：Drools、Hibernate、JBoss、Kettle、Spring Framework、NoSQL(如由MongoDB实现的数据库软件)和/或DB2数据库软件。

示例用户界面以及支付网格

图5是用于通过各种支付网格选项配置并且显示小额信贷信用报告的说明性用户界面的一个实施方案。用户界面500可由信用报告生成系统130生成并且呈现用于显示在用户计算设备(如消费者150)上。用户界面500显示与特定小额信贷信用账户关联的账户信息。例如，用户界面显示账号502、账户类型504以及在财务上对账户506负责的一方。如在这个部分中所使用，针对用户设计的用户界面的用户可为征信局的操作人员、授权以访问并调整金融实体中的信用查阅和报告过程的个人、小额信贷信用报告服务的订户或消费者等等。

用户界面500也示出了支付间隔508。在此说明性实例中，支付间隔显示为一个月。用户界面500允许用户设置支付间隔持续时间，并且如果用户这样选择的话，那么允许将支付间隔改变为其它持续时间。例如，用户可以输入10天，替代一个月的支付间隔。这使小额信贷信用报告用户灵活地将报告调整成适合他们特定需要的细节级别。

用户界面500也显示了最近一次报告日期510，所述最近一次报告日期510可以是征信局接收与此账户有关的最近一次所报告的支付的日期或与账户有关的最近一次接收到数据的日期。用户界面显示账户状态512，根据所示实施方案，所述账户状态512可为“违约”、“当前”或“不可用“。在一些实施方案中，可以使用另外或不同的支付状态指示符，如数字、符号或其它消息。支付网格中的每个条目的支付状态可以通过接收对确定每个条目的支付状态的请求、检索用于确定支付状态的规则集合并且相应地计算支付状态进行确定。违约金额514也显示在用户界面500之中，它指明了账户户主当前违约$800。用户界面500也显示了此账户关联的行业，如农业、教育、服务等等。

用户界面500显示支付网格518以及用于其它支付网格的若干选项520、522以及524。在此说明性实例中，用来生成当前支付网格的支付间隔在此实例中是一个月。用户界面500中包括了若干可选选项，包括按日支付网格选项520、按周支付网格选项522、按月支付网格选项524以及自定义的支付网格选项526，这些可选选项被显示在支付网格518附近。在一些实施方案中，支付网格中显示的默认支付间隔选项可以是按月或按周的。在一些实施方案中，默认支付间隔选项可以更新或自定义。

在一些实施方案中，信用报告生成系统130可以使用数据规则模块132A和显示规则模块132B并且在数据库中存储预先计算过的支付网格而来预先计算支付网格要显示的信息。例如，信用报告生成系统130可以预先计算小额信贷信用账户显示的按周和按月支付网格。这可允许更快速并更方便地显示频繁使用的支付网格。此后，如果用户请求预先计算过的支付网格，那么用户界面模块134可以直接显示预先计算过的支付网格。例如，当用户选择按月支付网格选项524时，系统可向用户呈现预先计算过的按月支付网格。

在一些实施方案中，接收用户请求之后，信用报告生成系统130可以使用数据规则模块132A和/或显示规则模块132B动态生成每个支付网格要显示的数据。例如，当用户选择按周支付网格选项522时，信用报告生成系统130可以动态生成按周支付网格要显示的数据，如在以上参照图3更详细地讨论。

在一些实施方案中，信用报告生成系统可以预先计算一些支付网格，但是动态生成其它支付网格。系统可以选择预先计算与小额信贷信用账户所关联的默认支付间隔关联的支付网格。在一些实施方案中，用户可以在用户界面中建立与小额信贷信用账户关联的默认支付间隔。用户界面500也使用户能够通过选择自定义选项526来自定义支付网格。选择选项526可向用户呈现用户界面，如图8的说明性实例，这将在以下进一步讨论。

用户界面500也允许了用户通过选择借方选项528切换到其它借方或账户。用户界面允许用户通过选择查看支付历史选项530并且调整要显示的报告周期查看并非最近时间段的支付历史。例如，如果当前所显示的支付周期是2012年11月15日至2012年11月30日，那么通过选择查看支付历史选项530，即可显示例如2012年11月1日至2012年11月14日的支付信息。

用户界面500也包括了拖欠计数器532，所述拖欠计数器532可以指明给定时间段内账户有多少次被报告为拖欠或在给定时间段期间支付有多少次迟到或遗漏。信用报告生成系统130也可允许用户限定与如何在用户界面500中计数并报告拖欠关联的数据规则。例如，在一些实施方案中，信用报告生成系统130可以允许用户限定是基于已遗漏的支付(即使所述支付仅迟了一天)总数还是替代地基于给定时间段内最近一次支付状态计算拖欠。其它选项可以包括(例如)出于拖欠计数器目的指定支付可以迟到多少天而不被算作迟到的支付。在一些其它实施方案中，出于拖欠计数器目的，选项可以包括部分支付是否算作迟到或遗漏的支付。选项也可包括不被认为是拖欠的部分支付所要求的百分比或最低支付。在其它实施方案中，非货币式支付选项可被设置用于拖欠计数器。例如，如果借方使用非货币物品进行支付，那么信息管理系统110可以允许用户设置这种选项：所述物品的货币价值是否可被用于拖欠计数器目的。在用户自定义与如何报告拖欠关联的规则后，信用报告生成系统130可向用户显示一组新的拖欠计数器532。

用户界面500也可包括详细支付历史信息534，所述详细支付历史信息534可以包括所报告的支付状态日期、支付状态、信用额度扩展、余额、实际支付金额、最低支付金额、支付类型、最近一次支付日期、支付到期日期、现金预付数和/或其它信息。

图6是用于通过各种支付网格显示选项配置并且显示小额信贷信用报告的说明性用户界面600的一个实施方案。类似于用户界面500，用户界面600允许用户选择并自定义支付网格。不同于用户界面500的是，用户界面600中显示的默认支付间隔为3天。这可通过用户在支付间隔字段608中改变。

用户界面600也可让用户基于不同支付间隔选择切换以查看其它支付网格，如按周支付网格(通过选择按周支付网格选项622)或按月支付网格(通过选择按月支付网格选项624)。用户界面也包括了拖欠计数器632。系统可以基于各种因素(如与这个账户或类似账户关联的实际支付周期和最常用的支付网格)提供默认另外的支付网格。系统可以允许用户调整与另外的支付网格关联的支付间隔。

图7是用于通过各种支付网格显示选项配置并且显示小额信贷信用报告的另一说明性用户界面700的一个实施方案。类似于用户界面500和600，用户界面700允许用户通过使用选项(如720(按日支付网格选项)、722(按周支付网格选项)、724(按月支付网格选项)，726(自定义选项)以及708(支付间隔字段))选择并自定义支付网格。然而，不同于用户界面500和600的是，用户界面700中显示的默认支付间隔是一周(如在支付间隔字段708中指明为7天)。这个间隔可以通过用户在支付间隔字段708中改变。

图8是用于创建新的支付网格的用户界面800的说明性实例。在一些实施方案中，此类用户界面可向用户(如执行者、管理人员或与小额信贷信用实体或征信局关联的其它个人)呈现，以便允许用户根据小额信贷信用实体的特定需要来自定义支付网格和/或配置在生成产品时将由规则模块132使用的显示规则。用户界面800呈现对小额信贷信用账户802的选择，其中用户可以选择要创建新的支付网格的账户。在此说明性示例中，用户被呈现有四个小额信贷信用账户804至810以供从中选择。用户界面800也被配置为允许用户输入支付间隔。此实例中，用户已在月字段812中输入0个月并在天字段815中输入10天。因此，用户界面800允许用户创建自定义的支付网格，所述自定义的支付网格使用10天支付间隔。在用户选择“创建支付网格”选项816之后，用户可以接收对创建带有10天支付间隔的新的支付网格的确认。然后，用户可以查看基于10天支付间隔的信用报告。另外地或可替代地，当在未来生成选定账户的报告时，信用报告生成系统130可以存储用于待由规则模块132使用的选定账户的支付网格。

图9是用于选择默认支付网格的用户界面900的说明性实例。在一些实施方案中，此类用户界面可向用户(如执行者、管理人员或与小额信贷信用实体或征信局关联的其它个人)呈现，以便允许用户根据小额信贷信用实体的特定需要设置默认支付网格和/或配置在生成产品时将由规则模块132使用的显示规则。信用报告/评分生成系统可以基于过去的支付历史信息(如实际支付周期)来向小额信贷信用账户直接分配默认支付网格。然而，如果用户希望调整默认支付网格，那么用户可以使用用户界面900来自定义默认设置。用户界面900将对小额信贷信用账户902至910的选择向用户呈现。用户界面900也被配置为允许用户设置默认支付间隔。此实例中，用户已在月字段914中输入0个月并在天字段916中输入7天。因此，用户界面900允许用户针对特定小额信贷信用账户将默认支付网格设置为带有7天支付间隔。用户也可选择多个账户，并且针对账户的全部或每个建立默认支付网格。

其它实施方案

虽然前述系统和方法已经就某些实施方案进行描述，但是其它实施方案对于本领域的普通技术人员来说将从本文中的公开清楚。另外，对于本文中的公开而言，其它组合、省略、替换以及改进将对技术人员是清楚的。尽管已经描述本发明的一些实施方案，但是这些实施方案仅仅借助实例呈现，并且并非意图限制本发明的范围。实际上，本文所描述的新颖方法和系统可以在不背离本发明的精神的情况下通过各种其它形式实施。此外，本文中的公开的与实施方案结合的任何具体特征、方面、方法、性质、特性、质量、属性、元素等等可以用于本文所阐明的所有其它实施方案。

在本文中所描述的所有过程可以在由一个或多个通用计算机或处理器执行的软件代码模块中具体化并且经由所述软件代码模块来完全自动化。所述代码模块可以存储在任何类型的计算机可读介质或其它计算机存储设备中。所述方法中的一些或所有可以可替代地在专用计算机硬件中具体化。另外，在本文中所提及的组件可以在硬件、软件、固件或其组合中进行实施。

除非另外特别说明，否则如“能够”、“可以”、“可能”或“也许”等的条件语言在上下文中应理解为通常使用的情况以传达：尽管其它实施方案不包括，但某些实施方案包括某些特征、元件和/或步骤。因此，此类条件语言通常并非意图暗示无论如何所述特征、元件和/或步骤都是一个或多个实施方案必需的，或者并非暗示一个或多个实施方案必须包括用于在借助和不借助用户输入或提示下决定是否包括这些特征、元件和/或步骤或者是否在任何特定实施方案中实施这些特征、元件和/或步骤的逻辑。

在本文中所述和/或附图中描绘的流程图中的任何过程说明、元素或方框应理解成潜在地代表包括用于实施过程中的特定逻辑功能或元素的一个或多个可执行指令的代码模块、代码片段或代码部分。替代实施方案包括在本文中所述实施方案的范围内，其中如本领域中的技术人员所理解的那样，根据所涉及的功能，元素或功能可删除、不按照所示出或讨论的顺序执行，包括基本上同时执行或逆序执行。

Claims (29)

1.一种信用报告系统，所述系统包括：

数据库，其被配置成存储多个记录，其中所述多个记录各自包括与多个账户关联的信用数据，其中所述数据库被配置成存储包括账户与多个支付间隔关联的支付状态信息的信用数据；

规则引擎，其被配置成存储多个可自定义规则，所述多个可自定义规则被配置为动态可访问的，所述多个可自定义规则与以下一个或多个关联：支付间隔、监管要求或者报告配置；以及

信用报告生成系统，其被配置与所述数据库进行电子通信，所述信用报告生成系统包括：

报告模块，其被配置成：

接收标识应当生成信用报告的第一个体的报告请求指示；

从所述数据库检索与所述个体关联的信用数据，其中所述检索到的信用数据包括与所述个体的第一金融账户关联的支付状态信息；

响应于所述报告请求，动态确定呈现所述检索到的信用数据的第一支付网格中的每个条目的支付状态，所述第一支付网格包括对应于第一支付间隔的条目，其中所述第一支付间隔包括按日、按周以及按月中的一个，其中所述第一支付网格中的每个条目的所述支付状态是至少部分通过应用从所述规则引擎检索到并且与所述第一支付间隔关联的第一可自定义规则进行确定；以及

响应于所述报告请求，动态确定呈现所述检索到的信用数据的第二支付网格中的每个条目的支付状态，所述第二支付网格包括对应于不同于所述第一支付间隔的第二支付间隔的条目，其中所述第二支付间隔包括按日、按周以及按月中的一个，其中所述第二支付网格中的每个条目的所述支付状态是至少部分通过应用从所述规则引擎检索到并且与所述第二支付间隔关联的第二可自定义规则进行确定；以及

用户界面模块，其被配置成：

呈现信用报告，所述信用报告包括所述第一支付网格，所述第一支付网格包括对应于所述第一支付间隔的条目，其中所述信用报告包括至少一个可选选项，所述至少一个可选选项使得所述用户能够查看所述第二支付网格，所述第二支付网格包括对应于所述第二支付间隔的条目；以及

响应于用户选择所述至少一个可选选项，呈现所述第二支付网格，所述第二支付网格包括对应于所述第二支付间隔的条目。

2.如权利要求1所述的系统，其中所述信用报告生成系统还被配置成：

接收请求以便基于用户定义的支付间隔生成信用报告；

生成支付网格，所述支付网格具有对应于所述用户定义的支付间隔的条目；以及

确定所述支付网格中对应于所述用户定义的支付间隔的每个条目的支付状态。

3.如权利要求1所述的系统，其中所述信用报告生成系统还被配置成：

接收请求以便指定支付网格作为金融账户的默认支付网格；以及

响应于对与所述金融账户关联的信用数据的请求，生成所述默认支付网格以供显示。

4.如权利要求1所述的系统，其中确定所述第二支付网格中的每个条目的所述支付状态包括：

至少部分基于所述第二可自定义规则和与除了所述第二支付间隔之外的支付间隔关联的支付状态信息确定所述第二支付网格中的每个条目的所述支付状态。

5.如权利要求1所述的系统，其中所述信用报告生成系统还被配置成：

接收用于确定第三支付网格中的每个条目的支付状态的用户定义的规则集合；以及

至少部分基于所述用户定义的规则集合确定所述第三支付网格中的多个条目中每个条目的支付状态。

6.如权利要求1所述的系统，其中所述第二支付网格中的每个条目的所述支付状态是至少部分基于与所述个体的所述第一金融账户关联的一个或多个实际支付周期确定，其中所述一个或多个实际支付周期不同于所述第二支付间隔。

7.如权利要求6所述的系统，其中所述一个或多个实际支付周期比所述第二支付间隔要短。

8.一种用于报告信用数据的计算机实现的方法，所述计算机实现的方法包括：

接收标识应当生成信用报告的第一个体的信用报告请求指示；

从一个或多个数据存储检索与所述个体关联的信用数据，其中所述检索到的信用数据包括与所述个体的第一金融账户的多个支付周期的每个关联的支付状态信息；

确定呈现所述检索到的信用数据的第一支付网格中的每个条目的支付状态，所述第一支付网格具有对应于第一支付间隔的条目，其中所述第一支付间隔包括按日、按周以及按月中的一个；以及

确定呈现所述检索到的信用数据的第二支付网格中的每个条目的支付状态，所述第二支付网格具有对应于不同于所述第一支付间隔的第二支付间隔的条目，其中所述第二支付间隔包括按日、按周以及按月中的一个，其中所述第二支付间隔所具有的长度不同于与所述个体的所述第一金融账户关联的实际支付周期。

9.如权利要求8所述的计算机实现的方法，其中所述方法还包括：

接收请求以便基于用户定义的支付间隔生成信用报告；

生成支付网格，所述支付网格具有对应于所述用户定义的支付间隔的条目；以及

确定所述支付网格中对应于所述用户定义的支付间隔的每个条目的支付状态。

10.如权利要求8所述的计算机实现的方法，其中所述方法还包括：

接收请求以便指定支付网格作为金融账户的默认支付网格；以及

响应于对与所述金融账户关联的信用数据的请求，生成所述默认支付网格以供显示。

11.如权利要求8所述的计算机实现的方法，其中所述方法还包括动态计算与账户关联的多个支付间隔。

12.如权利要求8所述的计算机实现的方法，其中所述方法还包括预先计算与账户关联的多个支付间隔。

13.如权利要求8所述的计算机实现的方法，其中每个条目的所述支付状态选自包括至少当前和违约的组。

14.如权利要求8所述的计算机实现的方法，其中确定所述第二支付网格中的每个条目的所述支付状态还包括：

检索用于确定支付状态的规则集合，其中所述规则集合与所述第二支付间隔关联；以及

至少部分基于所述规则集合和与除了所述第二支付间隔之外的支付间隔关联的支付状态信息确定所述第二支付网格中的每个条目的所述支付状态。

15.如权利要求8所述的计算机实现的方法，其中所述方法包括：

接收用于确定第三支付网格中的每个条目的支付状态的用户定义的规则集合；以及

至少部分基于所述用户定义的规则集合确定所述第三支付网格中的多个条目中每个条目的支付状态。

16.如权利要求8所述的计算机实现的方法，其中方法还包括接收支付宽限期，其中所述第二支付网格中的每个条目的所述支付状态是至少部分基于所述支付宽限期来确定。

17.如权利要求8所述的计算机实现的方法，其中所述方法还包括至少部分基于所述第一支付网格中的一个或多个条目的所述支付状态生成经预测的未来支付趋势。

18.如权利要求8所述的计算机实现的方法，其中所述方法还包括接收并且处理包括非货币式支付的信用数据。

19.如权利要求8所述的计算机实现的方法，其中所述方法还包括接收并且处理小额信贷信用数据。

20.如权利要求8所述的计算机实现的方法，其中所述第二支付网格中的每个条目的所述支付状态是至少部分基于与所述个体的所述第一金融账户关联的一个或多个实际支付周期确定，其中所述一个或多个实际支付周期不同于所述第二支付间隔。

21.如权利要求20所述的计算机实现的方法，其中所述一个或多个实际支付周期比所述第二支付间隔要短。

22.如权利要求20所述的计算机实现的方法，其中所述一个或多个实际支付周期比所述第二支付间隔要长。

23.一种包括计算机可执行指令的非暂时性计算机可读存储介质，所述计算机可执行指令引导计算系统进行以下操作：

接收标识应当生成信用报告的第一个体的报告请求指示；

从一个或多个数据存储检索与所述个体关联的信用数据，其中所述检索到的信用数据包括与所述个体所关联的小额信贷贷款关联的支付状态信息，其中所述小额信贷贷款与一个或多个支付周期关联，由此多个支付每月到期；

确定呈现所述检索到的信用数据的第一支付网格中的每个条目的支付状态，所述第一支付网格具有对应于第一支付间隔的条目，所述第一支付间隔不同于所述一个或多个支付周期；

确定呈现所述检索到的信用数据的第二支付网格中的每个条目的支付状态，所述第二支付网格具有对应于第二支付间隔的条目，所述第二支付间隔不同于所述第一支付间隔以及所述一个或多个支付周期；

呈现信用报告，所述信用报告包括所述第一支付网格，所述第一支付网格具有对应于所述第一支付间隔的条目，其中所述信用报告包括至少一个可选选项，所述至少一个可选选项被配置成导致具有对应于所述第二支付间隔的条目的所述第二支付网格的呈现；以及

至少部分基于用户选择所述至少一个可选选项，呈现所述第二支付网格，所述第二支付网格具有对应于所述第二支付间隔的条目。

24.如权利要求23所述的非暂时性计算机可读存储介质，其中所述第一支付间隔是按周的，并且所述第二支付间隔是按月的。

25.如权利要求23所述的非暂时性计算机可读存储介质，其中所述可执行指令还引导所述计算系统进行以下操作：

接收请求以便基于用户定义的支付间隔生成信用报告；

生成支付网格，所述支付网格具有对应于所述用户定义的支付间隔的条目；以及

确定所述支付网格中对应于所述用户定义的支付间隔的每个条目的支付状态。

26.如权利要求23所述的非暂时性计算机可读存储介质，其中所述可执行指令还引导所述计算系统进行以下操作：

接收请求以便指定支付网格作为金融账户的默认支付网格；以及

响应于对与所述金融账户关联的信用数据的请求，生成所述默认支付网格以供显示。

27.如权利要求23所述的非暂时性计算机可读存储介质，其中所述可执行指令还引导所述计算系统进行以下操作：

接收用于确定第三支付网格中的每个条目的支付状态的用户定义的规则集合；以及

至少部分基于所述用户定义的规则集合确定所述第三支付网格中的多个条目中每个条目的支付状态。

28.如权利要求23所述的非暂时性计算机可读存储介质，其中所述第二支付网格中的每个条目的所述支付状态是至少部分基于与所述个体的所述第一金融账户关联的一个或多个实际支付周期确定，其中所述一个或多个实际支付周期不同于所述第二支付间隔。

29.如权利要求28所述的非暂时性计算机可读存储介质，其中所述一个或多个实际支付周期比所述第二支付间隔要短。