Stablecoins: Customer Balances, On-Chain Endpoints or a Treasury Bridge?
Part III · Adding Stablecoins (Chapters 9–10) Builds on: Payment Systems, Chapter 26 (issuer liabilities and shared ledgers), Chapter 27 (the middle leg and fiat on/off-ramps), Chapter 24 (compliance); Chapter 2–Chapter 4 of this course New concepts in this chapter: three stablecoin positions, customer-facing stablecoin balance, on-chain endpoint, treasury bridge, issuer and service-provider permissions
1. The question from the previous chapter¶
StarMap wants to pay a Philippine developer on Friday night, but its existing bank route must wait until Monday. The capability map so far uses fiat money and the operating schedules of banks and card schemes.
Recall three ideas from the chapter on what stablecoins are.
A stablecoin is an issuer's liability. Holding one USDC represents a dollar claim backed by Circle's reserves. In the course's money hierarchy, this sits alongside other nonbank liabilities such as a PSP balance. The ledger is the innovation: holdings appear on a shared public blockchain, where a transfer can clear and settle together, around the clock, without connecting two separate bank ledgers. It replaces the middle leg of the cross-border chain: the connection between two banking systems. Converting fiat into stablecoins and stablecoins back into fiat still depends on local banking access at the ends.
Now place those ideas in the PSP model.
2. Three positions: balances, endpoints and treasury¶
Stablecoins can occupy three positions within the PSP model. Each changes what StarMap sees and what the PSP must do.
Position 1: an asset in the balance core
StarMap sees a USDC column beside euros, pounds and dollars. It can hold USDC, spend it or convert it into fiat.
To the core, this resembles another currency, but the backing changes. A fiat balance is backed by the bank safeguarding arrangement in the balance core. The USDC balance is backed by matching USDC in a wallet controlled by the PSP. StarMap's claim on the PSP is payable in those tokens. We call this a customer-facing stablecoin balance.
Position 2: on-chain pay-in and payout endpoints
StarMap's customers can pay it in USDC, and StarMap can pay others in USDC.
On-chain pay-in: the PSP allocates an address to StarMap. A customer sends USDC there. The PSP monitors the blockchain, detects the receipt and waits for enough confirmations — subsequent blocks that make a reversal progressively less likely under that chain's rules — before telling the core to credit StarMap. Structurally, the address resembles the virtual account in pay-in endpoints: the destination identifies the customer.
On-chain payout: StarMap supplies the developer's wallet address. The PSP validates the address and chain, screens the transfer, signs from a wallet it controls, pays the network fee called gas, waits for confirmation and tells the core to complete the deduction.
Both endpoints can operate 24/7. Friday night and Monday morning use the same on-chain process.
Position 3: a treasury bridge invisible to StarMap
StarMap continues to use only fiat. It requests a Philippine peso payout from its euro balance on Friday night, and the PSP pays from a peso pool.
The change is behind the scenes, in the treasury rebalancing described in payout endpoints. Previously, replenishing the Philippine pool required a bank transfer from Germany, often over SWIFT. Now the PSP can convert euros into USDC, transfer on-chain to a Philippine partner, and convert USDC into pesos for the local pool. Where both conversion providers and local funding are available, this can run on a weekend and complete within minutes. We call it a treasury bridge.
The bridge replaces the middle leg described in what stablecoins solve. FX remains at both ends: euro-to-peso conversion becomes euro-to-USDC plus USDC-to-peso conversion.
Compare the positions:
| Position | Visible to StarMap? | What changes? | What remains? | What the PSP adds |
|---|---|---|---|---|
| 1 · Customer-facing stablecoin balance | Yes, a new balance asset | For that asset, a wallet takes the place of bank-account backing | Customer claim against the PSP and reconciliation responsibility | Relevant custody permissions and custody systems |
| 2 · On-chain endpoints | Yes, another way to collect and pay | Blockchain takes the rail role | Identification, availability rules and handling of mistaken or returned funds | Address management, confirmation policy, gas and screening |
| 3 · Treasury bridge | No | The PSP's cross-border funding moves on-chain instead of over SWIFT | Local fiat pools and payout endpoints | Conversion counterparties and wallets |
The distinguishing question is who holds the stablecoin and for what purpose. A customer-held balance is position 1. Customer stablecoin payments, potentially converted immediately rather than held, are position 2. Temporary proprietary holdings for treasury are position 3. Different holdings produce different permissions and engineering obligations.
3. Licensing requirements: issuance, customer services and fiat access¶
Three activities must be separated: issuing stablecoins, holding or transferring them for customers, and handling fiat at the ends.
Issuance: major jurisdictions introduced or developed frameworks during 2024–2025. EU MiCA treats single-currency stablecoins as e-money tokens, issued by an EMI or bank. The US GENIUS Act, signed in July 2025, defines permitted issuers and one-to-one reserve requirements. Hong Kong's Stablecoins Ordinance took effect in August 2025 with HKMA licensing. Singapore's MAS also has a single-currency stablecoin framework. Most PSPs use existing issuers, such as Circle, Tether or Paxos, rather than issuing their own token.
Customer custody, exchange and transfer: these are the activities in positions 1 and 2. Many jurisdictions regulate them as cryptoasset services, separately from ordinary payment permissions:
| Jurisdiction | Cryptoasset-service requirements | Relationship to payment permissions |
|---|---|---|
| EU | Crypto-Asset Service Provider (CASP) authorization under MiCA | A separate framework alongside EMI permissions |
| UK | FCA cryptoasset registration, transitioning toward a full authorization regime, with an application window planned for 2026 and commencement in 2027 | Separate frameworks |
| US | Federal MSB registration; state MTLs commonly cover stablecoin transmission; some states add crypto-specific permissions | Partial overlap: an MTL may cover both |
| Singapore | Digital payment token services under the Payment Services Act | Separate activities under one law; an MPI licence can include both |
| Hong Kong | SFC licensing for trading platforms; other stablecoin-service rules continue to develop | Separate frameworks |
The Travel Rule, introduced in the compliance skeleton, requires relevant institutions to exchange originator and beneficiary information. An on-chain transfer ordinarily shows addresses, not names, so the endpoint needs an information exchange alongside the value transfer.
Fiat at both ends: if a customer pays StarMap in USDC but StarMap wants euros, conversion and the euro balance still require the permissions discussed in the balance core, pay-in endpoints and payout endpoints. Stablecoins do not remove the relevant fiat permissions.
The governing question is what asset is being held or transferred, and for whom. Handling customer fiat requires payment permissions; handling customer stablecoins invokes the relevant cryptoasset-service framework; doing both requires both sets of applicable permissions. A treasury bridge using only the PSP's own temporary holdings usually does not create the same customer-facing custody service, but compliant counterparties and AML obligations still matter.
The chapters on Bridge, Circle and BVNK in Payment Licences and Players examine company-specific combinations.
4. Engineering requirements: on-chain versus bank endpoints¶
On-chain endpoints revisit the questions in pay-in endpoints and payout endpoints, with different answers:
| Engineering question | Bank endpoint | On-chain endpoint |
|---|---|---|
| Who owns an incoming payment? | The bank reports the virtual account | The PSP monitors customer addresses; some chains use a shared address plus a memo |
| When is it final? | Apply the rail's settlement rules | Apply the chain's finality or confirmation policy |
| What if the destination is wrong? | Request a recall | No general recall; recovery normally requires the recipient's cooperation |
| How are fees paid? | Per-payment rail fees in fiat | Gas, typically using the chain's native asset, which must also be managed |
| Who controls the funds? | Bank-account access and bank custody controls | Wallet keys: self-managed using hardware security modules or multiparty computation, or infrastructure/custody providers such as Fireblocks, BitGo, Coinbase Custody or Anchorage |
| How is counterparty risk screened? | Screen names and accounts | Screen addresses and links to sanctions, stolen funds or mixers, using services such as Chainalysis, TRM or Elliptic |
Bank arrangements package services such as account identification, custody controls, settlement rules and recall handling. A blockchain does not provide an equivalent bank operator to perform them for the PSP. The PSP must implement or procure the corresponding operational functions itself.
Multiple chains and tokens multiply the work. USDC on Ethereum, Solana, Base and Polygon uses different deployments; USDT on Ethereum and Tron does too. Every chain-and-token combination is a separate endpoint with its own confirmation rules, gas requirements and address handling. "We support stablecoins" must therefore specify which tokens on which chains.
Public on-chain records make reconciliation data available without waiting for a bank statement. The structure remains three-way: blockchain records, endpoint records and the core ledger must agree.
5. What stablecoins leave unchanged¶
Return to the question in the course map: what changes in the PSP architecture?
| What changes? | What remains? | |
|---|---|---|
| Balance core | Another asset, with wallet-based rather than bank-account backing | Who owes the customer, daily reconciliation and separation of customer and proprietary funds |
| Pay-in endpoint | Another rail operating 24/7, without ordinary recall | Identification, finality assessment and availability policy |
| Payout endpoint | Another rail operating 24/7; treasury can transfer on-chain | Fiat pools, local payout delivery and beneficiary screening |
| Permissions | Applicable cryptoasset-service permissions | Relevant fiat permissions |
What stablecoins solve concludes that the middle leg changes while the ends remain. In PSP terms, position 3 changes treasury funding and position 2 adds endpoints, while any conversion back to fiat returns to the same balance-core and local-endpoint requirements.
6. The questions this raises¶
Which positions are companies using, and for whose problem? What does Stripe gain from Bridge? Where does Circle's CPN fit? Which positions combine in a card that spends a USDC balance?
The next chapter places the players by use case.
7. Self-check questions¶
- A PSP claims stablecoins enable cross-border payments in seconds, but its customers use only fiat. Which position is involved? Does every customer payout arrive in seconds?
- StarMap sends USDC to the wrong developer address. What remedy is missing compared with the bank payout endpoint, and what does that imply for validation?
- Compare the permissions of a PSP using only a proprietary treasury bridge with those of one offering customer USDC balances.
8. Answers¶
Try answering before reading on.
Position 3, the treasury bridge. Customers still pay through fiat endpoints and the destination's local rail. On-chain funding may replenish the pool quickly, including on weekends where the endpoints support it, but customer delivery still depends on the local payout rail. An instant rail can be fast; a batch rail retains its schedule.
There is no ordinary recall request to a receiving bank. Before sending, the PSP must validate the address format, chain, token compatibility and screening results. After sending, it cannot generally reverse the transfer itself. Some providers add address allowlists or small test transfers.
A proprietary bridge temporarily holds stablecoins for the PSP's own rebalancing, generally avoiding the customer-custody activity while retaining counterparty and AML requirements. Customer USDC balances add a custody service subject to the relevant regime, such as EU CASP, US state permissions or Singapore digital payment token permissions. Fiat conversion and balances still require their applicable permissions. The difference follows the asset and whose behalf it is held on.
Previous: Chapter 8 · The Issuing Ecosystem: Turning a Balance into a Card Next: Chapter 10 · Stablecoin Use Cases: Who Uses Them, and for What?