The topic of funds availability came up with a large potential partner on a call a few weeks ago. When funds are available to the recipient in an electronic transaction is more often than not a function of the Transfer Type that’s being used to exchange money.
In the US, there are many Transfer Types that don’t have immediate funds availability so throughout the years many businesses have solved that problem by creating a common solution to the problem.
That solution is leveraging a third party who steps in to provide liquidity enabling the receiver to get access to funds instantly.
Here are the basic mechanics in a normal scenario without a liquidity provider using Dwolla Customer Types. In this example VCR1 is the sender and VCR2 is the recipient.
This standard delay can be resolved by introducing a third party to provide liquidity as mentioned above. A less technical way to say that is that someone will front the cash to the receiver and take the risk that the sender’s payment fails.
An example of how this is done from a funds flow perspective is as follows.
VCR3 represents a new entity not included in the initial fund flow. VCR3 is operated or owned by a liquidity provider. It’s worth noting this is oversimplified for the sake of sharing the example. VCR3 could actually be operated by the client application owner as well as long as the contract between the VCR3 account owner and the client application owner allowed for it.
Is this actually possible?
It happens everyday in systems across the world. As high finance invades FinTech, or vice versa, this is happening more and more.
So what does liquidity cost?
It varies greatly. Some companies raise enough money and get the right licensing so they can fund it off their balance sheet. Another solution is to partner with a bank and yet another is partnering with a different kind of liquidity provider.
While the economics may vary, let’s look at 3 potential solutions if the liquidity is funded by accepting transaction risk in the form of short term debt. In this example there are 3 cost scenarios I commonly see:
- Fed Funds Rate. This sat at .25% annually as of me typing this the first time. Fed funds rate is going down by the day.
- A commercial line of credit. Let’s assume 6% annually. Even if the Fed rate is lower non-banks rarely enjoy that rate.
- Something more provocative. Let’s assume 12% annually. These are the types of rates more commonly seen.
The cost depends on the partner.
A key component here is the liquidity isn’t being provided on an annualized basis, it’s being provided on a day to day basis. When we look at the actual cost it’s important to look at how much money is extended and for how long.
When you start introducing real-time environments you can start breaking costs down day by day, hour by hour, minute by minute, and yes…. Second by second.
Daily interest is important in this scenario
On a typical ACH transaction you might have a 2 day delay to deal with. So if you need $1M dollars (because it’s an easy amount for this example) you could use one of the partner solutions I mentioned above to fund that $1M. Remember, the liquidity is almost always anchored by a relationship between the liquidity provider and application owner.
So who owns the cost? The client application owner typically carries the cost of the program that the liquidity provider makes possible.
In a nutshell, if we just use the lending rates I mentioned above we can assume $1M in liquidity is about $164.38 per day at 6%, accrued daily.
To cover the 2 day gap you’d need to pay $328.76. If you assume an average consumer transaction about $124 dollars, you could support 8,000+ consumer transactions a day and get the merchant paid in real-time by borrowing the money and taking the return risk. A nuance here that is important to remember is the consumer isn’t taking any loan. The consumer in this example is the beneficiary of the client application owner + liquidity provider taking on risk to provide a better user experience and instant access to money.
The cost of introducing real-time availability of funds is not as extreme as it once was.
At .25% the $164.38 per day cost becomes $6.85 per day. With a 2 day float you’re looking at a cost of $13.70 per $1,000,000. 🤯
Here are the numbers if you want to run through them. They are for demonstration purposes and shouldn’t be used as perfect. A number of variables could change the actual costs.
Programming Risky Things
When systems enable different parties to take on risk in real-time we can start to consider who could be bidding day by day, hour by hour, minute by minute, and second by second. While exciting, this is also dangerous if done irresponsibly.
If you’re building something like this I would strongly encourage you to hire a technical lawyer who can help you structure your relationships. The technical aspect of moving the money is now the easy part. It used to be the other way around!