Why Two Identical Treasuries Grow Into Different Companies
Two businesses can look almost identical on paper: similar revenue, similar treasury setup, both holding crypto and periodically converting part of it into fiat for payroll, supplier invoices or partner settlements.
For the first few months, there may be no visible difference between them. The divergence starts later, with a number neither business considered strategic at the beginning: how much its chosen rail can actually move when an obligation becomes larger than usual.
The Quiet Fork Nobody Flags In A Kickoff
The first company chooses an off-ramp that handles its current volumes comfortably. There is a transfer ceiling, but routine payments sit well below it, so nobody treats the limit as an operational issue.
The second company plans around its largest realistic obligation instead of its average transaction. At six months, both approaches work equally well because neither business is regularly testing the upper end of its infrastructure.
That makes transfer capacity easy to ignore. The rail works, payments clear and the treasury moves on to more immediate problems.
What Twelve Months Of Routine Actually Exposes
By month twelve, larger obligations start appearing. A bigger supplier invoice, a quarterly settlement, or several expenses landing at once can push a payment above the normal range.
The first company uses the obvious workaround and splits the conversion across several transfers or several days. The payment still gets completed, but each leg can execute at a different rate, requires separate reconciliation, and leaves the business exposed to market movement for longer. The second company can process the same type of obligation as one treasury event.
The difference is no longer simply a technical limit; it begins affecting execution, timing and operational workload.
How A Workaround Becomes A Payout Policy
By month twenty-four, repeated workarounds start becoming part of the process. Larger obligations are scheduled earlier, finance knows which payments need to be divided, and extra time is built into settlement planning.
Nobody necessarily made a formal decision to operate this way. The business simply adapted to what its infrastructure could handle until the rail’s ceiling became part of the treasury calendar.
That is how a technical parameter becomes an operating constraint. The business starts shaping payments around the infrastructure instead of using infrastructure sized around the payments it actually needs to make.
How The Three Ramp Models Compare
The useful comparison is not simply which provider supports crypto-to-fiat conversion. Their public product pages point to different operating models and different questions treasury teams should ask.
Get Paul Bennett’s stories in your inbox
Join Medium for free to get updates from this writer.
Kraken Ramp — Embedded On/Off-Ramp Infrastructure
- Scale: 400+ assets across 100+ blockchains, supported by a broader platform serving more than 9 million clients across 190 countries.
- Rails: 24+ payment methods, including SEPA, ACH, cards, PIX, Apple Pay and Google Pay.
- Compliance: regulated infrastructure is combined with API and SDK integration for businesses embedding the ramp into their own products.
- Limits: the public Ramp page does not publish a directly comparable large-business transfer ceiling.
WhiteBIT On/Off-Ramp — Business And Institutional Fiat-Crypto Flows
- Scale: 90+ EUR pairs, 900+ trading pairs, more than $3.4T in annual trading volume and 5,500+ institutional clients.
- Rails: SEPA for EUR, alongside other listed fiat rails, with a €5 fixed fee for euro deposits and withdrawals.
- Compliance: KYB and Source of Funds documentation form part of the onboarding flow for higher limits.
- Limits: standard deposit and withdrawal limits can reach €100,000 per day, with custom limits available depending on the client’s KYB level.
Stripe Crypto Onramp — Embedded Customer Conversion
- Scale: built on Stripe’s wider payments infrastructure and fraud models trained on signals from trillions of transactions.
- Rails: cards, Apple Pay, Google Pay, Instant ACH and regular ACH, with settlement speed varying by payment method.
- Compliance: KYC, sanctions screening, fraud prevention, and disputes are handled inside the product, with Stripe acting as merchant of record.
- Limits: the public Crypto Onramp page does not publish a directly comparable treasury-sized transfer ceiling.
The distinction matters because these products are built around different transaction patterns. One publishes concrete parameters around larger business fiat flows, while the others put more emphasis on embedded ramp coverage, payment methods, and customer conversion infrastructure.
The Cost Starts Before The Transfer Is Split
Splitting a payment creates more than additional transaction steps. A €90,000 obligation executed once has one conversion point and one reconciliation event; the same obligation divided into three legs creates three execution prices and a longer period during which the market can move.
Over time, the treasury has to plan around that uncertainty. Teams start converting earlier, allowing more time before deadlines and building additional checks into larger payouts.
The real cost is therefore not only fees or visible slippage. It is the extra operating logic that grows around a constraint nobody originally intended to become part of the process.
The Constraint That Quietly Compounds
At six months, a transfer ceiling can look irrelevant. At twelve months, it starts producing workarounds. By twenty-four months, those workarounds can become part of the company’s normal payout process.
Larger capacity can require more preparation upfront, including business verification and Source of Funds checks. That is easier to handle during onboarding than when a large payment is already approaching its deadline.
For treasury teams, the useful question is therefore not only whether a rail supports crypto-to-fiat conversion. It is whether that rail can handle the largest realistic obligation the business expects to make, and what needs to be approved in advance to make that possible.
A transfer cap remains a technical detail only until the company starts organizing itself around it. After that, it became a policy.
Disclaimer: This is not financial or investment advice. Do your own research before making any decisions. Use at your own risk.
