Bill payment and reporting

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 14/164,561, which claims priority as a non-provisional application to U.S. Prov. Pat. App. 61/919,618 filed Dec. 20, 2013, and U.S. Prov. Pat. App. 61/905,112 filed Nov. 15, 2013. The disclosures of each of the foregoing applications are hereby incorporated by reference in their entirety.

U.S. patent application Ser. No. 13/968,784 filed Aug. 16, 2013 and U.S. Prov. Pat. App. 61/70,666 filed Aug. 27, 2013 are also incorporated by reference in their entirety as if set forth herein.

BACKGROUND

The credit score is an important indicator of a consumer's financial health. A consumer's credit score may impact availability and/or terms (e.g., interest rate) of such things as loan applications, rental applications, and real estate mortgages, as well as impacting the consumer's ability to find employment. Therefore, consumers have a substantial interest in monitoring and improving their credit scores.

SUMMARY

Making timely payments and having those payments reported to national credit bureaus may improve a consumer's credit score. In order to ensure on time payments, consumer's may benefit from being able to view their creditors and make payments in one place.

Some embodiments may comprise a computing system with one or more hardware computer processors and one or more storage devices. The storage devices may be configured to store software instructions configured to cause one or more hardware computer processors to perform a number of operations. The operations may access a consumer's credit report. The computing system may extract information from the credit report on the consumer's tradelines to identify accounts belonging to the consumer. The system may also identify other accounts associated with a consumer that are not included in the consumer's credit report. The consumer may be enrolled into online services for one or more of the identified accounts. The computing system may generate a user interface to display the identified accounts and information associated with the identified accounts. The associated information may include account numbers, balances, payment history, statements, or other relevant information. The information may be extracted from the consumer's credit report as well as from electronic sources associated with one or more of the consumer's accounts. The computing system may determine one or more actions the consumer may wish to take on each of the consumer's accounts. For example, the computing system may allow the consumer to make a payment on accounts with outstanding balances. The user interface may provide action buttons to the consumer allowing the consumer to take the determined actions. When an action button is selected, the computing system may initiate the associated action. In some embodiments, the system enables the consumer to make payments to one or more of the identified accounts through the computing system. When the computing receives instructions to make a payment, it may initiate a process to make the payment. The computing system may also report the payment to one or more of the credit bureaus. In some embodiments, the computing system does not report the payment until confirmation of a successful payment is received by the computing system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating some embodiments of a bill payment system

FIG. 2 is a flowchart illustrating various processes that may be performed by the bill payment system, in some embodiments.

FIG. 3 is a flowchart illustrating one embodiment of a process of making a payment through the bill payment system and reporting those payments to a credit bureau.

FIG. 4A is a flowchart illustrating one embodiment of a process performed by the bill payment system to enroll a consumer in online bill services with the consumer's creditors.

FIG. 4B is a sample user interface which enables a consumer to validate accounts, as used in an embodiment.

FIG. 5 is a flowchart illustrating one embodiment of processes performed by the bill payment system to generate payment plans and payment recommendations for a consumer.

FIG. 6A is a sample user interface which presents a consumer with a credit report including several interactive features, as used in an embodiment.

FIG. 6B is a sample user interface which presents a consumer with a credit report including several interactive features, as used in an embodiment.

FIG. 7A is a sample mobile user interface which presents a consumer with a credit report and several contextual action buttons for each tradeline, as used in an embodiment.

FIG. 7B is a sample mobile user interface which presents a consumer with credit information and interactive buttons.

FIG. 7C is a sample mobile user interface which presents a consumer with information about an account with a creditor and provides interactive features.

FIG. 7D is a sample mobile user interface which presents a consumer with accounts and allows the consumer to setup automatic payments.

FIG. 7E is a sample mobile user interface which presents a consumer with account information and provides interactive features.

FIG. 7F is a sample mobile user interface which presents a consumer with account information and provides interactive features.

FIG. 7G is a sample mobile user interface which presents a consumer with account information and provides interactive features

FIG. 8A is a sample mobile user interface displaying alerts sent from a bill payment system, as used in an embodiment.

FIG. 8B is a sample mobile user interface displaying alerts sent from a bill payment system, as used in an embodiment.

FIG. 8C is a sample mobile user interface displaying alerts sent from a bill payment system, as used in an embodiment.

FIG. 8D is a sample mobile user interface displaying alerts sent from a bill payment system, as used in an embodiment.

FIG. 8E is a sample mobile user interface displaying alerts sent from a bill payment system, as used in an embodiment.

FIG. 9 is a sample user interface which presents a consumer with tradelines identified in the consumer's credit report, other accounts, and several contextual action buttons for certain accounts, as used in an embodiment.

FIG. 10 is a sample user interface which presents a consumer with various accounts, and including various payment options and action buttons for certain accounts, as used in an embodiment.

FIG. 11 is a sample user interface which presents a consumer with tradelines sorted so that more important tradelines are illustrated first and/or more prominently, as used in an embodiment.

FIG. 12 is a sample user interface which presents a consumer with tradelines and options to make bill payments, as used in an embodiment.

FIG. 13 is a block diagram illustrating one embodiment of creditors reporting payments received from a consumer's to a creditor bureau.

FIG. 14 is a block diagram illustrating one embodiment of a bill payment system reporting, to a credit bureau, payments made to multiple creditors through the bill payment system.

FIG. 15 is a block diagram illustrating one embodiment of the bill payment system reporting, to a credit bureau, payments made to multiple creditors through the bill payment system.

DETAILED DESCRIPTION

Although several embodiments, examples and illustrations are disclosed below, the inventions described herein extends beyond the specifically disclosed embodiments, examples and illustrations and includes other uses of the inventions and modifications and equivalents thereof. Embodiments are described with reference to the accompanying figures, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner simply because it is being used in conjunction with a detailed description of certain specific embodiments of the invention. In addition, various embodiments can comprise several novel features and no single feature is solely responsible for its desirable attributes or is essential to practicing the inventions herein described.

Traditional credit reports typically present information in a spreadsheet-like view, with columns that present data from the three major credit bureaus and rows that present a consumer's different tradelines (e.g., credit accounts) as well as credit inquiries of the consumer's credit that have been made by different companies (e.g., as part of an application for credit). The traditional credit report is more of a business view of the consumer's credit data, that was never really intended for the average user to see until federal regulations enabled consumers to receive their credit report from each of the three bureaus for free very year. Thus, credit reports became much more common and accessible to consumers. A consumer with access to their credit report may wish to actively manage the information presented on the report to improve their perceived credit worthiness. For example, consumers may wish to improve their credit score, decrease their debt, pay their bills, or take other actions related to the accounts present on a credit report.

System Block Diagram:

FIG. 1 is a block diagram illustrating one embodiment of a bill payment system 100 that may be used to implement certain systems and methods discussed herein, such as providing a credit report to a consumer, gathering a consumer's account data, enabling a consumer to take actions on one or more accounts, alerting a consumer to account activity or updated credit reports, processing payments to one or more creditors, and reporting payments made through the system to one or more credit bureaus. Each of these features is discussed further below with reference to various other figures.

In one embodiment, the bill payment system 100 is configured to interface with multiple devices and/or data sources. The bill payment system 100 may be configured to implement certain systems and methods described herein. The functionality provided for in the components and modules of the bill payment system 100 may be combined into fewer components and modules or further separated into additional components and modules.

In general, the word module, as used herein, refers to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language such as, for example, C, C++, C#. A software modules may be complied and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Java, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves or may be invoked in response to detected events and interrupts, or both. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware modules may be comprised of connected logic units, such as programmable gate arrays or processors. The modules described herein are preferably implemented as software modules, but may be represented in hardware or firmware. Generally, the modules described herein refer to logical modules that may be combined with other modules or devices into sub-modules despite their physical organization or storage.

