WO2019071263A2

WO2019071263A2 - Method and system for payment processing & syndicated consumer credit

Info

Publication number: WO2019071263A2
Application number: PCT/US2018/054882
Authority: WO
Inventors: Abdullah JAVED; Mohamed NOUH; Muhmmod JAVED; Petter TSE
Original assignee: Variance Group Inc.
Priority date: 2017-10-06
Filing date: 2018-10-08
Publication date: 2019-04-11
Also published as: WO2019071263A3

Abstract

A consumer credit instrument that augments the credit payment pipeline in order to give consumers and issuers more granular control over repayment terms. A system can establish a network with components that homogenize supply and demand for consumer credit by syndicating transactions from all consumers to all issuers on said network. The system can further facilitate the funding of each transaction. The system can leverage a number of issuer and consumer components that allow each party to have dynamic control over the terms such as APR and rewards for transactions.

Description

METHOD AND SYSTEM FOR PAYMENT PROCESSING &

SYNDICATED CONSUMER CREDIT

CROSS-REFERENCE TO RELATED APPLICATION

[1] This application claims the benefit and priority to U.S. Provisional Patent

Application No. 62/569,407, filed October 6, 2017, which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

[2] The disclosed embodiments pertain to the field of consumer, retail and merchant finance, and, in particular, how lenders and borrowers interact with one another during the lending process.

BACKGROUND

[3] In the consumer lending market, consumers/borrowers are individuals who are looking for credit in order to fund the purchases of goods/services. A merchant is any institution that sells goods or services be it in brick-and-mortar or online stores. An issuer/lender is any individual or institution willing to provide capital as credit for others. Interchange, for the purpose of this document, can be considered any fees that are part of the credit payment pipeline.

[4] Consumer finance is an industry classification pertaining to the lending and banking needs of individuals. More specifically consumer lending is a subcategory in which a consumer is looking to fund transactions through a lender. This can either be done through a line of credit (LoC) or a loan. Credit cards are one form of LoCs; they offer revolving credit with spending limits. Loans, on the other hand, typically help consumers fund large transactions by securing the debt against the purchase item. In both cases the consumer is charged an interest rate for the amount borrowed if it is not payed back within one billing cycle with or without grace periods. This interest rate is directly correlated with the risk involved in funding the transaction as well as the risk profile of the borrower. More specifically, consumer card repayment terms are determined by in large via the consumer risk profile, i.e., FICO score, etc. The riskier the consumer, the higher interest rate he/she is charged.

[5] The consumer credit card model primarily revolves around unsecured debt. This means that an issuer has no collateral against the credit that is extended to a borrower. In the event that a borrower defaults on payments, the issuer would have to sue the borrower in order to collect the remaining balance. Since collecting on defaulted, unsecured debt is costly, creditors typically charge higher interest rates for such loans. To avoid risky investments, lenders rely heavily on parameters like credit scores and debt-to-income ratios. Alternatively, there is a category of lending known as secured debt. It holds an asset as collateral until the debt is paid. If the borrower defaults on payments, the issuer has the ability to seize the asset and sell it to recoup losses. Therefore, secured loans often have a smaller interest rate in comparison to unsecured debt and often take the asset into account when determining payment terms.

[6] Consumer lending has not changed much since the Charge Card. This system extends a LoC from lender to borrower based on predefined terms such as interest, payment terms, and credit limit. In the current system both the borrowers and lenders are bound to the initial terms from the application for credit.

[7] In this traditional system, lenders are typically forced to either fulfil a request for credit or reject it in its entirety. For instance, in credit card payment systems across all networks (Visa, MasterCard, etc.), issuing banks are limited to two basic responses: approved or denied. The issuing bank can send back several codes to their network for the reason a transaction is declined, but only one for approval. To be exact, the current payment system begins with the origination of a transaction through a point of sales (PoS) machine or online purchase. The transaction is sent through a merchant acquirer to the proper network, which routes it to a specific issuing bank. The issuing bank responds to the transaction with an authorization code that is sent backwards along the same path. The borrower will then see the transaction "Approved," or "Denied," depending on the code the issuing bank returned. The PoS machine will accumulate these authentication codes for each transaction until it is cleared out by the merchant. At that time, the codes are resolved in batch between the issuing banks and merchant bank (this is when funds are actually transferred from the issuing bank to the merchant bank).

[8] This exchange between merchant acquirer, network, and issuing bank all relies on the existence of an interchange fee. This fee is a percentage of the transaction amount and is split among each of the aforementioned parties. The merchant acquirer and the network take the smallest amount of this split to cover operational costs. The issuing bank takes the largest cut because it is said to be taking on the most risk by underwriting the consumer's debt. Therefore, the merchant is paid the transaction amount minus the interchange fee. For example, if a consumer makes a credit card transaction at a merchant for a $100 with an interchange rate of 2.75%, the merchant will effectively receive only $97.25. The interchange is only lowered through negotiation between merchants and either merchant acquirers or networks. Issuing banks rarely, if ever, negotiate to reduce their percentage of the interchange. This fee is applied to all transactions, regardless of how risky a specific transaction is compared to others. The rate can be dependent on the type of card: different card economics, like rewards cards, can require higher subsidies and subsequently higher fees.

[9] Networks determine interchange rates in a process called interchange qualification. A number of factors go into assessing a specific transaction's interchange fee. Three factors are contingent upon the merchant: processing method, transaction data, and Merchant Category Code (MCC). Processing method refers to how a merchant handles the incoming transaction. It can be handled as a card-present transaction, in which the card is physically present and its data is read electronically (through a POS machine), or it can be handled as a card-not-present transaction, in which cardholder information is entered manually (like through online purchases). Card-not-present transactions are considered less secure and carry a higher interchange of the two. The interchange can also be dependent on the accuracy and completeness of the transaction data supplied by the merchant. Lastly, depending on its MCC code, a merchant can receive a discount on the interchange, although it is very rare.

[10] Three factors for interchange that a merchant cannot control are card type, card brand, card owner. Card type refers to whether the card is a debit card or a credit card. Since debit cards handle the cardholder's existing funds to pay for the transaction, they require little risk and have a lower interchange fee. The card brand refers to the type of rewards that the card offers the cardholder. Cards with reward offerings are typically subject to a higher interchange in current payment systems. Card owners can be either an individual, municipality, or business and each has a different pricing category.

[11] Lenders directly associate a borrower's risk to their credit score. This score is theoretically a consumer's propensity to pay back his/her debt. This credit score is an amalgamation of numerous factors such as income to debt ratio, payment history, length of credit history, etc. Each month the credit score is updated to reflect the changes to these factors in the past billing cycle. Other issuers then pull these reports in order to see any dramatic shifts in a consumer's risk profile.

[12] FIG. 1 can illustrate how current credit card payment processing 100 operates.

Each aspect of the process is labeled alphabetically in the order it occurs (events A through L). It incorporates all major participants that are involved to fund a transaction. The direction of the relationship shows the transfer of either information or products.

[13] At event A in Fig. 1 of the transaction, a cardholder 102 selects goods or services from a merchant 104 and requests to purchase them at check out. If both parties agree on the purchase price, the merchant 104 will proceed to event B. The cardholder 102 essentially affirms consent/agreement by providing the card to the merchant 104.

[14] Event B represents the means in which the merchant 104 aggregates transaction information 108. The transaction information 108 refers to data such as card info, MCC code, and transaction total. Brick-and-mortar merchants normally pull card information electronically through a Point of Sales (POS) machine 106. Online merchants typically request cardholders to input the transaction information 108 manually. After the transaction information 108 is aggregated, it is sent (e.g., event C) to a merchant acquirer 1 10.

[15] Event D represents the merchant acquirer 1 10 passing the transaction information 108 to an interchange network 1 12 (e.g. Visa, MasterCard). A set of APIs can be used in order to communicate the information. If the merchant acquirer 1 10 does not have a relationship with the cardholder's network 1 12 the process is unable to proceed.

[16] Event E denotes the network's transfer of the transaction information 108 to a cardholder's issuing bank 1 14. At this level, the network 1 12 implements fraud protection to make sure the transaction is legitimate. Depending on the level of risk associated with the transaction, it will be flagged for a specific reason. That flag is also sent to the issuer 1 14 along with the transaction information 108.

[17] When the issuer 1 14 makes a decision about funding the transaction it choose the appropriate response from a set of predetermined codes 1 16. This response code 1 16 is sent back to the merchant 104 through the same path. This is denoted by events F, G, H, and I. This response code 1 16 is rendered to the merchant 104 as an approval or denial through the Point of Sales terminal 106. If approved, the merchant 104 then gives the cardholder 102 the goods or services (denoted by event J).

[18] After the transaction is fulfilled, the issuer 1 14 usually bills the cardholder 102 for the amount due (this can be done through a servicing agent). This is denoted by event K. The cardholder 102 then pays the issuer 1 14 for the transaction. This is shown in event L.

[19] The need exists for a system that overcomes the above problems, as well as one that provides additional benefits. Overall, the examples herein of some prior or related systems and any associated limitations are intended to be illustrative and not exclusive. Other limitations of existing or prior systems will become apparent to those of skill in the art upon reading the following Detailed Description

BRIEF DESCRIPTION OF THE DRAWINGS

[20] FIG. 1 illustrates a transaction process.

[21] FIG. 2A illustrates an updated transaction process in accordance with an embodiment of the present technology.

[22] FIG. 2B is a diagram of an example environment for implementing the updated transaction process in accordance with an embodiment of the present technology. [23] FIGS. 3A-3E illustrate example displays on a device in accordance with an embodiment of the present technology.

[24] FIG. 4 illustrates exchange participants associated with the updated transaction process in accordance with an embodiment of the present technology.

[25] FIG. 5 illustrates an issuer interaction in accordance with an embodiment of the present technology.

[26] FIG. 6 illustrates a flow diagram illustrating a method of implementing the updated transaction process in accordance with an embodiment of the present technology.

[27] FIG. 7 is a block diagram of an example of a computing device, which may represent one or more computing devices or servers described herein, in accordance with various embodiments.

DETAILED DESCRIPTION

[28] The technology disclosed herein is related to a system, a method of operation thereof, etc. for facilitating financial transactions that involve at least consumers, networks, and/or issuers. The system described in detail below involves the creation of a consumer financial instrument that contains some or all of the following:

1 . A tool that allows users to effectively choose terms and rewards for each transaction made.

