USDGO is the stablecoin in OSL Group's current product architecture. It is a U.S. dollar-backed stablecoin issued by Anchorage Digital Bank N.A. OSL Business Payments, by contrast, is the enterprise service area for supported collections, cross-border payments, stablecoin settlement and payouts. The asset and service can be evaluated together, but they are not the same product and do not carry the same responsibilities.
OSL Group provides global stablecoin infrastructure through four first-level businesses: OSL Business, Banxa, USDGO and OSL Exchanges. Within OSL Business, enterprises can route account, market, payment, card, treasury and platform requirements to the relevant product area. This structure helps a buyer identify where to start, but the applicable contracting entity, service scope and commercial terms must still be confirmed for the proposed customer and market.
The practical rule is simple: approve the stablecoin as an asset, assess the service as an operating workflow and verify the legal and technical responsibilities separately. A group-level product map does not by itself confirm eligibility, supported routes, redemption access, pricing, service levels or liability.
For procurement, the useful distinction is not the full OSL product catalogue. It is the decision each team must close before a stablecoin workflow can be approved. Four layers are relevant to this review. S1
OSL layer to review | Decision to close | Evidence needed before approval |
|---|---|---|
- | - | - |
USDGO | Is the settlement asset acceptable? | Named issuer, applicable terms, reserve and attestation materials, asset and network identifiers, eligibility and any available conversion or redemption path |
OSL Business Payments | Can the proposed payment be operated and evidenced? | Contracting entity, supported customer and route, instruction and status records, exception handling and delivery evidence |
OSL Business Treasury | How will funding, conversion or liquidity be managed? | Responsible party, quote and conversion records, limits, settlement terms, exposure owner and fallback |
OSL Business Platform | How will the workflow connect to enterprise systems? | Supported interfaces, permissions, status and error model, reporting fields, implementation scope and support terms |
Other OSL Group businesses belong in the review only when the proposed workflow needs their distinct role. Banxa is relevant to supported end-user on- and off-ramp journeys, while an applicable OSL Exchanges entity is relevant to regulated local market access. OSL Business Account, Markets or Cards should be assessed only when account, trading or card functions are part of the requirement.
Anchorage Digital's USDGO materials identify Anchorage Digital Bank N.A. as the issuer and publish reserve-attestation information for enterprise review. S2S3 Those materials support the asset decision; they do not establish whether a payment service, integration or customer route is available.
OSL Business Payments, Treasury and Platform may each enter the same operating design, subject to current product scope and applicable terms. Their involvement should not be inferred from the use of USDGO alone. Each layer still needs its own entity, control, record and contract review.
Before approving a combined asset-and-service model, procurement should document the responsibility attached to each layer. Where a party or term is not public, the correct action is to request confirmation rather than infer it from the OSL brand.
Procurement layer | Product or business | Party and control responsibility to verify | Business records to obtain | Contract-specific checks |
|---|---|---|---|---|
- | - | - | - | - |
Group architecture | OSL Group | The group name does not by itself identify the contracting or regulated entity. Record the entity responsible for each service. | Current product documentation and entity details | Contracting entity, jurisdiction, activity and governing terms |
Stablecoin asset | USDGO | Anchorage Digital Bank N.A. is identified as issuer. The enterprise remains responsible for its own asset approval and use policy. | Issuer materials, reserve attestations, applicable terms, asset and network identifiers | Eligibility, acquisition path, supported networks, conversion or redemption access |
Enterprise payments | OSL Business Payments | Confirm the contracting OSL entity and how responsibilities are divided between the service provider and the enterprise's approval, compliance, beneficiary and accounting teams. | Payment instruction, status, fee, delivery and exception records where supported | Customer and market eligibility, asset and network, corridor, limits, pricing, support, liability and availability |
Treasury operations | OSL Business Treasury | Confirm which party quotes, converts, holds or transfers value and who approves exposure within the enterprise. | Quote, conversion, balance, settlement and exception records where supported | Pricing, limits, liquidity, settlement window, redemption dependency and fallback |
API or embedded workflow | OSL Business Platform | Confirm the service entity, permission model and the buyer's integration, security, data and customer responsibilities. | Technical documentation, request and status records, error handling and reporting fields where supported | Interfaces, authentication, fields, support model, service levels, implementation scope and market availability |
End-user on/off-ramp | Banxa | Confirm the relevant Banxa entity and the split between platform, provider and end-user responsibilities. | Onboarding, payment-method, asset, route, status and support records where supported | Supported users, markets, payment methods, assets, limits, fees and route availability |
Regulated market access | Relevant OSL Exchanges entity | Identify the local entity, regulator, jurisdiction and covered activity. | Regulatory record, account terms, order and transaction records | Customer eligibility, market scope, supported assets and activity-specific restrictions |
The procurement decision should be recorded layer by layer, rather than described as a general choice between an integrated or standalone model. Each proposed OSL component should receive one of three statuses.
Status | When it applies | Procurement action |
|---|---|---|
- | - | - |
Confirmed for the proposed use | The relevant entity, product scope, customer and market eligibility, records and applicable terms are documented | Include the layer in the approved operating design |
Outside the proposed scope | The business does not need that function or already uses another approved asset or provider for it | Exclude the layer and record where the responsibility sits instead |
Confirmation required | A material fact such as the contracting entity, route, network, conversion path, record, price, limit, service level, liability or fallback is not documented | Hold approval for that layer until the missing evidence is obtained |
These statuses can differ within the same proposal. USDGO may pass asset review while a payment route remains unconfirmed. OSL Business Payments may be in scope while USDGO is outside scope because another supported asset has been selected. OSL Business Platform may be unnecessary when no API or embedded integration is planned, while OSL Business Treasury should enter the record only if funding, conversion or liquidity functions are part of the arrangement.
Approval should therefore depend on the evidence status of every required layer. A shared OSL Group relationship does not close a missing entity, route, record or contract term.
USDGO answers the asset question in OSL Group's product architecture. It does not answer who operates a payment, manages a treasury step or provides an integration. Those responsibilities must be recorded against the relevant service and entity.
An enterprise can proceed when every required layer is supported by current evidence, exclude layers that are not needed and hold any layer with a material confirmation gap. This turns the OSL product map into a reviewable procurement record rather than a broad product assumption.
USDGO. Anchorage Digital's current materials identify Anchorage Digital Bank N.A. as the issuer. S2 The asset should be reviewed separately from any OSL Business service used in the proposed workflow.
Yes. USDGO can be assessed as an asset without assuming that an OSL payment, treasury or platform service is part of the arrangement. An OSL Business service can also be assessed for a supported workflow without assuming that USDGO is the selected asset.
The contracting entity, customer and market eligibility, asset and network support, route, records, pricing, limits, service levels, liability and fallback depend on current product documentation and applicable terms.
Stablecoin and payment-service use can involve issuer, reserve, redemption, regulatory, sanctions, banking, custody, wallet, network, conversion, FX, liquidity, data, cyber, accounting, tax and operational risk. Product names and group relationships do not guarantee access, availability, redemption rights, timing, cost, liquidity, reversibility, regulatory treatment or suitability. Enterprises should verify current official materials, entities, eligibility, contracts, configurations and route evidence before use.
SEBI and the RBI's Demat 2.0 pilot issues corporate bonds as digital tokens and settles them with the wholesale digital rupee, preserving existing legal terms while digitizing the infrastructure beneath a $620...
Why India's $620B Bond Pilot Changed Nothing Legal
S&P Global led a $110 million extension of Kaiko's Series B to build data infrastructure for round-the-clock tokenized markets.
Why S&P Global Leads Kaiko: Not Hype, But 24/7 Market Infrastructure
Bitmine's accumulation of more than 5 million staked ETH raises questions about whether custody, audit, and validator infrastructure can support single-asset concentration at public-company scale.
When One Firm Holds 5% of Ethereum: Infrastructure Stress Test
Compare enterprise stablecoin payment providers by use case, legal entity, workflow, controls, integration, reconciliation, support, and contract terms.
Best Enterprise Stablecoin Payment Providers: A 2026 Evaluation Framework
See how Finance can trace a USDGO payment from an approved obligation through payment records, recipient confirmation, reconciliation, and accounting close.
How to Reconcile a USDGO Payment: An Illustrative Finance-Close Example
Review what the July 2026 USDGO reserve attestation establishes, what it does not prove, and which issuer, redemption, and liquidity questions remain.
A USDGO Reserve Review in Practice: Findings, Limits and Follow-up Questions