We never keep your money

When a customer pays for your SaaS in USDC, that USDC arrives in your wallet. Not in our wallet, not in our pool, not in our holding account, not for an hour, not for a second. We never touch it. That is the brand and it is also the architecture — those two things are the same thing here on purpose.

Every other sentence on this page is a footnote on that one. If you only read the first paragraph and the last, you'll have the whole post.

What "non-custodial" actually means

A custodial payment processor is one that holds your money in transit. Card processors do this — when your customer pays you $100 via Visa, Visa's settlement bank holds the funds, applies the interchange and processor fees, and pays out the remainder to your bank account on a schedule (typically T+2). During that window, the money is custodied by the processor.

This is fine for cards. It's load-bearing, in fact: card processors need to hold funds to handle chargebacks, disputes, and the reversal economy that makes cards work at scale. The legal frame, the operational frame, and customer expectations are all aligned on that arrangement.

Stablecoin payments don't need this. There are no chargebacks. There are no reversal windows in the traditional sense — chain re-orgs are rare, finite, and detectable, and we cover them elsewhere. The customer pays in USDC, the USDC moves on-chain, your wallet receives it. The historical reason for a processor sitting in the middle of the rail doesn't exist.

The current reason a processor sits in the middle of a stablecoin rail — when they do — is usually one of two things: regulatory hedging (they want to be a money transmitter so they can offer adjacent services like fiat off-ramps), or technical legacy (their pipes were built for cards and they retrofitted USDC into the same architecture). Both are reasonable business choices for those companies. They are also choices, not necessities, and the cost of those choices is paid by the merchant in the form of held funds and the failure modes that come with them.

What changes when nobody holds the money

Things you no longer have to model:

• Payout schedules. There is no payout schedule because there is no payout. The merchant's wallet is paid 1-for-1 at the moment the chain confirms the transaction.
• Hold limits and reserves. There is no processor holding a reserve against your future chargebacks — because there are no chargebacks and there is no processor.
• The risk that your processor's solvency could trap your money. This was a real concern in 2023. It remains a real concern for processors that hold balances.
• Asynchronous reconciliation between processor and bank. Your ledger watches the chain. The chain is the ledger.
• Most of the regulatory weight that comes from operating as a money transmitter. The platform doesn't transmit money because it never has the money to transmit.

Things you still have to think about, in order of how often they come up:

• Chain re-orgs that invalidate a confirmed deposit. Rare, finite, well-modeled, addressed in a separate post.
• Customers paying on the wrong chain. The platform rejects the pull before it broadcasts, but a check at the application layer catches edge cases.
• FX or accounting reconciliation if you book in EUR but accept in USDC.
• The merchant's own custody — losing the private key to the settlement wallet is unrecoverable in a way that losing a Stripe password is not. This is the trade-off. We help with hardware-wallet support and verified-wallet workflows, but we cannot custody what we structurally refuse to custody.

In the code

The non-custodial property is structural, not asserted. There is no part of our infrastructure where customer funds sit. The platform's role is:

• Verify the customer's permit signature and broadcast the pull transaction. The transaction's recipient is the merchant's wallet — never ours.
• Observe the chain for the resulting deposit and emit a confirmed event when finality criteria are met.
• Compute the platform fee as a separate database column (fee_bps × amount) and invoice the merchant monthly. We bill the merchant the way a B2B SaaS vendor bills a B2B SaaS customer — because that's what we are.

We've covered the architectural choice between this off-chain billing model and an on-chain splitter contract in a separate post ("Why we bill off-chain instead of running an on-chain splitter"). The short version: both are valid; we picked the one that keeps the funds-routing surface as small as possible.

The compliance story

OpenSettle is not a money transmitter, custodian, broker, exchange, or fiduciary. We don't hold customer or merchant funds — at any time — and the underlying transactions are wallet-to-wallet on public blockchains. The non-custodial structure is what keeps us out of money-transmission scope in the U.S. and out of CASP scope under MiCA in the EU.

This is a load-bearing structural property, not a marketing claim. Were we ever to start holding funds — for any reason, even briefly, even for a useful product feature — the regulatory frame would change overnight. That's why we don't, and that's why we won't.

When does it not apply

Honesty bit: there's one path where money briefly transits a custodial intermediary, and we should be explicit about it. If a merchant wants to pay out their USDC settlement to fiat (USD, EUR), they connect a third-party off-ramp through OpenSettle, and that off-ramp custodies the funds during the conversion. We don't operate the off-ramp. We don't hold the funds. The merchant chose to off-ramp and consented to that intermediary by name. The non-custodial property of OpenSettle's rail is preserved; the merchant's choice to use a custodial off-ramp is the merchant's choice.

If you only ever take USDC in and out — direct to a self-custodied wallet — then no custodian is in the picture at all. That is the default. That is the architecture. That is the promise.

Why this is the brand

We pick our marketing claims with a guard script that fails any commit introducing a phrase we can't defend. "We never keep your money" is the kind of claim that lives at the top of that policy because it's the kind of claim a billing platform should be able to make — and most billing platforms can't. If the architecture matches the marketing, the marketing writes itself.