Just in Time (JIT) Funding is a powerful way to build great customer experiences and decrease cash reserve requirements necessary to facilitate them.
To understand how JIT works, you first need to understand how a regular debit transaction is authorized.
- A customer makes a purchase which is routed to the network (e.g., Visa, MasterCard, Discover, etc) by an acquiring processor.
- The network maps the card number to a bank account or line of credit in order to ask the bank that houses that account, “Does the account or LOC tied to this card have enough money to pay for this transaction?”
- The bank’s issuing processor, which is tied to the bank account or LOC, peaks into the account and LOC to answer the question. If the answer is “yes,” then the transaction is allowed. If the answer is “no,” then the transaction declines.
- If the transaction was allowed, then the acquiring bank pulls funds from the underlying account tied to the card or an account tied to the lender. If the latter, then the lender then pulls from the account holder when it is time pay the credit card bill at the end of the month.
Everything listed above up until answer “yes” or “no” is the authorization flow. The last bullet is settlement.
Just in Time funding allows FinTechs to add sophistication when checking for requisite funds on the issuing side of the transaction. Instead of simply pointing to the original account tied to the card, a FinTech can divert where it asks the question, “Is there enough money to allow this transaction?” to other account or group of accounts.
- Shared transactions: Instead of a having one friend pay for dinner and three friends paying her back, a “group auth” can be setup by a Fintech. If all four friends used the same banking application, they can connect themselves to one another for the purpose of the transaction. When it is time to authorize the transaction, the issuing side can ask the question, “Do all of these accounts collectively have sufficient funds?” as opposed to just the card the restaurant swiped. JIT funding would allow the network to ask the question of one card, but the issuing card to — in turn — ask it of the full group. Once authorization occurs a set of p2p transactions can send funds to the account tied to the card that was swiped. The restaurant would then pull funds from there.
- Multi-purse: If you have both a checking and savings account at your bank, a transaction can prioritize your checking account but use the savings as a backup when there isn’t enough money in the former. After authorization, an internal transfer from savings to checking can occur to ensure requisite funds for settlement.
- Micro-loans/Overdraft protection: A debit card program can provide a form of micro-loans by making up the difference on the amount a checking account is short on a transaction should the program provider believe the accountholder will pay them back. Instead of relying on a global overdraft configuration set up on the processor, the program can calculate creditworthiness every time an overdraft occurs. The transaction can authorize even when the account is short on funds, with the program moving money to the account just prior to settlement to ensure the merchant is paid.
- Budget and spend management: A single debit card can have different balances dependent on a state which maps to budgets. This, in essence, replicates having multiple purses. For example, a cardholder can put their card into a budget for “Travel” which will allow certain logic that checks for special velocity limits, various currencies, or merchant category codes to authorize a transaction as opposed to when in a state of “Office Supplies” which would have its own authorization logic. If authorized, these transactions would settle with corporate funds that sit in an account mapped to the card.
JIT provides wild flexibility for a program to do creative things to facilitate great customer experiences. For a processor, it enables tremendous selling flexibility to programs and banks without requiring immediate heavy integrations.
For example, a program may only connect to one bank through its processor but may be able to peak into other accounts through a Plaid connection. This enables the program to authorize against accounts at multiple banks even if the card they issue is tied to just one bank. There is risk, but it can be mitigated and tolerated if it fits into a program’s P&L.