2. A tool that creates protective controls for primary cardholders over any secondary credit card (e.g., a manifestation of an individual's extension of his/her credit utility to another entity) on their account.

3. A marketplace in which consumers can trade reward points directly with issuers.

[29] The technology disclosed herein further relates to creation of a network that contains some or all of the following:

1 . A component that syndicates a transaction at the time of origination to multiple issuers, allowing each the chance to fulfill it through a mechanism (e.g., a reverse auction mechanism, a traditional auction mechanism, a matching mechanism, etc.).

2. A component that mediates the funding of a transaction by aggregating partial fills of a single transaction from any number of issuers in order to completely fund a transaction.

3. A component that creates a real-time risk model for determining credit worthiness by synchronizing information such as credit balance, defaults, and transaction details across all issuers on a network.

4. A component that creates a multifactor authentication method to turn card-not-present transactions into card-present transactions.

5. A component that allows merchants to secure a syndicated loan by leveraging future accounts receivables through the network for repayment.

6. A component that issues titles for certain products that can be used to secure credit.

[30] The technology disclosed herein further relates to creation of a credit lending instrument that contains some or all of the following:

1 . A tool that allows spot underwriting in which issuers can choose payment terms per transaction and underwrite it in real time.

2. A component that allows lenders to approve the partial fill of a transaction.

3. A tool that allows lenders to create "campaigns," in which the lender can set limits for transactional funding of credit requests based off specified criteria (e.g. consumer financial profile, transaction information).

[31] Various examples of the invention will now be described. The following description provides certain specific details for a thorough understanding and enabling description of these examples. One skilled in the relevant technology will understand, however, that the invention may be practiced without many of these details. Likewise, one skilled in the relevant technology will also understand that the invention may include many other obvious features not described in detail herein. Additionally, some well-known structures or functions may not be shown or described in detail below, to avoid unnecessarily obscuring the relevant descriptions of the various examples.

[32] The terminology used herein is to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the invention. Indeed, certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

System/Transaction Overview

[33] FIG. 2A illustrates an updated transaction process 200 in accordance with an embodiment of the present technology. Similar to the process 100 of FIG. 1 , the updated transaction process 200 can involve a member borrower 202 (e.g., a cardholder or a service participant), a merchant 204 (with or without a Point of Sale machine 206), a merchant acquirer 210 (e.g., a financial service provider or a bank for the merchant 204), etc. Unlike the process 100, the updated transaction process 200 can include a dynamic interchange network 220 that operably connects a set of lenders 214 (e.g., lenders 214a-214n, such as credit card/LoC 214 issuers) to the merchant acquirer 210 and/or the member borrower 202.

[34] The updated transaction process 200 can rely on three distinct layers of processing in order to effectively augment the payment transaction (e.g., for credit, debit, ACH, or any other form of payment process). The first level of input can come (e.g., through a cardholder application or Application Programming Interface (API)) from the consumers (e.g., the member borrower 202) who are individuals looking for credit to fund transactions. Some of the embodiments can provide a number of components (e.g., the application/API, a service provider or a server, etc.) that allow consumers to control their credit/transaction preferences 222 (e.g., factors that affect the relationship between issuer and borrower, such as interest rate, reward type, cash back, and repayment terms). The second augmented layer can be at the network level (e.g., the dynamic interchange network 220). It can contain a number of purposed components that handle the processing of payments. The last layer of input can come (e.g., through a lender application or API) from the lender (e.g., one or more of the lenders 214), which is an institution that offers to loan money to consumers. Some of the embodiments provide a number of components that allow the lenders 214 to respond to incoming transaction requests from the member borrower 202.

[35] The dynamic interchange network 220 can allow consumers (e.g., the member borrower 202) and the lenders 214 to have granular control over credit transactions in the payment process. For instance, consumers can set preferences for repayment and rewards (e.g., one or more transaction preferences 222) before making a purchase. Similarly, lenders can respond to requests for credit for the purposes of dynamic/spot underwriting (point in time). The dynamic interchange network 220 can act as a mediator or a market place between the lenders 214 and borrowers/consumers to best match their preferences and fund transactions.

[36] As such, events A', B', C, and D' can be similar to the events A, B, C, and D of

FIG. 1 . When transaction information 208 (e.g., acquired at the POS machine 206 and/or by the merchant 204) gets to the dynamic interchange network 220, the dynamic interchange network 220 can check the transaction information 208 for inherent risk and flags fraudulent transactions. The transaction information 208 can then be updated with the cardholder's specific rewards preferences (e.g., the consumer input corresponding to the first augmented level) and syndicated across all lenders 214 in the dynamic interchange network 220. This syndication process is depicted through event E'.

[37] Through the dynamic interchange network 220, each of the lenders 214 can have the opportunity to respond to the transaction with their purposed repayment terms (e.g., repayment terms 224a-224n, respectively corresponding to the lenders 214a-214n). For example, the issuers who are willing to fund the transaction can respond with repayment terms that include the maximum amount they are willing to fund, APR, and/or reward offerings. Upon receiving these responses, the dynamic interchange network 220 can aggregate the repayment terms 224 to fund the transaction. The issuer(s) who was/were matched to fund the transaction can be notified. This process is denoted as process/event F'.

[38] After aggregating the responses (e.g., the repayment terms 224) from the lenders 214, the dynamic interchange network 220 can find one or more response codes 216 that best fits the scenario present (e.g., the received repayment terms 224 and/or the transaction preferences 222). The response code 216 can be sent back to the merchant 204, similar to FIG. 1 . Therefore, processes/events G', Η', Γ, and J' can be similar to processes G, H, I, and J. The overall process of receiving the transaction information, underwriting the loan/credit line, and funding the transaction based on the transaction- specific credit/LoC can be performed in real-time (e.g., within one or more seconds or less) based on the various components described below. As such, a consumer can rely on the embodiments below for purchases similar to credit card transactions, such as at brick-and- mortar stores or online, without experiencing any additional processing delays.

[39] Due to the nature of this dynamic interchange network 220, billing can be more complicated than the process 100. If left on their own, multiple issuers would have to contact one individual for repayment. Furthermore, billing statements may be highly segmented; cardholders would not have a static interest rate while multiple issuers have the ability to fund a single transaction. As a result, the dynamic interchange network 220 can implement a billing strategy that is connected between the issuers and the consumers. Billing and repayment can occur in a consolidated manner through the network in processes/events K' and L' respectively, which includes the billing and repayment process.

[40] The embodiments discussed herein can be in contrast to the existing consumer lending system, where lenders are stuck with the initial terms from the application for credit. For the existing systems and the process 100, as illustrated in FIG. 1 , if either of the parties changes these terms, it can take until the next billing cycle for the new terms to be underwritten and implemented. This does not allow flexibility for either party. For instance, borrowers (e.g., the cardholder 102 of FIG. 1 ) cannot increase their credit limit immediately if they face an unexpected increase in expenditures for a billing cycle. Unlike the lenders (the issuer 1 14 of FIG. 1 ) who can simply underwrite whatever new terms they desire, borrowers are often required to first contact their lender, then negotiate their desired terms, and then wait for them to be underwritten. This process has become so unrewarding for borrowers that it has become the norm for them to look for new lines of credit (LoC) instead of trying to refinance. Therefore, terms for lending on LoCs can be considered static. Unlike the process 100, the embodiments discussed herein can allow one or more of the parties to dynamically adjust terms in real-time, allowing flexibility for consumers. [41] Similarly for the existing systems, lenders cannot change interest rates for an increasingly risky consumer in real time. The system for assessing and reacting to risk profiles has significant delays. Specifically, it can take up to 90 days (three billing cycles) or more for an issuer to react to a substantial increase in the risk of a consumer: one month for the credit score to show a consumer taking on a significant new debt, one month to update the credit score to show a default, another month for the issuer to change their terms in response. Issuers cannot respond to how their consumers are interacting with other lenders any quicker. This example also shows that risk can change dramatically before issuers can properly react to them. Unlike the existing systems, the embodiments discussed herein can leverage the mechanics of syndicated purchases and/or blockchain to implement a system for real-time credit-worthiness. The embodiments can consolidate the borrowers and the lenders, and further propagate payment and/or purchase status/activities to all lenders in a network. Accordingly, the embodiments can provide a real-time risk management system for lenders that can supplement or replace any existing credit scoring/reporting systems. Further, the embodiments can dynamically adjust terms in real-time for lenders as well, reducing potential damages or issues associated with increases in consumer risk levels.

[42] FIG. 2B is a diagram of an example environment 250 for implementing the updated transaction process 200 of FIG. 2A in accordance with an embodiment of the present technology. The environment 250 can include one or more consumer devices 252, one or more merchant devices 254, one or more acquirer devices 260, one or more lender devices 264, etc. that are communicably coupled to each other. The devices can be communicably coupled to each other through direct contact (e.g., swiping or inserting a smart card or a key device), dedicated connections (e.g., closed circuit connections), and/or a communication network 270.

[43] The consumer devices 252 can include electronic devices, such as computers, mobile/smart phones, wearable devices, smart cards or keys, etc., belonging to or operated by the consumers (e.g., the member borrower 202 of FIG. 2A). The consumer devices 252 can include a consumer application 253 (e.g., software application) configured to interact with the consumers for the financial transactions according to the updated transaction process 200. For example, the consumer devices 252 and/or the consumer application 253 can be configured to receive the transaction preferences 222 of FIG. 2A and/or display the received repayment terms 224 of FIG. 2A, display the billing information (e.g., amount due), display account status (e.g., acquired benefits), etc.

[44] The merchant devices 254 can include electronic devices, such as servers, computing devices, the POS machine 206 of FIG. 2A, etc., belonging to, located at, and/or operated by sellers or service providers (e.g., the merchant 204). The merchant devices 254 can be associated with the acquirer devices 260 (e.g., servers, computing devices, etc.) belonging to, located at, and/or operated by their corresponding merchant acquirer 210 of FIG. 2A. Similarly, the lender devices 264 can include electronic devices, such as servers, computing devices, etc., belonging to, located at, and/or operated by the lenders (e.g., the lenders 214 of FIG. 2A). The lender devices 264 can include lender applications 265 configured to interact with the lending institutions for the financial transactions according to the updated transaction process 200. For example, the lender devices 264 and/or the lender applications 265 can be configured to present information regarding the member borrower 202 and/or the transaction information 208, such as the transaction preferences 222, the user's credit information, etc. Also for example, the lender devices 264 and/or the lender applications 265 can be configured to calculate (e.g., according to institutions' guidelines or settings) and/or obtain the repayment terms 224 of FIG. 2A.

[45] The communication network 270 can include wired or wireless networks that allow the connected devices to exchange data with each other. The communication network 270 can include different types of networks, network devices, protocols, etc. For example, the communication network 270 can include Local Area Network (LAN), Wide Area Network (WAN), the Internet, telephone network, cellular network, wireless fidelity (WiFi) networks, fiber optic networks, etc. Also for example, the communication network 270 can include circuits/devices (e.g., communication modules or chips, gateways, routers, repeaters, transmitters/receivers, etc.) for implementing Near-Field Communication (NFC), Bluetooth communication, Infrared (IR) communication, cellular communication standards (e.g., 4G, LTE, 5G, etc.), WiFi standards, etc.

[46] The communication network 270 can further be connected to an interchange device 280 configured to implement the augmented features for the payment transactions. For example, the interchange device 280 can include electronic devices (e.g., servers, computing devices, etc.) configured to implement the dynamic interchange network 220. From the perspective of the consumer devices 252, the merchant devices 254, the acquirer devices 260, the lender devices 264, etc., the dynamic interchange network 220 can seem integral with the communication network 270. The interchange device 280 can include devices belonging to or operated by a financial service provider (not shown).

Consumer Components

