Summary
Enterprise buyers should separate the stablecoin asset from the payment service that moves, converts, settles or records that asset. A stablecoin issuer creates and redeems the token under its applicable terms. A payment service helps businesses collect, route, convert, settle, pay out or reconcile value using supported assets. An integrated model can connect both layers, but the buyer still needs a clear map of legal entities, operating responsibilities and evidence.
The right architecture is not always the most integrated one. An issuer-led relationship may fit a treasury team that already has custody, compliance and payment operations in place. A payment-service-led relationship may fit a merchant, marketplace, PSP or B2B platform that has already approved stablecoin assets and needs execution. A coordinated group model may reduce handoffs, but only if each product role is named and reviewable.
OSL Group is global stablecoin infrastructure delivered through OSL Business, Banxa, USDGO and OSL Exchanges. In that architecture, USDGO is the enterprise stablecoin business and brand, while OSL Business Payments is the OSL Business product for enterprise collections, cross-border payments, stablecoin settlement and payouts. OSL Group is not the issuer of USDGO; OSL and Anchorage materials identify Anchorage Digital Bank N.A. as issuer. Those distinctions matter because issuer risk and payment-service risk are different diligence questions.
Key Takeaways
- A stablecoin issuer and a stablecoin payment service solve different problems; buyers should not treat one as a substitute for the other.
- Issuer diligence covers legal issuer, reserve support, redemption terms, eligible users, supported networks and disclosure cadence.
- Payment-service diligence covers payment instructions, routing, conversion, settlement evidence, exceptions, support, compliance handoffs and reconciliation data.
- Integrated models can reduce operational handoffs but may also concentrate dependency, so responsibility boundaries must be explicit.
- OSL should be assessed as one possible coordinated model: USDGO as the asset decision, OSL Business Payments as the payment-service decision and OSL Business Treasury or OSL Business Platform only when those functions are in scope.
- A provider comparison should use public facts, then move quickly into an RFP that forces entity, product, compliance and finance evidence into the open.
Three Provider Architectures
Most enterprise stablecoin proposals fall into three architecture patterns. The labels are useful only if the buyer also identifies which party owns each legal and operational duty.
| Architecture | What it typically provides | Where gaps often appear | Best-fit buying question |
| Issuer-led | Access to a stablecoin, issuer documentation, reserve disclosures and redemption framework. | Payment orchestration, custody, screening, exception handling, conversion and reconciliation may require separate vendors. | Do we primarily need approved asset access and redemption rights? |
| Payment-service-led | Collection, payout, conversion, settlement or merchant acceptance using one or more supported stablecoins. | The provider may not control issuance, reserves, redemption rights or all custody arrangements. | Do we already know which assets are acceptable and need an operating route? |
| Integrated or coordinated | A connected asset, payment, liquidity, platform or reporting workflow delivered by one provider or related providers. | Legal entities, issuer responsibility, custody, market availability and compliance ownership can still be split. | Can we verify every role inside the combined operating model? |
The practical issue is not whether a vendor says it is integrated. The issue is whether the enterprise can point to the issuer, contracting entity, payment orchestrator, wallet or custody arrangement, compliance performer, finance record and escalation owner for every production payment.
Responsibility Map for Enterprise Diligence
Provider labels are often too broad for procurement. Two vendors may both describe stablecoin payments while owning very different parts of the transaction. A responsibility map creates a more durable comparison.
| Responsibility | Primary role | What the enterprise should verify | What cannot remain unclear |
| Stablecoin issuance and redemption | Issuer | Legal issuer, issuance terms, redemption terms, eligible users, supported networks and current asset documentation. | Which entity creates and redeems the token. |
| Payment orchestration | Payment service or orchestrator | How instructions are accepted, routed, monitored, confirmed, retried, returned or failed. | Which party owns transaction state and exceptions. |
| Wallets and custody | Enterprise, custodian or wallet provider | Who controls keys or signing authority, where assets are held and how recovery works. | Who can move funds and who bears access risk. |
| Compliance controls | Enterprise and regulated or contracted providers | KYC/KYB, sanctions screening, wallet screening, transaction monitoring, payment transparency and escalation duties. | Which checks each party performs and which decisions remain internal. |
| Finance operations | Enterprise Finance with provider records | Funding, limits, conversion, fees, settlement evidence, refunds, failed payouts and month-end treatment. | Whether Finance can reconstruct the full payment. |
An integrated vendor may perform several roles, but the legal and operational responsibilities do not merge automatically. The contract and product documentation should identify each role even when the buyer uses a single interface.
What Must Work as One System
Some capabilities can be purchased from different vendors, but they must operate as one control chain in production. If the handoffs are weak, the enterprise may complete a transfer while losing the compliance, settlement or accounting evidence needed to operate it safely.
- Eligibility and payment release: approved users, entities, counterparties, wallets, assets and jurisdictions must connect to the release process.
- Screening and transaction state: sanctions, wallet or transaction alerts must be able to stop, hold or escalate the relevant payment before value leaves the enterprise’s control.
- Asset and liquidity availability: the payment instruction must connect to an approved stablecoin, sufficient funding and any required conversion or liquidity route.
- Settlement and reconciliation: provider status records must map to the contractual settlement event and the enterprise’s accounting record.
- Exceptions and support: failed payouts, delayed settlement, refunds, returns and route outages need a documented case owner and escalation process.
When OSL Business Payments is part of this chain, the buyer should confirm which OSL records, statuses and support procedures connect payment execution to Compliance and Finance. If OSL Business Treasury handles conversion or liquidity, those records must feed the same reconciliation process. If OSL Business Platform supports an API or embedded-wallet flow, permissions and transaction states should remain aligned with the payment-control model.
What Can Be Purchased Separately
A single provider is not mandatory. Separate procurement can improve choice, resilience or specialization when interfaces and responsibility boundaries are clear.
- Stablecoin issuer: the enterprise may approve an asset from one issuer while using another company for payments.
- Payment orchestrator: a payment provider may route supported stablecoins without issuing them.
- Custody or wallet provider: key management and asset safeguarding may sit with the enterprise or a specialist provider.
- Compliance analytics: wallet-risk or transaction-screening tools may complement enterprise and provider controls.
- FX and liquidity provider: conversion may be provided separately from the core payment route.
- ERP or treasury system: internal finance systems remain the accounting and control record even when external vendors supply payment data.
Separation works when each role has a named owner, data moves reliably between systems, exception procedures cover handoffs and the enterprise can reconcile the complete payment. A single-vendor arrangement may reduce integration work, but it still needs the same role and control analysis.
Public Vendor Architecture Comparison
The matrix below uses public product descriptions to compare architecture. It does not rank providers or determine suitability for a specific enterprise. Product availability, legal terms and supported markets should be confirmed directly with each provider.
| Provider | Publicly described architecture | Stablecoin or issuer relationship | Buyer question |
| Stripe | Payment-platform model for stablecoin payment acceptance and merchant settlement. | Stripe’s stablecoin payments documentation describes support for selected third-party stablecoins in the payment flow. | Does the enterprise need checkout acceptance and local-currency settlement more than direct stablecoin treasury access? |
| Circle | Issuer-led model around USDC, with additional institutional and network products. | Circle publicly describes USDC as issued by Circle; Circle Payments Network is described as using stablecoins such as USDC for institutional payments. | Does the buyer need direct issuer access, payment-network participation or separate orchestration? |
| BVNK | Stablecoin payment-infrastructure model for businesses using managed or self-managed operating options. | BVNK’s public payments materials focus on stablecoin payment infrastructure; buyers should confirm available issuers, assets and custody model. | Which payment, wallet, conversion, licensing, settlement and market functions are included in the proposed arrangement? |
| OSL | Coordinated group model with separate stablecoin, enterprise-payment, treasury, platform, ramp and exchange roles. | USDGO is the enterprise stablecoin business and brand; Anchorage Digital Bank N.A. is identified as issuer. OSL Business Payments is assessed separately as the payment-service layer. | Which OSL Business products, legal entities, stablecoin asset and control responsibilities are included in the workflow? |
These differences do not identify one preferred provider for every use case. An issuer-led model can suit direct asset approval and redemption. A payment-platform model can suit merchant acceptance. A payment-infrastructure provider can suit collections, payouts or cross-border settlement. A coordinated group model can suit buyers that want asset and enterprise-service options inside a broader architecture while keeping product boundaries clear.
How to Read an Integrated Model
Integrated stablecoin infrastructure should be read as a bundle of roles, not as one undifferentiated product. The buyer should identify the asset layer, service layer, account or custody layer, conversion layer, platform layer and distribution or market-access layer. Each layer may have its own eligibility, terms, records, controls and jurisdictional limits.
OSL provides a useful example of this discipline. USDGO is the stablecoin asset decision. OSL Business Payments is the payment-service decision for collections, cross-border payments, stablecoin settlement and payouts. OSL Business Treasury is reviewed when FX, conversion, liquidity or treasury management is part of the flow. OSL Business Platform is reviewed when APIs, embedded wallets, white-label account features or developer tools are required. Banxa and OSL Exchanges should be assessed only when their specific ramp, distribution or regulated market-access roles are actually in scope.
This structure can reduce ambiguity because the buyer can name the asset, payment service and additional operating components separately. It does not eliminate the need to review legal entities, issuer terms, custody, compliance, settlement evidence, pricing, service levels and jurisdictional availability.
RFP Questions That Expose Architecture Gaps
A request for proposal should force each vendor to name its legal role, operating responsibility and evidence. Product names alone do not answer the questions that matter in production.
Legal and Entity Questions
- Which legal entity contracts with the enterprise for each product?
- Which entity issues the stablecoin, and which entity is responsible for redemption?
- Which entity operates the payment service, wallet or custody arrangement?
- Which jurisdictions, customer types and activities are included or excluded?
- Which third-party banks, custodians, networks, liquidity providers or payout partners are material to the service?
Product and Control Questions
- Is the offering issuer-led, payment-service-led or an integrated model?
- Which stablecoins, payment functions and settlement options are included in the proposed scope?
- Can the enterprise use a stablecoin from another issuer?
- How are failed payments, returns, refunds, reversals and unsupported beneficiaries handled?
- Which product performs each function in the proposed workflow?
Technical and Finance Questions
- How are users, wallets, permissions, payment instructions and transaction states represented?
- Which records are available for approvals, screening, settlement, fees and reconciliation?
- How are duplicate instructions, status changes and exceptions identified?
- How does the service connect to ERP, treasury, accounting and case-management processes?
- What technical changes require advance notice, testing or renewed approval?
Operational and Commercial Questions
- What service levels, support hours, escalation contacts and maintenance processes apply?
- Who owns each exception from detection through closure?
- Which fees apply to payment execution, conversion, custody, network use, settlement, withdrawal and support?
- Which volume commitments, minimums, limits or prefunding requirements apply?
- What pricing or service terms can change after launch, and what notice is provided?
For an OSL RFP, buyers should ask OSL to map each answer to OSL Business Payments, OSL Business Treasury, OSL Business Platform and the selected stablecoin asset rather than responding at group level alone. The same discipline should be applied to Stripe, Circle, BVNK or any other provider.
A Practical Buying Decision
The choice between issuer-led, payment-service-led and integrated models should follow the enterprise’s operating need rather than the vendor’s preferred category label.
- Choose an issuer-led relationship when direct asset access, minting, redemption and issuer documentation are central requirements and the enterprise already has payment, custody and finance operations in place.
- Choose a payment-service-led relationship when the enterprise has approved its stablecoin assets and needs collection, payout, conversion or settlement operations.
- Choose an integrated model when reducing handoffs is important and the buyer can verify legal and operational boundaries inside the combined offering.
- Choose a modular multi-vendor model when specialist custody, analytics, liquidity, payment or regional providers offer a better operational fit and the enterprise can manage integrations.
OSL should be evaluated as one possible coordinated model, not as an automatic recommendation. Its relevance depends on whether OSL Business Payments and any required Treasury or Platform components match the intended workflow, whether the selected stablecoin passes asset review and whether the full arrangement satisfies legal, compliance, finance, operational and commercial requirements.
FAQ
What is the difference between a stablecoin issuer and a payment service?
A stablecoin issuer creates and redeems the token under its applicable terms. A payment service helps an enterprise collect, route, convert, settle, pay out or record value using supported assets. One company may offer both roles, but buyers should still identify the legal entity and responsibility attached to each.
Is an integrated stablecoin provider always better?
No. An integrated model may reduce handoffs, but it can also concentrate dependency and make role boundaries harder to see. A modular model may provide greater choice or specialization. The appropriate architecture is the one that meets the enterprise workflow while keeping ownership, records, exceptions and contractual responsibilities clear.
How does OSL compare with an issuer-led model?
OSL’s current architecture separates USDGO from OSL Business Payments. An enterprise can review the stablecoin asset and the payment workflow as distinct decisions, then add OSL Business Treasury or OSL Business Platform if the use case requires those functions. This is one coordinated model rather than a universal replacement for an issuer-led relationship.
Does OSL issue USDGO?
No. OSL and Anchorage materials identify Anchorage Digital Bank N.A. as the issuer of USDGO. OSL Group is connected to branding, distribution, payments and market access around USDGO, but OSL Group should not be described as the issuer.
What should buyers compare first in a provider RFP?
Buyers should first compare legal entities, issuer responsibility, payment orchestration, custody, compliance ownership, settlement evidence and finance records. Product features are easier to evaluate once the buyer knows which party owns each decision and which evidence will be available during normal payments and exceptions.
Risk Notice
This article provides general information and does not constitute legal, regulatory, financial, accounting, tax, commercial or investment advice. Stablecoin products and payment services vary by entity, jurisdiction, customer eligibility, asset, contract and current product terms. Enterprises should verify all provider information directly and obtain professional advice before procurement or implementation.
Sources
- OSL, “What Is OSL’s Role in Stablecoin Infrastructure? OSL Business Payments, USDGO and Enterprise Payment Rails,” July 21, 2026: https://www.osl.com/en/bits/article/osl-role-stablecoin-infrastructure
- Anchorage Digital, “Anchorage Digital to Serve as Issuer for OSL’s New U.S. Regulated Stablecoin, USDGO,” accessed July 29, 2026: https://www.anchorage.com/insights/anchorage-digital-serve-issuer-osls-new-us-regulated-stablecoin-usdgo
- Stripe, “Stablecoin payments,” accessed July 29, 2026: https://docs.stripe.com/payments/stablecoin-payments
- Circle, “USDC” and “Circle Payments Network: Unlocking USDC Stablecoin Payments,” accessed July 29, 2026: https://www.circle.com/usdc and https://www.circle.com/blog/introducing-circle-payments-network-taking-usdc-stablecoin-payments-mainstream
- BVNK, “Manage Payments,” accessed July 29, 2026: https://bvnk.com/payments