No headings found on page
crypto payments for igaming

TL;DR:

  • Float is a lag problem: every day of settlement delay adds roughly one peak day of redemption value to the cash you must keep idle.

  • Size on peak days and single-redemption tails, not on monthly averages, or you will breach on the first promotional weekend.

  • Provider-held prefunding stacks a second lag on top of the rail lag — the replenishment cycle — and usually earns you nothing.

  • Instant-settling rails can cut required float by 70–90% in a simple worked model because the in-flight window collapses toward zero.

  • Custody matters as much as speed: cash held in your own wallets stays on your balance sheet and outside your provider's insolvency estate.

Size your float as peak daily redemption value multiplied by settlement lag in days, plus a variance buffer for volume spikes and outsized single redemptions.

Sweepstakes casino redemption float requirements therefore scale with lag, not with revenue — and the balance should sit in wallets you control, not in your platform provider's prefunded account.

What exactly is redemption float, and why is it your problem?

Redemption float is the cash you cannot deploy because it is committed to prize redemptions that have been approved but not yet landed in the recipient's account. It is not a reserve against fraud, and it is not a rolling reserve held by an acquirer. It is working capital, parked, doing nothing.

The finance owner feels it in three places. First, as an opportunity cost on idle cash. Second, as a covenant or forecasting problem when the balance swings. Third, as counterparty exposure when someone else is holding it.

The reason float exists at all is that money leaves your control before it arrives in theirs. If a rail takes three business days to clear, you must fund day one, day two and day three simultaneously, because approvals keep arriving while yesterday's batch is still in transit. Float is the integral of your outflow over the settlement window.

How do you calculate the float you actually need?

Use a four-term model. Every input below is an illustrative assumption you should replace with your own data.

Term 1 — Peak daily redemption value

Assume 4,000 redemptions per week averaging $85. That is $340,000 per week, or $48,571 per average day. Now apply a peak factor: assume your busiest day runs 1.8× average, giving a peak day of roughly $87,000.

Term 2 — Settlement lag in days

Count calendar days to funds availability, not business days, because weekends queue. Assume ACH at three business days, which behaves like four calendar days across a Friday approval.

Term 3 — Variance buffer

Assume daily redemption value has a standard deviation of 25% of the mean, so σ ≈ $12,100. Over a three-day window, variance scales with the square root of time: σ × √3 ≈ $21,000. Hold two of those, so roughly $42,000.

Term 4 — Single-redemption tail

Assume your policy caps a single redemption at $10,000, and you see up to three in a peak week. Add $30,000, so one large winner does not drain the pool.

Put together for a three-day rail: (3 × $87,000) + $42,000 + $30,000 ≈ $333,000. That is close to a full week of redemption value sitting idle to service a business doing $340,000 a week in payouts.

Now run the same model at a lag of 0.25 days, which is what an intraday-topped-up wallet on an instant rail looks like: (0.25 × $87,000) + ($12,100 × √0.25 × 2) + $30,000 ≈ $64,000. Same volume, same variance assumptions, same tail policy. The only thing that changed is the lag.

At an assumed 10% cost of capital, the difference between $333,000 and $64,000 is about $27,000 a year in carry — before you count the operational cost of monitoring, sweeping and reconciling a larger balance.

How does settlement lag drive the number more than volume does?

Notice what the model does not care about. Doubling your redemption volume doubles the float. Halving your settlement lag also halves the in-flight component and shrinks the buffer by the square root of the reduction. Growth is expensive on a slow rail and cheap on a fast one.

This is why lag is the highest-leverage variable available to you. You cannot easily tell players to redeem less, and you should not want to. You can change the rail. Operators running on payment rails built for same-day settlement compress the in-flight window from days to hours, and the float falls out of the model automatically.

The second-order effect matters too. Long lags force you to hold buffer for uncertainty you cannot resolve in time — you are funding a decision you made three days ago against volume you cannot yet see.

Short lags let you fund against observed demand. That is the practical case for instant prize payouts on sweepstakes platforms: the treasury benefit is not just speed, it is the ability to fund reactively rather than predictively.

What do float requirements look like rail by rail?

Rail

Typical lag to availability

Float vs peak day

Main constraint

Push-to-card

Same day to next day

1.0–1.5×

Prefunded balance, issuer declines

ACH batch

2–4 business days

3.0–4.0×

Batch cutoffs, weekend queuing

Domestic wire

Same day if before cutoff

1.0–1.5×

Per-item fees, banking hours

Provider-held pool

Rail lag plus replenishment

4.0–6.0×

Minimum balance, no interest

Stablecoin wallet

Minutes

0.2–0.5×

On-chain liquidity, wallet ops

Read the third column as a multiple of your peak daily redemption value before variance buffer and single-redemption tail. Using the $87,000 peak day above, an ACH-only programme lands between $261,000 and $348,000 of in-flight cash; a stablecoin wallet lands between $17,000 and $44,000.

Push-to-card looks fast, and in terms of recipient experience it is. But the float does not disappear, it relocates: you are typically required to keep a funded balance with the processor ahead of the payouts, so you carry a prefunded pool even though the transaction itself is quick. Speed to the recipient and speed of your capital are two different measurements.

Wires are fast and clean but priced per item, which makes them viable for the tail of large redemptions and uneconomic for a $85 average ticket. Most operators end up using them selectively, which means maintaining a second funding path and a second reconciliation process.