[47] FIGS. 3A-3E illustrate example displays (e.g., GUIs) on a device (e.g., the consumer devices 252 of FIG. 2B) in accordance with an embodiment of the present technology. The various example displays can illustrate features and/or components of the updated transaction process 200 of FIG. 2A that are associated with the consumer.

[48] Through the consumer applications 253 of FIG. 2B, the member borrower 202 of FIG. 2A (e.g., a consumer) can apply for this service just as he/she would for a credit card. At certain time(s) (e.g., at sign-up and/or regular intervals, for each purchase or for purchases exceeding a threshold limit, etc.), the member borrower 202 can provide their personal (e.g., login or membership information, government-issued identification, etc.) and financial information (e.g., bank accounts, credit card accounts, reward programs, etc.) through an application process/portal (e.g., using a paper-application, a web-based portal, the consumer applications 253, etc.). The provided information can go through a number of verification processes in order to validate it. The borrower's credit score can also be pulled from any of the credit reporting agencies. Once approved, the new user can be issued an overall account including a unique identification code, a financial profile, a physical credit card, access to the discussed system (e.g., the consumer applications 253, the lender applications 265 of FIG. 2B, the interchange device 280 of FIG. 2B, etc.)/method, etc.

[49] Access to the consumer component can be through an application of any nature, be it mobile, web, or anything therein (e.g., the consumer applications 253). The application allows the member borrower 202 to leverage the system described herein and control their credit preferences for any upcoming purchases. These preferences can be set and changed as often as the borrower would like. Therefore, a borrower's terms can effectively change for each transaction. The consumer applications 253can capture and communicate the change in the borrower's credit preferences, which can be applied to any subsequent transactions. This can be done without negotiating with issuers or waiting for following billing cycles to implement. The consumer applications 253can control the card/account via an apparatus as one would a television set with a remote control. The actions that a consumer can take to dictate his/her terms can be described as the "mobile wallet".

[50] In some embodiments, the member can initially identify the transaction preferences 222 of FIG. 2A at service signup and/or update the preferences through any web-based portal, the consumer applications 253, etc. FIGS. 3A-3B illustrate the transaction preferences 222 and associated processing results in accordance with an embodiment of the present technology. The consumer applications 253 of FIG. 2B can be configured to decide upon their desired payment terms per transaction. For example, the consumer applications 253 can implement the example GUIs illustrated in FIGS. 3A-3B to receive a target interest rate 302, a target monetary incentive 304, a target reward program 306, etc. The target interest rate 302 can represent a maximum limit or a range of the interest rates that the member borrower 202 of FIG. 2A is willing or would like to accept for the member's transactions/purchases. The target monetary incentive 304 can represent a desired cashback amount/rate for the member's transactions/purchases. The target reward program 306 can represent the member's selection of other non-monetary reward programs (e.g., airline mileage programs, hotel benefit programs, store-specific reward programs, etc.) that the member wants the transactions/purchases to apply to.

[51] The consumer applications 253 can be configured to authenticate (e.g., through username, password/pattern, biometric recognition, such as facial/voice/fingerprint/iris recognition, device recognition, third-party authentication, etc.) the member borrower 202. Based on the authentication and the data collection, the consumer applications 253 can combine and/or use the target interest rate 302, the target monetary incentive 304, the target reward program 306, etc. as the transaction preferences 222 of the member.

[52] As an illustrative example, the member can choose a preference that sets a maximum limit for APR (e.g., the target interest rate 302) at 15%. By setting that preference, the member can effectively state that he/she is unwilling to accept funding for transactions with an APR higher than the maximum limit. In this scenario, if a lender is willing to underwrite the borrower's transaction at 14% APR (which is under the borrower's ceiling of 15%), then the two parties are matched and the negotiation will resolve in the fulfillment of the transaction. If no lenders on the network are willing to underwrite the borrower's transactions at less than 15% APR, then the transaction fails to resolve the negotiation and the system can implement backstops. As such, negotiation can occur at the time of transaction: lenders and borrowers can be matched when both parties agree on the terms (through an automated process) as described below.

[53] Borrowers can choose preferences such as the maximum interest rate (e.g., the target interest rate 302) and the reward points (e.g., the target monetary incentive 304 and/or the target reward program 306) they expect from their purchases. This information can be linked, preferably, to a credit card (e.g., a virtual/purchase-specific credit card account) since the payment architecture already exists and is ubiquitous. This credit card can have one major distinction in its payment processing: the issuing bank's approval of a transaction is checked against the consumer's preferences. If both the issuer and the borrower can agree on the terms, the transaction can fulfilled. For example, a borrower can set his/her preference for interest to be no more than 10% for any of his/her following transactions. If the issuer is willing to fund and underwrite the transaction such that the interest rate is less than or equal to 10%, the transaction is completed.

[54] In some embodiments, the system can create a consumer profile (e.g., a collection of information pertinent to the credit worthiness of the borrower, such as credit history, debt, employment history, etc.) when a borrower signs up for a card and/or at certain intervals (e.g., monthly/quarterly/yearly, for each purchase, for purchases exceeding a predetermined price, etc.). The system can use the profile to generate the bounds on their available credit terms. Bounds can either be "soft" or "hard." A soft bound can be seen as a suggestion, where a borrower is given the information on an optimal range for their terms, but are not forced to stay within them. A hard bound is a limiting factor on a borrower, forcing them to stay within a specified range of terms. The borrower's credit profile could be flashed across all lender on the network to gain information on what terms they are willing to offer that borrower. This, coupled with the ability to perform an automated reverse lookup on a lender's underwriting preferences, makes it possible to gain a comprehensive understanding of a borrower's availability for credit on the network.

[55] These bounds can be created through a completely automated process. For example, the bounds can be calculated (e.g., using the matching system/component) based on analyzing preexisting data for the borrower and/or the lenders (e.g., based on estimating the probability for lenders to extend credit to a specific borrower's credit profile under specific terms).

[56] In some embodiments, the calculation results can be communicated to the borrower and/or used to limit the borrower from setting the preferences. For example, the service provider system (e.g., the interchange device 280, the consumer applications 253, the lender applications, 265, etc.) can calculate a confidence estimate 312 and/or a purchasing power estimate 314. The confidence estimate 312 can include an estimated likelihood that the user-specified terms (e.g., the target interest rate 302, the target monetary incentive 304, the target reward program 306, etc.) will be funded or accepted by a financial institution. The purchasing power estimate 314 can include an estimated amount that a financial institution will likely fund the borrower according to the user-specified terms. In calculating the confidence estimate 312 and/or the purchasing power estimate 314, the service provider can access the member borrower's credit rating, current outstanding balances, earning capacity, and/or other financial activities/history (e.g., recent purchases, prior credit events, previous payment history, etc.). The service provider can further access underwriting guidelines, prior funding/approval histories, etc. of the lenders in calculating the confidence estimate 312 and/or the purchasing power estimate 314. The system can include a software process/routine/module, an equation, a model, an artificial intelligence, etc. configured to calculate the confidence estimate 312 and/or the purchasing power estimate 314 based on at least one or more of the parameters listed above (e.g., the user-specified terms, the member's financial information, the lenders' information, etc.). In some embodiments, the system can calculate and communicate the confidence estimate 312 and/or the purchasing power estimate 314 in near real-time as the member adjusts/enters the transaction preferences 222. [57] In some embodiments, the consumer applications 253 can be configured to provide options for making a purchase. FIG. 3C illustrates a funding option set 330 (e.g., multiple options in paying for a purchase) in accordance with an embodiment of the present technology. For example, the GUI can provide the funding option set 330 including one or more financing options (e.g., a virtual account mechanism 332, a service-provider mechanism 334, etc.) and/or one or more payment infrastructure options 336 (e.g., an NFC payment protocol, a barcode or a quick response (QR) code based protocol, etc.). Through the consumer applications 253, the service provider can allow the member to use the service-provider mechanism 334 to utilize point-to-point (P2P) payments and/or paying merchants integrated with the service provider, such as by generating a transaction linked QR code/barcode at the integrated merchant that the user can scan and pay via the consumer applications 253. Similarly, the member can choose to utilize NFC at the POS machine 206 of FIG. 2A, a QR code or a barcode, etc. through the payment infrastructure options 336.

[58] Regarding the virtual account mechanism 332, FIG. 3D illustrates details of a virtual account 340 in accordance with an embodiment of the of the present technology. The virtual account mechanism 332 can allow the member to utilize the virtual account 340 (e.g., an account associated with one or more purchases and/or funding options for the member) to request a virtual account number (VAN) 342 (e.g., a unique identifier for the one or more purchases and/or the funding options) for card-not-present transactions. The virtual account 340 can include a permanence setting 344 that the user can select to make the VAN 342 applicable to one-time use or for recurring purchases/payments.

[59] In some embodiments, the service provider and/or the member can use the VAN

342 to whitelist and/or blacklist merchants and/or categories while assigning a spending limit to them. For a given member, each VAN 342 can be stored and tracked separately (e.g., via tracing an outstanding balance 346) and tied back to the user's overall account (e.g., instead of a particular credit card number). For example, a member can set up a recurring payment account (e.g., via payment settings 348) for online media streaming at specified merchants and/or set a credit limit of $X/month. Accordingly, the user can manage and limit the exposure of the VAN 342. [60] The virtual account 340 can further span functionality that allows authorized users to access a service-provider's card. For example, using "parental" or administrative (e.g., corporate accounts with specific usage purposes/limitations) features for the primary cardholder, a parent member or an administrative member can set up the virtual account 340 as a secondary card or to their children or authorized users. Through the virtual account 340 and the consumer application, the parents/administrators can have effectively real-time alerts on the activity on the secondary card. Further, the parent/administrative member can set restrictions on the secondary card, such as control over white/black list, spending limits (e.g., over a predefined time interval, such as daily, weekly, and/or monthly limits), usage time periods (e.g., during school hours, until 9:00 pm, etc.), usage locations (e.g., specific geolocations, such as zip codes or user-specified locations), etc.

[61] In some embodiments, the consumer applications 253 can confirm a purchase for the member borrower 202. FIG. 3E illustrates a display for an example purchase confirmation 350 in accordance with an embodiment of the present technology. The purchase confirmation 350 can be configured to notify the member of the accepted/proposed financing terms, purchase details, etc. For example, the purchase confirmation 350 can include an approval status 352 that indicates whether the financing terms are in a proposal state (e.g., from the lender), have been agreed by both parties (i.e., the borrower and the lender) and/or approved by the lender, etc. Also for example, the purchase confirmation 350 can include a transaction summary 354 that indicates a total transaction amount, purchased goods or services, financing terms (e.g., interest rate, cash-back amount, gained rewards, etc.), etc. Also for example, the purchase confirmation 350 can include a confirmation input 356 (e.g., an electronic signature, a biomarker, a Ul interaction, etc.) can be from the member that represents an agreement or an acknowledgement to the purchasing/lending terms. The confirmation input 356 (e.g., biomarkers) can be used by the service provider to further authenticate that the member is actually the person making/authorizing the purchase and accepting the lending terms.

[62] Also as an illustrative example, if a borrower cannot be matched to a lender because of mismatching terms, then the transaction can be declined at the point of sale. To make the sale of goods seamless despite a failed transaction, there can be two additional processes that are introduced as contingencies. The first process can include notifying (e.g., through the purchase confirmation 350 and/or the approval status 352) the borrower of the failure to match his/her preferences to a lender. If there are lenders who extended credit offers, but at different terms, the borrower can be prompted, through a notification (not shown), to select one of those alternative offers 358. If the borrower accepts one of the alternative offers 358, the transaction can be funded.

[63] The second process to avoid a decline at the point of sale can include the introduction of a "backstop." A backstop can be available credit at predefined terms, much like a LoC. If the member borrower 202 cannot be matched to lenders given their preferences, the transaction will fall back to this predefined pool. This can be done in one of two ways: 1 ) the interchange device 280 handles the creation of a backstop credit facility, or 2) the member borrower 202 links an account(s) (e.g., through a GUI) to use as a backstop (e.g. credit card, debit card, ACH account). If the system cannot match the borrower to a lender, the system can complete the transaction using the backstop. While there were no incentives or available methods for one lending company to forward/receive any transactions to/from a competitor, one or more of the discussed embodiments can provide a service or an additional layer (e.g., an open market place), where the borrower has control in linking accounts or facilities across multiple categories, lenders, and/or systems. As such, the member borrower 202 can use the system to implement or utilize the "backstop" across different lenders (e.g., using a designated Visa card from a specific bank when the borrower cannot be matched to lenders given their preferences).

