CA3023325A1 - System and method for dynamic financial management - Google Patents

Abstract

Fragmented, unconnected participants and legacy financial services infrastructure cause said infrastructure to perform inefficiently. This makes rearranging financial instruments and transactions (e.g., lending/investments) slow and insecure. As a result, rearranging financial instruments and transactions to achieve optimal credit utilization using current unconnected legacy financial services infrastructure is not viable. Systems and methods are provided to achieve rapid, efficient, automatable, and secure management, clearing, tracking, and settlement of transactions by using distributed ledgers and storing the transaction records via a blockchain protocol.

Description

SYSTEM AND METHOD FOR DYNAMIC FINANCIAL MANAGEMENT
FIELD
[0001] Some embodiments herein relate generally to the fields of financial services and information technology. More specifically, embodiments described herein relate to systems and methods monitoring and improving one's credit history and, more particularly, to systems and methods for creating a synthetic collateralized loan and an automated revolving loan manager.
INTRODUCTION

[0002] In Western banking systems, a credit score is a key numeric value that is used to systematically and objectively score and consequently classify consumers on their ability to .. manage their finances as well as their ability to pay back loans. This is, in part, used for loan repayment qualifications and as a protective measure for financial institutions (Fls) to alleviate some of the risk when issuing out a loan. The measures taken by Fls influence whether a consumer gets approved for a mortgage, auto loan, credit cards, and most importantly, the rates at which they receive these products. A poor credit score can cost individual's thousands of .. dollars in high interest rate fees and can, in some cases, hinder employment opportunity and potential rent inquiries. Approximately 200 million Americans currently have credit files, and the major credit bureaus are generating more than 1 billion reports each year.

[0003] There is an abundance of evidence to support the need for credit building assistance.
For example, the National Consumer Law Centre reports that "70 million consumers have had interactions with the debt collection industry in [2016]". The IRS showed 5,098 approved tax-exempt credit counselling organizations in 2015 compared to 788 in 2005. In 2015 the IRS
reported revenues from these organizations totaling USD $2.3 trillion, as compared to USD $1 billion in 2005. A ¨6.5x increase in organizations and a ¨2300x increase in revenue indicate a significant suggestion that more and more individuals are seeking help with regards to managing their credit. With these types of increases, there is clearly a need that prior art is not fulfilling in terms of credit improvement and financial management support.
SUMMARY

[0004] Embodiments herein may enable computerized systems to attain faster transaction times, while maintaining security, by allowing clients to secure a loan, while simultaneously (or nearly simultaneously) collateralizing that loan with funds received by the system, and investing the loan once secured, into a financial product. Further, when coupled with the transparency of a detailed audit trail, and verification that a blockchain ledger provides, some embodiments may also provide, in addition to faster transaction times, greater and easier access to transaction records, and may substantially remove counterparty risk.

[0005] In accordance with one aspect, there is provided a method for monitoring and dynamically optimizing credit utilization, the method comprising: a) storing a financial transaction data associated with the client in a distributed blockchain ledger; b) monitoring the financial transaction data associated with the client via the distributed blockchain ledger; c) monitoring one or more issuer subsystems for at least one debt associated with the client; d) detecting a loan instrument associated with the client, the loan instrument having at least one loan instrument parameter; f) calculating an optimal credit utilization factor for the client by aggregating and processing the financial transaction data associated with the client according to one or more parameters of an optimal utilization rate; g) executing an optimization process to accord one or more values within the financial transaction data associated with the client with the one or more parameters of the optimal utilization rate; and h) writing a record of the optimization process to the financial transaction data associated with the client stored in the blockchain ledger.

[0006] According to another aspect, the distributed blockchain ledger is an append-only, immutable database.

[0007] According to another aspect, the financial transaction data includes: a) at least one unique identifier associated with one or more financial transactions; b) a plurality of details relating to the one or more financial transactions; and c) one or more timestamps associated with each unique identifier.

[0008] According to another aspect, the optimal credit utilization factor is calculated by a debt prediction engine, the debt prediction engine 211 processing the financial transaction data associated with the client to determine the optimal credit utilization factor prior to the detection of the loan instrument associated with the client.

[0009] According to another aspect, the one or more values within the financial transaction data associated with the client include at least one debt limit of at least one debt instrument.

[0010] According to another aspect, the optimization process includes according the at least one debt limit of the at least one debt instrument with the one or more parameters of the optimal utilization rate.

[0011] According to another aspect, the optimization process includes repaying the at least one debt instrument and securing a second at least one debt instrument having a second at least one debt limit.

[0012] According to another aspect, the optimization process includes reconfiguring the at least one debt limit of the at least one debt instrument.

[0013] According to another aspect, the method comprises sending at least one notification to at least one credit bureau.

[0014] According to another aspect, at least one smart contract automatically executes at least one step of the method.

[0015] According to another aspect, the optimization process includes securing at least one investment vehicle having at least one investment vehicle parameter.

[0016] According to another aspect, the method comprises liquidating the at least one investment vehicle and securing a second at least one investment vehicle having a second at least one investment vehicle parameter.

[0017] In various further aspects, the disclosure provides corresponding systems and devices, and logic structures such as machine-executable coded instruction sets for implementing such systems, devices, and methods.

[0018] In this respect, before explaining at least one embodiment in detail, it is to be understood that the embodiments are not limited in application to the details of construction and to the arrangements of the components set forth in the description or illustrated in the drawings.
Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

[0019] Many further features and combinations thereof concerning embodiments described herein will appear to those skilled in the art following a reading of the instant disclosure.

DESCRIPTION OF THE FIGURES

[0020] In the figures, embodiments are illustrated by way of example. It is to be expressly understood that the description and figures are only for the purpose of illustration and as an aid to understanding.

[0021] Embodiments will now be described, by way of example only, with reference to the attached figures, wherein in the figures:

[0022] FIG. 1 is a block diagram depicting components of an automated credit improvement system, according to some embodiments;

[0023] FIG. 2 is a flow diagram depicting the flow of data through components of an example automated credit improvement system, according to some embodiments;

[0024] FIG. 3 is a flow diagram depicting an example onboarding procedure and loan underwriting procedure according to some embodiments;

[0025] FIG. 4 is a flow diagram depicting an example process for serving of the principal plus interest of a loan, according to some embodiments;

[0026] FIG. 5 is a flow diagram depicting an example process for settling a loan using a crypto wallet, according to some embodiments;

[0027] FIG. 6 is a flow diagram depicting an example process for reinvesting funds, according to some embodiments;

[0028] FIG. 7 is a flow diagram depicting an example process for processing a client's decision to continue or terminate service via the credit improvement system (CIS), according to some embodiments;

[0029] FIG. 8 is a flow diagram depicting an example process for terminating an account in the CIS, according to some embodiments.

[0030] FIG. 9 is a flow diagram depicting an example process for a client securing a revolving loan by means of the CIS when the bill or payment is consistent, according to some embodiments;

[0031] FIG. 10 is flow diagram depicting an example process for a client securing a revolving loan by means of the CIS when the bill or payment amount is above a pre-set threshold; and

[0032] FIG. 11 is flow diagram depicting an example process for a client securing a revolving loan by means of the CIS when the bill or payment amount is below a pre-set threshold.
DETAILED DESCRIPTION

[0033] One problem in current financial systems is the inefficiency caused by fragmented participants and legacy infrastructure. This makes transactions (lending/investments) slow and insecure. Settlements take several days to execute and are delayed by hard-copies of agreements and due diligence documents. By utilizing a distributed ledger and storing the transaction on a blockchain, all transactions can be processed swiftly, securely, and efficiently since multiple actors may not be required to accomplish clearing/settlement.

[0034] Embodiments herein may enable computerized systems to obtain faster transaction times by allowing clients to secure a loan, while simultaneously (or nearly simultaneously) collateralizing that loan with funds received by the system, and investing the loan, once secured, into a financial product. Some embodiments may also allow clients to secure other financial instruments or may automatically secure, manage, and/or terminate revolving financial instruments such as revolving loans. Further, when coupled with the transparency of an audit trail, and verification that a blockchain ledger provides, some embodiments may also provide, in addition to faster transaction times, greater and easier access to transaction records, and may substantially remove counterparty risk.

