Every payout has a waiting room: the hours or days between "we decided to pay" and "they have the money." Nothing about that gap shows up as a line on the invoice, which is why it's easy to underprice. But treasury teams know what lives in it — rate drift, cash parked in advance, and a steady drip of reconciliation work. This piece reads that waiting room like a statement, line by line, and shows which lines shrink when payouts settle in minutes on a stablecoin rail — and which lines stay exactly where they were.
Illustrative numbers, stated assumptions. Every figure below is a worked example with its assumptions printed next to it — not a benchmark, a client result, or a market statistic. Swap in your own volumes, corridors and cost of capital; the shape of the argument is what carries over.
Line 1 — The waiting room: Settlement lag is an open position
When a payment takes three days to land, you're not just waiting. For those three days you carry a commitment — an amount promised to someone — against assets that are still moving: a currency pair, a cash balance, a balance in a stablecoin. Treasury calls that an open position, and the part of it that comes from time alone is the part a faster rail attacks.
The useful rule of thumb is short. If a rate moves randomly, the size of a typical swing doesn't grow in proportion to time — it grows with the square root of time. Triple the waiting period and the typical swing grows by about 1.7, not 3. That's why the first hours of a delay matter less than they feel like, and why compressing days into minutes removes most of the exposure rather than just a fraction of it.
Line 2 — FX drift: What three days costs, in dollars
Take a payout run of $400,000 in which the amount was promised at one moment and the conversion rate gets fixed at another. Assume the relevant pair moves about 0.5% on a typical day (a round number for a major pair — use your own) and treat time as continuous. The typical one-standard-deviation swing over the waiting window then looks like this:
Two honest caveats before anyone quotes that table. First, 1σ is a width, not an expected loss: a random walk has no built-in direction, so the number describes how wide your outcomes are, not what you'll lose on average. Second, the table treats the clock as running around the clock; real currency markets pause, which makes weekends and holidays worse than the smooth curve — the exposure is stuck open while nobody can trade out of it.
Faster settlement moves the FX risk — it doesn't delete it. If you pay in a dollar-pegged stablecoin, the dollar value of the payout is fixed when you send it. But someone who needs local currency still has to convert, and now it's the recipient (or an off-ramp partner) who carries the rate risk until they do. What you gain is a short, controllable window on your side of the trade and the freedom to price payouts in dollars. What you don't gain is a world without currencies.
Line 3 — Trapped cash: The balance that sits there for nothing
Slow rails need pre-funding: money positioned in advance, in the right account, in the right place, so that a payout can leave when it's due. That working balance earns nothing for the payout itself. As a worked example, say a payments team holds a $250,000 buffer across corridors, and its cost of capital is 5% a year. The buffer costs about $12,500 a year to keep — before counting the time spent topping up the wrong account on a Thursday.
A rail that settles in minutes changes the shape of that buffer, not just its size. Instead of liquidity pinned in several places "just in case," a single operating balance can fund a run when it's approved and be back to work afterwards. The saving is real only if the whole run actually moves that way, which is the reason to move one corridor first and measure rather than argue about it in the abstract.
Treasury risk is mostly the cost of waiting — and waiting is the one input a rail can change. (A rule of thumb, not a quote.)
Line 4 — The ops tax: Cutoffs, weekends, and the Tuesday email
The hardest line to price is the one that lives in other people's inboxes. Picture a marketplace that pays its sellers every Friday — a composite scenario, not a real client. Bank cutoff passes at the end of the afternoon; the batch is queued; the money lands Tuesday. Over the weekend sellers write in asking where it is, a handful of payments bounce on a mistyped detail, and finance spends Monday matching returns to the original batch.
None of that is a failure in the ordinary sense — it's the rail working as designed. A network that never closes removes the cutoff and the weekend as variables: a payout sent on Friday evening is a payout that can be confirmed on Friday evening. Failures don't vanish — an address typed wrong is a different kind of problem, and a harder one to reverse — but they become visible within minutes, while there's still a person at their desk to fix them.
Statement — before and after: Same payout run, two rails
Put the four lines side by side and the picture is less "one rail is better" than "the costs move to different places":
Footnotes to the statement: What doesn't go away
A statement that only lists savings is an advertisement. The lines that stay, or appear, when you move payouts on-chain:
- Stablecoin risk. A dollar-pegged asset is a claim on an issuer and a reserve, and pegs can wobble. The practical controls are boring ones: choose the stablecoin and network deliberately, and keep the time funds spend in the token short — which is the same habit that makes instant settlement worth having.
- The last mile. Recipients need somewhere to receive and a way to turn the funds into spendable local money. If their off-ramp costs more than the delay you removed, you've optimised the wrong end.
- Irreversibility. A transfer sent to the wrong address isn't returned by a clearing house. Address validation, a small test payment for a new payee, and a duplicate policy for your recipient list belong in the process from the first run.
- Compliance. Screening, sanctions checks and Travel Rule obligations apply to payouts too. Your program stays yours; the KYC & AML guide covers who owns which part.
- Accounting and tax. Treatment of stablecoin balances and payouts varies by jurisdiction. Confirm it with your advisers before the first run, not after the first quarter-end.
The run — one payout, four calls: How a Multisend payout works in CPAY
Mechanically, a payout run is a list of addresses and amounts. In the CPAY dashboard, Multisend takes that list pasted in, or uploaded as a CSV, and gives you a say in what happens to duplicate addresses: keep the first, merge balances into one amount, or keep every duplicate. The system sends one transaction for every 200 addresses — a run of 1,000 recipients becomes five transactions — and estimates the fees before anything leaves the wallet.
The API follows the same four steps: estimate the system fee, approve the contract if this token hasn't been approved, estimate the network fee, then send. The two steps that move funds take an Idempotency-Key header, which is what you want on a payout: if a connection drops and you retry, the same key can't produce a second payment.
Two practical notes. In the dashboard, the final confirmation asks for 2FA; over the API, the request body carries the wallet password or a base64 signature, depending on how the wallet is protected. And if a payout is part of a treasury routine rather than a one-off, the account's auto-swap rules can convert incoming funds into the currency you pay out from once a minimum amount arrives — one less manual step between "money arrived" and "run approved."
Decision — who moves first: Start with one corridor, not the whole ledger
The sensible move is rarely "switch every payout." It's one corridor, measured against its own baseline. A short way to choose:
- Move first where recipients already hold or want stablecoins — contractors, sellers, creators, partners who are crypto-native or paid across borders.
- Move first where the bank route is slowest or most cutoff-bound, so the waiting-room lines are fattest.
- Move first where you're pre-funding the most — that's where the trapped-cash line pays back soonest.
- Keep the bank rail where recipients can't realistically receive crypto, where payroll rules require bank transfers, or where the recipient's off-ramp cost would eat the saving.
- Measure three things from the pilot: time from approval to confirmed receipt, total cost per payout including off-ramp, and the number of "where's my money" tickets. That's the statement you'll show finance.
FAQ — Common follow-ups
Does paying in stablecoins remove FX risk?
It shortens and relocates it. On your side the payout is fixed in dollar terms at the moment you send, so the days-long window disappears. The recipient, or an off-ramp partner, carries any rate move until the funds are converted into local currency. Whether that's a good trade depends on who is better placed to hold the risk — often the answer is the party that can convert fastest.
How fast is "instant," really?
Minutes rather than banking days is the honest framing. The exact figure depends on the network you use and how many confirmations you wait for, and it moves with congestion. Time a few runs on the networks you plan to use rather than relying on a headline number.
What if a payout goes to the wrong address?
On-chain transfers are final — there is no clearing house to recall them. Build the prevention into the process: validate addresses before a run, send a small test payment to any new payee, use the duplicate-handling options in Multisend deliberately, and keep the idempotency key unique per run so a retry can't double-send.
What about stablecoin de-pegging?
It is a real risk and the reason to keep the time funds sit in the token short. Choose the stablecoin and network on purpose, avoid holding balances longer than the run needs, and have a written answer for what you'd do if a peg moved during a payout window. Instant settlement helps here too: less time in the asset means less time exposed to it.
Do recipients need to complete KYC?
Your compliance program decides what you need to know about recipients and which checks apply to each payout. The rail supplies screening and monitoring tools; the policy and the accountability stay with you. Agree the process with your compliance lead before the pilot, not after it.
Ready to try a first payout? The Multisend API documentation has the full reference, and the CPAY team is a call away.
Sources: CPAY Documentation — Multisend, Using API for multisend.