In one embodiment, the bill payment system 100 includes, for example, one or more servers or personal computers that are IBM, Macintosh, or Linux/Unix compatible. In another embodiment, the bill payment system 100 includes one or more laptop computers, smart phones, personal digital assistants, or other computing devices. The bill payment system 100 may include a memory 130, which may include a random access memory (“RAM”) for temporary storage of information, a read only memory (“ROM”) for permanent storage of information, and/or a mass storage device, such as a hard drive, diskette, optical media storage device, or USB flash drive. Typically, the modules of the monitoring system are in communication with each other via a standards based bus system. In different embodiments, the standards based bus system could be Peripheral Component Interconnect (PCI), Microchannel, SCSI, Industrial Standard Architecture (ISA), and Extended ISA (EISA) architectures, for example.

The bill payment system 100 may be generally controlled and coordinated by operating system software, such as Windows 95, 98, NT, 2000, XP, Vista, 7, 8, SunOS, Solaris, Blackberry OS, or other compatible operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X. In other embodiments, the Bill payment system 100 may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file systems, networking, and I/O services, and provide a user interface, such as a graphical user interface (“GUI”), among other functions.

The example bill payment system 100 shown in FIG. 1 includes one or more commonly available input/output (I/O) interfaces and devices 111, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O interfaces and devices 111 include one or more display devices, such as a monitor, that allow the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. The Bill payment system 100 may also include one or more multimedia devices 140, such as speakers, video cards, graphics accelerators, and microphones, for example. In one embodiment, the I/O interfaces and devices 111 comprise devices that are in communication with modules of the bill payment system 100 via a network, such as the network 160, or any local area network, including secured local area networks, or any combination thereof. In some embodiments, multimedia devices 140 and I/O interfaces and devices 111 may be contained in computing devices 162.

In the embodiment of FIG. 1, the bill payment system 100 also includes modules that may be executed by the CPU 105. In the embodiment of FIG. 1, the bill payment system 100 includes an account data gathering module 150, a user interface module 110, a payment module 170, a payment reporting module 180, an alert module 195, and an account validation module 190. In this embodiment, the account data gathering module 150 is configured to gather data about one or more of a consumer's accounts. This data may come from creditors 164, credit bureaus 106, other data sources 166, and/or the consumer. The credit data may include the consumer's credit report as well as one or more credit scores for the consumer, such as a FICO score, a credit score proprietary to a particular credit bureau, and/or a multi-bureau credit score, such as a VantageScore. In some embodiments, the credit score that is used by the payment system 100 advantageously considers rental payment history (e.g., history of rental payments for a residence of the consumer) in generated credit scores. Thus, in such embodiments the credit score is weighted based on the rental payment history of the consumer. VantageScore is one example of a credit score that currently considers rental payment history in its credit scores.

Credit data may also include data not typically on credit reports such as the consumer's income, rental payments, or other financial information about the consumer. The payment module 170 is configured to process payments from a consumer's account to pay one or more creditors 164. The payment reporting module 180 is configured to report payments made by the payment module 170 to the credit bureau 106, such as to provide payment information that may be added to credit data of the consumer quicker than waiting for reporting of the payment from the creditors that receive the payments. Payments may be reported directly to the credit bureau 106 over network 160, or may be made through an intermediate third party. The account validation module 190 checks the authenticity of a consumer's accounts. The accounts may be validated with data from a credit bureau 106, a creditor 164, other data sources 166, and/or data from computing device 162. The alert module 195 alerts a consumer about activity on one or more accounts associated with the consumer or the consumer's credit report. These may be accounts validated through account validation module 190, with new data provided over network 160 by creditors 164, credit bureaus 106, and/or other data sources 166.

High Level Flow Chart:

FIG. 2 is a flowchart illustrating various processes that may be enabled by the bill payment system 100, such as various processes associated with a consumer paying bills through interaction with a credit report. In one embodiment, the process of FIG. 2 is performed by the bill payment system 100, such as by the various modules discussed above. In other embodiments, the process (or portions of the process) may be performed by any other computing device. For example, portions of the process may be performed by a consumer device that interfaces with the bill payment system 100. Depending on the embodiment, the method of FIG. 2 may include fewer or additional blocks and the blocks may be performed in an order that is different than illustrated,

Beginning in block 210, the Bill payment system 100 accesses a consumer's credit report. The Bill payment system 100 may access the credit report at the request of the consumer, periodically as part of a credit monitoring service, or at another time of interest to the consumer.

Moving to block 220, the Bill payment system 100 determines a consumer's accounts from tradeline information in the consumer's credit report. Each tradeline may be a single line in a credit report stating information about a particular consumer financial account. Consumers may have few or multiple tradelines on their record, such as credit card accounts, mortgages, automobile loans, other loans, and/or other credit accounts. Together, all tradelines reported on a specific consumer can be used to determine the consumer's overall risk or creditworthiness. Each tradeline on the consumer's credit report may include information about the associated account, which may include account numbers, account balances, payments history, credit limits, interest rates, and/or other information relevant to a particular account. Bill payment system 100 can use one or more of these pieces of information to identify the consumer's accounts.

In Block 230, the bill payment system 100 identifies other accounts associated with a consumer, such as accounts that do not appear on the consumer's credit report. For example, some utility companies may not report payments to the credit bureaus and need to be identified from other sources. This may be done at the consumer's direction or from information provided by the consumer. For example, in some embodiments, the consumer may provide information about an account with a cable company to bill payment system 100. In Block 230, the system may then identify and access the consumer's specific account and associated details. In some embodiments, bill payment system 100 may automate one or more steps in the process. For example, bill payment system 100 may use the consumer's address from the credit report and determine which cable companies provide service to that location. Using the consumer's identifying information or provided account information, the bill payment system may then determine which cable company (if any) the consumer has an account with.

In Block 240, the bill payment system 100 enrolls the consumer in electronic bill payment and presentment services for each of the determined creditors. This may include creditors identified in Block 220 as well as those identified in Block 230. This may be done automatically for each account with available electronic bill payment capabilities, or only for accounts in which the consumer requests enrollment. If a consumer is enrolled in electronic payment and presentment services, the bill payment system 100 may present the consumer with options to view payment history for that account, account statements, current balances, amounts due, payment due dates, or other information provided by the creditor as part of its online bill payment and presentment services. Enrolling a consumer in a creditor's online services is discussed further below in reference to FIG. 4A.

Continuing to Block 250, the bill payment system 100 updates the credit report data with current data indicating updated account information received direct from the creditor and/or recent payments made to various creditors via the bill payment system 100, each of which may not be immediately indicated in the consumer's credit report. For example, a credit report may not be updated immediately when a payment is made or an account's balance changes. However, a consumer may wish to view more up-to-date balances on tradelines, such as to determine a payment to make on the tradelines. Therefore, in some embodiments, the bill payment system 100 updates that account data with the current data, such as data directly from the tradelines or based on payments sent to the tradeline via the bill payment system 100, from each of the tradelines. This may be done for all accounts or only for accounts where the service is requested by the creditor. In some embodiments it is done for all accounts that the bill payment system enrolls the consumer in, such as in block 240. In one embodiment, the account data provided to the consumer includes both a balance directly from the credit report data, as well as a balance that includes updated information obtained by the bill payment system, such as directly from the various accounts and/or completed payment information that has not yet been reflected on the credit report. Thus, the consumer may be able to view both balances, such that a difference between the balance obtained from the credit report and the balance that has been updated with more current information available to the bill payment system may be considered side-by-side.

In Block 260, the bill payment system sorts the consumer's tradelines based on one or more of various criteria, such as based on impact of the various account balances on the consumer's credit score. For example, accounts with the largest impact on the consumer's credit score may be shown first. In other embodiments, accounts may be sorted based on the amount of negative effect the account has on a user's credit score, the credit usage percentage, the impact on a consumer's credit score if a payment is not received soon, payment due dates, and/or any other criteria which influences a consumer's credit score, or other financial goals.

