Faster payouts create a funding problem before they solve a user problem
A ChainCatcher article by Steven argues that one of the most overlooked facts in payments is the time gap between when money is shown as paid and when cash is actually available to fund that payment.
A merchant may not receive final settlement until T+1, while the recipient expects funds today. A marketplace may complete a consumer collection and see the seller request a withdrawal right away. A cross-border payments company may receive USD in the US while the beneficiary in Mexico expects MXN seconds later.
From the user side, the screen says one thing: payment completed.
From the treasury and balance-sheet side, the question is different. If the money has not arrived yet, why can it already be paid out? Who is covering those hours, or that day, in between?
The most direct answer is that the payment company covers it first. If the matching funds will only settle tomorrow, but the payment service provider, or PSP, sends the payout today out of corporate cash, that is self-funded prefunding. The PSP uses its own balance sheet to absorb the timing gap.
The article says two issues are often mixed together at this point.
First, paying out with the PSP’s own money does not automatically mean the company has legally or commercially made a loan to the customer. From a treasury perspective, the first issue is balance-sheet usage and funding exposure.
Second, and more practically, a PSP can process a very large amount of money every day without being free to use all of that money for prefunding. Customer funds, corporate cash, and credit capacity are not the same pool. As a payment business scales, credit stops looking like a separate financial product and starts looking like part of payment infrastructure because those three numbers stop lining up.
Processing volume is not the same as prefunding capacity
Steven uses LianLian DigiTech to illustrate the point through a listed payments company’s balance sheet.
According to the article, LianLian DigiTech reported global payment TPV of RMB 452.4 billion for full-year 2025, up 60.7% year over year.
But further down the balance sheet, the company had cash and cash equivalents of about RMB 1.628 billion, total equity of about RMB 3.072 billion, and customer segregated funds of about RMB 19.466 billion as of the end of 2025.
Put together, those figures point to a basic distinction: customer funds and corporate liquidity are not the same thing.
A payment company can process billions in annual volume without needing, or being able, to hold an owned balance sheet of the same size as full-year TPV. That is one of the reasons the payment business can scale. But when payment obligations and cash arrival no longer line up, the money that can actually be used to pay early is not all the money passing through the platform. It is the firm’s own corporate liquidity plus whatever external funding capacity has already been arranged.
The article notes that LianLian also disclosed about RMB 1.407 billion in unused bank credit lines during the same period. Steven adds that this does not mean those lines are necessarily used for payment prefunding, but it does show another layer of financial capacity. A payment company’s callable funding ability is not defined by on-balance-sheet cash alone.
The article breaks the payment funding stack into three numbers that are often confused:
- Customer funds determine how much money a company manages.
- Own free cash determines how much it can front with its own balance sheet.
- Credit capacity determines how much it can still commit after own free cash runs short.
Why money can be paid out before it arrives
The article gives a marketplace example. Assume a platform needs to pay RMB 100 million to sellers at 10 a.m. today, but the matching consumer funds will only become available later in the afternoon or even the next day. The timing mismatch may come from acquiring settlement cycles, a C2B2B2C or B-structure arrangement, bank review speed, or other operating reasons listed in the article.
On the product surface, this is just a payout. But from 10 a.m. onward, the platform has already taken on a RMB 100 million payment obligation while the cash tied to that obligation is not yet freely usable.
That space in the middle is the funding gap.
If the marketplace chooses to wait, the seller bears the delay. Payment happens when the funds are actually available. If the product promises T+0, same-day, or instant payout, the platform is taking that waiting time off the seller and onto itself.
The problem has not gone away. The time burden has changed hands.
The simplest answer is to use corporate cash. If cash is sufficient, the platform pays today and restores its cash position after the expected funds arrive tomorrow. Steven frames that as a balance-sheet decision. The platform uses its own capital to buy a better payment experience.
At small scale, credit may barely be visible. Treasury can hold a bit more buffer and move on. But if daily payment volume rises from 10m to 100m and then to 1bn, the same one-day mismatch consumes much more capital.
Even if a PSP has the money, the article argues that using it this way all the time is not automatically good capital allocation. Keeping several hundred million in cash on hand all year to cover only a few peak days is expensive in opportunity-cost terms.
That leads to the next question: what if own free cash is not enough, or is no longer worth using?
One route is to pull the payment experience back: delay payouts, raise prefunding requirements, reduce volume limits, or in extreme cases suspend some payments. The other route is to find another balance sheet through bank credit lines, overdrafts, intraday facilities, settlement financing, or private credit.
Steven’s point is that payment first collides with credit not when a PSP launches a loan product, but when payment begins to cross time.
Liquidity management is not the same thing as credit
The article then separates liquidity from credit.
If Mexico needs 20m MXN today but the local account has only 5m, while the group’s Hong Kong account has enough USD and can convert foreign exchange and move the matching MXN position to Mexico, the issue is liquidity management. The corporate balance sheet has not grown. Money has only been moved from one currency, location, and position to another.
Liquidity, in the article’s framing, answers how existing resources are deployed.
But if all currently available internal liquidity across the group adds up to only 80m while today’s payment obligations already total 100m, the remaining 20m cannot be solved by moving money from A to B. The real issue becomes how to fill the gap.
The company can, of course, permanently hold another 20m in cash. That is still self-funded. But if it does not want to tie up its own capital for every possible peak-demand scenario, then a bank, a credit provider, or another capital provider needs to supply extra funding capacity.
The article reframes the relationship this way:
- Liquidity determines how to use existing resources.
- Funding determines where the shortfall gets filled.
- Credit is one important way to obtain extra funding capacity.
This distinction matters. Self-funded prefunding is not the same as borrowing, and it does not mean a PSP has offered the customer a credit product.
Still, the article argues that once payment scale grows large enough, relying on own free cash to cover every peak-demand event becomes steadily less capital-efficient. At that stage, credit does not just provide more money. It provides elasticity. Liquidity governs how existing money is used. Credit determines whether capacity can expand when existing money is not enough.
Instant payment often means the balance sheet is paying behind the scenes
Steven says the payment industry has spent more than a decade making money move faster, from T+3 to T+2, T+1, same-day, T+0, and now more forms of instant payment. From the user-experience side, that path is straightforward.
What is less intuitive is that faster receipt for the end user does not mean upstream cash arrives any faster.
In the older setup, a merchant was paid at T+1 and the PSP also received the related settlement at T+1, so the two timelines broadly matched. If a platform moves merchant payout forward to T+0 for competitive reasons while the underlying settlement remains T+1, a one-day funding gap appears where none existed before.
So the article argues that the industry is not always eliminating settlement time. In many cases, it is removing the waiting period from customer experience and placing it onto a financial institution’s balance sheet. Steven sums it up with a short line: the instant-payment experience is often being paid for by the balance sheet in the background.
As payments become more real-time, timing risk does not disappear. It gets reassigned. The seller stops waiting and the platform starts waiting. The merchant stops waiting and the acquirer starts waiting. If the client does not want to prefund, the PSP must decide whether to carry that burden itself or find someone else to carry it.
The article says that logic has already been turned into products. It points to YouLend’s Instant Settlement and Instant Payout as an example. The core idea is to let the merchant receive funds tied to a receivable before normal settlement has fully finished. The sale has happened, cash has not fully followed, but the merchant gets paid anyway. Financing absorbs the waiting time in the middle.
The article also argues that stablecoins do not make this problem disappear on their own. A blockchain may transfer value 24/7, but fiat banking, FX, redemption, local clearing, and traditional funding markets do not necessarily run 24/7 on the same schedule.
That means 24/7 settlement is not the same thing as zero funding requirement.
Steven flips the example one more way. In the past, if money could not move on Saturday, users expected to wait until Monday. If the rail now supports instant settlement at 3 a.m. on Saturday, a different question appears immediately: where does the liquidity and funding come from at that hour? The more real-time the rail becomes, the less the back office can rely on saying, just wait until the cash arrives.
At scale, payment networks compete on credit elasticity
The article uses a simple scaling example. If daily volume is 1m and 10% of it carries a timing gap of a few hours, temporary coverage of 100k is enough. At 1bn per day, the same 10% mismatch becomes 100m.
Real payment networks, however, do not move along a smooth line every day. Payday, major promotions, bank holidays, weekends, FX volatility, settlement delays, and banking disruptions can all create payment obligations far above normal levels in a specific market within a matter of hours.
Because of that, a large PSP cannot simply preload every market with enough cash to match the biggest historical peak. That might be safe in theory, but the article says it is extremely expensive in economic terms.
Steven argues that mature payment networks eventually build layered capacity. Ordinary flow can be absorbed through natural flow, netting, and own liquidity. Routine fluctuations can be handled by treasury buffers. Larger gaps then trigger bank credit lines, overdrafts, intraday facilities, settlement financing, or other external funding.
In other words, a large payment network needs more than a fixed liquidity pool. It needs credit elasticity.
Liquidity capacity answers one question: under normal conditions, how much can I pay today? Credit elasticity answers another: if today suddenly stops being normal, how much more can I still pay?
This is why the article says firms such as Huma/Arf and MANSA are worth watching. What they are trying to change is not the payment rail itself, but the capital deployment model sitting behind the payment network.
The older model leans on pre-positioned capital. Treasury borrows first, moves cash first, and prepares balances across markets first, then waits for the payment system to consume those positions.
The direction represented by Huma/Arf and MANSA is closer to an on-demand sequence:
- Payment happens.
- Liquidity or credit is called.
- Settlement is completed.
- Capital is recovered.
The article describes that as on-demand financial capacity.
After the Huma and Arf combination, one core use case highlighted in the piece is cross-border payment financing through on-demand liquidity, aimed at reducing some payment institutions’ dependence on static prefunding. MANSA, the article adds, provides settlement-time liquidity for institutions such as PSPs, EMIs, and remittance firms.
Steven says the more important point is not whether those firms use stablecoins. It is that credit capacity is shifting from something static to something dynamically called. If that model scales further, it affects more than funding cost. It changes treasury architecture. Payment companies would no longer need to keep the same amount of cash permanently parked in every corridor for every possible demand scenario. Own free cash gives base capacity. Credit gives elasticity.
Why companies that control payment flow naturally move toward credit
The article then turns from credit for payment to credit from payment.
That shift helps explain why platforms that control payment flow, such as Stripe, Adyen, PayPal, and Block, often expand into merchant financing and working capital.
The logic is straightforward. A traditional lender needs to understand revenue, cash flow, seasonality, growth, customer concentration, and repayment ability to underwrite a business. A payment company already sees much of that every day: TPV, transaction frequency, average ticket size, refunds, chargebacks, sales trends, and seasonality.
If the platform also has the account and settlement relationship, it may see even more, including cash inflow, cash outflow, account balances, supplier payments, and the working-capital cycle.
These are not annual financial statements. They are real-time business activity.
That is why payment data naturally becomes underwriting data in the article’s framework.
But Steven argues that the real structural edge for a payment company is not only more data. In many cases, it also controls the cash flow itself.
The article gives an example in which a merchant generates 100k in daily sales through a platform and receives 1m in working capital. Repayment does not have to rely on the merchant wiring money every month. It can happen directly through future settlement, deduction, and repayment.
Stripe Capital is presented as a clear case. The article says Stripe can generate a financing offer based on factors such as processing volume and payment history, while repayment can be taken as a share of future Stripe sales. At the same time, the merchant relationship, payment flow, and the entity that ultimately provides the balance sheet do not necessarily have to be the same company.
That structure matters because it shows that having a credit product does not mean the platform must also own the final balance sheet. The payment platform can handle flow, data, and distribution. A bank or another capital provider can supply funding and risk capital.
The article identifies this as one of the biggest structural differences between a payment company and a traditional lender. The payment company can often both see the cash flow and control the cash flow. Flow supports underwriting on one side and serves as the repayment rail on the other. Underwriting, disbursement, and repayment become embedded in the flow itself.
From that angle, a payment company’s move into credit is not simply product expansion. It follows directly from infrastructure logic: the flow is both the data layer and the repayment rail.
In the end, credit still comes back to the balance sheet
If a payment platform already has flow, data, and customer relationships, why not do all of credit itself? Steven’s answer is that data and balance sheet are very different capabilities.
According to the article, payment platforms are stronger at flow, data, distribution, customer relationships, and repayment control. Banks and institutional capital are stronger at funding, credit capacity, risk capital, and the balance sheet.
That means the future of payment plus credit may not be a world where more PSPs become banks. It may be one where the credit stack is split into clearer layers:
- Payment platform: flow and distribution.
- Credit infrastructure: underwriting and orchestration.
- Bank or private capital: balance sheet.
The article says Stripe Capital already shows this kind of structure, where the credit product is embedded in the payment experience while the financing provider does not have to be the payment platform itself. Huma/Arf and MANSA, in Steven’s view, are trying to push a similar decoupling deeper into payment settlement.
Historically, bank credit lines and payment systems have often operated as two relatively separate infrastructures. Going forward, the article argues, credit capacity itself may connect more directly to payment flow and be called dynamically when settlement actually occurs.
That shifts the core question. Instead of asking which PSP has started making loans, the article suggests asking three different questions: who controls the flow, who decides the credit, and who ultimately provides the balance sheet?
Those three functions no longer need to sit inside the same company.
Payment companies hold the flow. Banks and capital markets hold the balance sheet. Credit is the layer that connects the two.
Steven’s conclusion: credit is not a side branch of payment, but the price of time
The article closes by returning to its opening question: if the money has not arrived yet, why can it already be paid?
At small scale, the answer may be simple. The PSP fronts it. That is self-funded prefunding. At a somewhat larger scale, treasury can move positions across the firm’s global balance sheet. But when payment obligations become more real-time, volume keeps rising, and own free cash cannot expand without limit, external funding becomes necessary.
Steven breaks the framework into four layers:
- Payment solves money movement.
- Liquidity determines how existing money shows up in the right place at the right time.
- Funding determines where the gap is filled when existing positions are not enough.
- Credit determines how future repayment capacity can be brought forward as usable financial capacity today.
That repayment capacity, the article says, can come from future cash flow, receivables, collateral, or the institution’s own credit profile.
Liquidity manages positions. Credit provides elasticity. Beneath both sits the balance sheet, which still determines how large the network can really become.
This is why the article says the payment industry will keep moving closer to credit. Not because every PSP wants to become a lender, but because as payments become more real-time, volumes grow, and settlement chains become more complex, someone still has to answer a practical question: what happens when today’s money has not arrived but the payment cannot stop?
If the company’s own balance sheet is enough, it carries the burden itself. If not, it has to call on someone else’s balance sheet.
Steven adds that calling credit the price of time does not mean time is the only thing being priced. What is really being priced is the credit risk, liquidity cost, capital consumption, and uncertainty tied to that timing gap, along with the compensation required by whoever provides the funds.
In that sense, credit is not just a loan product. It is a layer of financial capacity that can expand dynamically when a payment network runs into timing gaps, peak volume, and settlement mismatch.
The article ends by restating the three core funding measures:
- Customer funds determine how much money a firm manages.
- Own free cash determines how much it can prefund itself.
- Credit capacity determines how much it can still promise after own cash is no longer enough.
The bottom line, in Steven’s telling, has not changed. Payment volume can be far larger than a PSP’s own balance sheet. But when cash arrival and payment obligations are out of sync, that gap must ultimately be carried by some balance sheet.
Payment moves money. Liquidity routes money. Credit lets future financial capacity support today’s payment. In the end, a balance sheet does not just determine how many transactions a company has processed in the past. It determines how much it is still willing and able to promise before the money has actually arrived.