[64] Yet another consumer component can include an exchange for borrowers to trade reward points with issuers. Instead of handling the trade of reward points directly, some embodiments can utilize an auction method for the exchange. The member borrower 202 can issue a request looking to trade certain reward points for another through the consumer applications 253. Reward point issuers can respond to these requests by offering to trade a certain number of the desired points with the borrower. Upon approval, the points can be exchanged between the two parties: the issuer can take control of the points the borrower wanted to exchange, while the borrower can now obtain new points. In doing so, the method and/or the corresponding system can create fluidity of reward points. For instance, the exchange can help a borrower who no longer needs points from a certain airline and would instead prefer points from another airline. Instead of letting those points go to waste, the member borrower 202 can exchange them directly into something useful. The discussed embodiments can be separate from a rewards partner. Instead, the system can allow an entity (e.g., a consumer with access to rewards points) to trade directly with others, such as to other consumers/borrowers, or to unrelated entities (e.g., selling airline miles to gain points at a grocery chain, selling hotel miles to purchase fuel, etc.).

Network Component

[65] FIG. 4 illustrates exchange participants associated with the updated transaction process in accordance with an embodiment of the present technology. For example, FIG. 4 illustrates an example flow or interaction sequence 400 between devices, systems, services, etc. in implementing the updated transaction process 200 of FIG. 2A.

[66] After the member borrower 202 creates the overall account, the sequence 400 can begin when he/she uses the service for a financial transaction, such as for an online purchase or by accessing the POS machine 106. The POS machine 106 or the online portal can gather and transmit the transaction information 208 of FIG. 2A, such as the purchasing price, the paying account number, purchase details, etc. The transaction information 208 can be routed to the dynamic interchange network 220 (e.g., the interchange device 280 of FIG. 2B) through the merchant acquirer 210 of FIG. 2 and/or a gateway 402 (e.g., a computing device configured to connect one network to another) associated with the merchant 204 of FIG. 2A and/or the merchant acquirer 210. The gateway 402 can be configured to wait for a response from the dynamic interchange network 220.

[67] The interchange device 280 can be configured to identify that the transaction is on behalf of an issuer on the service platform (e.g., a potential lender that is part of the dynamic interchange network 220). Additionally, the interchange device 280 can be configured to implement supply-side campaigns 404. Campaigns can include limits, conditions, preferences, or guidelines for transactional funding of credit requests based on specified criteria (e.g. consumer financial profile, transaction information, etc.) set by one or more parties (e.g., each of the lenders 214 of FIG. 2A). The supply-side campaigns 404 can include campaigns (e.g., as specified by the merchants) that identify buyers (e.g., the lenders 214 that can fund the transaction) that can receive the transaction. In some embodiments, the supply-side campaigns 404 can include preliminary conditions or limitations identified by the lenders. The supply-side campaigns 404 can allow the issuer to control whether the transaction shown to a dynamic bidding engine (DBE) 420, or if it is to be sent to other lenders.

[68] The interchange device 280 can include or be connected to an issuer router 408 configured to transmit to one or more qualifying lenders a bid request 410 associated with the transaction. For a given transaction, the interchange device 280 and/or the issuer router 408 can filter the lenders 214 based on comparing the supply-side campaigns 404 with the transaction information 208, the member's financial information (e.g., outstanding balance, credit rating, purchase history, etc.), the transaction preferences 222 of FIG. 2 of the member, etc. The issuer router 408 can forward the bid request 410 (e.g., a message or a request asking a lender for repayment terms for a given transaction) to the matching/qualifying lenders. The bit request 410 can include one or more of the transaction information 208, the member's financial information, the transaction preferences 222, etc.

[69] Accordingly, the network component (e.g., the dynamic interchange network

220, the interchange device 280 therein, other network devices therein, etc.) can include or implement a method to syndicate requests for consumer payments to multiple issuers. This network can establish a system in which all associated issuers are able to fund all associated borrowers. As a credit transaction is sent through the network to any number of issuers (e.g., issuers whose campaigns match the given transaction), each issuer can receive the transaction request and respond to it by either approving or denying it.

[70] The network component can include one or more portions of the lender applications 265 of FIG. 2B. For example, the network component can include the DBE 420 (e.g., a software platform/solution) on the lender's side that is configured to allow the lenders 214 to bid to fund the transaction in effectively real-time. The DBE 420 can facilitate bidding on behalf of buyers/lenders on inventory they seek to purchase (e.g., by funding the transactions). Accordingly, the DBE 420 can be configured to analyze the bid request 410 for the lender. In some embodiments, the DBE 420 can include an identity service component 422, a fraud service component 424, a risk service component 426, a lender- side campaign component 428, a budget service component 430, a pricing engine 432, etc. Based on the analysis, the DBE 420 can return a bid response 434 (e.g., acceptance, denial, associated repayment terms 224 of FIG. 2A, alternative terms, etc.). Details regarding the lender-side features are described below.

[71] The network can sort the bid responses 434 to find issuers to fill the transactions.

Once issuers are selected, a response (e.g., the repayment terms 224) can be sent to the merchant acquirer 210 as well as to the lenders 214 who were selected to fund the transaction.

[72] Some embodiments can include a further component that allows issuers to partially fund transactions. This further component (i.e., a portion of the interchange device 280) can be configured to implement a protocol in which the lenders 214 can send more information than predefined alphanumeric response codes. For example, the interchange device 280 can be configured to prompt for additional information and/or receive an overloaded field or an additional field in the communication data structure. Correspondingly, the DBE 420 can include one or more components configured to consider partial payments, generate and send corresponding messages, etc. The embodiments can allow the lenders 214 to respond with basic codes as well as with dynamic information such as the amount they wish to fund, APR, and rewards offerings. Accordingly, the lenders 214 can dynamically respond to a borrower's transactions. For instance, just because a borrower requests $100 in credit does not mean the issuer needs to approve that amount. Partial funding of transactions based on the protocol allowing exchange of dynamic information provides usefulness, such as in the event that a specific transaction is particularly risky. This deviates from the traditional structure of credit, where a LoC is extended and all purchases up to that amount are funded completely (with exceptions of fraud and situations of similar nature).

[73] For illustrative example, lenders of a credit card are often limited to respond to transactions by choosing a response code from a predefined, limited list in existing systems (e.g., as illustrated in FIG. 1 ). For instance, the code "00" on the Visa network signifies that the credit card transaction was successfully approved and completed, while the code "Q1" signifies that the card authentication failed. The closest thing lenders have to a real-time system for spot underwriting (with dynamic credit terms) on the Visa network may be code "02" which tells merchants to "refer to card issuer, special condition." In general, these codes indicate some form of accepting or declining a transaction at the point of sale. This makes responding to transactions extremely limited and overall susceptible to inefficiencies.

[74] For one or more of the embodiments described herein, the lender can manage their preference (e.g., lender-side campaigns) on what types of transactions to target and how to respond with terms. As described in detail below, the system (e.g., one or more components of the DBE 420, the lender applications 265, etc.) can allow lenders to then tailor responses to incoming credit requests based on those preferences. Instead of relying on predefined codes, lenders can send a payload of information (e.g., the bid response 434, the repayment terms 224, etc.) that contains all attributes necessary to underwrite a transaction and match their offer to a borrower's request. The data format can be associated with the field of the attribute (e.g. APR might only accept possible values from 0.000% to 30.000%). The lender can set these preferences through a web application or through an API.

[75] Some embodiments can further include a subsystem for the interchange device

280 that aggregates partial fills in order to fulfill a transaction. It relies on the premise that transactions are syndicated to multiple issuers that can fund up to the transaction amount. For example, a transaction with predetermined payments can be processed based on matching issuers such that the sum of amounts each issuer approved is equal to or greater than the transaction amount. If the sum happens to be greater than the transaction amount, issuers can be expected to honor up to the amount they authorized for the transaction. The amount in excess can be split among each issuer and subtracted from their issued credit.

[76] As an illustrative example, each transaction can include information (e.g., the transaction information 208, the bid request 410, etc.) such as the credit worthiness of the borrower, the transaction amount, and various other information to help lenders make a well- informed decision on underwriting. The lenders 214 can respond to transactions by sending a dynamic payload of information. One "attribute" contained in this payload can be the amount of credit the lender is willing to extend for the transaction. For example, the lenders can respond to an incoming $10 transaction with an offer to fund only $5 of it. This is known as a "partial fill" within in this embodiment. Partial fills can allow lenders to better manage their exposure to risk where lenders and borrowers may agree to terms for credit.

[77] To remedy this issue, the interchange device 280 can be configured to implement an automated process to stitch together partial fills to collectively fund a transaction. For the above example, this means that two issuers can fund a $10 transaction by underwriting $5 each. Since each issuer can respond to a transaction with numerous other credit terms, the interchange device 280 can stitch partial fills (e.g., for different APRs and/or cashback options across the partial fills) and aggregate the terms of the transaction (e.g., the different APRs and/or cashback amounts), and further check whether the combined terms still satisfy the borrower's set threshold. This principle/process can also carry over to other attributes such as cashback. Accordingly, the interchange device 280 can store and track (e.g., for billing) the different pieces that make up the entire transaction. In some embodiments, the interchange device 280 and the overall network can track the information for each of the transactions including the involved parties (e.g. the members, the merchants, and/or the lenders) and terms using blockchains. For example, the interchange device 280 and/or additional computing devices in the network can utilize a credit chain system to track the various parties and/or the transactional terms/information.

