Patent Application
20240177125
Equated monthly installment (EMI) are loans established by financial Institutions (FIs) for consumers. EMI can also be associated with recurring subscription fees of a consumer with a provider. Additionally, some debit card arrangements allow EMI payments even when the consumer lacks the funds in the bank account to cover a purchase. This is useful to the consumer making purchases with credit when their bank account has insufficient funds to cover the purchases.
Often the financial institutions require the consumers to provide an e-mandate, which links a consumers financial account to the loan or subscription and provides authorization for the FI to auto withdraw the monthly minimum payment from that bank account. E-mandates or auto transfer authorization allows FIs to collect funds from consumers without reminders and without extensive paperwork; consumers also do not have to worry about missing a payment.
The FI collects the funds and pays the corresponding debt holder, which may be another bank associated with the consumer's debit card or which may be a subscription service. E-mandates and auto transfers permit digital transfers of consumer loan or subscription payments directly from the consumer's financial account to the creditor using an e-mandate producer.
However on the payment date for a loan or a subscription, if a consumer does not have a sufficient balance in the bank account being used for payment, the auto transfer payment fails, and the consumer must pay a penalty fee to both the e-mandate producer authority and the creditor associated with the loan or subscription. Lacking sufficient funds to cover a monthly payment also negatively impacts a consumer's credit report.
In various embodiments, methods and a system for auto installment payments via smart contracts on a blockchain are presented. A user registers accounts of the user that are to be used as payment sources for an installment payment owed by the user to a creditor through a provider. The user is provided a secure token which is presented by the user to a cloud-based service for establishing a smart contract on a blockchain that includes the registered accounts, terms of the installment payments, and other customer conditions. The cloud service provides the user with a first access token linked to a default account for the user and a second access token linked to the other registered accounts of the user which are not the default account. The user provides the first access token and the second access token to the provider. The provider accesses the smart contract on the blockchain using the secure token and provides the first access token. The smart contract determines whether a current account balance of the default account linked to the first access token has sufficient funds to cover the installment payment due to the provider and if so, transfers the payment due to an account associated with the provider or the creditor on behalf of the user. When the default account lacks sufficient funds, the provider provides the smart contract with the second access token and the smart contract calculates a percentage of the payment amount due to take from each of the accounts and transfers the corresponding funds from the accounts to an account associated with the provider or the creditor.
When a user takes a loan from a bank or a subscription from a server, either the user or the bank sets up a mandate for auto monthly bank transfers from a bank account of the user to the creditor of the loan or the subscription. This can be done through paperwork or electronically using an e-mandate. On the payment due date, the mandate is presented to the registered bank account and when there are insufficient funds to cover the payment, the mandate is rejected and fails. The user has to pay a penalty (similar to bouncing a check) to both the creditor and the FI that set up the mandate or auto monthly transfer payment. The creditor reports these events to the credit bureau, which creates a negative impact on the user's credit worthiness.
The user may actually have multiple different bank accounts when an auto transfer payment fails on a specific one of the user's bank account. Moreover, the user's bank account that lacked sufficient funds may have only lacked sufficient funds by a very small amount, such as less than a dollar. These circumstances are irrelevant and not accounted for in the existing auto transfer payment process. Unfortunately for the user, the amount the user was short and the fact that the user had other accounts to fully cover the payment are irrelevant and the user is stuck with fees to two entities plus the required installment payment to the creditor.
The teachings provided herein and below obviate these issues by providing a secure mechanism by which users can register their existing bank accounts on a blockchain. Once registered, a FI issuing authority for a consumer card provides the user with a first secure token. The user is authorized with the first secure token to establish a smart contract on the blockchain. The user establishes the smart contract through a cloud-based service using the first secure token. The service configures and installs the smart contract on the blockchain and provides the user with two access tokens. The first access token authorizes the requestor to take payments from a default account of the user and the second access token authorizes the requestor to pool funds from other registered accounts in the user's blockchain.
When a requestor (mandate or auto payment provider) wants to collect an installment payment, the first access token is presented to the smart contract, assuming the default account has sufficient funds for the balance, the requestor transfers the installment payment from the default account and pays the corresponding creditor to a transfer to the creditor's account made on behalf of the user. When the smart contract indicates there is insufficient funds in the default account, the requestor presents the second access token associated with other registered accounts of the user. The smart contract then pools funds from the default account and the other accounts in a calculated proportion and provides the pooled funds back to the requestor and the requestor transfers the pooled funds in the amount of the installment payment to an account associated with the creditor on behalf of the user.
Any consumer with an EMI or auto installment loan or subscription can securely benefit from the teachings provided herein by utilizing all available accounts instead of a single account for the installment payments. The EMI or auto installment provider (requestor) timely receives funds from the consumer to make payment to the consumer's creditor. No fees are charged by the provider or the creditor when the consumer's pooled funds are sufficient to cover a monthly installment payment.
Various embodiments of the teachings are now presented with initial reference to
Furthermore, the various components are illustrated, and the arrangement of the components is presented for purposes of illustration only. It is to be noted that other arrangements with more or fewer components are possible without departing from the teachings of auto installment payments via smart contracts on a blockchain, presented herein and below.
As used herein, the terms “user,” “debtor,” and “consumer” may be used interchangeably and synonymously. This refers to an individual that has a loan or a subscription and has set up an e-mandate or an authorization for automatic installment payments to a creditor associated with the loan or subscription through a provider. A “provider” is a FI that is servicing an e-mandate or an auto installment payment service on behalf of a debtor and the debtor's creditor. A “creditor” can be a FI or a retailer that provides goods or services, such as subscriptions.
An “account” has used herein refers to a financial account from which funds can be transferred to satisfy all or a portion of an installment payment for a loan or a subscription of a consumer. The account can be a FI bank account, a debit card linked to a FI account, or a credit card account that authorizes fund withdrawals.
Cryptocurrency and non-fungible tokens (NFTs) sellers and buyers have few options when selling or purchasing cryptocurrency/NFTs besides a large cryptocurrency exchange. Peer-to-Peer (P2P) transactions between a seller and a buyer is not secure and is not safe. Embodiments, presented herein and below, provides a service by which P2P transactions are decentralized, secure, and efficient. The parties to a transaction experience no risk of loss and do not have to wait for days once a payment obligation of the transaction is satisfied. The service itself does not experience any risk associated with cryptocurrency/NFTs transactions as it only holds assets associated with a transaction in escrow on behalf of the parties. Thus, the enterprise associated with the service does not maintain any volatile assets on its balance sheet and does not run afoul of any governmental regulations with respect to cryptocurrency/NFTs. The enterprise may charge a small fee for the service or may offer it for free to customers as a value-added service.
System 100 includes at least one cloud/server 110, user-operated devices 120, blockchain devices 130, and one or more FI servers 140. Cloud/server 110 includes a processor and a non-transitory computer-readable storage medium 112. Medium 112 includes executable instructions for a payment mediator service 113 and Application Programming Interfaces (APIs) 114, which when executed by processor 111 in turn causes processor 111 to perform operations discussed herein and below with respect to 113 and 114.
Each user-operated device 120 includes a processor 121, a non-transitory computer-readable storage medium 122. Medium 122 includes executable instructions for a service application (app) 123 and a payment mediator (app) 124, which when executed by processor 121 causes processor 121 in turn to perform operations discussed herein and below for 123 and 124.
Blockchain devices include processors 131 and a non-transitory computer-readable storage mediums 132. Mediums 132 includes executable instructions for smart contracts 133, which when executed by the processors 131 cause processors 131 in turn to perform operations discussed herein and below for smart contracts 133.
Each FI server 140 includes a processor 141 and a non-transitory computer-readable storage medium 142. Medium 142 includes executable instructions for a payment service 143, blockchain API 144, and, optionally, a mediator service API 145, which when executed by processor 141 in turn causes processor 141 to perform operations discussed herein and below with respect to 143-145.
Initially, users download payment service app 123 and payment mediator app 124 to their devices 120. Alternatively, one or more users utilize a web browser of device 120 that provides service app 123 and/or payment mediator app 124 through web pages and plugins to the browser. The users accesses a user interface of app 123 to interacted with payment service 143 for purposes of registering each available account of the user for use on the blockchain (BC) 130. Once the accounts are registered, payment service 143 interacts through mediator service API 145 to provide the registered accounts, the user identifier, and conditions or terms of the user's agreement with the FI as a provider that collects installment payments on behalf of the user and a creditor.
Payment mediator service 113 returns a first secure token back to payment service 143 through API 145. Payment service 143 provides the first secure token to the user interface of app 123 for the user to use to establish a smart contract 133 on the BC 130 through payment mediator service 113.
The user accesses a user interface of payment mediator app 124 and provides the first secure token back to payment mediator service 113. Payment mediator service 113 links the first secure token to the registered accounts, the user, and the installment payment agreement between the user and the provider associated with FI server 140. Payment mediator service 113 requests that the user identify a default account from the list of registered accounts. Payment mediator service 113 generates two secure access tokens, the first secure access token provides authorization to take installment payment funds from the user-identified default account and the second secure access token provides authorization to take installment payment funds from the other registered accounts that were not designated as the default account.
Payment mediator service 113 generates instructions for a smart contract 133 that is identified over the BC 130 by the initial first secure token provided by the provider through the payment service 143 during account registrations by the user. The instructions include caveats or conditions that identify the amount of the installment payment, the length of the installment payment, etc. The conditions link the first access token to the default account and the second access token to the other non-default registered accounts. The executable instructions with the conditions are then instantiated as the smart contract 133 on the BC 130 accessible from a location on the BC 130 linked to the first secure token provided during account registrations.
The user accesses the user interface of app 122 and interacts with payment service 143 to provide the first and second access tokens. The payment service 143 was already provided the first secure token from payment mediator service 113 such that the first secure token is already linked to the user identifier of the user and the user's installment payment agreement with the provider associated with payment service 143.
When a payment due date is identified for the user's installment payment agreement, payment service 143 uses the first secure token to access the smart contract 133 and provides the smart contract as input the first access token using BC API 144. The smart contract 133 includes instructions to verify that the first access token is authentic and to check a current balance in the default account. Assuming the default account has a sufficient balance to cover the installment payment amount due, smart contract 133 transfers the installment payment amount from the default account to an account linked to the provider or linked to a creditor associated with the installment payments. The provider or creditor account can be preconfigured in the instructions of the smart contract 133 or provided as additional input provided by the payment service 143 to the smart contract 133.
When the default account has less than the total amount due for the installment payment, the smart contract notifies payment service 143 through BC API 144 and in response payment service 143 provides back the second access token using BC API 144. The smart contract 133 further includes instructions for automatically calculating what portions of funds from the default account and the non-default accounts are to be used to provide the payment service 143 the full installment payment due by the user. This can be done in a variety of manners.
For example, the instructions of the smart contract 133 can evaluate account histories associated with the registered accounts in view of historical balances and current balances in each registered account to calculate the percentage of the payment due taken from each of the accounts. A percentage of the payment due is then allocated to each of the accounts and the smart contract 133 transfers the corresponding funds by assigned percentage of the payment due from the corresponding accounts to an account associated with the provider or creditor to satisfy the installment payment due in full.
In an embodiment, the user can assign priorities through a profile to each of the registered accounts or assign rules, which are processed by the instructions of the smart contract 133 to determine the percentages of the payment due taken from each account. In an embodiment, the user can access the user interface of app 123 at any time and change rules and/or priorities even after the smart contract 133 is executing on the BC 130.
In an embodiment, smart contract 133 can utilize a machine-learning model (MLM) that receives as input the account histories and balances of the registered accounts, current balances of the registered accounts, and the payment due amount. The MLM produces as output a specific amount to take from each of the accounts to obtain the full payment due.
In an embodiment, API 145 can be processed by the provider to interact with mediator service 113 and delegate the first and second access tokens to a different provider. This is useful when providers change. It is noted that conditions associated with the installment payments for the loan or subscription cannot be changed by any provider after initial creation of the first secure token by payment mediator service 113. This ensures that the terms of the user's loan agreement or subscriber agreement are not unilaterally altered by providers without the user's consent.
The smart contract 133 denies an installment payment due only if a total of all the current balances for the registered accounts of the user are insufficient to cover the installment payment due. This reduces the likelihood that the user will be hit with fees from the provider and creditor and ensures that creditors are timely receiving the amounts due to them by the user.
In an embodiment, payment mediator service 113 can charge a service fee to the provider, the creditor, and/or the user. Service 113 can also charge a monthly and/or usage-based fee to the provider and/or creditor. In an embodiment, service 113 charges no fees and is provided as a value-added service to the users, the providers, and the creditors.
The above-referenced embodiments and other embodiments are now discussed with reference to
In an embodiment, the payment mediator service executes on cloud 110 or server 110. In an embodiment, the payment mediator service executes on a FI server 140.
In an embodiment, the payment mediator service is one, all, or some combination of 113 and/or 114. In an embodiment, payment mediator service presents another, and in some ways, an enhanced processing perspective from that which was discussed above with system 100.
At 210 (shown in
In an embodiment, at 211 (shown in
At 220 (shown in
In an embodiment of 211 and 220, at 221 (shown in
At 230 (shown in
In an embodiment of 221 and 230, at 231 (shown in
At 240 (shown in
At 250 (shown in
At 270 (shown in
In an embodiment, at 271 (shown in
In an embodiment of 271 and at 272 (shown in
In an embodiment of 271 and at 274 (shown in
At 280 (shown in
In an embodiment, at 281 (shown in
The smart contract executes the instructions on the BC. This is done autonomously once the payment mediator service instantiates the smart contract on the BC.
In an embodiment, the device that executes the BC payment mediator service is cloud 110 or server 110. In an embodiment, the device that executes the BC payment mediator service is a FI server 140.
In an embodiment, the BC payment mediator service is all of, or some combination of, 113, 114, 133, and/or method 200. The BC payment mediator service presents another and, in some ways, an enhanced processing perspective from that which was described above for system 100 and method 200.
At 310, the BC payment mediator service receives registered accounts of a user from a provider. The provider services installment payments being made from the user to a creditor in connection with a user loan or a user subscription service.
At 320, the BC payment mediator service provides the provider a secure token for delivery to the user and creation of a smart contract that manages the installment payments on the BC. At 330, the BC payment mediator service receives the secure token from the user and the BC payment mediator service links the secure token to the registered accounts received for the user at 310.
At 340, the BC payment mediator service receives selections from the user that designate a default account and secondary accounts from the registered accounts. It is noted that this may be just a single selection made by the user through a user interface that identifies the default account with the secondary accounts assumed to be those registered accounts that are not the default account.
At 350, the BC payment mediator service generates a first access token associated with the default account. The BC payment mediator service also generates a second access token that associated with the secondary accounts as a whole.
At 360, the BC payment mediator service configures instructions with conditions associated with the installment payments, the default account, the secondary accounts, the first access token, and the second access token. In an embodiment, the user can provide some customer conditions through the user interface to the BC payment mediator service.
In an embodiment, at 361, the BC payment mediator service configures the instructions to apportion funds transferred from the accounts to satisfy a particular installment payment when a current balance of the default account is insufficient. When the current balance of the default account is sufficient to cover the particular installment payment, the instructions are configured to transfer the payment from the default account to an account associated with the provider or the creditor.
In an embodiment, at 362, the BC payment mediator service configures the instructions to maintain up-to-date balance totals for each of the accounts. That is, at any given point in time when an installment payment is requested by a provider, the current balances of the accounts are updated in real time.
In an embodiment, at 363, the BC payment mediator service configures the instructions to transfer funds from the default account to an account associated with the provide or the creditor when a current balance of the default account is sufficient to pay a particular installment payment. This was stated before, it is just when the default account lacks all the necessary funds to cover a payment that the BC payment mediator service calculates an apportionment of funds from each of the accounts to transfer. This is done to ensure that based on user patterns with the account histories that no single user account is overly drained when a given payment is made on behalf of the user.
In an embodiment, at 364, the BC payment mediator service configures the instructions to validate and authenticate the first and second access tokens provided by the provider to the smart contract for a given installment payment. Each access token may include signatures or encrypted values that permit the BC payment mediator service to authenticate the provider and the token itself as being created by the BC payment mediator service and not modified thereafter.
At 370, the BC payment mediator service instantiates the instructions on the BC as a smart contract that is reachable by the provider on the BC via the secure token. The smart contract autonomously manages the installment payments using the conditions, the first access token, and the second access token.
It should be appreciated that where software is described in a particular form (such as a component or module) this is merely to aid understanding and is not intended to limit how software that implements those functions may be architected or structured. For example, modules are illustrated as separate modules, but may be implemented as homogenous code, as individual components, some, but not all of these modules may be combined, or the functions may be implemented in software structured in any other convenient manner.
Furthermore, although the software modules are illustrated as executing on one piece of hardware, the software may be distributed over multiple processors or in any other convenient manner. The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.