In Block 270, the bill payment system 100 generates a payment recommendation for each tradeline or other account. The recommendation may be based on one or more goals provided by the consumer, the consumer's ability to pay, and/or other factors. For example, goals may include increasing a credit score, paying off debt, purchasing a new car or house, or other financial goals chosen by the consumer. Generating recommendations for each account associated with a consumer is discussed further below in reference to FIG. 5.

In Block 280, the bill payment system 100 provides the consumer with contextual action buttons for each tradeline presented in a user interface to the consumer. The status of accounts associated with each tradeline may prompt a consumer to take certain actions. For example, an account with a past due payment may prompt a consumer to take immediate action to make a payment, or a new late payment on a tradeline may prompt a consumer to dispute the late payment with the creditor or credit bureau. In some embodiments, the bill payment system automatically determines one or more actions associated with a respective tradeline and provides action buttons allowing a consumer to take one or more actions in response to the status of each account. For example, if a bill has a balance due, the system may provide an action button allowing a consumer to make a payment. In some embodiments, the consumer may set up rules that allow the bill payment system to automatically take any (or certain) actions that are determined to be relevant to a particular tradeline. For example, if the bill payment system determines that a payment to a particular tradeline is due within a short period of time, and that a potential negative impact will be seen in the consumer's credit data (e.g., credit score) if the payment is not made, the bill payment system 100 may be configured to automatically make the payment without further interaction from the consumer. Contextual action buttons are discussed further below in reference to the user interface illustrated in FIGS. 6-12.

In block 290, the bill payment system 100 reports payments made through payment module 170 to one or more credit bureaus. To improve his or her credit score, a consumer not only needs to pay off debt and make timely payments on credit accounts (among other items), but also needs those payments reported to the credit bureau. While many creditors report payments to one or more credit bureaus, the creditors often only report the information at set periodic intervals. For example, a creditor may accumulate credit payment (or lack of payments) from many consumers for 30 or 60 days before reporting the payments to a credit bureau. Therefore, a consumer may make a payment, but may experience a significant delay before the payment appears on the consumer's credit report. If the payment does not show up on the consumer's credit report, the consumer's credit score and perceived creditworthiness may not be positively impacted (and may actually be negatively impacted if such a delay gives the appearance that the creditor is not paid in a timely manner). Therefore, it would be advantageous to a consumer if payment could be reported to the credit bureau sooner. In some embodiments, the bill payment system 100 reports payments made via the bill payment system 100 directly to a credit bureau, while in other embodiments, the system may report through a third party or other modules. Reporting payments to credit bureaus is discussed in more detail below in reference to FIGS. 3, 13, 14, and 15.

Example Payment Reporting

FIG. 3 is a flowchart illustrating one embodiment of a process of making a payment through the bill payment system and reporting those payments to a credit bureau, such as in block 290 of FIG. 2. The processes described in reference to FIG. 3 are discussed further below in reference to FIGS. 13-15. Depending on the embodiment, the method of FIG. 2 may include fewer or additional blocks and the blocks may be performed in an order that is different than illustrated.

Beginning at block 310, the bill payment system 100 receives instructions to make a payment to a creditor. Those instructions may be provided by the consumer at the time payment is to be made, may have been provided previously, or may be initiated automatically in view of system and/or user bill payment rules. For example, as discussed in reference to block 280 of FIG. 2, the system may provide the consumer with an action button allowing the consumer to make a payment. In some embodiments, the bill payment system 100 automatically makes payments to the consumer's creditors based on prior authorization. For example, a consumer may authorize bill payment system 100 to manage the consumer's debt, or may set recurring payments of a specified amount for one or more of the consumer's accounts. In one embodiment, the bill payment system 100 automatically determines (e.g., based on system and/or consumer preferences) to which creditors payments should be made, amounts of payments to be made, and/or dates for the payments, such as in order to minimize negative impact on the consumer's credit score. Thus, payments to creditors may change from month to month in order to minimize negative impact (or cause positive impact) on the consumer's credit score. The user may also select different payment options for different accounts.

In block 320, the bill payment system 100 processes a payment as instructed by the consumer. The payment may be processed by the payment module 170 or with other hardware or software. Payments may be made in a variety of ways based on the consumer's ability to pay, his preferences, and/or constraints on the system. For example, in some embodiments, the user has deposited money with the bill payment system 100 and the bill payment system may process payments by sending those funds to the creditors. Payments made with the consumer's deposited funds allow the system to immediately process payments. Similarly, the consumer may have provided the bill payment system 100 with access to one or more payment accounts, such as checking or savings accounts, from which funds may be drawn in order to make payments to various creditors. However, in some embodiments the user may not have money deposited with the system and/or sufficient funds in any linked payment accounts to make a particular payment. This may be because the consumer has not made any deposits, has depleted deposited funds with previous payments, or the system may not allow the consumer to deposit funds. In some embodiments the bill payment system 100 may automatically pay the consumer's bills as instructed and collect payments from the consumer at a later time. For example, if the consumer has a payment due, but has not instructed the bill payment system 100 to make the required monthly payment, the bill payment system 100 may make a payment so it will not be considered late, and then may collect from the consumer at a later date. In effect, the consumer may have a short term loan with the bill payment system 100. Depending on the embodiment, if payments are made for the consumer in this manner, the consumer may be charged interest on the payment amount for the duration of the time it takes for the consumer to provide sufficient funds to one or more linked bank accounts or directly to the bill payment system 100 to cover the payment. Alternatively, the consumer may be charged a flat fee for the bill payment system making such a payment on behalf of the consumer, perhaps contingent on the consumer providing reimbursement of the payment amount within a particular time period, such as one week or one month.

In one embodiment, clicking on a pay bill button associated with a credit account of the consumer initiates automatic payment of that bill by the bill payment system (e.g., based on preferences that have been pre-established by the consumer, such as whether to pay a minimum payment amount or the entire outstanding balance on the particular account) without any further interaction from the consumer. For example, the bill payment system 100 may have access to both the consumer's bank and credit account information. In such circumstances, the bill payment system 100 may automatically remove money from the consumer's bank account to transfer to the creditor when instructed to make a payment.

In other embodiments, clicking on a “pay bill” button associated with a credit account of a consumer doesn't instantly pay the bill. Instead, the bill payment system 100 and/or payment module 170 may direct the user to a bill payment center in response to the consumer clicking a “pay bill’ button. The bill payment center may then offer the user the ability to pay the individual bill the consumer selected, or any other bills identified by the credit reporting system 100. In other embodiments, clicking a “pay bill” button may bring the consumer to a third party website. For example, clicking on the “pay bill” button on the consumer's Discover card tradeline may direct the consumer to the Discover card website. From the third party website the consumer can then the bill.

In block 330, the bill payment system 100 validates that a payment initiated via the bill payment system 100 has been successfully received by the intended creditor, such that the payment can be accurately reported to one or more credit bureau. For example, this may be performed by the payment module 170, payment reporting module 180, or other suitable hardware or software. Payments may be validated in several ways. In some embodiments, the bill payment system 100 makes payment directly to a creditor using funds available to the bill payment system 100. In such embodiments, the system may receive feedback from the creditor if the payment was successful (or not). At that point, the process of reporting to the credit bureau may continue in step 340. In some embodiments, the system doesn't make payments directly to the creditor, or doesn't receive feedback of successful payment immediately from the creditor. In those cases, the bill payment system may validate the payment by monitoring the consumer's outstanding balance with the creditor (e.g., such as by accessing account data of the consumer via an API associated with the particular creditor and/or accessing the account data by logging into the consumer's account using the consumer's login credentials by proxy), viewing payment history on the creditor's, monitoring bills listed as due by the creditor, or receiving other communications from the creditor.