[78] Some embodiments can further include a new consumer financial instrument for aggregation of partial fills. For example, the interchange device 280 can be configured to deal with transactions that have dynamic payment terms. As a consumer instrument, this process can focus on aggregating partial fills from multiple issuers so that the payment terms are most favorable for the consumer. The interchange device 280 can be configured to prioritize payment terms over any other variable. For instance, the interchange device 280 can optimize for the lowest possible interest rate to fund a transaction. Therefore, when aggregating responses from issuers, fulfillments with the lowest interest rates would be selected first. Similarly, if a borrower found rewards to be most important (e.g., through the transaction preferences 222) when fulfilling transactions, issuers who could provide those points would be selected before all others. Some embodiments can allow borrowers to have multiple preferences for payment terms while still resolving issues of priority in aggregating issuer responses. [79] The aggregation component of the interchange device 280 can also manage transactions in which both borrowers and issuers can choose preferences for terms. Many payment terms are simple to match since they are binary (either an issuer is offering certain reward points or is not). However, with interest rates and partial fills, fulfillment could occur in a number of ways. Furthermore, with the introduction of partial fills, a single transaction can be funded by multiple issuers, each with its own interest rate. The interchange device 280 can be configured to calculate an overall interest rate for the member and track the individual portions for the lenders, such as for the billing component. As an illustrative example, the interest rate can be defined as the weighted average of all interest rates weighed against the amounts used to fund the transaction. This can be shown by looking at a simple $15 transaction that is funded by 3 issuers: $3 at 10% interest, $10 at 17%, and $2 at 12% interest. Each interest rate would be multiplied by the dollar amount it contributed to the transaction and added up. This sum would then be divided by transaction amount. Therefore, in this case the weighted interest rate can be about 14.9%.

[80] Another network component (e.g., the merchant-side functions/applications, the interchange device 280, etc.) can include a merchant-oriented tool that helps reduce interchange fees. Aside from operation costs, a sizeable amount of the interchange fee can stem from the risk associated in funding transactions. For example, the interchange device 280 can be configured to target and reduce the risk networks face when funding transactions. For example, the interchange device 280 can include a component that is configured to implement a multifactor authentication method to turn card-not-present transactions into card-present transactions, thereby consequently eliminating their associated fees. At the time a card-not-present transaction is processed (e.g., an internet- based purchase), a notification can be sent to the cardholder (e.g., to the device or address identified in the profile associated with the card, a device separate from the one used to enter the card or purchase information, or a combination thereof). In response to the notification, the cardholder can authenticate his/her identity, through biometrics (e.g. fingerprint authentication) or secure pin using a device (e.g., a merchant device or a cardholder's mobile device), and verify the purchase. Until the transaction is verified it can be processed as it traditionally is (card-not-present). Upon a valid or authenticating response from the cardholder, the transaction can be changed to card-present (e.g., a requirement for user's physical presence can be replaced by an added layer of multifactor authentication). Accordingly, the dynamic interchange network 220 improves the transaction security by making it difficult to steal cardholder information and purchase things online, thereby allowing the interchange fee to be lower than usual.

[81] In some embodiments, the dynamic interchange network 220 can include a component (e.g., a portion of the interchange device 280) configured for syndicated loans for organizations like merchants. This component can leverage the predictable cash flow of merchants to secure debt. Specifically, this component can target the future sales of a merchant that may be routed through this network. The interchange device 280 can divert a portion of incoming transactions from a merchant to directly paying back the loan. For example, one of every 100 sales a merchant sees within the network can be used to pay off the loan by diverting the payment to the issuers of the syndicated loan instead of the merchant bank.

[82] In some embodiments, the dynamic interchange network 220 can include a component (e.g., a portion of the interchange device 280) configured to implement a title issuing service for purchased products. This component can offer an opt-in service that provides seamless title issuance for specific, durable products. The component can be configured to allow borrowers and lenders to secure loans with the title. Accordingly, the interchange device 280 can transfer ownership for that product if the borrower defaults on his/her debt. This component can also take the date and price of the product into account when issuing a title. That would make this system conducive to issuing insurance on said product as well.

[83] As an illustrative example, for blockchain, a transaction can have a trail that can be used to track a purchase. One or more of the embodiments described herein can contain item information in the transaction payload. The merchants can be integrated and send an item's identification (e.g., the transaction information 208 utilizing SKU, UPC, or any other standard for identifying an item) through the POS terminal along with the other transaction information. Either the merchant or the member borrower 202 can provide a serial number for the item to uniquely distinguish it from other items like it. The dynamic interchange network 220 (e.g., the interchange device 280 therein) can create a smart contract of the item on the blockchain. The contract's owner can be the person who purchased the item. If the item was purchased on credit, the item can be considered a Repo. If the borrower fails to meet repayment terms, item can be returned to the lien holder. The dynamic interchange network 220 can be configured to act as the agent for implementing the above-described features, or it could be outsourced to a third-party that would have access to the dynamic interchange network 220.

Lending Component

[84] Returning to FIG. 4, the lenders 214 of FIG. 4 can include components configured to facilitate the dynamic interchange network 220 of FIG. 2A. The interchange device 280 of FIG. 2B and/or the DBE 420 can be configured to allow lenders/buyers to choose the inventory they wish to purchase. For example, the lender devices 264 of FIG. 2B can include the lender applications 265 of FIG. 2B having the components or configured to implement the components, such as the DBE 420. As mentioned above, in some embodiments, the DBE 420 can include the identity service component 422, the fraud service component 424, the risk service component 426, the lender-side campaign component 428, the budget service component 430, the pricing engine 432, etc.