[0035] With so much emphasis placed on credit scores and history, consumers are surprisingly oblivious to the factors that influence this score and lack the understanding of how certain actions can affect it in a negative or positive way. In addition, the most alarming discovery is the consumer's unwillingness or lack of time to invest the effort needed in getting a comprehensive understanding of the score, and also diligently and consistently following the required practices involved with improving the score. The system and method described in this patent automates this time consuming process for the consumer and builds a healthy relationship with financial management through saving while building a better credit history.

[0036] There are several companies attempting to market themselves as helping consumers build their credit. Firstly, there are the websites such as Borrowell and Credit Karma. These websites rely on quarterly reports provided by the credit bureau's (CBs) to update the consumer's credit file information. The CBs acquire the consumer's credit files from financial institutions whose main goal is to make a profit from the interest margins.
After presenting the consumer with the free credit score, these websites then market their own loans and services to the consumer at a rate reflecting the credit score they received from the CBs.

[0037] Secondly, there are credit counseling agencies which provide assistant in financial knowledge, basing their models on education. These agencies generally follow the form of pre-generated bullet point messages on how a consumer can improve their credit score. Such general recommendations can include "Pay your bills as they come due", "Length is important to .. credit history", and "Keep your credit card balances low". At the most helpful, they might offer suggestions to the consumer's current situation by parsing your credit file.
In either case, having knowledge on how to improve a credit score is irrelevant unless the consumer adopts and integrates the recommendations into their daily spending habits.

[0038] Thirdly, there are the debt consolidation firms. These firms make claims to improve a consumer's current credit score standing by consolidating all the debt payments into a blanket loan with one payment, while supposedly "reducing" the loan amounts owed through negotiations with the creditor. Although easier, this debt consolidation comes with a high interest loan and is not the optimal solution to a so called "credit fix".

[0039] Finally, there are self-implemented recommendations that consumers can utilize to make consistent payments easier. For example, clients who have credit cards can usually set-up automatic bill payments or register to receive reminders. These fail in two ways: i) the credit cards can be maxed out using this method, downgrading the client's risks score; and ii) this can cause over-the-limit transactions and the consumer will end up paying hefty fees. Although reminders are sent out, this doesn't guarantee the bills will be paid on time.
In addition, most financial institutions do not report on small loans. The consumer data files are simply too costly to send to CBs that the financial institutions (Fls) only report on large loans such as a house mortgage and auto loans. This is a catch-22 situation because attaining these mortgage and auto loans depend heavily on having a good credit score to begin with.

[0040] There is, therefore, a need in the art for a method and system to automate the loan application, security investment, and monthly payment withdrawals to assist individuals in saving money as well as a regulated reporting process of positive loan payments to the CBs.

[0041] Cryptographic wallets and smart contracts can make such systems run automatically, solutioning end-to-end management and monitoring of the lending process, agreement generation, loan disbursement, loan repayments, alarms, recovery in case of default, and investment execution and management. Additionally, the advantages to this system are in the security of documents. Use of cryptographic wallets and cryptocurrencies may provide advantages as it may provide settlement times that are much faster than the current infrastructure allows, and encryption may increase the security of such transactions.
Incorporation of smart contracts may be advantageous because it may remove inefficiencies in the contract lifecycle, thereby reducing the degree of human intervention required in negotiation, execution, administration, and compliance; in return smart contracts may improve the speed, reduce the cost, and increase the security of contracts.

[0042] By utilizing military-grade encryption techniques like hashing, public-private key encryption, Merkle trees, and consensus protocols, the assets collected by the system are securely protected and by using smart contracts the system becomes self-managed and self-verified, protecting the clients and providing ease of use to the auditors, something that prior art cannot fulfill. Moreover, with the decentralized nature of the cryptocurrencies used for lending and investment, the system may be able to remain free from political and governmental risks.
Since there is no central authority, the inflationary risks or monetary controls will be non-existent.

[0043] Embodiments described herein provide methods and systems for loan processing, creating a synthetic loan in order to report loan payments while actually saving money monthly and accessing the saved funds at the end of the term. The system, using a financial partner (issuer), will receive a loan request from a client subsystem, automatically executing a smart contract with the issuer where the loaned funds will be received and then placed right away into an investment vehicle, and then the system will report account creation and payments to the CBs.

[0044] FIG. 1 displays, according to some embodiments, the credit improvement system (CIS) 101 where data from the distributed blockchain ledger can be moved to or from system to various subsystems. The CIS 101 may be capable of transferring data via one or more communication networks 118 to the client subsystems 116 and the issuer subsystems 120.

[0045] In some embodiments, the CIS 101 may include a processor 102, a power supply 104, an input/output "I/O" component 106, communications 108, memory 110, a crypto wallet 112 and data representing one or more values from the distributed ledger 114 (these values may be stored in a memory, e.g., memory 110). I/O 106 can include an input component capable of receiving client input (e.g., a mouse or keyboard), and may further include one or more outputs (e.g., a video display), that may be capable of transmitting (e.g., displaying) information to a client. CIS 101 may also include a variety of software and hardware interfaces (e.g., web interface, graphical client interface).

[0046] In some embodiments, the I/O 106 may enable the CIS 101 to communicate with other computing devices (e.g., web servers). The memory 110 storage medium may include flash memory, a hard-drive, volatile memory (Le. SRAM, DRAM), read-only memory (ROM), optical disks, random-access memory (RAM) and the like.

[0047] In some embodiments, the communications component(s) 108 may allow the CIS to communicate with one or more subsystems via network 118. This may be accomplished by communications component 108 utilizing one or more suitable data communication protocols (e.g., WAP, TCP/IP, HTTP, etc.) to transmit, receive, and interpret data.

[0048] In some embodiments, the network 118 may be a wireless (e.g., WLAN, cellular, satellite) network or a wired network or a combination thereof. The communication network 118 may further comprise a variety of devices (e.g., routers, servers, storage devices, bridges, etc.) and may employ a variety of protocol types.

[0049] In some embodiments, the processor 101 may run one or more software applications that may include operating system applications, firmware applications, communication applications (e.g., web applications or native applications to interact with client and issuer subsystems and facilitate loan processing). The processor 101 may be configured to fetch and execute computer-readable code and instructions and may be implemented as a central processing unit (CPU), microprocessor, digital signal processors, state machines, and the like.
= The processor 101 may be closely coupled with memory 110 elements through one or more system buses.

[0050] In some embodiments, subsystems (e.g., Issuer Subsystem 120, Client Subsystem 116, Admin Subsystem 206) may store a distributed blockchain ledger 212 and a crypto wallet (e.g., see 112 in FIG. 1) which may allow the subsystems to interact with one another using one or more cryptocurrencies in a secure, reliable, and expedited fashion.

[0051] In some embodiments, clients interacting with the CIS 208 may be provided the crypto wallets and accounts that may be hosted on the CIS to assist the performance of the functions .. described herein. These crypto wallets may allow the subsystems to access peer-to-peer networks of computers through which the distributed ledgers may be stored and managed. In a non-limiting example, a layer of complex cryptography may be applied and virtualized data token protocols may create, store, transfer, and manage ownership of assets (e.g., cryptocurrencies, financial instruments, etc.). The virtualized data token protocols may be able to decrypt transactional data in order to track and verify transactions by comparison to, and analysis with, previous data stored on the blockchain ledger (e.g., 114).
Smart contracts rule engine 210 leveraging the blockchain ledger 212 may be coupled with the crypto wallets enabling the performance of certain functions through event-driven code.

[0052] In some embodiments, the Ethereum blockchain may be used to write smart contracts that execute onboarding (appending documents to the chain), issue loaned funds, invest in financial instruments, and liquidate or close out positions once triggered by a given event. In other embodiments, the vendor of choice for smart contracts may depend on the enhancements in scale, flexibility, transactions times, and/or fees provided by smart contracts. Other vendors that will best suit the required use case will be chosen, including, but not limited to Monax, Symbiont, Hyperledger, Sawtooth, or Quorum.