In block 340, the bill payment system 100 reports the payment to a credit bureau. In some embodiments, the bill payment system 100 reports the payment directly to the credit bureau. In some other embodiments, the bill payment system 100 may report the payment to a third party credit reporter who then reports payments to the credit bureau.

In block 350 the bill payment system 100 provides an indication to the creditor that the bill payment was reported to one or more credit bureau. The creditor may then avoid reporting that same payment to the credit bureau in order to avoid duplicate reports of the same account activity, and possibly introduce errors in the consumer's credit information. In some embodiments, instead of providing an indication to the creditor that the bill was reported, the bill payment system 100 may indicate to the credit bureau that the payment information is likely to be reported a second time by the creditor. Then the credit bureau may prepare for the duplicate information to keep accurate records of the consumer's information. Example processes of reporting payments to one or more credit bureaus are discussed further below in reference to the block diagrams shown in FIGS. 13-15.

Example Automatic Online Account Enrollment

FIG. 4A is a flowchart illustrating one embodiment of a process performed by the bill payment system 100 to enroll a consumer in online bill services with each (or some) of the consumer's creditors. Many creditors offer one or more online services to customers. Services may include viewing bills, viewing payment history, viewing statements, making payments, or other services related to the consumer's accounts. However, to access these features, a consumer must typically visit each individual creditor's website. Websites which allow a consumer to view account data from multiple creditor's in one place require the consumer to input various information about each account in order to set up access. The method of FIG. 4A provides improved processes of enrolling consumers in bill presentment and/or payment features of various accounts. Depending on the embodiment, the method of FIG. 4A may include fewer or additional blocks and the blocks may be performed in an order that is different than illustrated.

Beginning in block 410, the bill payment system 100 determines a consumer's credit accounts from the consumer's credit report, similar to the process discussed above with reference to block 220. Tradelines on a consumer's credit report list valuable account data which bill payment system 100 may analyze to determine the specific credit accounts associated with the consumer.

In block 420, the bill payment system 100 receives account information on other accounts associated with the consumer not listed on the consumer's credit report, similar to the process discussed above with reference to block 230. These other accounts may include utility bills, savings accounts, checking accounts, rent, and/or other liabilities and assets that are not reported to a credit bureau. The bill payment system 100 may provide other features and more useful services to the consumer if it has access to more information about the consumer's overall financial situation.

In block 430, the bill payment system 100 validates the authenticity of accounts associated with the consumer. This may be performed by an account validation module 190, or by other hardware or software components of the bill payment system 100. Without any account validation functionality, consumers may have an incentive to create other accounts to increase their credit score without making actual payments. For example, a consumer's credit score may increase if the consumer generates a history of on time payments to a creditor. However, without proper account validation, a consumer could have phony rent payments to a friend, made through the bill payment system 100, and reported to one or more credit bureaus by the bill payment system in order to increase the consumer's payment history. However, if the consumer is not actually renting property from the friend, the payments should not be reported to the credit bureau as a representation of the consumer's creditworthiness. To prevent consumers from gaming the system in this manner, account validation may be performed for any accounts which will have payments reported to the credit bureau. In some embodiments, some accounts, such as credit card accounts listed on a consumer's credit report, may be assumed to be valid. However, other creditors, such as a consumer's landlord or accounts that are added to the consumer's account via other methods than being on the consumer's credit report (e.g., manually added by the consumer), may need additional validation before payments to those creditors are reported. In some embodiments, the consumer is prompted to provide evidence that an account is authentic. For example, the consumer may provide a copy of his utility bills, phone plan, rental lease, or other information which could demonstrate that payments to a consumer's creditor are authentic. Authentication documents may be provided in hard copy, by scanning documents, by taking a picture of bills with the consumer's camera or phone, or by other means of reliably reproducing documents. In the example of FIG. 4B, the consumer is prompted to upload a copy of a lease agreement to the bill payment system 100. The bill payment system 100 may then authenticate the document (e.g., automated document analysis and/or manual document analysis) to validate the consumer's account. Once the account has been validated, the bill payment system 100 can report rent payments to one or more credit bureaus. The bill payment system 100 may also have automated processes for determining if payments are to a legitimate source. For example, the bill payment system 100 may receive electronic confirmation of an account's authenticity from a trusted source. In the example of FIG. 7B, the consumer is provided with options to add accounts for each of four different types of payments, rent, credit card, utilities, and loans. In one embodiment, each of the types of accounts is associated with a different type of validation. For example, if the consumer wishes to add a credit card account, the account may be validated by testing credentials provided for the credit account using a service such as may be provided by Yodlee or Fiserv, while if the consumer wishes to add a loan account, the consumer may be required to provide a photograph of a loan statement, which may then be processed (either automatically and/or manually) in order to determine if the consumer really holds the account. Thus, in one embodiment the bill payment system 100 is configured to initiate different validation processes (e.g., logging in by proxy, providing photographs of statements, bills, agreements, etc.) for different account types that are added to the consumer's account.

In block 440, the bill payment system 100 enrolls the consumer in electronic payments and/or statements for associated accounts. For accounts listed on the consumer's credit report, this may be done automatically based on the account information listed in the report and the personal information provided by the consumer. In some embodiments other processes are required to enroll the consumer in accounts not listed on the consumer's credit report. For example, to enroll in statements from the consumer's checking account, the bill payment system 100 may require the consumer's account numbers. In some embodiments, the bill payment system 100 may require the consumer to manually enroll in online services and then supply the bill payment system 100 with username and password information.

In block 450, the bill payment system 100 provides the consumer with electronic statements from each account for which the consumer is enrolled in online statements. The statements may be viewed after the consumer selects an action button to view statements for a particular account. The bill payment system 100 may also aggregate all of the consumer's statements to present to the consumer in a user interface.

Example Methods of Determining Recommended Payments

FIG. 5 is a flowchart illustrating one embodiment of processes performed by the bill payment system 100 to generate payment plans and payment recommendations for a consumer. In some embodiments, the bill payment system 100 uses information from the consumer's accounts to generate payment recommendations for a consumer. For example in systems with the processes discussed in FIG. 4A, the bill payment system 100 may provide recommendation based on the consumer's total liabilities and assets. In other embodiments, the bill payment system 100 may make recommendations based on fewer or additional pieces of information, such as constraints set by the consumer. Depending on the embodiment, the method of FIG. 5 may include fewer or additional blocks and the blocks may be performed in an order that is different than illustrated.

In block 510 the bill payment system 100 accesses information on accounts associated with a consumer. Data about these accounts may be accessed in a manner similar to those discussed above in reference to FIG. 4A.

In block 520, the bill payment system 100 receives one or more goals from the consumer. Typical goals may include increasing the consumer's credit score, paying off the consumer's debt, purchasing a home, or other financial or life goals. In some embodiments the bill payment system 100 receives this information directly from a consumer. For example, the system may ask the consumer for goals when the consumer firsts accesses the bill payment system 100. In other embodiments, the bill payment system 100 may not generate recommendations until the consumer provides at least one goal, or may make recommendations using a default goal unless the consumer provides a specific goal. In some embodiments, the bill payment system monitors the consumer's interactions with the bill payment system 100, and/or other information about the consumer (e.g. types of account open, spending habits, age, sex, race, etc.), to automatically generate goals and priorities for the consumer.

In block 530 the credit report service 100 generates a payment plan for the consumer based on the consumer's goals or priorities, the consumer's available funds, the amount due on the consumer's accounts, the balance remaining on each account, interest rates, and/or other available information about the consumer. The payment plan may include information such as which accounts to pay for first, which accounts to pay the most money toward, minimum balances to keep in certain accounts, etc. For example, if the consumer's goal is to pay down the total debt, the bill payment system may generate a payment plan that makes minimum payments on all accounts and makes the maximum payment possible with current funds toward the account(s) with the highest interest rate. Further examples of payment plans are discussed below in reference to FIG. 9.

