Technical guide · For PSPs, EMIs & payout platforms
Stablecoin settlement architectures: custodial vs non-custodial
On fiat rails, custody is implicit — banks hold the money at every hop and you never choose who. On stablecoin rails, custody becomes an explicit design decision per leg. That choice sets your counterparty exposure, compliance perimeter, working-capital footprint, and what happens when something breaks. Below: the operator-level comparison, and how to measure the difference on your own corridors before committing.
The short version
A custodial architecture buys you speed. One provider holds the keys, runs the chain plumbing, and hands you a single API and a single reconciliation feed. The cost is concentration: your balances, your corridor coverage, and your uptime all sit behind one counterparty, and a freeze or outage there stalls the whole flow.
A non-custodial architecture buys you control and unbundled economics. You choose the asset, the chain, the liquidity venue, and the off-ramp per corridor, and every leg is directly observable against your own addresses. The cost is operational surface — key management, signing policy, gas funding, monitoring — plus a compliance perimeter that may now include you.
The decision is rarely global. It is made per corridor, per ticket size, and per beneficiary type — which is why comparing two providers on a rate card tells you very little about which architecture your flows should actually run on.
Side-by-side, on the dimensions that matter
| Dimension | Custodial | Non-custodial |
|---|---|---|
| Who holds the keys | The provider. Balances sit in provider-controlled wallets or omnibus accounts; you hold a claim on the provider, not the asset. | You do — via your own wallet infrastructure, an MPC/HSM setup, or a qualified custodian you contract directly. The provider signs nothing on your behalf. |
| Counterparty exposure | Your working capital is exposed to the provider's solvency, banking partners, and freeze events. In-flight and idle balances are both at risk. | Exposure is limited to the transaction window at each on/off-ramp. Idle balances stay under your control between payouts. |
| Operational surface | Lowest. One API, one contract, one reconciliation feed. Chain selection, gas, nonce management, and rebalancing are the provider's problem. | Highest. Key management, signing policy, gas funding, chain upgrades, address allowlisting, and on-chain monitoring become yours to run. |
| Speed to first payout | Weeks. Onboarding, KYB, and an API integration. Fastest path to a live corridor. | Months. Wallet architecture, signing controls, treasury policy, and security review land before the first production payout. |
| Failure surface | Provider-level: outage, liquidity gap, corridor suspension, account freeze. When the provider stalls, the whole corridor stalls and you have no fallback path. | Component-level: a chain congests, an off-ramp throttles, a signing service degrades. Failures are narrower and individually routable around. |
| Route flexibility | Constrained to the provider's supported assets, chains, and payout rails. Switching architecture means re-integrating. | Assets, chains, liquidity venues, and off-ramps are chosen per corridor and swappable without re-platforming. |
| Compliance posture | The provider is the regulated actor on the crypto leg and typically the Travel Rule originator. Your obligations concentrate at onboarding and monitoring; evidence lives in their systems. | You may be the VASP or the obliged entity depending on jurisdiction and flow shape. Travel Rule messaging, screening, and address risk are yours to implement or contract for. |
| Working capital | Often pre-funded with the provider to guarantee payout speed — reproducing the nostro problem in a new form. | Capital sits on your balance sheet or on-chain and is deployed per payout. Lower trapped float, higher treasury workload. |
| Auditability | Provider statements plus whatever on-chain references they expose. Cost attribution per transaction is often bundled. | Every leg is directly observable on-chain against your own addresses. Per-transaction cost and latency attribution is exact. |
| Cost shape | Blended per-transaction fee plus FX spread. Simple to forecast, harder to decompose or negotiate line by line. | Unbundled: gas, liquidity spread, off-ramp fee, custody/signing cost. Harder to forecast, easier to optimise once measured. |
Who holds the keys
Custodial
The provider. Balances sit in provider-controlled wallets or omnibus accounts; you hold a claim on the provider, not the asset.
Non-custodial
You do — via your own wallet infrastructure, an MPC/HSM setup, or a qualified custodian you contract directly. The provider signs nothing on your behalf.
Counterparty exposure
Custodial
Your working capital is exposed to the provider's solvency, banking partners, and freeze events. In-flight and idle balances are both at risk.
Non-custodial
Exposure is limited to the transaction window at each on/off-ramp. Idle balances stay under your control between payouts.
Operational surface
Custodial
Lowest. One API, one contract, one reconciliation feed. Chain selection, gas, nonce management, and rebalancing are the provider's problem.
Non-custodial
Highest. Key management, signing policy, gas funding, chain upgrades, address allowlisting, and on-chain monitoring become yours to run.
Speed to first payout
Custodial
Weeks. Onboarding, KYB, and an API integration. Fastest path to a live corridor.
Non-custodial
Months. Wallet architecture, signing controls, treasury policy, and security review land before the first production payout.
Failure surface
Custodial
Provider-level: outage, liquidity gap, corridor suspension, account freeze. When the provider stalls, the whole corridor stalls and you have no fallback path.
Non-custodial
Component-level: a chain congests, an off-ramp throttles, a signing service degrades. Failures are narrower and individually routable around.
Route flexibility
Custodial
Constrained to the provider's supported assets, chains, and payout rails. Switching architecture means re-integrating.
Non-custodial
Assets, chains, liquidity venues, and off-ramps are chosen per corridor and swappable without re-platforming.
Compliance posture
Custodial
The provider is the regulated actor on the crypto leg and typically the Travel Rule originator. Your obligations concentrate at onboarding and monitoring; evidence lives in their systems.
Non-custodial
You may be the VASP or the obliged entity depending on jurisdiction and flow shape. Travel Rule messaging, screening, and address risk are yours to implement or contract for.
Working capital
Custodial
Often pre-funded with the provider to guarantee payout speed — reproducing the nostro problem in a new form.
Non-custodial
Capital sits on your balance sheet or on-chain and is deployed per payout. Lower trapped float, higher treasury workload.
Auditability
Custodial
Provider statements plus whatever on-chain references they expose. Cost attribution per transaction is often bundled.
Non-custodial
Every leg is directly observable on-chain against your own addresses. Per-transaction cost and latency attribution is exact.
Cost shape
Custodial
Blended per-transaction fee plus FX spread. Simple to forecast, harder to decompose or negotiate line by line.
Non-custodial
Unbundled: gas, liquidity spread, off-ramp fee, custody/signing cost. Harder to forecast, easier to optimise once measured.
Most production setups are hybrid
Framing this as a binary is the most common mistake. Custody is chosen per leg, and the legs of a single payout can differ. Common shapes we see in real corridor maps:
- Custodial on the on-ramp leg, non-custodial for the settlement asset between legs — provider takes fiat-in risk, you keep control of idle balances.
- Non-custodial treasury with a custodial off-ramp per destination market, chosen per corridor rather than globally.
- Delegated signing: you own the keys, a provider holds a policy-bound co-signer so payouts do not depend on one team being awake.
- Dual-path corridors: a custodial provider as the primary route with a non-custodial fallback that only activates on provider degradation.
What decides it: evidence, not architecture preference
Both models work. What differs is how they behave under your traffic — your corridors, your ticket distribution, your beneficiary types, your compliance perimeter. These are the datapoints that actually settle the argument:
- Landed cost per payout, decomposed into gas, spread, provider fee, and FX — not a blended rate card.
- Time to beneficiary credit at p50, p95, and p99, split by leg so you can see which architecture actually loses the time.
- Failure and retry behaviour under real traffic: throttles, screening holds, and how each architecture recovers.
- Working-capital requirement per corridor, including pre-funding demanded by custodial providers.
- Compliance coverage: Travel Rule counterparty reach, screening depth, and who is the obliged entity on each leg.
Bearing independently assesses the architecture decision using the current setup, realistic alternatives and the evidence available for the flow. We do not hold funds or sell a rail. Targeted provider or technical checks are used where needed and feasible, with optional shadow-mode or controlled testing subject to access and scope. The recommendation distinguishes documented facts, estimates and unresolved questions before you commit.
Related reading
Deciding this for your own flow?
Bearing assesses one real payment-infrastructure decision — architecture, providers, feasibility, economics and trade-offs — and documents a recommendation with the evidence behind it. The fixed launch fee is US$1,500 for your current setup and up to two alternatives, including a written recommendation and a readout.
Compare architectures on your own corridors
Tell us the corridors, ticket sizes, and beneficiary types you're evaluating. We will discuss whether a focused architecture assessment would be useful and what evidence is available. Any targeted checks or optional testing depend on the decision, provider access and scope.
Frequently asked questions
What is the difference between custodial and non-custodial stablecoin payments?+
In a custodial architecture a provider holds the keys and the balances; you hold a claim on the provider and integrate a single API. In a non-custodial architecture you (or a custodian you contract directly) hold the keys, and the provider only performs specific functions such as an on-ramp or an off-ramp. The trade is operational simplicity and provider concentration risk against control, unbundled cost, and a much larger operational surface.
Which model is better for a PSP or payout platform?+
Neither is better in the abstract. Custodial usually wins for a first corridor, low volume, or a small operations team. Non-custodial starts to win as volume grows, as trapped pre-funding gets expensive, or when a single provider's coverage no longer matches your corridor map. Most mature operators end up hybrid — custodial on some legs, non-custodial on others, chosen per corridor.
Does non-custodial mean we become a VASP?+
Sometimes, and it depends on jurisdiction, flow shape, and whether you are handling third-party funds. Self-custody of your own treasury is a different question from holding stablecoins on behalf of customers. Treat classification as a legal question to resolve early — it changes licensing, Travel Rule obligations, and which architectures are even open to you.
How do these architectures differ from traditional fiat rails?+
On a correspondent-banking flow, custody is implicit: banks hold the money at every hop and you never choose who. On stablecoin rails, custody becomes an explicit design decision you make per leg. That is the real architectural change — not the speed. It is also why two providers quoting similar fees can carry completely different risk and working-capital profiles.
How does Bearing help choose between them?+
Bearing independently assesses one architecture decision, comparing the current setup with realistic custodial, non-custodial and hybrid alternatives using available evidence. Targeted provider or technical checks are used where needed and feasible. The recommendation separates documented facts, estimates and unresolved questions. Optional shadow-mode or controlled testing depends on access and scope; an API or sandbox test does not establish production performance or compliance certification.