The provider-held pool row is the one that surprises people, so it gets its own section.

Why does sweepstakes platform provider prefunding cost more working capital?

Sweepstakes platform provider prefunding stacks two lags where the rail only had one. You still bear the underlying rail lag, because the provider is paying out over the same networks you would use.

On top of that you bear the replenishment cycle: the time between your balance hitting a trigger threshold and your top-up landing in the provider's account.

Assume the provider requires a minimum balance equal to 1.5× your average weekly redemption value — $510,000 on our numbers — and replenishment takes two business days by ACH.

Your effective float is the minimum balance, plus the payouts in flight, plus enough headroom that you never dip below the minimum during the two-day top-up window. In practice operators find themselves holding four to six times peak day, not three.

Three further costs are easy to miss in the spreadsheet:

No yield, no control. The balance almost never earns interest for you, and you cannot sweep it overnight. On $510,000 at an assumed 10% cost of capital, that is roughly $51,000 a year of carry you are donating to a counterparty's banking relationship.

Credit and commingling exposure. If the pool sits in the provider's operating account rather than a segregated one, you are an unsecured creditor for your own prize money. Ask where the account is held, whose name is on it, whether it is segregated, and what happens to it in an insolvency. Get the answer in writing.

Reconciliation drag. You are now reconciling three ledgers — your own approvals, the provider's pool statement and the rail's settlement file. Every additional ledger is an additional place for a break to hide, and breaks are what turn a float question into an audit question.

None of this means providers are acting badly. Prefunding exists because the provider is taking settlement risk on your behalf and wants to be covered. The point is that the coverage is paid for with your working capital, and it is usually cheaper to remove the risk than to collateralise it.

Before you renegotiate a buffer, model your float against LightningPay's settlement times and see whether the buffer is still necessary at all.

How should you structure redemption treasury management day to day?

Good redemption treasury management in iGaming looks less like forecasting and more like inventory control. You are managing a working balance with a reorder point, a reorder quantity and a lead time.

Set a floor equal to your peak day plus variance buffer plus tail allowance. Set a trigger above the floor by one replenishment lead time of expected outflow. Sweep everything above the trigger back to your main treasury account daily, so idle cash does not accumulate by accident.

Then instrument it. Track four numbers weekly: actual peak day versus your assumed peak factor, realised σ of daily redemption value, count and size of tail redemptions, and observed time-to-availability by rail. Every one of those is an input to the model above, and every one drifts as your player mix changes.

Re-run the model monthly. Operators who set float once at launch are usually 30–50% over-funded within two quarters, or badly under-funded after a single successful promotion — and they only discover which when a redemption queue stalls.

How do stablecoin rails change the math?

Stablecoin float payouts give operators the shortest lag currently available on a general-purpose rail, and that shows up directly in the float term. When settlement is measured in minutes, the in-flight component of the model collapses toward zero and the variance buffer shrinks with it, because you are topping up against demand you have already observed rather than demand you guessed at three days ago.

The custody change is the second benefit and arguably the larger one. In a non-custodial arrangement, the balance stays in a wallet you control until the moment it pays out. It remains your asset on your balance sheet, it is not commingled with a provider's operating cash, and it is not exposed to a provider's creditors.

Be honest about what replaces the old costs. You now need wallet operations: key management, signing policy, address whitelisting, on-chain fee monitoring and a documented process for handling a failed or misdirected transfer. You also need a clear internal position on which asset you hold and how you account for it. These are real obligations, but they are operational and controllable, whereas provider-held prefunding is a capital cost you cannot manage down.

Final thoughts

Float is not a fixed cost of running a sweepstakes programme; it is the output of two variables you can negotiate — how long money spends in transit, and who holds it while it does.

Most operators attack the wrong one, spending months negotiating a smaller minimum balance with a provider when shortening the settlement window would have removed the need for the balance entirely.

The arithmetic is unsentimental: a rail that settles in minutes needs a fraction of the parked capital that a three-day rail needs, and a wallet you control does not expose that capital to anyone else's creditors.

Treat lag reduction as a treasury project with a measurable return, not an integration preference, and the buffer conversation becomes largely redundant.

If you own the treasury line, that is the cheapest structural improvement on your desk this year — speak to LightningPay about non-custodial payout treasury before you commit to another prefunding schedule.

Frequently Asked Questions

How much float do I need for sweepstakes redemptions?

Should my platform provider hold the prefunded balance?

Why size float on peak days instead of monthly averages?

Does faster settlement reduce the variance buffer as well as the in-flight balance?

What should I monitor to keep float sized correctly over time?

Power your payments & payouts with LightningPay

Accept Bitcoin and stablecoins, enable instant withdrawals, and deliver better player experiences with infrastructure built for iGaming.

Trusted & Certified

SOC2 Type 2

PCI-DSS

ISO 27001

KYC/AML

Power your payments & payouts with LightningPay

Accept Bitcoin and stablecoins, enable instant withdrawals, and deliver better player experiences with infrastructure built for iGaming.

Trusted & Certified

SOC2 Type 2

PCI-DSS

ISO 27001

KYC/AML

Power your payments & payouts with LightningPay

Accept Bitcoin and stablecoins, enable instant withdrawals, and deliver better player experiences with infrastructure built for iGaming.

Trusted & Certified

SOC2 Type 2

PCI-DSS

ISO 27001

KYC/AML