In block 540, the bill payment system determines a recommended payment for each account based on the generated payment plan. For example, with a payment plan focused on paying off debt, if the consumer has only two credit accounts, one with 10% interest and one with 5% interest, the bill payment system 100 may recommend the minimum payment on the account with 5% interest and a payment as much as the consumer can afford toward the account with 10% interest.

In block 550, the recommended payments are provided to the consumer. Some examples of providing recommended payments are discussed further below in reference to FIG. 9.

The flowcharts illustrated in FIGS. 2-5 and described above are example processes which may be performed by the bill payment system 100 and/or other suitable computing systems, such as consumer computing devices. In some embodiments, fewer or additional blocks may be present, or the processes may be performed in a different order than shown in the figures.

Sample User Interfaces:

The bill payment system 100 may present one or more user interfaces to the consumer through computing devices 162. In some embodiments, the user interfaces may be generated and/or configured by a user interface module 110, but one or more functions of the user interface module may be performed by one or more other modules, or other suitable hardware or software components.

In the user interface illustrated in FIG. 6A, the bill payment system 100 presents the consumer with a credit report. Depending on the embodiment, the credit report may be based on credit data from a single credit bureau or from data from multiple credit bureaus. The credit report presented in FIG. 6A provides the consumer with more information than a typical credit report and also allows the consumer to take actions based on information contained in the credit report. For example, the consumer is presented with action buttons associated with respective tradelines and updated balances.

As discussed in reference to Block 280 in FIG. 2, the bill payment system 100 may provide the consumer with contextual action buttons for tradelines presented in a user interface to the consumer. The action buttons enable a consumer to take actions related to one or more accounts. For example, an account with a past due payment may prompt a consumer to take immediate action to make a payment, or a new late payment on a tradeline may prompt a consumer to dispute the late payment with the creditor. In some embodiments, the system provides action buttons allowing a consumer take an action in response to the status of each account. For example, if a bill has a balance due, the system may provide an action button allowing a consumer to make a payment. Common action buttons may enable the consumer to make bill payments, view account statements, order credit reports, initiate loan refinancing, apply for new credit cards, compare credit cards, enroll in a creditor's online services, schedule automatic payments for one or more creditors, or take other actions relevant to a tradeline's current statue.

In the example of FIG. 6A, the consumer's home loan account 610 appears on the credit report. The bill payment system 100 generated and provided several actions buttons based on the account data of the home loan. In the example of FIG. 6A, the loan has an outstanding balance, and therefore, the bill payment system 100 has automatically provided an action button 612 offering the user an opportunity to make a payment. In this example, the bill payment system 100 also provided a refinance action button 614 to initiate a mortgage refinancing, such as in response to determining that better terms may be available to the consumer than those in the current Home Loan. The bill payment system 100 may have access to the interest rate charged on the loan, current interest rates, interest rates at the time the loan was made, the consumer's current credit score, the consumer's credit score when the loan was made, and/or other information which may allow the bill payment system 100 to determine if the consumer is likely to receive a lower interest rate by refinancing a loan. Furthermore, in some embodiments the bill payment system 100 may request loan rates from one or more data sources (e.g., such as specific financial institutions that offer loans of the type needed and/or loan aggregators) in order to determine one or more specific loans that the consumer may apply for in order to improve loan terms. In other embodiments, the refinance action button 614 may be offered on all home mortgages.

The Discover account 620 listed in the credit report in FIG. 6A presents the consumer with a card comparison action button 622 that provides a comparison of credit cards available to the consumer, such as to allow the consumer to find a card with a better rewards program. This action button 622 may be presented to the consumer because the bill payment system 100 determined there are credit cards with similar terms, but better rewards than the consumer's current card. In some embodiments, actions buttons may offer advertisements from lenders or other entities based on the consumer's current credit cards and credit history. For example, action buttons may bring the consumer to an advertiser's website to complete an application, or may automatically complete an application on the consumer's behalf.

The CitiOne account 630 listed in the example credit report in FIG. 6A presents the consumer with an action button to setup automatic payments 631. If a consumer selects the automatic payments action button 631, the consumer may be presented with options to setup automatic payments. For example, the system may allow the consumer to select when to make payments or how large a payment to make (e.g., options may be provided to automatically pay the minimum payment amount, the statement balance, the current amount due, a fixed amount, or a set percentage of one of the above, for example). In some embodiments, selecting the automatic payment action button 631 may automatically change the bill payment system's settings to make automatic payments to the consumer's creditor. For example, clicking the automatic payment action button 631 may set the systems settings to automatically make minimum payments to the consumer's CitiOne account 631. In some embodiments, the bill payment system 100 provides an action button to setup automatic payments for each of the consumer's creditors to which the consumer is not automatically making payments (e.g., based on predefined preference of the consumer and/or system default preferences, such as regarding payment amount and payment date). FIG. 7D, as discussed below, illustrates an example user interface for setting up automatic payments on a mobile device.

Bill payment system 100 may determine which action buttons to include for respective tradelines by defining attributes for each of the consumer's accounts. The system may then compare the attributes to a list of attributes which trigger certain action buttons. In some embodiments, bill payment system 100 may track the actions buttons selected by consumers, and the attributes of the associated account. The system can then optimize the action buttons presented to the consumer (and/or to other consumers) based on selection of previously presented action buttons.

Clicking on a payment action button, such as payment action button 624 associated with the Discover account 620, may immediately pay the consumer's bill, bring the consumer to a bill payment center, or transfer the consumer to a third party site from which the consumer can pay his bill (e.g. the creditor's site). For example, in FIG. 6A, the user interface includes “Pay Bill” action buttons associated with each tradeline, which may be selected by the consumer in order to initiate automatic payment of the bill without further input from the user (e.g., a one click automatic payment button), may take the consumer to another user interface where the consumer is able to select a payment account and/or other payment options in order to complete the payment (e.g. ACH, credit card, debit card, PayPal, etc.), and/or may provide the user with a payment center user interface that provides other payment options for the particular tradeline and/or other tradelines. In some embodiments, the bill payment system 100 determines rules for automatic payment of bills of the consumer, such as based on input of such rules by the consumer. For example, a consumer may desire that any bill having a deadline within one day is automatically paid by the bill payment system 100 in order to avoid the tradeline having a past-due indicator in the consumer's credit file and potentially negatively impacting the consumer's credit score. Similarly, a consumer may desire to have the bill payment system 100 automatically pay bills according to account prioritization's (e.g., based on impact on credit score, as discussed above) such that the consumer is not required to provide any input in order to have bills from various creditors automatically paid. In essence, the consumer may be able to rely on the bill payment system 100 making payments of the consumer's bills in the manner that is most advantageous to the consumer's credit score. In this regard, the bill payment system 100 may also have logic to select an appropriate payment account of the consumer, such as based on balance information of multiple accounts and considering upcoming payments associated with the consumer. Examples of bill payment processes are discussed above in reference to block 320 of FIG. 3.

The example user interface in FIG. 6A has “View Statements” action buttons, such as view statement action button 626 associated with the Discover account 620, enabling the consumer to view statements for each account. Clicking such an action button may present the consumer with one or more statements associated with the corresponding account. If the consumer has not enrolled with the creditor to view online statements, the bill payment system 100 may prompt the consumer to enroll in online statements when the consumer attempts to view statements. Alternatively, the bill payment system 100 may automatically enrolled the consumer in online statement viewing with the corresponding creditor, if sufficient information is available to complete the enrollment automatically. The bill payment system may present the consumer with statements as part of the bill payment system, or may direct the consumer to view statements at a creditor's site. In some embodiments the bill payment system 100 may cause the consumer's computing device 162 to download files containing the statements. The bill payment system 100 may also store the payments made through the payment module 170. This may allow the bill payment system 100 to provide a complete view of prior statements and payments to a consumer. For example, bill payment system 100 may aggregate payments and billing history of multiple tradelines into a single user interface, such that the user can view payment and billing information across multiple accounts more easily.