[85] The identity service component 422 can determine the identity of the member borrower 202 involved in the transaction. The identity service component 422 can analyze (e.g., string search, data extraction based on bid format/protocol, etc.) the bid request 410 to determine various relevant information. For example, the identity service component 422 can determine an identifier that protects the anonymity (e.g., member's name, personal address, etc.) of the member borrower 202 while grouping other relevant demographic (e.g., age, sex, general location, credit score, etc.) or financial information of the consumer. Also for example, the identity service component 422 can determine the merchant associated with the transaction.

[86] The fraud service component 424 can be configured to check the transaction for fraudulent transactions. For example, the fraud service component 424 can be configured to compare the bid request 410 to a predetermined template that characterizes fraudulent activities. In some embodiments, the fraud service component 424 can include a machine- learning model and/or artificial intelligence that is configured to analyze/recognize patterns (e.g., recent trends) or characteristics (e.g., merchant/user associated with previous fraudulent activities, profile/demographics information indicating higher likelihood, etc.) of fraudulent activities.

[87] The risk service component 426 can be configured to calculate a level of risk associated with the transaction. For example, the risk service component 426 can generate and update a real-time risk model for determining credit worthiness. The risk model can synchronize information such as credit balance, defaults, and transaction details across all issuers on a network. Accordingly, the risk service component 426 can access or identify the member's financial information (e.g., outstanding credit balance or debts, credit score, defaults, etc.). Based on the accessed information, the risk service component 426 can be configured to propagate in real-time any defaults, credit balances, etc. known by one lender to other lenders in the network. In comparison to the traditionally fragmented credit score profiles (i.e., used by banks today), the risk service component 426 can allow the banks to update members' activities and associated risks in real-time. The risk service component 426 can take the transaction information 208 into account so that the risk can be assessed per transaction. In some embodiments, the risk service component 426 can calculate a risk score or profile for the lender or other subsequent processes. In some embodiments, the risk service component 426 can filter out (e.g., automatically reject) certain transactions that meet/exceed threshold risk conditions.

[88] The lender-side campaign component 428 includes specified criteria (e.g., in addition to the supply-side campaigns 404) for funding credit requests. The lending component can be configured to allow issuers to create stringent criteria for lending based on the bid request 410 (e.g., the transaction information 208, the member's financial information, etc.). For instance, the lenders can set their ideal payment terms (e.g., existing payment terms for credit cards, but with additional control on lending preferences) for specific ranges of credit scores. Similarly, the lenders can set the campaign to target consumers based on geolocation, age, gender, credit score, interest rate requirements and thresholds, etc. Also, the lenders can set the campaign to target certain transaction classifications (e.g., purchased good or service, such as travel, gas, necessities, etc.) and/or merchants, such as for prioritizing/rejecting transactions that take place at specific merchants. Also, the lenders can set the campaign to control partial fills, such as for outstanding loans and/or purchase prices over certain thresholds and/or matching certain conditions (e.g., consumer's financial state). Accordingly, the lenders can fund any amount of an incoming transaction less than or up to the purchase price. For instance, a lender could receive an incoming request for $100 from a particular borrower and offer to fund only $50 of the total amount. This is not possible in traditional card schemes because banks typically rely on credit limits. With spot underwriting, issuers' systems can have the ability to look at specific transactions and determine the appropriate amount & terms to fund.

[89] In some embodiments, the lenders can further set the campaigns to target transactions associated with consumer purchase cycles, such as based on durable and nondurable goods, consumer staples, etc. Also, the lenders can set the campaign to set key performance indicator (KPI) goals for each of the campaigns, such as for interest rate goals, targeted number of transactions, targeted number of new users and/or recurrent users, etc.

[90] The lender-side campaign component 428 can be configured to provide lenders with additional/detailed control over how they manage transactions based on merchant codes, fraud level, real-time risk assessment, and other factors. For example, an issuer will be able to set a budget aside for a specific type of transaction. Also for example, an issuer can set an APR threshold of 5% for transactions from a specific merchant, with cardholders who have credit scores between 750-810, and purchase amounts under $100. Once the campaigns are configured, the lender-side campaign component 428 can match consumer transactions based on the available campaigns. The lender-side campaign component 428 can filter through the available campaigns and match the correct campaign according to the target details and the transaction information, member purchaser's information, etc. In some embodiments, the lender-side campaign component 428 can whitelist/blacklist consumers, merchants, other lenders (e.g., for reselling/buying outstanding credits), etc.

[91] The budget service component 430 can be configured to control a lending amount, including an aggregate lending amount for the lender over a period of time (e.g., daily, weekly, monthly, quarterly, yearly, etc.). In some embodiments, the budget service component 430 can be configured to control a pace/frequency (e.g., no more than x many bids per a given period) for the lending. The budget service component 430 can interact (e.g., through an interface for the lender applications 265) with the lender to set the lending budget and/or the lending pace, and then track the lending amounts and/or events against the budget. When the bid request 410 is received, the budget service component 430 can verify the remaining budget amount and/or the prior lending events (e.g., timing thereof) to determine whether the lender can finance the transaction amount.

[92] The pricing engine 432 can be configured to determine a financial response to the bid request 410. The pricing engine 432 can determine a price for the bid. The pricing engine 432 can be configured to price individual transactions using the data points about the member (e.g., member's credit rating, outstanding debts, financial history, earning power, etc.), the transaction (e.g., the total purchase price, merchant location, etc.), the lender's status (e.g., number of outstanding accounts, amount of outstanding debts or defaults, etc.), etc. while still adhering to the terms. In some embodiments, the pricing engine 432 can include one or more conditions, models, Al, etc. configured to use the data points to price the transaction. In pricing the transaction, the pricing engine 432 can calculate the terms (e.g., interest rates, lender's maximum financing amount, reward amounts/types, etc.) for financing the proposed transaction. When the calculated terms match or fall within the member's transaction preferences 222, the DBE 420 can present the terms as the repayment terms 224. When the calculated terms are outside of the member's transaction preferences 222, the DBE 420 can present the terms as alternative terms, such as for presenting a counter-offer to the member.

[93] Based on one or more of the various processes discussed above, the DBE 420 can provide a response (e.g., a bid response 434) approving/accepting to fund the transaction, rejecting the transaction, or providing alternative repayment terms for funding the transaction. The bid response 434 can include the repayment terms 224/alternative terms for financing the transaction. In some embodiments, the interchange device 280 can include a matching engine that accounts for tie breaking, failure scenarios, backstops, etc. For example, the interchange device 280 can be configured to select the bid response that matches the member's preferences, such as for a lowest interest rate, highest reward amount, a targeted program, etc. If the DBE 420 cannot find any available campaigns or if there are no bids, the interchange device 280 can send a no-bid response and/or use the backstop account to fund the transaction. In some embodiments, the DBE 420 can regularly (e.g., based on polling or through one or more open data streams) check for anti-money laundering (AML), sanctions screening, profitability, fraud, etc.

[94] In some embodiments, the lenders 214 can subscribe to stream/receive auction level data and reporting in real-time. In some embodiments, the DBE 420 can be configured to generate a bid-landscape analysis, win-rate analysis, etc. For example, the DBE 420 can track the bids and their results for the individual lender and/or the collection of lenders in the dynamic interchange network 220. Based on the bid results, the DBE 420 can generate a human-readable output data (e.g., graphs, charts, or other visual representations) that characterize the bid results according to one or more criteria.

[95] In some embodiments, the DBE 420 can be configured to buy/sell outstanding credits (e.g., credits issued by a lender for a previous purchase) between the lenders 214. For example, the DBE 420 (e.g., through the lender applications 265 and/or the interchange device 280), can be configured to access additional liquidity from other issuers, such as for selling. Also, the DBE 420 can be configured to lend against credit card transactions previously funded by other issuers. In such cases, the DBE 420 can issue the bid request 410 for the existing credit similarly as for a new purchase, and the various components can function similarly as described above.

[96] As an illustrative example of inventory reselling, a first issuer can use the inventory reselling feature to resell all transactions/credit for consumers that have a sub- prime credit score, located in a certain region, or matching other specific conditions. The first issuer can programmatically set up or adjust the supply-side campaign and/or its lender-side campaign accordingly. For example, the first issuer can use a Ul in the lender application to select credit score ranges, regions, or other conditions to identify the targeted debts/transactions. Similarly, the first lender can further identify other limiting factors, such as floors in terms of pricing that a lender buyer would need to meet. Based on the identified conditions, the first lender open the matching inventory to one or more lenders in the dynamic interchange network 220. When the inventory becomes available, the dynamic interchange network 220 can proceed through the bidding process as described above. Additionally, when a consumer and/or a purchase matches the condition, the dynamic interchange network 220 can identify the matching campaign and request a bid to the selected whitelisted buyers/lenders. Each lender can respond according to their settings/configurations for the DBE 420. In some cases, the service provider can also be one of the lenders.

[97] Also an illustrative example of inventory reselling, the member borrower 202 can sell (e.g., to one or more member borrowers, to one or more lenders, etc.) their reward points through the dynamic interchange network 220. To facilitate the borrower selling feature, the dynamic interchange network 220 (e.g., the consumer applications 253, the interchange device 280, the DBE 420, etc.) can be configured similarly as the DBE 420 described above, but for identifying member borrower's inventory of rewards and allowing other members and lenders to bid on the inventory.

[98] Based on the DBE 420, the lending component can include a real-time credit underwriting system. Based on the activities on the Borrower Component and the Network Component, the system can track the consumer's transactions and status in real-time. Since the system relies on validating the consumer's financial data (e.g., balances, repayment history, purchase records, credit rating/score, etc.), it can make this information accessible to lenders at the time of transaction. For example, the system can receive a transaction (e.g., a request through a POS device) for a purchase. The system can use the received information (e.g., the card/account number and/or borrower name) to look up or access the consumer's financial data. The system can provide the potential lenders with the consumer's financial data along with the transaction. As such, there is no need to separately pull or validate the information, and the lenders can simply check the borrower's credentials against their lending criteria at the time of transaction (e.g., based on an automated real-time comparison between the borrower's credentials/financial data and thresholds values representing lender's criteria). Lenders, therefore, can approve borrowers for small amounts of credit instead of lines of credit.

[99] Yet another lending component can include implementation of a method for merchants to mitigate their interchange fees by becoming issuers of credit themselves. In one or more embodiments, the merchants can lend money to borrowers like the banks. When the member borrower comes to their store and tries to purchase goods/services with credit, the merchant can act as a lender. The key difference for merchants can be that they have already purchased the item the cardholder is attempting to buy. Therefore, the merchant likely does not have to spend any additional capital to fund the transaction. As such, the merchant can gain a percentage of interchange that was formerly reserved for banks. Furthermore, the merchant can make any money on interest that occurs from repayment.

[100] FIG. 5 illustrates an issuer interaction in accordance with an embodiment of the present technology. For example, FIG. 5 can illustrate details for the issuer response in the payment process when using the purposed issuer campaign management tool.

[101] The incoming transaction (e.g., from the merchant devices 254 of FIG. 2B) can be processed by the network (e.g., the interchange device 280 of FIG. 2B, the DBE 420 of FIG. 4, etc.) and then sent to the issuer. In order to respond to incoming requests, the issuer (e.g., one of the lender devices 264, corresponding one of the lender applications 265, or a combination thereof) can have access to the DBE components (e.g., the account/user merchant identity service component 422 of FIG. 4, the fraud detection service component 424 of FIG. 4, the risk analysis component 426 of FIG. 4, the campaign matching component 428 of FIG. 4, the budget service component 430 of FIG. 4, the pricing engine 432, book limits/user limits components, reporting component, or a combination thereof). These components can be used alongside the issuer's campaign configurations and updated cardholder profiles to respond to the incoming transaction. Based on the responses, the network can respond back to the issuer with a win/loss notification. The issuer's response along with the win/loss notification can be stored in a set of databases for reporting purposes.

Flow Diagram

[102] FIG. 6 illustrates a flow diagram illustrating a method 600 of implementing the updated transaction process 200 of FIG. 2A in accordance with an embodiment of the present technology. The method 600 can be implemented by the dynamic interchange network 220, such as with the consumer devices 252 (e.g., through the consumer applications 253), the merchant devices 254, the lender devices 264 (e.g., through the lender applications 265), the interchange device 280, etc. as illustrated in FIG. 2B. The method 600 can further include functions of the DBE 420 of FIG. 4.

[103] At block 602, the dynamic interchange network 220 can obtain each transactional parties' preferences/settings. Using the borrower user's components, the dynamic interchange network 220 can obtain borrower's preferences (e.g., the transaction preferences 222 of FIG. 2A). For example, the consumer devices 252 can interact with the member borrower 202 through the consumer applications 253 to obtain the target interest rate limit 302 of FIG. 3, the target monetary incentive 304 of FIG. 3, the target reward program 306 of FIG. 3, a reward amount, or a combination thereof. The interchange device 280 can obtain the transaction preferences 222 from the member's device through the communication network 270.

[104] Also at block 602, the dynamic interchange network 220 can obtain details for lenders' campaigns using the lender components. For example, the lender devices 264 can interact with the lenders 214 of FIG. 2 through the lender applications 265 to obtain various parameters described above for the lenders' campaigns. The interchange device 280 can obtain the campaigns from the lender devices 264 through the communication network 270.

[105] At block 604, the dynamic interchange network 220 can obtain borrower's financial information. For example, the interchange device 280 can interact with the lender devices 264 or devices of other financial institutions (e.g., banks, merchants, etc.) to receive existing accounts and balances, purchase history, payment history, etc. Also for example, the interchange device 280 can interact with one or more credit reporting bureaus to receive member's credit score and/or other financial information.

[106] At block 606, the dynamic interchange network 220 can obtain transaction information. When the member borrower 202 initiates a transaction (e.g., a purchase) with a merchant, the merchant device can interact with the user's device to identify the interchange device 280. Accordingly, the merchant device can send the transaction information 208 of FIG. 2 associated with the pending transaction.

[107] In some embodiments, the dynamic interchange network 220 can calculate funding estimates (e.g., the confidence estimate 312 of FIG. 3, the purchasing power estimate 314 of FIG. 3, etc.). The dynamic interchange network 220 can notify the member of the likelihood of finding a lender and/or the likely maximum credit amount based on the member's preferences. The dynamic interchange network 220 can calculate the estimates in real-time using the lenders' campaigns, past transactions, etc. in comparison to the member's financial information. Accordingly, the member may approve/apply the preferences or adjust the preferences to improve the chances or benefits.

[108] At block 608, the dynamic interchange network 220 can send the bid requests 410 of FIG. 4 to the lenders 214. For example, after receiving the transaction information 208, the interchange device 280 can determine the references and financial information of the corresponding member borrower. The interchange device 280 can generate the bid requests based on the transaction information 208, the transaction preferences 222, the member's financial information, or a combination thereof. In some embodiments, the interchange device 280 can initially identify a list of the syndicated lenders within the network, such as according to the supply-side campaigns 404 of FIG. 4 and the transaction information 208. The dynamic interchange network 220 can use the issuer router 408 of FIG. 4 to send the bid requests 410 to one or more of the syndicated lenders.

[109] At block 610, the dynamic interchange network 220 can analyze the bid requests 410 according to each of the lenders' campaigns. Using the lender components (e.g., the DBE 420), the dynamic interchange network 220 can compare the received bid request to the lenders' campaigns. At block 612, for matching campaigns, the dynamic interchange network 220 can determine the lending terms, such as credit/funding amount, interest rate, cash-back incentive amount, reward program and/or the reward amount, etc.

[110] The lenders' components can generate the bid responses 434 of FIG. 4 that include the individual lender's terms for extending the credit. At block 614, the dynamic interchange network 220 (e.g., at the interchange device 280) can obtain the bid responses 434. At block 616, the dynamic interchange network 220 can generate final repayment terms. Accordingly, at block 618, the dynamic interchange network 220 can coordinate the transaction. For example, when one bid response falls within the member's transaction preferences, the dynamic interchange network 220 can facilitate a funding process for the financial transaction, such as by sending the repayment terms 224 of FIG. 2 and extending the credit to the member borrower 202, transferring funds to the merchant, etc. Also, when multiple bids fall within the preferences, the dynamic interchange network 220 can select one bid response for facilitating the funding process. Also, when one or more bid responses correspond to partial funding, the dynamic interchange network 220 can combine the terms and use credit from multiple lenders to facilitate the funding process. Also, if the total amount of credit does not meet the transaction amount, the dynamic interchange network 220 can notify the member of any alternative terms, use backstop accounts, or a combination thereof for facilitating the funding process.

[111] After coordinating the transaction, at block 622, the dynamic interchange network 220 can track the transaction for each party. For example, the interchange device 280 can track the outstanding balances, acquired cash-back or rewards, etc. for the member. Also, the interchange device 280 can track the balance-owed (e.g., for wholly funded transactions and/or partially-funded transactions) and corresponding interest rates for the lenders. At block 624, the dynamic interchange network 220 can use the tracked information to bill the member and/or disburse payments to appropriate lenders.

[112] Based on the tracked information, at block 652, the dynamic interchange network 220 can allow multiple parties to sell their inventory to another party in the network. For members, at block 654, the dynamic interchange network 220 (e.g., through the member devices and applications) can interact with the member to identify a certain portion of the member's rewards for sale. For lenders, at block 654, the dynamic interchange network 220 can interact with the lender or analyze the inventory of outstanding credits/balances according to the campaigns. Based on the interaction and/or the analysis, the dynamic interchange network 220 can identify certain accounts or portions thereof for sale.

[113] Based on the identification, the dynamic interchange network 220 can facilitate the resale/transfer process similarly as the process described above for the financial transactions/purchases. For example, at block 608, the dynamic interchange network 220 can send bid requests to applicable parties (e.g., other members, merchants, other lenders, etc.). At block 610, the dynamic interchange network 220 can analyze the requests according to the lenders' campaigns, merchant's settings, or member's preferences in buying rewards or outstanding credit balances. According to the analysis, at block 612, the dynamic interchange network 220 can determine exchange consideration (e.g., payment amount) for the transfer. At block 616, the final transfer terms can be generated. At block 618 the dynamic interchange network 220 can facilitate the transfer between transactions, which can be further tracked at block 622.

[114] The method 600 can allow one or more parties (e.g., the service provider) to implement the dynamic interchange network 220 that stands between or connect the lenders 214 and consumer borrowers. Accordingly, through the method 600, the dynamic interchange network 220 can allow each participant to determine payment terms per transaction (e.g., instead of a predetermined LoC or a locked-in account or credit card). The method, as described above, can allow the devices (e.g., from the borrower's consumer device to the interchange device 280) to communicate borrower credit preferences (e.g., the transaction preferences 222). Upon receiving the borrower credit preferences, the network (e.g., the interchange device 280) can collect issuer credit responses (e.g., the bid responses 434) from the lenders 214 in response to a borrower's transaction and his/her credit preferences. The network can implement a process or a configuration that analyzes the bid responses according to borrower's preferences and produce the most favorable payment terms for the borrower based on his/her preferences. Accordingly, the network can facilitate transactions between lenders and borrowers based on their unique preferences, thereby providing one or more levels of sophistication in comparison to other traditional auction platforms. Also, the network can syndicate to multiple issuers a borrower's request for credit in a credit card network, thereby allowing the current existing networks and merchants from pivoting their business model.

[115] Further, for the method 600, the devices in the dynamic interchange network 220 can communicate using a communication protocol that can capture dynamic information (e.g., interest rates, reward offerings, etc.) for funding the transaction. For example, the communication protocol, as described above, can allow the devices to specify the repayment terms 224 including transaction-specific interest rates and/or rewards, partial funding information, alternative terms that fall outside of the borrower's preferences, etc. Accordingly, the dynamic interchange network 220 can communicate dynamic information (e.g., added payload information) in addition to or instead of predetermined response codes (e.g., the predetermined codes 1 16 of FIG. 1 ). As such, the lenders 214 can respond to transactions with full specifications (e.g., APR, fees, etc.) for underwriting, which provides the lenders 214 with flexibility in handling transactions in ways beyond that of the predetermined codes 1 16.

[116] As described above, the dynamic information can allow the lenders 214 to partially fund the transaction (e.g., extend credit that is less than the full purchasing price of the transaction. The network can aggregate the partial funding responses and allow multiple issuers to fund a single transaction. Accordingly, the network can allow multiple lenders to syndicate the underwriting of loans, thereby reducing/sharing the exposure and/or risk associated with the transaction (e.g., for relatively large transactions).

[117] The method 600 further enables parties (e.g., the borrowers and/or the lenders) to sell/trade their assets. For example, the member borrower can request to trade any reward points he/she has earned to gain other benefits/rewards/cash from other borrowers, merchants, lenders, etc. A responding party can make their best purchase offer/bid for the member's trade request. Similarly, the lenders 214 can sell their inventory (e.g., outstanding credit accounts) to other lenders and/or merchants in the network.

[118] The method 600 can enable merchant financing by allowing the merchants to gain access to syndicated loans through their POS device system. The repayment terms can be secured through future accounts receivable by directly allocating a set portion of the merchant's transactions through this network to the payment of the merchant's debt.

Remarks

[119] One or more of the embodiments discussed above can be used to implement a card service, a new payment model, a new underwriting scheme, and/or network based on a new lending model. The new lending model can lower the entry barrier previously set by world's largest banks, allowing any other lender or smaller bank to offer a competitive yet profitable card product. With the increase in market competitors, consumers can receive best deal terms possible, avoid complex and predatory terms, eliminate the need to carry multiple cards for different rewards, and avoid penalties associated with shopping around for the best product. [120] As discussed above, this new lending model will be based on spot underwriting where credit is extended for each transaction swipe instead of via fixed credit limits. Cards can be issued to consumers, transactions will flow through the discussed network, and the credit will then be instantly auctioned off to liquidity providers. Consumers can dictate their own terms by selecting interest rate ceilings, reward programs, cash back amounts, etc. Lenders can build campaigns by selecting preferences from the vast array of real-time information embedded in each financial transaction (e.g., credit card swipe). The system can implement a Dynamic Bidding Engine {DBE), which will match and syndicate each of the cardholders' transactions to a corresponding lender or group of lenders - a significant departure from the higher risk, single bank, fixed-term underwriting that has starved the economy of ample lending capital.

[121] Based on the functions of the dynamic interchange network 220 and the DBE 420, the service provider can provide automatic regulatory reporting (e.g., to credit bureaus) on behalf of the lenders 214. Also, the service provider can reduce servicing fees/costs, such as by verifying card-not-present transactions and translating them to card-present transactions, for the consumer, the merchants, the lenders etc. Further, the service provider can reduce or eliminate portions of the existing structure (e.g., direct locked in relationships between each consumer and a limited set of lenders) to provide increased choices/options for the consumer, an open marketplace for funding transactions, decreased overall risks for lenders, etc. Additionally, the above-described aspects of the technology can lower the bar for creditors/banks to offer and brand their own services, thereby increasing competition for existing banks or networks that will lead to consumer benefits.

Example Hardware Components

[122] FIG. 7 is a block diagram of an example of a computing device 700, which may represent one or more computing devices or servers described herein, in accordance with various embodiments. The computing device 700 can include one or more computing devices (e.g., one or more devices in the environment 250 of FIG. 2B) that implement the updated transaction process 200 of FIG. 2A. The computing device 700 can execute at least part of the method 900 of FIG. 9. The computing device 700 includes one or more processors 710 and memory 720 coupled to an interconnect 730. The interconnect 730 is an abstraction that represents any one or more separate physical buses, point-to-point connections, or both connected by appropriate bridges, adapters, or controllers. The interconnect 730, therefore, may include, for example, a system bus, a Peripheral Component Interconnect (PCI) bus or PCI-Express bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), IIC (I2C) bus, or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus, also called "Firewire". The interconnect 730 can also include wireless connection or communications between components.

[123] The processor(s) 710 is/are the central processing unit (CPU) of the computing device 700 and thus controls the overall operation of the computing device 700. In certain embodiments, the processor(s) 710 accomplishes this by executing software or firmware stored in memory 720. The processor(s) 710 may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), trusted platform modules (TPMs), or the like, or a combination of such devices.

[124] The memory 720 is or includes the main memory of the computing device 700. The memory 720 represents any form of random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such devices. In use, the memory 720 may contain a code 770 (e.g., applications) containing instructions according to the operation of at least a portion of the updated transaction process 200 or the method 900 disclosed herein.

[125] Also connected to the processor(s) 710 through the interconnect 730 are a network adapter 740 and a storage adapter 750. The network adapter 740 provides the computing device 700 with the ability to communicate with remote devices, over a network and may be, for example, an Ethernet adapter, Fibre Channel adapter, or a wireless modem. The network adapter 740 may also provide one or more devices in the example environment 250 with the ability to communicate with other computers. The storage adapter 750 enables the computing device 700 to access a persistent storage, and may be, for example, a Fibre Channel adapter or SCSI adapter. [126] The computing device 700 can further include one or more user interfaces 760 connected to the interconnect 730. The user interfaces 760 can communicate information to a user and/or receive inputs/information from the user. For example, the user interfaces 760 can include a display screen, a speaker, a haptic device, tec. Also for example, the user interfaces 760 can include a touch screen, a keyboard, a mouse, a microphone, etc. Also for example, the user interfaces 760 can include one or more GUIs.

[127] The code 770 stored in memory 720 may be implemented as software and/or firmware to program the processor(s) 710 to carry out actions described above. In certain embodiments, such software or firmware may be initially provided to the computing device 700 by downloading it from a remote system through the computing device 700 (e.g., via network adapter 740).

[128] Overall, the system/process described herein may be implemented for execution by any suitable computing environment in which the invention can be implemented. The system may be implemented by routines executed by a general-purpose data processing device, e.g., a server computer, wireless device or personal computer. Those skilled in the relevant art will appreciate that aspects of the invention can be practiced with other communications, data processing, or computer system configurations, including: Internet appliances, hand-held devices (including personal digital assistants (PDAs)), wearable computers, all manner of cellular or mobile phones (including Voice over IP (VoIP) phones), dumb terminals, multi-processor systems, microprocessor-based or programmable consumer electronics, set-top boxes, network PCs, mini-computers, mainframe computers, and the like. Indeed, the terms "computer," "server," "host," "host system," and the like are generally used interchangeably herein, and refer to any of the above devices and systems, as well as any data processor.

[129] Aspects of the invention can be embodied in a special purpose computer or data processor that is specifically programmed, configured, or constructed to perform one or more of the computer-executable instructions explained in detail herein. While aspects of the invention, such as certain functions, are described as being performed exclusively on a single device, the invention can also be practiced in distributed environments where functions or modules are shared among disparate processing devices, which are linked through a network, such as the communication network 270 of FIG. 2B. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[130] Aspects of the invention may be stored or distributed on tangible computer- readable media, including magnetically or optically readable computer discs, hard-wired or preprogrammed chips (e.g., EEPROM semiconductor chips), nanotechnology memory, biological memory, or other data storage media. Alternatively, computer implemented instructions, data structures, screen displays, and other data under aspects of the invention may be distributed over the Internet or over other networks (including wireless networks), on a propagated signal on a propagation medium (e.g., an electromagnetic wave(s), a sound wave, etc.) over a period of time, or they may be provided on any analog or digital network (packet switched, circuit switched, or other scheme).

[131] It is understood that the above described embodiments can be implemented using one or more devices (e.g., processors, Field Programmable Gate Arrays (FPGAs), state machines, memory devices, such as volatile or non-volatile memory, communication devices, such as modems or transceivers, user or device interfaces, or a combination thereof). Further, the discussed embodiments can be implemented in a networked environment. For example, the system can interact with the consumer through a user device (e.g., a personal computer or a laptop computer, a mobile device, etc.), which can be connected to one or more service provider devices (e.g., servers) implementing or executing one or more processes discussed above. The service provider devices can include lender devices or be separately connected to the lender devices (e.g., servers belonging to or operated by the lenders). The various devices can be connected using a communication network (e.g., telephone network, a local area network (LAN), a wide area network (WAN), a cellular network, etc.).

Conclusion

[132] Those skilled in the art will further appreciate that the depicted flow charts may be altered in a variety of ways. For example, the order of the blocks may be rearranged, blocks may be performed in parallel, blocks may be omitted, or other blocks may be included. [133] Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise," "comprising," and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to." As used herein, the terms "connected," "coupled," or any variant thereof means any connection or coupling, either direct or indirect, between two or more content elements; the coupling or connection between the content elements can be physical, logical, or a combination thereof. Additionally, the words "herein," "above," "below," and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word "or," in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

[134] The above Detailed Description of examples of the invention is not intended to be exhaustive or to limit the invention to the precise form disclosed above. While specific examples for the invention are described above for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternative implementations may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or subcombinations. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed or implemented in parallel, or may be performed at different times. Further any specific numbers noted herein are only examples: alternative implementations may employ differing values or ranges.

[135] The teachings of the invention provided herein can be applied to other systems, not necessarily the system described above. The content elements and acts of the various examples described above can be combined to provide further implementations of the invention. Some alternative implementations of the invention may include not only additional elements to those implementations noted above, but also may include fewer elements. Aspects of the invention can be modified, if necessary, to employ the systems, functions, and concepts of the various references described above to provide yet further implementations of the invention.

[136] These and other changes can be made to the invention in light of the above Detailed Description. While the above description describes certain examples of the invention, and describes the best mode contemplated, no matter how detailed the above appears in text, the invention can be practiced in many ways. Details of the system may vary considerably in its specific implementation, while still being encompassed by the invention disclosed herein. As noted above, particular terminology used when describing certain features or aspects of the invention should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the invention with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the invention to the specific examples disclosed in the specification, unless the above Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the invention encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the invention under the claims.

[137] To reduce the number of claims, certain aspects of the invention are presented below in certain claim forms, but the applicant contemplates the various aspects of the invention in any number of claim forms. Accordingly, the applicant reserves the right to pursue additional claims after filing this application to pursue such additional claim forms, in either this application or in a continuing application.

Claims

CLAIMS I/We claim:

1 . A method of consumer credit lending between issuers and borrowers, allowing ipants to determine payment terms per transaction, the method comprising:

obtaining borrower credit preferences representing a borrower's preferences for credit on one or more upcoming transactions;

obtaining borrower's financial information for financing the credit on the one or more upcoming transactions;

receiving transaction information from a merchant device, the transaction information representing a financial transaction;

using one or more issuer routers, sending bid requests to a set of syndicated lenders, wherein the bid requests include the transaction information and the borrower's financial information;

collecting issuer bid responses from one or more lenders in the set of syndicated lenders in response to the bid requests; and

using one or more processors, generating repayment terms based on the bid requests, wherein the repayment terms establish conditions for one or more lenders to fund the financial transaction based on borrower credit.

2. The method of claim 1 , wherein:

the bid responses includes one or more responses that each indicate a corresponding lender partial funding for an amount less than a total transaction amount; and generating the repayment terms includes generating the repayment terms based on the one or more bid responses that correspond to the partial funding to combine credit from multiple lenders to fund the financial transaction.

3. The method of claim 2, wherein:

generating the repayment terms includes calculating a set of combined repayment terms based on the one or more partial funding bid requests; and further comprising:

tracking individual repayment terms from each of the partial funding bid requests for billing purposes.

4. The method of claim 1 , wherein:

each of the bid responses includes individual repayment terms specified by a corresponding lender for funding the financial transaction; and

generating the repayment terms includes:

selecting one of the bid responses based on matching the individual repayment terms of the one of the bid responses to the borrower credit preferences, and

generating the repayment terms based on the individual repayment terms specified by the selected bid response.

5. The method of claim 4, further comprising automatically coordinating funding for the financial transaction when the repayment terms fall within the borrower's transaction preferences and further meets or exceeds a purchasing price for the financial transaction.

6. The method of claim 1 , wherein generating the repayment terms includes generating alternative repayment terms that are outside of the borrower's transaction preferences.

7. The method of claim 6, further comprising:

receiving a selection from the member borrower for selecting one or more of the alternative repayment terms; and

automatically coordinating funding for the financial transaction according to the borrower's selection.

8. The method of claim 1 , further comprising:

identifying a backstop account corresponding to an open line of credit available to the member borrower; and automatically coordinating funding for at least a portion of the financial transaction with the backstop account when the repayment terms are outside the borrower preferences, are less than a transaction price for the financial transaction, or a combination thereof.

9. The method of claim 1 , further comprising generating a virtual account number (VAN) for tracking funding of the financial transaction.

10. The method of claim 9, further comprising tracking using the VAN the repayment terms and the lenders that funded the financial transaction for billing and repayment purposes.

1 1 . The method of claim 9, further comprising using the VAN to replace a credit card number for a funding lender, a merchant, or a combination thereof associated with the financial transaction.

12. The method of claim 1 , wherein generating the repayment terms includes generating the repayment terms that dictate an interest rate, a cash-back incentive detail, a reward program, a reward amount, or a combination thereof associated with a credit issued by a funding lender in dynamically funding the financial transaction on a transaction basis, and instead of locked terms for a line of credit or a credit card account issued by an exclusive lender.

13. The method of claim 1 , further comprising continuously monitoring the borrower's financial information to detect changes therein.

14. The method of claim 13, wherein continuously monitoring the borrower's financial information includes detecting changes in the borrower's outstanding debt or credit, changes in purchase patterns, an occurrence of payment defaults, a change in credit score, an occurrence of a fraud event, or a combination thereof associated with the member borrower.

15. The method of claim 1 , wherein:

receiving the transaction information includes receiving the transaction information for a card-not-present transaction;

further comprising:

separately authenticating the borrower for the financial transaction through a predetermined communication account unique to the borrower, a device uniquely accessible by the borrower, a unique password, one or more biomarkers of the borrower, or a combination thereof; and

processing the financial transaction as a card-present transaction based on the separate authentication of the borrower.

16. The method of claim 1 , wherein:

obtaining borrower credit preferences includes receiving a target interest rate limit, a target monetary incentive, a target reward program, a target reward amount, or a combination thereof associated with obtaining the credit on the one or more upcoming transaction;

further comprising:

calculating a confidence estimate, a purchasing power estimate, or a combination thereof based on the borrower credit preferences and the borrower's financial information, wherein:

the confidence estimate represents a likelihood that the one or more upcoming transactions will be funded by a lender with terms that satisfy the borrower credit preferences, and

the purchasing power estimate represents a likely maximum credit amount that a lender will issue for the one or more upcoming transaction based on the borrower credit preferences.

17. The method of claim 1 , further comprising:

tracking multiple transactions for the borrower including tracking rewards resulting from the multiple transactions;

receiving a borrower election identifying one or more portions of the rewards for sale; sending reward transfer bids to one or more of lenders, merchants, other members, or a combination thereof;

collecting transfer bid responses from the one or more of lenders, merchants, other members, or a combination thereof; and

based on the bid responses, facilitating a transfer of the rewards from the borrower to another party in exchange for a consideration.

18. The method of claim 1 , further comprising:

identifying one or more lending campaigns for each of the syndicated lenders, wherein the lending campaigns identify limits, conditions, preferences, or guidelines for a corresponding lender to issue credits in funding transactions; and

automatically generating the bid responses for the lenders according to their lending campaigns, wherein the bid responses are generated when the borrower's transaction preferences, the borrower's financial information, the transaction information, one or more conditions of the corresponding lender, or a combination thereof matches one or more of the lending campaigns.

19. The method of claim 18, wherein automatically generating the bid responses includes calculating a credit amount up to or less than a purchase price of the financial transaction, wherein the credit amount is calculated according to the matching lending campaign and based on the borrower's transaction preferences, the borrower's financial information, the transaction information, one or more conditions of the corresponding lender, or a combination thereof.

20. The method of claim 18, further comprising:

identifying one or more credit accounts in the credit inventory according to a corresponding lender's lending campaign;

transferring the one or more credit accounts from the corresponding lender to one or more of remaining lenders according to their repayment terms; wherein:

identifying the one or more lending campaigns includes identifying limits, conditions, preferences, or guidelines for the corresponding lender for selling portions of their credit inventory;

sending the bid requests includes sending the bid requests to the remaining syndicated lenders, wherein the bid requests correspond to the identified credit accounts initially held by the corresponding lender; and

collecting the bid responses includes collecting the bid responses from the remaining syndicated lenders, wherein one or more of the collected bid responses include lender's repayment terms for acquiring the credit accounts or a portion thereof.

21 . A consumer credit lending system comprising:

one or more device interfaces configured to communicate with a borrower's device, a lender's device, a merchant's device, a financial reporting institution's device, or a combination thereof; and

one or more processors operably coupled to the one or more device interfaces, the one or more processors configured to:

obtain borrower credit preferences representing borrower's preferences for credit on one or more upcoming transactions,

obtain borrower's financial information for financing the credit on the one or more upcoming transactions,

receiving transaction information associated with a financial transaction; using one or more issuer routers, sending bid requests to a set of multiple syndicated lenders, wherein the bid requests include the transaction information and the borrower's financial information;

collect issuer bid responses from one or more lenders in the set of syndicated lenders in response to the bid requests; and

generate repayment terms based on the bid requests, wherein the repayment terms establish conditions for one or more lenders to fund the financial transaction based on borrower credit.

22. At least one tangible, computer-readable medium, carrying instructions, which when executed by at least one data processor, performs a method of consumer credit lending that stands between issuers and borrowers: the instructions comprising:

obtaining borrower credit preferences representing borrower's preferences for credit on one or more upcoming transactions;

receiving transaction information associated with a financial transaction;

using one or more issuer routers, sending bid requests to a set of multiple syndicated lenders, wherein the bid requests include the transaction information and the borrower's financial information;

23. A method of consumer credit lending, comprising:

receiving, at a consumer credit lending platform, borrower credit preferences representing borrower-set parameters for credit on at least one upcoming transaction, wherein the consumer credit lending platform communicates between computing devices of issuers and computing devices borrowers, and wherein the consumer credit lending platform allows each participant to determine payment terms per transaction; and,

collecting issuer credit responses from lenders in response to the borrowers' upcoming transaction and the borrower credit preferences.

24. The method of claim 23 wherein receiving the borrower credit preferences and collecting the issuer credit responses includes communicating between devices according to a protocol configured to collect dynamic information for funding the transaction, wherein the dynamic information includes information in addition to or instead of responses codes.

25. The method of claim 23 wherein receiving the borrower credit preferences includes receiving a set of administrative restrictions including one or more of a merchant whitelist, a merchant blacklist, one or more spending time limits, one or more spending amount limits, one or more usage locations, or a combination thereof associated with purchases.