Choosing a stablecoin on/off-ramp partner

An on/off-ramp fits in a sentence: fiat goes in, a stablecoin comes out, and the process runs in reverse on redemption. The operating model behind that sentence contains a dozen decisions a payments business has to make before it can compare providers at all.

Who receives the fiat? Who converts it, and at what price? Where does the liquidity come from? Who holds the stablecoin between one customer instruction and the next? How quickly can a larger conversion settle, and what does "quickly" become at ten times the usual ticket? What data comes back to treasury and finance? Which regulated entity performs each step?

"On/off-ramp" is a label that covers several different bundles of these services. Two providers can both call themselves an on/off-ramp provider and be offering materially different things, one a bank-connected payment product with conversion attached, the other a market counterparty that expects the fintech to bring its own fiat rail. Comparing them on a rate card before mapping the flow is how procurement signs for the wrong thing.

Map the responsibilities before comparing providers

The flow separates into five parts, and it helps to draw them before reading a single proposal.

The customer and payment layer is the fintech's own product: the customer relationship, the account ledger, the experience of initiating a conversion or redemption. This normally stays with the fintech whatever else is outsourced.

The fiat rail receives and pays out conventional currency through banking or payment infrastructure. It needs an entity with the right permissions to hold client money and move it, and it needs the payment schemes the product promises.

Conversion and market activity take the fiat-to-stablecoin (or stablecoin-to-fiat) requirement to the digital-asset market and bring back the other side.

Custody is where the stablecoin sits between flows, and how each client's entitlement is recorded while it sits there.

Post-trade covers settlement status, reporting, reconciliation, and the records that operations, finance, and compliance need afterwards.

A single provider may cover several of these. Nothing requires it to. A workable architecture has one banking partner running the fiat rail, a separate market counterparty running conversion and custody, and the fintech's own systems stitching them together. Sophisticated buyers evaluate both shapes side by side, and the right answer depends on existing banking relationships, the fintech's licence, and how much integration it is willing to own.

A market-side counterparty covers conversion, liquidity, custody, and reporting, and does not provide the fiat rail; the fintech brings or arranges its own through an appropriately authorised payment provider. Knowing which side of that line each candidate sits on is the first filter.

Conversion model changes what the price means

Once the map is drawn, the market side is where the least visible differences between providers live.

A provider can perform a conversion in several ways. It can execute against the market as agent on the client's behalf. It can act as principal, quoting its own price and holding the resulting position on its own book. Where the stablecoin issuer allows it, a provider can route through the issuer's mint and redeem process at par. Many providers combine these depending on size, token, and time of day.

None of these is wrong. Each shapes the price differently. A principal quote bundles the provider's margin and risk into the rate, simple for small tickets and opaque for large ones. Issuer mint and redeem is clean for supported tokens but depends on the issuer's cut-off times and minimums. Agency execution makes the market price and the provider's fee visible as separate numbers, and puts the provider on the same side of the trade as the client.

The question a buyer should put in writing is: how is the provider paid, and can we distinguish the market price from the provider's fee on every transaction? The answer tells you more than any pricing page. Aplo's model, for reference, is agency execution against the market with the fee agreed and stated separately, and no proprietary trading book. Whichever model a provider runs, what matters at procurement stage is that the buyer can see and evidence the result. The evidence a provider should be able to produce is set out in best execution in crypto: what institutions should ask.

Settlement speed only matters at the size you actually need

Every provider says conversion is fast. The useful questions are about the shape of "fast" under conditions that are not the demo.

Typical performance is the easy one: under normal conditions, for a routine ticket, how long between instruction and settled stablecoin (or settled fiat on the way out)? Worst-case performance matters more. What happens when a venue is degraded, when a stablecoin is trading away from par, when the fiat rail is closed, or when a compliance hold is triggered mid-flow? Availability is the third question: if the product promises weekend or overnight conversion, does every step in the chain, including the fiat leg, operate at those hours, or only the market leg?

Then capacity. At what ticket size does the experience change from streamed price to worked order, and what does the settlement time become at that size? A provider that settles a routine ticket in minutes and a large one over a day is describing a liquidity constraint the buyer needs to design around.

Which brings the conversation to liquidity itself. Stablecoin liquidity is uneven by token, by currency, and by venue. USD-denominated tokens are deep on most venues; EUR-denominated tokens are thinner and more fragmented, and the depth a provider can actually execute against is smaller than the depth visible on a screen. There is a longer discussion of why crypto liquidity remains fragmented across venues and why "we handle execution" does not settle the question.

A buyer should ask which stablecoins and fiat currencies are supported, what executable depth exists in each pair at the sizes the product needs, and what the largest ticket is that can be handled at streamed price rather than worked. A capability is only useful at the size and frequency the product requires, and a provider that answers with a number and a caveat is more credible than one that answers with "yes".