A consumer may also see one or more alerts when viewing the user interface. Alerts may take any form indicating important information to the consumer. For example, the consumer may see pop-up bubbles, icons which the consumer clicks on to see alert text, symbolic icons, color coding, audio such as chimes or speech, or other audio or visual indicators highlighting important events on the consumer's credit report. For example, some alerts may include the availability of new bills or statements, changes to the consumer's credit score, payments processed by the bill payment system, payments reported by the bill payment system, new data available on the consumer's credit report, and/or bills due soon or past due. For example, in FIG. 6A, the consumer is presented with two alerts in the form of pop-up bubbles. The first alert 628 indicates that the consumer has a bill due soon. In this example, the alert 628 also provides the consumer with an estimate of the amount the consumer's score will drop if the bill is not paid on time (or possibly within a known grace period for payment and/or for reporting past due payments to the credit bureaus). The second alert 618, which is associated with the home loan account 610, indicates that the consumer has been enrolled in the creditor's electronic payments and bill payment services as discussed in reference to FIG. 4A above. As discussed elsewhere, enrollment in the bill payment service may be entirely automated by the bill payment system 100 and/or may include various levels of input from the consumer in order to coordinate the bill payment linkage with the creditor.

In some embodiments, the consumer may also receive alerts when one or more of the consumer's accounts are validated as describe in reference to block 430 of FIG. 4A above. FIG. 6B illustrates an example user interface with an alert 650 to the consumer that a new account has been validated. Rent account 655 is also now available as part of the consumer's credit report. In some embodiments, the account may not appear on the consumer's credit report until after a first payment has been reported to one or more credit bureaus.

A consumer may only wish to receive alerts from some accounts. As illustrated in FIG. 6A, the consumer may be able to select an enroll alerts checkbox 629 in order to enroll, turn on, turn off, and/or adjust alerts for specific accounts. In one embodiment, when the checkbox 629 is selected, the consumer is presented with an alert user interface that allows the consumer to adjust preferences for alerts on that particular account. For example, the consumer may be able to adjust which events generate alerts. For example, the consumer may only want to receive alerts when there is a danger of a negative impact on the consumer's credit score.

In some embodiments the consumer may access the bill payment system 100 from a computing device 162 as a website viable in a browser, a mobile website, as mobile app, a widget, and/or other combination of hardware and software which allow the consumer to interact with the bill payment system 100. FIGS. 7A-7G illustrate examples of mobile user interfaces. The mobile interfaces may include the same or similar features as the user interface described in reference to FIG. 6A, or may contain fewer or additional features. For example, FIG. 7A shows many of the same features as FIG. 6A, in a similar format to FIG. 6A, however the interface is presented on a mobile device.

In other embodiments, mobile user interfaces may be more focused on allowing the consumer to perform a fewer number of functions on a single screen. For example, FIG. 7B illustrates a user interface a consumer may see on a mobile device. In FIG. 7B, the consumer is shown a credit score, an available balance at a payment account, and buttons representing categories of bills which the consumer may have. The available balance may be the balance at a particular bank where the consumer has an account, the balance at a deposit account associated with the bill payment system 100, an aggregation of the consumer's available balances at more than one location, or another calculation of the balance a consumer can spend toward bills. In some embodiments, the consumer may be shown fewer or additional pieces of information, such as balances in multiple bank accounts. In some embodiments, the buttons shown on the user interface may change depending on the accounts associated with the consumer.

Clicking on one of the buttons on the sample user interface in FIG. 7B may bring the consumer to another user interface that allows the consumer to make payments to a particular account. For example, in FIG. 7C, the consumer is presented with the information necessary to make a payment on a utility bill. The consumer is presented with checkboxes to determine both what amount to pay, and which account to make the payment from. In other embodiments the user interface may enable the consumer to enter custom payment amounts, or select split the payments between more than one payment accounts. The consumer is presented with options to schedule a payment at a later date, or to select a button to make an immediate payment.