[0053] In some embodiments, the CIS 101 may be implemented via a variety of computing systems (e.g., laptop computer, desktop computer, mainframe computer, a server, cloud-based environment, etc.). Any embodiments described herein may be hardware based, software based, and/or a combination of both. Further, embodiments described herein may be implemented by means of specifically configured, special purpose computer hardware.

[0054] In some embodiments, multiple clients may access the CIS 101 via a multitude of devices (e.g., portable computer, digital assistant, mobile device, tablet device, etc.) and may be accessed, for example, through a web browser, an order management system (OMS), or an application programming interface (API). The client subsystems 116 and issuer subsystems 120 may include components similar to CIS 101. The client subsystems and the issuer subsystems may communicate through the communication network 118.

[0055] Referring now to FIG. 2, there is provided a flow diagram depicting an example embodiment of the present disclosure which utilizes a peer-to-peer communication network 118 to transfer and store financial transaction data representative of one or more parts of the distributed blockchain ledger 212 on the clients' computing device(s). This may act as a distributed database, and securities created by issuers, as well as records of security ownership 218, loan transaction provisions 216, and any associated documents may be embedded to the blockchain ledger 212.

[0056] In some embodiments, this distributed blockchain ledger 212 may be an append-only, immutable database that may store all of the information and details of the aforementioned products, and a timestamp for all executed actions that ever occur on the system 208.
Consensus protocols (e.g., proof of work, proof of stake, proof of activity, proof of ownership, proof of capacity, proof of burn, etc.) utilized by the cryptographic wallets may verify these transactions. The crypto wallet 112 may employ high-grade encryption protocols such as Transport Layer Security (TLS) utilizing hashing algorithms 220 for appendage and public-key infrastructure cryptography (PKI) to create, manage, distribute, use, store, and revoke digital certificates (e.g., certifications indicating authorization).

[0057] In some embodiments, security documents 222 may pass through an encryption layer which may include a hashing algorithm 220 such as Secure Hash Algorithms 1, 2, and 3 (SHA
1, SHA 2, SHA3) before being transferred to, and stored at, the distributed blockchain ledger 212 as embedded data 214. Successful completion of smart contract 210 execution may initiate a process which may transfer security ownership, onboard issuers, onboard clients, and onboard products, and which may be implemented through the CIS system 208 or added to the crypto wallets (e.g., see 112 in FIG. 1). In certain embodiments, the crypto wallets will mandate the use of multi-factor authentication 209 in order to control access to the node network in order to add data blocks. A node network may refer to a collection of nodes that can read and write to the blockchain, (e.g., use the Ethereum Virtual Machine). A full node may have to download the entire blockchain and validate the chain. Every node may possess a copy of the blockchain, or a partially validated subset thereof (e.g., a "light node").

[0058] In some embodiments, when the distributed blockchain ledger 212 receives appended data, appended data may be signed using asymmetric cryptography techniques (e.g., public key cryptography). Each crypto wallet (e.g., see 112 in FIG. 1) may store: i) a public key which may be available to all nodes (clients) on the network; and ii) the clients' (a private key associated with the client to whom each crypto wallet belongs) private key. These keys may serve different functions: the public key may be used, for example, in the form of a send-to address and may be predominantly used to encrypt data, while the private key may be used to authorize or decrypt encrypted in order to allow access data for access, and to digitally sign blocks of data later appended to the blockchain ledger 212.

[0059] It will be understood that many various alterations or modifications may be made to the system and methods involved without deviating from the scope of the embodiments described herein. Although example embodiments may utilize a decentralized ledger, some embodiments may include a centralized blockchain ledger, a centralized authority not administering the blockchain ledger to process transactions, etc.

[0060] In some embodiments, the CIS 208 may process loans in a cryptocurrency, rather than in fiat money, and may invest this distributed ledger digital asset in one or more investment vehicles, which may be stored on a distributed database in a decentralized network. The distributed ledger technology (DLT) network may utilize a private permissioned-based ledger which may enable issuer subsystem and CIS 208 to read and write permissions to append blocks to the distributed blockchain ledger (e.g., 212).
Issuer Onboarding

[0061] In some embodiments, securities created in the CIS system will comply with all regulatory rules, including, but not limited to, Blue Sky laws, FINRA, FINTRAC, SEC, BSA, and international requirements. The liability may be on the issuers to ensure anti-money laundering due diligence and compliance with Know-Your-Client (KYC) rules in their respective operating jurisdictions.

[0062] In some embodiments, individual entities who wish to become a part of the CIS 208 may apply to become issuers, data pertaining to issuers may be stored in issuer subsystem (202). The application will be available on the CIS and the entities will need to upload specific documents pertaining to the successful onboarding of each issuer. The CIS 208 may contain instructions functional to provide an application (i.e., enrolment) process by which individual entities may request to become 'issuers' for the purposes of the CIS 208. Such application process may be provided via the CIS (e.g., via a client interface device or website), and may require each client to successfully upload a specific set of documents in order to execute a successful onboarding process.

[0063] In some embodiments, one or more administrators 206 may vet each application and may decide whether the documentation provided is sufficient to meet the standards and norms set out for the jurisdictional regulations in each region the CIS 208 operates ¨ this process may be performed via an admin subsystem 206 automatically, when the documentation and information supplied to it are in-line with the previously set rules of compliance and KYC/AML
standards. If a scenario is outside the standard rules for document and information gathering that is given to the admin subsystem 206, then human intervention may be required and the admin subsystem 206 will alert the issuer subsystem 202 with a notification that manual review is mandatory and the admin system cannot make a decision based on the facts presented.
These manual review administrators may, for example, consist of third-party KYC/AML firms that provide verification services on a contract basis to the CIS 208 or may be a group consisting of board members from established approved issuers.

[0064] In some embodiments, documents and forms submitted via issuer subsystem may be stored by the CIS on the distributed blockchain ledger 212. The administrators of CIS
may be able to review the information submitted, and if accepted, may be able to issue a unique identifier associated with the issuer (e.g. an "IssuerlD") which will act as a unique primary key ¨
this process may be performed via the admin subsystem 206.

[0065] In some embodiments, upon successful completion of the onboarding process, issuer subsystem 202 may determine that the onboarding process has been successfully completed, and may issue securities. All issuers subsystems 202 may be mandated to provide at least one primary security and a guaranteed investment vehicle, which may enable clients to issue commands (e.g. via client subsystem 204) to withdraw their principal monies at the end of the term of a particular investment vehicle.

[0066] In some embodiments, other investment vehicles may be introduced by issuer subsystems 202 including, but not limited to, debt securities, equity securities, guaranteed investment vehicles, term deposits, and any other securities that comply with governmental laws and regulations. Each investment vehicle introduced by issuer subsystem 202 may be appended to the distributed blockchain ledger 212 along with data outlining ownership 218, identifying the issuer(s) 202 regulatory rules 216, and document information 214 pertaining to the security. In other embodiments the onboarding can be instituted by a smart contract rule engine 206 by pre-specifying the required documents and entity type for a successful issuer subsystem 202.

[0067] In some embodiments, the same logic may be applied by issuer subsystem 202 in order to create new security offers. Documentary data from issuer subsystem 202 outlining the details of each newly created security may be appended to the distributed blockchain ledger 212. The issuer may be supplied a public key address and a private key for the usage of their crypto wallets. This public key address may link the issuer to the IssuerlD, and this ID may be embedded into all data tokens and distributed blockchain ledger 212 entries.

[0068] In some embodiments, the issuer may incorporate the CIS 208 to use as its service via a website, app, or any other suitable consumer facing interface. A client wishing to utilize the CIS 208 may do so from the issuers' client interface which may enable clients to complete various steps outlined herein. In some embodiments, instead of paying the issuer directly, the client may direct loan payments to be made via the CIS.
Client Onboarding