Custody and reconciliation sit inside the flow

For a payments business, custody is rarely a static holding. Stablecoins arrive from a conversion, wait for an outgoing instruction, and leave again, sometimes within the hour. That makes the custody questions operational rather than only prudential.

Where are the assets held, and in what structure? A provider may hold client assets in pooled omnibus wallets with each client's entitlement recorded in an internal sub-ledger, or in dedicated on-chain wallets per client, or offer both. These are different things and should not be conflated: "segregated" in a provider's documentation may mean segregation at the books-and-records level rather than a separate address, and the buyer should ask which. A common structure is pooled omnibus wallets with a real-time sub-ledger recording each client's entitlement, sometimes with dedicated wallets as an option; the buyer should ask which structure applies and how reconciliation runs between the sub-ledger and on-chain balances, and how often.

How does the trading balance relate to the custody balance? If conversion and custody sit with the same provider, an asset can move from settled trade to custodied balance without an on-chain transfer, which reduces movements and the reconciliation breaks that come with them. If they sit with different providers, every conversion produces a transfer that has to be tracked across two systems.

Can operations tell, at any moment, whether a given balance is available, reserved against an order, executed but unsettled, or in transit? That state model is what lets a fintech promise its own customers a settlement time with confidence. The custody model that fits the working day walks through omnibus and dedicated arrangements, segregation, and how custody interacts with execution across a normal operating day, and is a useful frame for the questions to ask.

The API has to survive operations

Most on-ramp API discussions stop at "can we initiate a conversion programmatically". That is the first of seven questions, and the least likely to expose a weak provider.

Status comes second: can the fintech's systems query where a transaction currently sits, in enough granularity to drive a customer-facing state? Callbacks or events come third: can internal systems react to a settlement, a partial fill, a rejection, or a compliance hold without polling? Reporting is fourth: can every transaction be traced back to the underlying customer or treasury instruction that caused it, with venue-level fill detail where the conversion was routed? Reconciliation follows: can operations and finance close the day from the provider's data, or will they rebuild it in a spreadsheet? Testing: is there a sandbox that behaves like production, including the failure states? And support: when a transaction is stuck at 17:45 on a Friday, who owns the next action, and is that a named person or a queue?

The buyer should also confirm which chains and token contracts the provider supports, and on what basis new ones are added. Transaction-level reporting with venue-level fills on routed orders is a reasonable baseline to expect; the rest of this list is what a fintech should put to every candidate in the same words.

Regulatory scope depends on who does what

An EMI evaluating an on/off-ramp should not assume its existing permissions cover every service in the flow.

MiCA Article 60(4) gives an e-money institution a notification route, rather than a separate CASP authorisation, for custody and administration and for transfer services, but only with regard to the e-money tokens it issues. Exchanging crypto-assets for funds, executing orders on behalf of clients, and holding tokens issued by someone else are separate crypto-asset services under Article 3(1)(16), and the EMI route in Article 60 does not extend to them. So the division of responsibilities drawn earlier is also a regulatory map: for each function, which entity is authorised to perform it, in which jurisdiction, for which clients.

The precise setup depends on the entities, permissions, jurisdictions, and services involved, and this is a question for counsel rather than for a provider's sales deck. What a buyer can do at procurement stage is confirm that the market-side counterparty holds the authorisations for the services it is providing, and verify them on the relevant registers, the AMF white list and ESMA's register in the EU, rather than in the provider's own material. Aplo SAS, for its part, holds MiCA CASP authorisation from the AMF in France with passporting requested to seven further EU markets.

Compare the whole commercial model

A conversion rate on its own explains almost nothing about what the flow will cost.

The full picture includes the provider's explicit fee; any spread embedded in the rate; the cost of the fiat leg, which may sit with a different provider; custody charges where assets are held between flows; network or transfer costs where on-chain movements are involved; minimums; and how each of those changes with volume or ticket size. Sophisticated buyers ask for a complete breakdown of every cost in the chain, and a provider that cannot produce one is telling you something about how it thinks about its own margin.

A fee-based agency model is not automatically cheaper than a spread-based one. It is more explicit, which is a different claim and the one that can be supported. When the market price and the provider's fee are separate numbers on every transaction, the fintech can price its own product knowing which part of the cost moves with the market and which part it has negotiated, and it can compare providers on the negotiated part without arguing about what the market price was at the time.

Start from the flow, not the rate card

The fintech that gets this right writes down its own flow first: which entity holds fiat, which converts, which custodies, which reports, and which is licensed for each. Then it puts the same questions to every candidate and compares the answers rather than the brochures. Those questions separate a provider that will still work at three times the volume from one that looked fine in the demo.

If you are mapping that flow now and want to understand the market-side model, speak to us.