In the example user interface of FIG. 7D the consumer is presented with the option to set up payments on Rent, Utility, Loan, and Credit Card accounts. These accounts may be recognized by the bill payment system 100 in any of the manners discussed above, such as from a consumer's credit data, a consumer's financial accounts, or from input from the consumer. The bill payment system may show only accounts for which the consumer has not already set up automatic payments, or may provide the consumer with a listing of all of the consumer's accounts so the consumer can determine whether or not to automatically pay each account by toggling, for example, a checkbox. In the example of FIG. 7D the consumer may set up payments by selecting a checkbox for each account and then clicking the “Setup AutoPay” button. In some embodiments, the consumer may be able to set rules for automatic payment of one or more of the consumer's accounts before setup of payments is complete, such as which account to pay from, how much to pay, or when to make a payment (e.g., payments may automatically be made in order to reduce negative impact on the consumer's credit score).

FIGS. 7E, 7F, and 7G demonstrate other embodiments of bill payment user interfaces which may allow a consumer to setup automatic payments or to make immediate payments. The user interfaces may automatically change based on the type of account that is being presented as well as the capabilities of the specific creditors. For example, in FIG. 7E, the consumer is presented with the ability to make a rent payment. The consumer may be seeing this user interface because he/she selected the “Rent” button on the sample user interface in FIG. 7B. The consumer may also be directed to this user interface after selecting the “Setup AutoPay” button in FIG. 7D. To make a rent payment, the consumer is presented with the amount of rent due, when it is due, and the option to schedule a payment. In some embodiments, the consumer may also be presented with a payment button allowing the consumer to make an immediate payment based on the selected information. FIGS. 7E and 7F demonstrate additional examples allowing a consumer to set up an automatic payment or make a payment. FIG. 7E illustrates a sample user interface for setting up payment to on a loan, and FIG. 7F illustrates a sample user interface for setting up a payment on to a credit card account. In some embodiments, payment options may be adjusted automatically based on available accounts, such as only displaying accounts from which the creditor will accept payments. For example, in FIG. 7C, a consumer is presented with the option to make a payment through a bank account or a credit card account. However, in FIG. 7F the consumer is presented with a single payment option to make a payment from a bank account.

In addition to being present on a user interface, alerts may be sent to a consumer through one or more additional mediums. For example, bill payment system 100 may send a consumer emails, text messages, and/or call the consumer. FIGS. 8A-E illustrate several mobile user interfaces displaying alerts sent from a bill payment system to a consumer's mobile device. Mobile device 810 in FIG. 8A illustrates an alert center, e.g., a mobile application and/or a notification screen that is part of an operating system of the mobile device, through which a consumer can view recent alerts. For example, the consumer is alerted of an upcoming electric bill, the reporting of a payment to a credit bureau, and an increase in the consumer's credit score. Alerts may provide information to a consumer about the impact taking actions suggested in an alert, and/or not taking such actions, is likely to have on a consumer's credit score. For example, in mobile device 810, the consumer is alerted to an upcoming due date for an electric bill. However, the electric utility company does not report timely payments to the credit bureaus (but only reports missed payments after two months of missed payments when the account is turned over to a collections department/agency). Therefore the alert not only alerts the consumer of the bill due, but also informs the consumer that late payment will not be reported to the credit bureaus, and therefore, will not impact the consumer's credit scores. Mobile devices 820, 830, 840 and 850, in FIGS. 8B-8E respectively, provide additional examples of alerts sent to a consumer's phone. The alerts may be received as a text message, through a mobile app, as an instant message, and/or as an email. Mobile device 820 alerts the consumer of several steps in the bill payment process. The first alert, from twelve minutes ago, indicates when a payment was made through the bill payment system 100. The second alert from 11 minutes ago indicates when the payment was reported to all three credit bureaus. The final alert indicated that credit bureau 1 has confirmed receipt of the payment information. The consumer may receive additional alerts about the transaction when the other credit bureaus confirm receipt of the payment information, as well as when the credit bureaus update the consumer's credit report with the received information as is shown in mobile device 830. In some embodiments, the consumer may be alerted to fewer or additional steps performed in the process of making and reporting payments. Additionally, the consumer may have the option of determining which alerts to receive. FIG. 8D illustrates an alert for the availability of a new statement. In some embodiments, clicking on the alert may bring the consumer directly to the detailed statement. FIG. 8E shows an alert presented to a consumer as confirmation that automatic payments have been set up. The confirmation alert gives the consumer confidence that the automatic payments are correctly set up and reminds the consumer of the benefit of enrolling in automatic payments.

In some embodiments, bill payment system 100 may present the consumer's tradelines in a format other than the traditional spreadsheet list. For example, in FIG. 9 the consumer's credit report represents tradelines as tiles. Each tile may provide the consumer with the same information as is provided by tradelines in a traditional credit report. In some embodiments the tradelines enable the consumer to perform the same functionality as discussed in reference to FIG. 6A. For example, the consumer is provided with an option to make a payment, and to connect accounts listed on the consumer's tradelines with the consumer's current account data.

As discussed above in reference to FIG. 5, payment recommendations may be based on the consumer's goals or priorities, the consumer's available funds, the amount due on the consumer's accounts, the balance remaining on each account, interest rates, impact on the consumer's credit score, and/or other available information about the consumer. For example, in FIG. 9, the Delta Miles card account tile 910 indicates that the consumer's credit usage of that account is at 40%. The bill payment system 100 has alerted the consumer of this, but can go further and actually recommend a payment amount. Here, the bill payment system 100 has recommended a payment of $2,305.73 because that will bring the consumer's credit usage under 30% for the account, which may improve the consumer's credit score. In the example, the bill payment system has also recommended a payment of $460 dollars to the consumer's CitiOne account (on the CitiOne account tile 920). The CitiOne account is currently past due and is negatively impacting the consumer's credit score. Therefore, the bill payment system 100 has recommended making the minimum payment now to bring the account up to date.

The embodiment in FIG. 9 also presents the consumer with creditors which do not report to credit bureaus 108. For example, the user interface includes an electric bill account tile 930 that includes information regarding an electric bill, which doesn't appear on a standard credit report. However, utility bills may be an important part of a consumer's personal finances. Linking utility bills to the bill payment system 100 allows a consumer to visualize most/all of his liabilities. In addition, if the bill payment system 100 has accurate utility bill information, it may be able to make more accurate payment recommendations, not only for the utility bill, but also for other accounts of the consumer based on the utility bill balance, payment amount, due date, etc. Utility bills may be linked to the bill payment system 100 in the same manner as bank and credit accounts, and in some embodiments the utility bills may be paid directly from the credit report user interface, such as by the consumer selecting a pay now button displayed on the user interface in order to initiate payment from a pre-established payment account of the user. Utility bills, or other bills not typically reported to credit bureaus such as rent, may appear on user interfaces whether formatted as in FIG. 9, FIG. 6A, or another format.

FIG. 10 illustrates a similar user interface to that illustrated in FIG. 9, but containing contextual action buttons for each account in addition to an option to make a payment to the creditors. For example, in addition to the option to make a payment, the consumer is presented with action buttons enabling the consumer to compare credit cards, file disputes, enroll in electronic billing, initiate a mortgage refinancing application, search for cars, apply for new student loans, and lower the consumer's electric bills. In some embodiments, one or more of the actions buttons may be an advertisement from a third party company.

FIG. 11 shows a user interface where the bill payment system 100 automatically sorts the consumer's accounts. The consumer may decide which criteria to use to sort tradelines, or the criteria may be defined by the bill payment system 100. For example the consumer's accounts may be sorted based on the impact on the consumer's credit score. This puts the accounts that have a largest impact on the consumer's credit score in the place the consumer is most likely to see them. For example, the user interface of FIG. 11 includes a CitiOne credit account tile 1110, which indicates that the consumer has a past due payment on the CitiOne account. Because late payments have a significant bad impact on a consumer's credit score, the consumer may be presented with that account first. Next, the user interface includes a Delta Miles account tile 1120, which indicates that credit usage on that credit account is over a recommended limit. Therefore, in the example embodiment, the bill payment system 100 automatically puts the tile 1120 in an easy place for the consumer to recognize and access the payment button. Other accounts, such as the student loan, may be placed further down in the priority. Accounts with no, or unknown effect, may be lower priority, and placed lower in the user interface. For example, the MasterCard with unknown status and the utility bill that is not a credit account are placed in the bottom row of tiles.

Bill payment system 100 may sort the consumer's tradelines to be presented as tiles, in a traditional credit report view, or in another manner when sorted. In some embodiments the consumer's tradelines may be sorted based on the urgency with which they should be addressed, the impact on a consumer's credit score, the negative impact on a consumer's credit score, the balance remaining, the balance due, the recommended payments, and/or other logical orders. The bill payment system 100 may determine the impact of a credit event on a consumer's credit score, or it may receive the impact from a credit bureau 106.

FIG. 12 is another sample user interface which presents a consumer with his tradelines and options to make bill payments. The user interface is integrated into a traditional credit report. In some embodiments there may be other actions buttons besides an option to pay a bill. For example, there may be action buttons which allow a consumer to file disputes.

Example Data Reporting

Data reporting is the reporting of consumer credit information by a business where a payment is required for a product or service that has been received or used by a consumer. Businesses that report data, called data reporters or data furnishers, are responsible for the secure electronic transfer of consumer payment information to a credit reporting agency (CRA), such as Experian. Once the information is received, the CRA includes it in its database and a tradeline is updated and/or created. A tradeline is a particular financial account of a consumer, and may be represented in various manners in a user interface displaying credit information, such as the tiles discussed above. Consumers may have few or multiple tradelines on their record. Together, all tradelines reported on a specific consumer make up his or her credit report and can be used to determine the consumer's overall risk or creditworthiness.

The credit score is an important indicator of a consumer's financial health. Consequently, having a high credit score is important to consumers for many reasons. A consumer's credit score may impact availability and/or terms (e.g., interest rate) of such things as loan applications, rental applications, real estate mortgages, and so on. A poor credit score may even prevent a consumer from finding a good job. Thus, many consumers have a substantial interest in monitoring and finding ways to improve their credit scores. However, a consumer's credit report is based on the information on their credit report, and the information on a consumer's credit report doesn't change until it is updated by a data reporter. Typically, there are two types of data reporters. The first type is the creditors themselves. Some creditors report data about their consumer accounts directly to the credit bureaus. The second type is third party data furnishers (also referred to as third party data reporters). These companies report to the credit bureaus on behalf of one or more companies with consumer credit accounts. In both cases, the creditors receiving payments from consumers typically aggregate payment information from many consumers and only report to the credit bureaus periodically (e.g. every 30 days). Thus, if a consumer makes a payment with the hope of improving his credit score there is often a substantial delay before any improvement actually occurs. For consumers seeking a quick improvement to their credit scores, this delay can be costly.

The block diagram in FIG. 13 illustrates a typical data reporting process for payments made toward a consumer's credit account. In this example, a consumer interacts with computing device 162 to make a payment. A payment module 170 makes payments to one or more creditors. After a creditor receives payments, it reports those payments to one or more credit bureaus 106. Each creditor independently reports to the credit bureaus 106 on its own periodic schedule. A consumer may have no way of knowing when a creditor will report payments to a credit bureau, and no way to report payments to the credit bureaus faster.

FIG. 14 is a simplified block diagram illustrating data reporting by a bill payment system 100 instead of (or in addition to) by the individual creditors receiving the payments. In this example, the consumer interacts with computing device 162 to make one or more payments, such as to different creditors. For example, computing device 162 may present the user with a user interface such as those illustrated in FIGS. 6-12 through which the consumer can interact with the bill payment system 100. Bill payment system 100 may contain a payment module 170 which makes payments to creditors as described in block 320 of FIG. 3. After the payment module processes a payment to a creditor, a payment reporting module 180 reports the payment to one or more credit bureaus. The payment reporting module 180 may report the payments individually as they occur, or may aggregate multiple payments to one or more creditors to send to the credit bureaus.

In some embodiments payments are reported directly to the credit bureau 106. In other embodiments, payment data is reported to the credit bureau 106 through one or more third party data furnishers 108. The third party data furnishers 108 report the consumer's payment data to one or more credit bureaus 106. Advantageously, if the consumer initiates payments to multiple creditors through the bill payment system, the bill payment system may report all of those payments to one or more credit bureaus 106, either in a batch report for the consumer or an individual payment reports. As noted above, in one embodiment the bill payment system 100 confirms that the payment has been received by the creditor before reporting to the credit bureau. In other embodiments, the bill payment system 100 may report the payment immediately (e.g. even concurrently with payment been sent to a creditor), possibly with an indication that the payment receipt has not been confirmed by the creditor.

Alert module 195 is configured to provide alerts to the consumer regarding events of interest to the consumer or the status of the consumer's accounts. Examples of alerts to consumers are discussed above in reference to FIGS. 6 and 8. The alerts may be presented as part of a user interface for the consumer, or may be sent to one or more of the consumers computing devices 162 such as by email, text message, or other means of communication. In FIG. 14, the alert module 195 is in communication with the payment module 170 and the payment reporting module 180 such that it is able to report when a payment is made to a creditor 164, and when payments are reported to the credit bureau 106.

FIG. 15 is a block diagram illustrating one embodiment of the bill payment system reporting, to a credit bureau, payments made to multiple creditors through the bill payment system. In this embodiment, the consumer interacts with computing device 162 which is in communication with bill payment system 100. In some embodiments, one or more elements of bill payment system 100 may be executed by computing device 162. For example, user interface module 110 may be a set of program instructions stored on a computer memory which is part of computing device 162 and causing computing device 162 to generate a user interface to provide to the consumer. In some embodiments, some or all of the modules illustrated in the bill payment system 100 may be partially and/or entirely located and executed on the consumer computing device 162. Bill payment system 100 enables a consumer to make payments to his creditors and report those payments to one or more credit bureaus.

Account data gathering module 150 gathers data on accounts associated with the consumer. The process of gathering account data about a consumer may include parsing information on the consumer's credit report, searching for other accounts associated with the consumer, and/or receiving information from the consumer about other accounts, for example. The account data gathering module 150 may perform the processes in blocks 210, 220, 230, and/or 250 as discussed in reference to FIG. 2. In some embodiments, the account data gathering module 150 identifies accounts associated with a consumer, and also updates data about the accounts (e.g. balance, due dates, etc.) with information in the consumer's credit report and information accessed from the consumer's creditors when the consumer accesses the bill payment system 100. Information may be accessed from the consumer's creditors by scraping the creditors online sites, by parsing information in statements received from the creditors, etc. For example, in one embodiment the consumer may provide a photograph of accounts (tradelines) on the consumer's credit report to the account data gathering module 150 (which in some embodiments may be powered by a third party service, such as those provided by Fiserv), which parses the information in the photograph (e.g., which may require performing optical character recognition initially) in order to detect one or more accounts and related account data. In other embodiments, the account data gathering module 150 has access to an electronic copy of the consumer's credit data and, thus, may extract account data directly from that electronic data (e.g., in xml, cvs, or any other electronic format).

Account validation module 190 validates the accounts identified by the account data gathering module 150 as discussed above in reference to the process performed in block 430 or FIG. 4A. In some embodiments, the processes of account validation module 190 are performed by account gathering module 150.

User interface module 110 generates user interfaces and provides those user interfaces to the consumer through the consumer's computing device 162. The user interface may be any of the exemplary user interfaces discussed in FIGS. 6-12, or may be a different user interface which provides the consumer with the ability to make payments to his creditors.

Payment module 170 makes payments to the consumer's creditors as discussed in reference to block 320 of FIG. 3. In some embodiments, payments may be made to reporting creditors 164A and/or non-reporting creditors 164B (discussed further below). In order to report payments to a credit bureau 106, the payment module 170 may need an indication from the creditors that the payment was received and accepted. For example, if the payment module initiates a payment from the consumer's bank account to a creditor, but the payment is returned for insufficient funds, then the bill payment system 100 does not want to report that payment to a credit bureau. In some embodiments, the payment reporting module 180 receives the indication from the creditor that the payment was valid.

Payment reporting module 180 reports payments to one or more credit bureaus 106. For example, after a payment is confirmed valid, the data may be reported to the credit bureau 106C via the third party data furnisher or directly to the credit bureau 106C (e.g., if the bill payment system is a data reporter). Payment reporting module 180 may send reports to the credit bureau continuously as payments are made, or may compile payments to send in batches.

Creditors 164A and 164B are entities to which the consumer owes money. Some creditors (data reporters) 164B furnish data to credit bureaus 160A, 160B, and 160C, other creditors (non-reporting creditors) 164A do not report payment data to credit bureaus, or in some cases only report negative information to credit bureaus (such as referring the consumer's debt to a collection agency). In some embodiments, both data reporters 164B, and non-reporting creditors 164A may communicate with the bill payment system 100. For example, they may communicate with the account data gathering module 150 to update outstanding balances, or communicate with bill payment module 170 to receive payments from the consumer. However, only the data reporters 164A report transactions directly to the credit bureaus 106. In some embodiments, payments to non-reporting creditors 164B can also be reported to one or more credit bureaus 106 through the bill payment system. For example, once a payment is confirmed with a particular non-reporting creditor 164A, the payment reporting module 180 may communicate the payment to one or more credit bureaus 106 (either directly or via one or more third party data furnishers 108).

As illustrated in FIG. 15, in some embodiments, payment reporting module 180 provides information only to some of the credit bureaus 106. In FIG. 15, payment reporting module 180 furnishes payment data only to credit bureau 106C. Bill payment system 100 generally furnishes data to credit bureaus 106 faster than a reporting creditor 164B would furnish data through their own system. This means that credit bureau 106C would have more up to date information than the other credit bureaus 106A and 106B which only received payment data when it is furnished by the reporting creditors 164B.

The bill payment system 100 and related modules are described as concerning the presentment, payment, and reporting of bills for an individual consumer. However, specific modules may be used by many consumers at the same time. For example, payment reporting module 180 may aggregate payments made by many consumers through the bill payment system 100 to send in a single batch to a credit bureau 106. Having a single reporting module perform functions for multiple consumers may increase the efficiency of the system.

OTHER EMBODIMENTS

Although the foregoing systems and methods have been described in terms of certain embodiments, other embodiments will be apparent to those of ordinary skill in the art from the disclosure herein. Additionally, other combinations, omissions, substitutions and modifications will be apparent to the skilled artisan in view of the disclosure herein. While some embodiments of the inventions have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms without departing from the spirit thereof. Further, the disclosure herein of any particular feature, aspect, method, property, characteristic, quality, attribute, element, or the like in connection with an embodiment can be used in all other embodiments set forth herein.

All of the processes described herein may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers or processors. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all the methods may alternatively be embodied in specialized computer hardware. In addition, the components referred to herein may be implemented in hardware, software, firmware or a combination thereof.

Conditional language such as, among others, “can,” “could,” “might” or “may,” unless specifically stated otherwise, are otherwise understood within the context as used in general to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

Any process descriptions, elements or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown, or discussed, including substantially concurrently or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.