[0069] Referring now to FIG. 3, there is provided a flow diagram depicting an example onboarding procedure according to some embodiments. In some embodiments, an onboarding procedure 302 must be completed before a client may interact with the CIS
platform 208. A
request may need to be sent by a client via the client subsystem 116 to access the platform and the distributed ledger. This may, as a non-limiting example, be in the form of an application similar to the issuer requiring identity documents to be provided. The client may complete such upload via, for example, a graphical client interface generated by the CIS 208 and transmitted to a client output (e.g., computer monitor, phone screen, or audio alerts, etc.).
The onboarding procedure may require the client to supply basic identifying information (e.g., full name, address, contact medium, password, etc.), personal information (e.g., social insurance number), and bank information adequate to open up a loan/bank account (e.g., loan payout amount, loan term, loan payment period, loan payoff currency (i.e. USD, CAD).

[0070] In some embodiments, several electronic contract documents (e.g., terms of service, privacy policy, loan agreement, pre-authorized debit (PAD) agreement, and power of attorney agreement to invest funds on behalf of client(s) may be processed electronically using e-signatures (PKI) or similar technology. In some embodiments, the issuer subsystem 202 may vet each application and may decide whether the documentation provided is sufficient to meet .. the standards and norms set out for the jurisdictional regulations in each region the CIS 208 operates ¨ this process may be performed via an issuer subsystem 202 interface automatically, when the documentation and information supplied to it are in-line with the previously set rules of compliance and KYC/AML standards. If a scenario is outside the standard rules for document and information gathering that is given to the subsystems, then human intervention may be required and the issuer subsystem 202 will alert the client subsystem 204 with a notification that manual review is mandatory and the admin system cannot make a decision based on the facts presented. These manual review administrators may, for example, consist of members from the issuer's KYC/AML department that provide verification services for all issuer transactions. Upon successful completion, client may be assigned a client identification value (ClientID) which may uniquely identify the account and may be used for loan withdrawals and security purchases.

[0071] In some embodiments, documents supplied by clients to the CIS 208 (e.g., via client subsystem 204) may be embedded to the distributed blockchain ledger 212 along with identifiers of any related accounts, ClientID, and any data tokens associated with ownership of any investment vehicle. The ability to access the blockchain ledger and the immutability of the ledger may allow for a concise and transparent audit trail enabling compliance and regulatory authorities to undertake any necessary review.

[0072] In some embodiments, each client registered on the network may have access to their own cryptographic wallets 112 in order to access information on the read and/or modify data stored on the distributed blockchain ledger 212. This information may be presented to the client and/or issuer via a GUI generated by the CIS 208 and transmitted to a client interface.
Graphical Interface

[0073] In some embodiments, the CIS 208 may allow client subsystem (e.g., 116, 204) to determine how a client's credit score may be affected (e.g., by payment history, length of time credit vehicle is held, utilization rate, amount of debt, etc.) and what factors contribute to, and modify, the credit score. This may be accomplished by, for example, calculating a plurality of performance metrics affecting the credit score (e.g., whether payments were made on time, whether payments were for the complete amount due, how many different credit vehicles such as credit cards the individual owns, etc.) from the real-time financial transactions, periodically retrieving updated credit reports, and providing a historical timeline of the calculated credit scores and plurality of credit score parameters, which can be displayed on a graphical client interface. The visual representation of how credit information is affecting the credit score, and most importantly, the impact of specific actions affect the credit score and how to alter clients habits in order to improve the credit score may be a core feature of the CIS
208. The data presented to the client will be dynamically created and tailored for the modern consumers' omni-channel experience (e.g., a consistent client experience across multiple device types such as computer, laptop, mobile phone, etc.).

[0074] In some embodiments, the CIS 208 may cause a pie chart to be displayed via a client interface. When a client causes an interaction with elements of the displayed pie chart (e.g., via a mouse cursor or a tap on a touch screen) certain performance metrics may be displayed which may contain detailed explanations of the category of data represented by the portion of the pie chart and their impact on the overall score. These performance metrics may be interpreted by the CIS processor 102 when any loan origination occurs (e.g., 312, 608, and 708) (e.g., a client gives access, at time of loan origination, to scrape said client's credit report and other financial information and process them via the CIS 208 by particularly configured computer instructions to create useful visual representations for the client's specific financial situation).

[0075] In some embodiments, the issuer may retrieve these reports from credit bureaus and may append this data to the distributed blockchain ledger (e.g., 212) along with the approval and confirmation of the loan contract. The CIS (e.g., 208) may then access this data by first decrypting the data using a private key and may then parse the report to extract various data records representing, for example, trade lines, debt, bankruptcies, payment frequency, and/or record delinquencies. Each performance metric represented by the various extracted data records may be displayed, for example, as a slice of a pie chart shown on a client interface. The size of each slice of the pie chart may be proportionate to the impact of the represented performance metric on the client's credit score.

[0076] In some embodiments, the CIS (e.g., 208) may generate and analyze aggregated reports in the event that a client repeatedly "rolls over" their loan with the CIS. Rolling over may refer to, for example, reinvesting funds from a mature security into a new issue of the same or a similar security. CIS (e.g., 208) may display a time series analysis of these credit reports, credit scores, and credit summaries. All of these reports may be stored as encrypted information on the blockchain ledger, or may be linked to a dedicated server running a cloud-based system to access the report through PKI.

[0077] In some embodiments, the time series analysis may provide different views of the data in the form of a main dashboard which may highlight underlying trends and features of the data not immediately apparent to the client. These views may enable, as non-limiting examples, filtering down by points of interest, tabulation, and other exploratory techniques which may allow .. the client to more easily take note of and comprehend various important data trends represented by the analytics data. In various aspects, the performance metrics can include one or more of: debt-to-income ratio; credit line utilization; number of transactions; growth in savings or debits; financial risk ratios; balance-to-limit; and debt-to-limit.
Installment Loan ¨ Creation

[0078] Referring now to FIG. 3, there is provided a flow diagram depicting an example process for a client securing a loan by means of the CIS. At 302, the process may begin by client completing a client onboarding procedure (e.g., via client subsystem 116), which may proceed as described above. Information submitted by the client may be transmitted by client subsystem to the CIS via a communication network (e.g., 118).
.. [0079] In some embodiments, the information submitted by the client may be encrypted using, for example, SHA-256 hashing algorithms and may be appended to the distributed blockchain ledger (e.g., 212). In certain embodiments, instead of embedding large documents submitted by the client to the distributed blockchain ledger 212, a data token (which may represent ownership of the data files containing submitted documents) may include a cipher that may function to provide access to these documents, which documents may be stored in a memory (e.g., a secure cloud-based database connected to the CIS). Encryption of these documents on the cloud may employ, for example, AES-256 bank/military grade database storage encryption. At 304, an admin fee may be charged, for example, to cover expenses associated with maintaining platform sustainability.
.. [0080] In some embodiments, once the funds have been received and, if the embodiment requires, the account has been approved, the CIS may complete the account creation process 308 by, at 310, decrypting and transmitting the e-signed contract documents to one or more issuers. This may authorize a loan to be originated under the client's name.
At 306, the client may be notified of the new account creation.
.. [0081] In some embodiments, issuers may originate one or more loans at 312 and may transfer the cryptocurrency (e.g., via the issuer subsystem crypto wallet 112) to a crypto wallet address in the CIS. At 308, once the loan funds have been received, the CIS
may notify credit bureaus of the new credit account for the client. The notification sent to the credit bureaus may include identifiable information (e.g., information sent in Metro2 format (i.e., the current standard format for reporting credit), or, if the systems of the credit bureaus are capable of utilizing distributed ledger technology, the new credit account information may be appended to this ledger, assuming the CIS system has been permissioned for write-access thereto.
[0082] In some embodiments, at 316 CIS may then invest the funds received from the client at 314 (e.g., using power of attorney) into securities made available by the issuers (financial institutions). These securities may include but are not limited to debt securities, equity securities, guaranteed investment vehicles, term deposits, and any other securities that comply with governmental laws and regulations. The client may be encouraged to invest in a guaranteed investment vehicle to secure his principal and not lose the savings he is making throughout the year. This will open ao investment account 318 for the client in the issuers subsystem.
[0083] In a non-limiting example embodiment, the CIS 208 may convert the securities the issuer onboards into virtual data tokens, or in some instances virtual data tokens representative of underlying securities, which can then be transferred from the issuer to the client through crypto wallets. The ownership of the security gets transferred, the virtual data tokens get updated with the new owner, and this information, along with all transactional details gets .. appended to the distributed blockchain ledger (e.g., 212). At 322, the CIS
may then wait for confirmation from the issuer that the funds have been invested. Upon receipt of such confirmation at 324, client may be notified at 326 of the investment information (e.g., via a GUI
on a client interface).
[0084] It will be understood that a portion or all of the aforementioned may be executed by use of smart contracts (e.g., 206), with the initiation, performance, and confirmation or rejection of the contract appending to the distributed blockchain ledger 212 maintaining immutable logs of all actions performed by all parties.
[0085] Referring now to FIG. 4, there is provided a flow diagram depicting an example process for reinvesting and/or settling a loan, according to some embodiments.
Upon successful loan creation, the CIS may perform and supervise monthly repayments required for the client to settle the loan within a year. In an embodiment, the flow/settlement of funds can be accomplished using fiat currency. Loan payoff payments may refer to a loan principal amount plus an amount of interest agreed in the terms of the original loan. At 402, the process may commence when the CIS sends a request for the electronic fund transfer (EFT) to the client's bank. At 404, the bank may process the EFT request and may release the requested funds at 406. In another embodiment, the client may make payments via a credit card processor where a fiat money asset network already exists to settle transactions. The CIS may allow clients to make loan payments via a variety of payment methods and may enable the client to pay off the loans in a manner they prefer.
[0086] In some embodiments, after the CIS has received the funds, multiple processes may occur simultaneously or in short succession: at 408, the CIS may convert the fiat currency into cryptocurrency using the open-market exchange rates and then may forward the funds to the issuer via issuer subsystem, or depending on the issuers preference, retain the fiat currency and forward the funds in their current state. At 410, funds may be applied to reduce the client's loan balance ¨ the amount of the reduction may correspond to the EFT or credit card payment.
The issuer may then reduce the client's balance.
[0087] In some embodiments, at 414 the CIS may simultaneously (or in short sequence) internally reduce records of balance on the client's account in concert with the reduction of the loan amount at 410. The CIS may then, at 412, notify the client (e.g., via SMS, push notification, electronic mail, etc.) that the funds have been received by the partner financial institution and applied to the outstanding loan amount.
[0088] In some embodiments, at 416, the CIS may notify one or more credit bureaus of the successful payment, the reduced loan balance, and whether the payment was completed in a timely manner (this notification may be immediate or may be completed on a scheduled basis).
[0089] In some embodiments, at 418 while the CIS is performing one or more of the above-mentioned processes, the issuer subsystem may send a confirmation of the payment to the CIS.
Upon receipt of such confirmation, CIS may, at 420, send an additional notification to the client.
This notification may include, for example, the remaining balance of the loan, the balance in the client's account, and next month's payment amount. Once the issuer subsystem receives the funds, it may maintain the liability to hold, spend, or convert the funds to local currency.
[0090] In some embodiments, the CIS will act as an intermediary between the client subsystem and the issuer subsystem, in order to form a loan agreement and collect the fiat money (e.g., government currency-denominated payment) which may be used to pay off the loaned funds. These funds may then be sent to the issuer to pay off the loan in a distributed ledger digital asset (e.g., cryptocurrency), or a lesser value due to any fees (e.g., fees established in the terms of service and/or loan contract).
[0091] In a non-limiting example, after the fifth but before the last (twelfth) monthly payment = cycle, the CIS may cause notifications to be sent to clients explaining the renewal process along with the benefits of renewing the service along with informative content (e.g., "FICO spokesman Craig Watts says that 35% of the score is based on the history of your credit and 15% is based on the length of your credit account). This information may then be provided to the client who may be urged to "roll the loan over" (see definition of rollover above) in order to keep improving these statistics on their credit history.
[0092] In some embodiments, if loan payments are being made in cryptocurrency, the process may begin as depicted at 502 of FIG. 5, when the client deposits funds into their crypto wallet (e.g., purchasing out on open market and sending them to the public key address, or having payroll deposited straight into the wallet). On the agreed date specified in the loan agreement, the smart contract (e.g., 206) may, at 504, initiate a loan payment withdrawal. The CIS may then request that a monthly amount be sent to its crypto wallet at 506, and the client subsystem may use a public key from the CIS to transfer the funds. At 508, the client subsystem may verify the funds by using its private key and the funds may be released to the crypto wallet of CIS.
[0093] In some embodiments, after the CIS has received the funds at 510, funds may be applied to reduce the client's loan balance ¨ the amount of the reduction may correspond to the cryptocurrency payment. There will be no need to conversion as the funds will be deposited into the issuer's crypto wallet 112 directly. The process flow subsequently will follow the same logic as in FIG. 4 starting from 408 Continuation of Service - Reinvesting [0094] Referring now to FIG. 6, at 602 if at the end of the loan term a client has decided to continue using the CIS without withdrawing the original principal, they may need to sign a new set of contracts and pay an updated fee at 604. At 604, once updated client information and contracts have been received, one or more smart contracts may be executed at 606 and the documents pertaining thereto may be encrypted and posted to the distributed blockchain ledger 212.
[0095] In some embodiments, at 606, the digital storage location of the documents may be passed downstream to the issuer subsystem, and at 608 the issuer subsystem may instruct the issuer to originate a new loan and liquidate the investment under the same client account. This may allow for the account age to lengthen rather than restart. At 610, the funds may be received by the CIS on behalf of the client via a crypto wallet 112 in the CIS and the CIS may begin a process to initiate renewal of the account. In a non-limiting example, the following processes may be executed simultaneously or in short succession: first at 614, the CIS
may notify the client that the funds were received (e.g., via GUI); next, at 616, the CIS may notify the issuer to invest the funds back into a new security and at 618 the investment may be completed; next, CIS may notify the credit bureaus of a new loan taken out on the client's account and/or, if possible, append this data to the distributed ledger 212.
[0096] In some embodiments, the issuer will receive the combination of the original principal and the new loan into a crypt wallet and may initiate the smart contract to transfer the new security investment to the client subsystem. This new investment information may be sent to the CIS, and at 620 the new digital asset may have its ownership transferred to the client. The information will flow upstream to the CIS 622 and be passed to the client 624.
[0097] In some embodiments the same process may be achieved through using fiat currency and utilizing current payment infrastructures such as EFT's.
Continuation of Service - Withdrawal [0098] Referring now to FIG. 7, there is provided a flow diagram depicting an example process for processing a client's decision to continue while withdrawing the original principal via the CIS. At 702, a client may decide to reinvest or withdraw funds from the CIS. If the client decides to continue the use of the services provided by the CIS, but wishes to, for example, withdraw the original principal, the client may need to sign a new set of contracts and pay an updated fee at 704. This may be accomplished by executing a process similar to that depicted in FIG. 6 and described above.
[0099] In some embodiments, once the updated information and contracts have been received 704, the smart contract may execute and encrypt the documents and post this data to the distributed blockchain ledger 212. At 706 the location where the encrypted documents have been stored may then be passed downstream to the issuer which may cause the issuer to originate a new loan contract and liquidate the investment at 708. The new loan contract and liquidated investment may be under the same client account, which may allow the account to remain active rather than restart (thus bettering the client's credit history).
[00100] In some embodiments, at 710 the CIS may receive the funds on behalf of the client and may begin the renewal account initiation. The following processes may be executed simultaneously or in short sequence: at 714, the system may notify the client that the funds have been transferred to their crypto wallets, and that the client may now withdraw said funds into fiat currency or use the funds in the wallet as-is; at 716, the CIS may direct the issuer to = invest the loaned funds back into a new security selected by the client;
at 712, the CIS may notify the credit bureaus that a new loan has been taken out on the client's account (e.g., in METRO2 format), and/or, if possible, append data reflecting the new loan to the distributed blockchain ledger 212.
[00101] In some embodiments, at 718, the issuer may receive the new loaned funds and invest them in the new security. At 720 this new investment information may be transmitted to the CIS and the security data token may be transferred into the client's crypto wallet and the CIS will send 722 this information upstream to the client 724. After this, the processes outlined by FIG. 4 or FIG. 5 may repeat for a pre-determined period of time (e.g., t, where t is the length of the term). If the client selects to renew the account, the process may loop for t times.
Final Payment - Closure [00102] Referring now to FIG. 8, there is provided a flow diagram depicting an example process for terminating an account in the CIS according to some embodiments.
At 802, upon successful completion of the term of a loan initiated via the CIS, (e.g., the process in FIG. 4 has completed 11 cycles); the CIS may initiate and request the client subsystem to process the final payment, under the client's instruction to terminate their account. At 804 the client completes the payment, and, if using fiat currency to make the payments, the client's bank may receive the request for the final EFT and may release the final funds 806. In another embodiment, the CIS
may execute a contract for the client subsystem to transfer the final payment from the client's crypto wallet to the public key address of the CIS crypto wallet.

[00103] In some embodiments, at 806 the client subsystem may transfer ownership of the =asset to the CIS temporarily as it proceeds to liquidation. When asymmetric cryptography has been processed successfully, and the final funds have been received 808, the funds may be transferred to the issuer subsystem, reducing the client's balance to zero ($0) and settling the loan 810.
[00104] In some embodiments, at 814 the CIS may update the client's loan balance in the CIS
(e.g., on the account dashboard) to $0. At 812, a notification may be sent to the credit bureau regarding the settled loan and indicating a CIS account with good credit standing. Throughout the process the client may be notified 816 by the CIS of the transfers of funds and settlement of the loan.
[00105] In some embodiments, at 818, to finalize the process, the CIS may send a request to the issuer subsystem to liquidate the security investment and transfer its ownership to the issuer subsystem crypto wallet. At 820, the issuer, upon receiving the request and after proper assessment, may liquidate the security on behalf of the CIS and the client.
The account with the issuer may then be closed. At 822, after the liquidation process, the funds may be transferred to the CIS, and thereafter ultimately transferred to the client at 824. At 824, the account may be closed based on the client's request. Finally, at 826, the client may receive the final funds accompanied with a notification of the closed account and settled loan.
[00106] Revolving Loan [00107] One of the attributes that credit ratings agencies use to score individuals on their risk score is the type of credit that they have. A broader variety of credit, coupled with on-time payments, exemplifies that the individual is capable of managing multiple streams of debt. If the variety of debt is properly managed, this can have a significant positive impact on the rating models the CRA's use when evaluating a person's risk level. Therefore, to improve a credit score, multiple methods can be utilized. Previously, instalment loans with fixed payments were used to pay back the loan while investing the funds into a GIC. The approach described herein can increase an individual's credit score, with all other factors remaining constant.
[00108] In some embodiments, another way the CIS can be used to improve the credit score is by using a revolving loan to pay off "predictive payments" (e.g., payments that can be accurately predicted due to their consistent quantum and schedule). A modern-day consumer may have multiple monthly bills, including but not limited to, shelter (rent and mortgage), telecommunications (phone and internet), utilities, and other potential items such as subscription boxes, subscription groceries, and entertainment (Netflix, Spotify, etc.).
[00109] The following example embodiments a credit card payment to illustrate some of the processes. It will be understood that any revolving loan or similar financial vehicle may be used so long as the loan repayments can be made at will versus according to a set repayment schedule, and the borrower of the loan (e.g., the client) can draw down the funds available if the loan ceiling has not been reached.
[00110] Three (3) non-limiting example scenarios are provided involving use of a revolving loan to improve a client's credit score. The first non-limiting example scenario illustrates a case where the bill or payment is consistent over time and will not change in the near twelve (12) month period. This can include, for example, a rent or mortgage payment with a locked in amount, or an internet bill with unlimited bandwidth so as to not incur overage charges. The second and third non-limiting example scenarios illustrate cases involving inconsistent bill payments, such as utilities that might fluctuate between seasons. FIG. 9 through FIG. 11 illustrate the three non-limiting example scenarios and will be described below.
[00111] Referring now to FIG. 9, there is provided a flow diagram depicting an example process for a client securing a revolving loan by means of the CIS. At 902, the process may begin by client completing a client onboarding procedure (e.g., via client subsystem 116), which may proceed as described in 302, including information submittal 904, admin fees 904, information encryption 902, blockchain appends 906, account approval 906, client notification 908, and loan creation 910. The process, as depicted, may include receipt and/or processing of information about the bill or payment to be replaced by the CIS, which may not be depicted in FIG. 3.
[00112] When the client is on-boarded, the CIS may require the client to input: i) consistency of bill or payment amount; ii) average bill or payment amount; and iii) bill or payment issuer information and permissions to access the bill amounts. If it is an internet bill, for example, the client may indicate: that it is an internet bill that does not change in amount due monthly; the provider (Rogers, Bell, Verizon etc.); the average bill amount, service provider account number (to pay the bill on clients' behalf); and a TOS that may provide digital permissions to the CIS, thereby enabling the CIS to pull the bill amount directly from the bill provider (e.g., using APIs, flat-files, or any other means available).

[00113] If the payment is, for example, a rent payment the client may provide:
the rent amount;
indication that the rent will not change; and, rather than an account number that the CIS will pay on behalf of the client, a payment method that is suitable for the landlord to accept the rent payment (i.e. PayPal, e-transfer, crypto wallet). In other embodiments, once the CIS has been given access to the bill issuer's data on behalf of the client, it may perform a twelve-month trailing average calculation on all historic bill amounts and automatically input a value (e.g., a suggested payment amount) into this field.
[00114] In some embodiments, once the funds have been received and, if required, the account has been approved, the CIS may complete the account creation process 906 by, at 910, decrypting and transmitting one or more e-signed contract documents to one or more issuer subsystems. This may authorize a revolving loan to be originated under the client's name 912. At 908, the client may be notified of the new account creation. The example hereafter will use a credit card to illustrate concept discussed above.
[00115] At 913, once the loan has been issued, the CIS may notify credit bureaus of the new credit account for the client. The notification sent to the credit bureaus may include identifiable information (e.g., information sent in Metro2 format, the current standard format for reporting credit), or, if the systems of the credit bureaus are capable of utilizing distributed ledger technology, the new credit account information may be appended to this ledger, assuming the CIS system has been given digital permission for write-access.
[00116] Once the loan has been issued, the information for exclusive usage may be forwarded by the issuer subsystem to the CIS 914. The credit card may only have one purpose, which will be governed and controlled by the CIS. This may ensure that no client intervention may erode the credit building objectives by overspending, not maintaining the optimal balance, and not paying on time.
[00117] Optimization of the credit utilization factor may be a prime objective of the revolving loan system. In order to achieve the applicable generally accepted optimal credit utilization rate (e.g., CRA's recommended 20%-30% utilization rate), it may be imperative to employ a debt prediction engine 211 to predict the bill or payment amounts, and execute one or more credit optimization processes issuing cards with limits that can sustain fluctuations of the payments and not drop below the recommended rate. To achieve this, the credit card issued according to the optimization process at 912 may have a credit limit of, for example, four (4) times the consumer inputted payment amount. The inherent benefit of quadrupling the bill payment amount is that every time a payment is made by the CIS on behalf of the client, the client's card will reach the optimal utilization rate, every single payment.
[00118] As a non-limited and solely illustrative example, a rent payment in the amount of $1000 is due monthly and originates at 916 with the landlord requesting and expecting the payment. Since this was a rent payment amount that the client had inputted, no bill pulling will be required by 918 but will still be applicable if the consistent bill came from an established organization providing a service to the client where the CIS would have been able to access the information by itself. In 904 the payment time schedule would have been set (e.g., first of the month, last of the month, middle of the month, biweekly, etc.) and the CIS
activates the payment process 920. The system first draws the needed funds from the client's bank to ensure that the credit card is left with no balance owing and no client funds available in the system to be able to pay off the revolving loan. This step occurs as an initial pre-step in order to safe-guard against losses.
[00119] At 922 the bill payment processes commence when the CIS sends a request for the electronic fund transfer (EFT) to the client's bank. The bank may, in response, process the EFT
request and may release the requested funds. In another embodiment, the client may be able to make payments via a variety of payment methods which may enable the client to pay off the loans in a manner they prefer. If the fiat currency option is not chosen, the CIS may draft a smart contract to be automatically executed monthly on the specified repayment date. This smart contract may include the specified rent amount, and may pull the funds from the crypto wallet the client has provided. Multiple processes may occur simultaneously or in short succession: the CIS may convert the crypto currency into fiat currency using the open-market exchange rates and then may forward the funds to the issuer via issuer subsystem.
[00120] Once the funds have been received, the CIS may pay off the bill in full using the credit card issued 920. This may be completed by utilizing currently available infrastructure for bill payments, for example by using a financial institution's web banking to input the client's account number and forwarding the funds to the billing organization. This may also be accomplished by utilizing a partnership with the bill issuers to directly interact with the CIS. If the payment is, for example, rent, as in our example above, the CIS may charge the credit card through a payment merchant, and now, as it is holding the funds, the CIS may transfer the funds to the landlord in any means they find suitable (e.g., e-transfer, PayPal, or bank transfer). Any fees associated with money transfers may be covered by the client system.
[00121] In some embodiments, at 924 while the CIS is performing one or more of the above-mentioned processes, the bill/payment subsystem may send a confirmation of the payment to the CIS. Upon receipt of such confirmation, CIS may, at 926, send an additional notification to the client. This notification may include, for example, the outstanding balance of the loan, the due date, and days outstanding. In some embodiments, at 927, the CIS may notify one or more credit bureaus of the credit usage, the debt owing, and whether the payment was completed in a timely manner (this notification may be immediate or may be completed on a scheduled basis). Most importantly, the report to the CRA will show a 25% perfect utilization rate of credit.
[00122] At 928, funds received in 922 may be applied to reduce the client's loan balance ¨ the amount of the reduction may correspond to the EFT or crypto payment. In the case of the cryptocurrency, the digital tokens may not need to be converted, but may be transferred to the issuer subsystem right away, once again utilizing asymmetric cryptography to sign, verify, and authorize the transfers. In case of fiat currency, or converted crypto currency, the funds will be sent to the issuer of the credit card and the issuer may then reduce the client's balance 930.
Once there is a payment processed, the CIS will report to the CRAs 932 that the credit card has been paid off and is in good standing. A randomly generated number (e.g., a number between 2 and 7) may determine a delay (e.g., a number of days' delay) after which the CIS may proceed with sending out the credit card payment. This delay may imitate a human's payment behaviour and may avoid the appearance of automated payments when monitored (e.g., by credit rating agencies) as automated payments may have a suboptimal effect on credit building.
[00123] It will be understood that a portion or all of the aforementioned may be executed by use of smart contracts (e.g., 206), with the initiation, performance, and confirmation or rejection of the contract appending to the distributed blockchain ledger 212 maintaining immutable logs of all actions performed by all parties.
[00124] Referring now to FIG. 10, there is provided a flow diagram depicting an example process for a client securing a revolving loan by means of the CIS when the bill or payment is above the threshold. It is understood that when the bill or payment is available 1002 and the CIS
pulls the payment amount 1004 that the client has completed an onboarding process that mirrors the steps from 902 through 914 including information submittal 904, admin fees 904, information encryption 902, blockchain appends 906, account approval 906, and loan creation 910.
[00125] The only difference between the process depicted in FIG. 10 and FIG. 9 may be found at 912 - the issuance of the credit card. Optimization of the credit utilization factor may be a prime objective of the revolving loan system. In order to achieve an optimal utilization rate (e.g., CRA's recommended 20%-30% utilization rate), it may be imperative to predict the bill or payment amounts, and to issue cards with limits that can sustain fluctuations of the payments (e.g., fluctuations in the amount due) and not deviate from the recommended rate. To achieve this with an unknown bill or payment amount, the credit card issued at 912 that had a credit limit of four (4) times the consumer inputted bill average may now, according to the example embodiment of FIG. 10, have a limit of three (3) times the client's inputted average bill or payment amount. The difference between quadrupling in 912 and tripling for FIGS. 10 and 11 may be indicative of a conservative approach when reporting the credit utilization rates to the CRA and may ensure said rates never drop below a 30% utilization rate.
[00126] In some embodiments, to improve process efficiency, a threshold may be set to dictate the upper bound level that a bill or payment may fluctuate up to and not have a detrimental effect on the credit rating models of the CRAs. The bound of this threshold is, according to some example embodiments, 30% and may indicate the bill or payment amount relative to the total credit limit. If the client indicated, or the CIS
deduced, that an average amount owing for a certain bill is $100, then the credit card issued in accordance with this example embodiment will be for $300. If a bill arrives for $50, the bill is 16.67% (50/300) of the credit limit amount and may be processed in accordance with the example process of FIG. 11.
Further, a bill below $90 (0.3 x 300) may be below the 30% threshold and may follow the example process of FIG. 11. Any bill above $90 may follow the example process in FIG. 10 where the credit card will only be used for 25% of the purchase.
[00127] In some embodiments, if a bill with an unknown amount due (y) comes in it can be below or above the threshold. If it is above, the credit card issued may only be used for 25% of the bill amount (described later in 1016), and if it is below, the full amount may be processed by the credit card. If the bill is below, for example $70, the credit limit used may be 23% (e.g., 70/300) which may be a lot closer to the optimal credit utilization rate than if we used the previous issuance example of four times (4x) the average bill amount where the credit limit used would be 17.5% (70/400). Hence we can see why the lower multiple of credit limit issuance may bring an advantage to irregular payments falling below the average bill amount, optimizing the credit utilization, while the payments above the average are optimized by using 25% of the bill paid by the card, while the remainder is paid by other means.
[00128] In an example embodiment, a utilities payment with an average amount of $150 is due monthly and originates at 1002 with the service provider requesting and expecting the payment.
The information the client supplied in 904 may contain all details and permission for the CIS to access the information by itself 1004. In 904 the payment time schedule would have been set (e.g., first of the month, last of the month, middle of the month, biweekly, etc.) and the CIS may activate the payment process 1006. The system may first draw the required funds from the client's bank to ensure that the credit card is left with no balance owing and no client funds available in the system to be able to pay off the revolving loan. This step may occur prior to other steps in order to safe-guard against losses.
[00129] At 1008 the bill payment process may commence when the CIS sends a request for the electronic fund transfer (EFT) to the client's bank. The bank may process the EFT request and may release the requested funds. In another embodiment, the client may make payments via cryptocurrency. The CIS will draft a smart contract to run monthly on the specified payment date, with the specified bill amount, and will pull the funds from the crypto wallet the client has provided. Multiple processes may occur simultaneously or in short succession:
the CIS may convert the crypto currency into fiat currency using the open-market exchange rates and then may forward the funds to the issuer via issuer subsystem in 1022, or send the crypto currency to the issuer system in the native token, also at 1022.
[00130] Since the bill that arrived in the non-limiting example above was for $150 and, thus, over the 30% threshold of the credit limit, the CIS may only use 25% of the available credit limit to pay the bill 1010. As previously mentioned, this will ensure our optimal credit utilization is not exceeded. The card limit that was issued is three (3) times the average bill amount of $100, so the credit limit is $300. This means $75 is 25% and this amount gets paid with the credit card 1010, reducing the available funds down to $225 (300-75) 1012, and reporting the balance and activity to the CRAs at 1014.
[00131] In some embodiments, reporting the balance and activity to the CRAs may be done through the currently available infrastructure for making bill payments, for example by using a financial institution's web banking interface to input the client's account number and forwarding the funds to the organization, or utilizing a partnership with the bill issuers to directly interact with the CIS. The bill issuer (e.g., the utilities company) may send a receipt confirmation 1015 back to the CIS which may trigger the remainder of the amount to be paid via EFT from the CIS
holding account 1016. Since only $75 dollars was paid from the credit card, the amount remaining may be $75 (150-75) and will be sent to the bill issuer 1016. The bill may now be fully paid with a final confirmation from the bill company coming to the CIS 1018.
[00132] To mimic human payment behaviours there may be a randomized day delay (e.g., between two (2) and seven (7) days) before the CIS pays off the credit card balance. At 1008 an amount of $150 is pulled from the client, of which only $75 was used as EFT to pay the remainder of the bill in 1016. After the delay, the remainder $75 not sent to the bill issuer is used to pay off the credit balance 1020 of $75 that was paid in 1010. A
notification to the client is sent at 1026 indicating that the both the bill and the credit card balance have been paid off. The issuer subsystem may receive the credit card payment at 1022, increase the balance available on the credit card, and a report may be sent to the CRAs indicating that the balance has been paid in full and there are no issues or delayed payments with this revolving loan 1024.
[00133] It will be understood that a portion or all of the aforementioned may be executed by use of smart contracts (e.g., 206), with the initiation, performance, and confirmation or rejection of the contract appending to the distributed blockchain ledger 212 maintaining immutable logs of all actions performed by all parties.
[00134] Now referring to FIG. 11, in some embodiments, if an amount owing in a bill is below the threshold, the process may be quite similar to that of when it is above (e.g., FIG. 10), the processes from 1102 through to 1106 may mirror certain processes depicted in the example of FIG 10. The difference may be at 1110, when the credit card is used for the full bill payment rather than a part of it. The CIS may use the credit card to pay off the full bill amount. This can be done through the current infrastructure of bill payments, using a financial institution's web banking interface to input the client's account number and forwarding the funds to the organization, or utilizing a partnership with the bill issuers to directly interact with the CIS. If the bill is $60, the full amount may be sent to the bill holder 1112, thereby reducing credit card balance to $240 (300-60) 1113.
[00135] In some embodiments, the balance owing at 1113 may be reported to the CRAs 1114 at an activity level of 3x-y/3x where y is the bill and x is the average bill amount. In our scenario this will be 80% (240/300). This may be particularly effective because, as previously explained the lower bills are not a detriment to the credit history and may provide the most efficient process when the objective is optimization of the utilization rate. Following a similar tactic described above, the payment may be delayed for a randomized period (e.g., between two (2) and seven (7) days) before being fully paid off at 1116. The issuer subsystem may receive the payment and reduce the balance owing to $0 at 1118, and the CIS may report the activity to the CRAs at 1120.
[00136] In some embodiments, if a client wishes to add more payments or bills to the CIS
under their account, it may be most prudent to combine the bills or payments into one card if they are of the same payment schedule expectations. Such combinations of payments or bills may only be efficiently made when the schedule according to which said payments or bills arrive are similar.
[00137] For example, in some embodiments, the client may be prevented from combining different payment expectations schemes. In case of combinations, the new service may be added onto the existing, increasing the credit limit of the original credit card. If the original service had an average bill amount of $100, the credit limit is $300, and if the new bill that the client wishes to add has an average bill amount of $50, then the credit limit of the original card will need to be increased by $150 (50 x 3) from $300 to $450. Then, when both payments are pulled from their respective bill issuers, the combination (sum) of the bill amounts will be used to calculate the threshold limits. Following similar protocol, if the payment is above the threshold, the process in FIG 10 will activate, and if below, the process in FIG 11 may commence.
[00138] In a non-limiting example, after the fifth but before the last (e.g., twelfth) monthly payment cycle, the CIS may cause notifications to be sent to clients explaining the renewal process along with the benefits of renewing the service along with informative content (e.g., "FICO spokesman Craig Watts says that 35% of the score is based on the history of your credit and 15% is based on the length of your credit account). This information may then be provided to the client who may be urged to continue using the credit card for bills or regularly scheduled payments in order to keep improving these statistics on their credit history.
[00139] It is understood that the collective steps shown in the figures are illustrative and steps may be modified, omitted, appended, substituted, removed and the order of certain steps may be altered while remaining within the realm of the present disclosure.

[00140] Embodiments of methods, systems, and apparatus herein are described through reference to the drawings.
[00141] The discussion herein provides many example embodiments of the inventive subject matter. Although each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly disclosed.
[00142] The embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.
[00143] Program code is applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a software communication interface, such as those for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof.
Other Applications [00144] Potential applications that may be practiced in regards to some embodiments are described below. There may be other, different, modifications, customizations, iterations, etc. of the below example applications, and it should be understood that the following is provided as non-limiting, illustrative examples only.
[00145] Throughout the discussion herein, numerous references are made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server configured to provide the CIS system can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.
[00146] The technical solution of embodiments may be in the form of a software product. The .. software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk.
The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided by the embodiments. For example, computerized instructions functional to enable computer systems to perform functions .. of the client subsystem, the CIS, and the distributed blockchain ledger may be provided and may be installed and operated one or more computers in order to enable performance of the systems and methods described herein.
[00147] The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements. For example, the embodiments described herein may be executed on a particularly configured single-purpose custom computer device.
[00148] Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein.
[00149] Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification.
[00150] As can be understood, the examples described above and illustrated are intended to .. be exemplary only.

Claims (13)

WHAT IS CLAIMED IS:

Any and all features of novelty or inventive step described, suggested, referred to, exemplified, or shown herein, including but not limited to processes, systems, devices, and computer-readable and -executable programming and/or other instruction sets suitable for use in implementing such features.

1. A computer-implemented method for monitoring and dynamically optimizing credit utilization, the method comprising:
a. storing a financial transaction data associated with a user in a distributed blockchain ledger;
b. monitoring the financial transaction data associated with the user via the distributed blockchain ledger;
c. monitoring one or more issuer subsystems for at least one loan instrument and at least one investment vehicle associated with the user;
d. detecting the loan instrument associated with the user, the loan instrument having at least one loan instrument parameter;
e. calculating an optimal credit utilization factor for the user by aggregating and processing the financial transaction data associated with the user according to one or more parameters of an optimal utilization rate;
f. executing an optimization process to accord one or more values within the financial transaction data associated with the user with the one or more parameters of the optimal utilization rate; and g. writing a record of the optimization process to the financial transaction data associated with the user stored in the blockchain ledger.

2. The method of claim 1, wherein the distributed blockchain ledger is an append-only, immutable database.

3. The method of claim 1, wherein the financial transaction data includes:
at least one unique identifier associated with one or more financial transactions;
a plurality of details relating to the one or more financial transactions; and one or more timestamps associated with each unique identifier.

4. The method of claim 1, wherein the optimal credit utilization factor is calculated by a debt prediction engine, the debt prediction engine processing the financial transaction data associated with the user to determine the optimal credit utilization factor prior to the detection of the loan instrument associated with the user.

5. The method of claim 1, wherein the one or more values within the financial transaction data associated with the user include at least one debt limit of at least one debt instrument.

6. The method of claim 5, wherein the optimization process includes according the at least one debt limit of the at least one debt instrument with the one or more parameters of the optimal utilization rate.

7. The method of claim 5, wherein the optimization process includes repaying the at least one debt instrument and securing a second at least one debt instrument having a second at least one debt limit.

8. The method of claim 5, wherein the optimization process includes reconfiguring the at least one debt limit of the at least one debt instrument.

9. The method of claim 1, comprising sending at least one notification to at least one credit bureau.

10. The method of claim 1, wherein at least one smart contract automatically executes at least one step of the method.

11. The method of claim 1, wherein the optimization process includes securing the at least one investment vehicle, the at least one investment vehicle having at least one investment vehicle parameter.

12. The method of claim 11, comprising liquidating the at least one investment vehicle and securing a second at least one investment vehicle having a second at least one investment vehicle parameter.

13. The method of claim 1, comprising:
receiving at least one user information from the user via a client subsystem;
and storing the at least one user information from the user in a memory;
as a user onboarding step.