A client approves your work on Monday. The money leaves their account. You see it in your platform balance. Then you wait until Friday, or the following Tuesday, or until a threshold is met and a weekly batch runs.
The money exists. It has cleared. It is sitting somewhere. It is with the platform or its payment provider, and it is away from you.
This is one of the most consistent complaints about freelance platforms, and one of the least explained. A payout hold can protect against real risk. It can also leave the platform earning money on your cash. Both things can be true at the same time.
Some payout holds protect against real risk
Start with the honest reasons, because they are real. Any platform that pretends otherwise is being careless. There are three legitimate reasons to hold money after a client has paid.
Card payments can be reversed
When a client pays by card, the payment is reversible for a period that can extend to 120 days. If the platform has already paid the freelancer and the client then disputes the charge, the platform is out of pocket and chasing someone who has spent the money.
This is the largest genuine risk, and it is why holds exist at all. It also depends on the payment method more than the work. A bank transfer that has settled carries almost none of this exposure.
Fraud checks need time on some accounts
Marketplaces are used for money laundering and for collusion between fake buyers and fake sellers. A holding period gives automated systems and, occasionally, humans time to notice patterns before funds leave.
That reason is legitimate, and it mostly applies to new accounts. The risk profile of an account with two years of history and forty completed jobs is entirely different from a three-day-old account moving unusual sums.
A client may still raise a dispute
The client may raise a problem after approving. Some platforms hold funds through a defined window so there is something to reverse.
That is reasonable in principle, and frequently overstated when platforms apply it. If the client has explicitly accepted the work, the window should be short and it should be stated. Holding money against a dispute that has not been raised, and cannot be raised because acceptance closed it, is poor risk management.
The platform may earn money while you wait
The reason nobody puts plainly in the terms is float.
Money held on behalf of users sits in an account. That account earns interest. At meaningful volume and current rates, the interest on funds in transit is a material revenue line. It grows directly with how long the hold lasts.
This is standard across payments, legal, and usually disclosed somewhere in a document nobody reads. The issue is neutrality. The party that decides how long you wait for your money is the same party that earns more the longer you wait.
Once you know that, a lot of otherwise puzzling design decisions become easier to read. The default payout schedule is weekly rather than daily. Instant payout is a paid feature. The threshold before a payout triggers is set where it is. None of those numbers were chosen by a risk model.
A delay in payout is a working capital cost
Platforms discuss holds as a risk parameter. For a freelancer, the held money is working capital. That difference matters.
An independent worker earning through a platform has costs that arrive on their own schedule: rent, software subscriptions, tax set-asides, occasionally subcontractors. A predictable five-day gap between completing work and being paid is manageable. An unpredictable one, or one that extends when volume rises, forces them to hold a cash buffer.
That buffer means the freelancer is financing the platform’s risk management. It is real money with a real opportunity cost. It is also invisible in every comparison of platform fees, because it never appears as a fee.
For someone earning fifty thousand a year, a two-week average hold means roughly two thousand pounds of their money is permanently in someone else’s account. That does not happen once. It happens continuously, for as long as they use the platform.
A good hold changes with the actual risk
The alternative is to make the length of the hold reflect actual risk. A single policy applied to every transaction is easier to run, but it treats very different payments as if they carried the same exposure.
Four things drive real exposure, and all four are knowable at the moment of payment.
- Payment method. A settled bank transfer is different from a card payment. Treating them identically means the transfer users subsidise the card users.
- Account history. Both sides matter. A client with three years of completed engagements and no disputes is a different proposition from a new account.
- Transaction size relative to history. A job at twice the freelancer’s usual value is worth more scrutiny than one at their median.
- Whether acceptance was explicit. A client who actively approved deliverables has materially reduced the dispute probability. That should shorten the hold, and on most platforms it does not.
Combine those inputs, and most transactions between two established parties paying by transfer carry very little residual risk. Those should release in hours, not days. The remaining minority, new accounts and card payments and unusual sizes, carry the risk and should carry the hold.
Open Lance computes the hold for each transaction
On Open Lance, the hold is computed per transaction rather than set by policy. It uses exactly those four inputs. The result is shown to both parties at the point of agreement, before anyone commits, along with the reason it is what it is.
That last part was the hardest engineering decision, and it is the one we would defend most strongly. Showing the number in advance means it has to be defensible in advance. You cannot quietly extend a hold when cash flow is tight if you told the freelancer at the outset that it would be twenty-four hours.
We also do not sell instant payout. If the risk permits release, it releases. Charging someone to access money you have already determined is safe to release is charging for a delay you created.
The escrow model has to know exactly where the money is
None of this works unless the escrow is modelled properly. Escrow is the part of the system that holds money for the parties until the platform is allowed to release, refund or dispute it. This is the unglamorous half of the problem.
Funds move through defined states:
- authorised
- captured
- held
- releasable
- released
- refunded
- disputed
Every transition has a trigger, a permitted actor and an audit record. There is no path where money is in an ambiguous condition. There is also no state that can only be exited by a human clicking something.
The reason to care about this is that ambiguity is where holds get long. A platform whose escrow is a balance column and a set of cron jobs cannot compute a risk-based release, because it does not reliably know what state anything is in. A cron job is a scheduled background task. In this setting, it usually means a batch process that runs later and moves money according to a broad rule.
When the system cannot reliably answer what condition a payment is in, it applies a uniform hold because that is the only thing it can be confident about. The generous interpretation of long holds is that they are a symptom of weak modelling rather than deliberate float capture. In our experience, both are usually true at once.
Platforms have several reasons to leave holds alone
If risk-proportionate release is obviously better for users, the next issue is why it is so rare. There are three reasons, in descending order of how sympathetic they are.
The escrow model does not support it
Many platforms grew a payments system organically. Funds are a balance, movements are ledger rows, and state is inferred from a combination of timestamps and flags. You cannot compute a per-transaction risk release on top of that, because you cannot reliably answer what condition a given payment is in. A uniform hold is the only policy such a system can implement confidently.
Nobody is asking about the delay
Fee percentages are compared obsessively. Hold periods are compared much less, because they do not appear in a pricing table and their cost is invisible. A platform that halves its hold gets no marketing benefit, while one that adds a paid instant-payout feature gets a revenue line. Incentives point one way.
Float has become part of the forecast
At sufficient scale, interest on funds in transit stops being a rounding error and starts appearing in forecasts. Once a revenue line depends on average hold duration, shortening it requires someone to argue for less revenue. That argument rarely wins.
One published number would make holds easier to compare
None of this needs regulation to improve. It needs one number published, and platforms could do it tomorrow.
Publish the median time from client payment to funds available, per account cohort, updated monthly. Publish the measured outcome, including the tail, rather than the policy.
That single figure would do more for the market than any amount of fee comparison. It is the one cost that every freelancer bears, none of them can see, and all of them would factor into their choice if they could. A platform confident in its holds would publish it as a competitive advantage. A platform whose holds are longer than its risk requires would find reasons not to.
We publish ours. Because the hold is computed per transaction, the number exists and is defensible. A platform applying a uniform fourteen-day policy has a number too. It simply has less reason to show it.
The answers to four questions tell you a lot
Four questions are enough, and the answers are informative even when they are refusals.
- What is the median time from client payment to funds available to me, measured on my own account rather than quoted as a policy?
- Does the hold change based on payment method or account history? If not, why not?
- Who earns interest on funds in transit?
- Is instant payout a paid feature? If so, what risk assessment justified the delay it is bypassing?
That third question is the one that gets the least direct answers, and the reluctance is itself the answer.
This pattern appears wherever an intermediary controls timing
Holds are a specific case of something general: an intermediary sets a parameter that costs users money and benefits itself, with no external pressure to set it well. Payment terms in supply chains work the same way, as do settlement periods in card networks and clearing times in banking.
In each case the defence is risk. In each case the risk is real, but the number is larger than the risk requires, and the gap is revenue. The way to tell them apart is to ask whether the parameter varies with actual exposure or is applied uniformly. Uniform parameters are almost never about risk.
The full engineering behind our version, including the state model, is in the Open Lance case study.
