Enterprises using stablecoins for cross-region treasury rebalancing need a written policy that defines where value may be held, when a transfer may begin, who approves it, how much exposure is permitted and when the company must pause or use a bank fallback. The policy should cover each approved source-and-destination pair. It should not grant blanket permission to move funds across every entity, jurisdiction, asset or service.
USDGO may be evaluated as the stablecoin asset within such a policy. Anchorage Digital Bank N.A. is the issuer of USDGO, while OSL supports the asset's distribution and enterprise use. OSL Business Treasury may be assessed for relevant foreign-exchange, stablecoin conversion, liquidity and treasury workflows. OSL Business Payments may be assessed when a route includes collections, settlement or payouts. The enterprise still owns its treasury policy, approvals and risk limits, and it should approve the asset, service providers, counterparties and route separately. S1S2S3
Apply the policy to a defined source-and-destination pair, not to the entire group by default.
Base funding decisions on accessible value, rather than the balance displayed in an account or wallet.
Set separate exposure limits for the issuer, custodian, service provider, liquidity counterparty, settlement bank and any trading venue.
Name the bank fallback, its activation condition and the person authorized to use it before an exception occurs.
Review the policy on a schedule and after a material change, limit breach, failed transfer or control incident.
Within OSL Group's global stablecoin infrastructure, this policy keeps USDGO at the asset layer and the relevant OSL Business service at the workflow layer. S1S2
A treasury team first needs to know where value sits and what obligations it is intended to support. A position register should identify the legal owner, location, purpose, accountable owner and accessible balance for every approved bank account, wallet, custodian, service provider or trading venue.
Position field | What the policy should record | Why it matters |
|---|---|---|
- | - | - |
Legal owner | The entity that owns or controls the position | Prevents a group-level balance from being treated as freely available to every entity |
Value location | Bank account, wallet, custodian, provider or trading venue | Identifies the operational and counterparty dependencies |
Business purpose | Supplier payment, operating expense, tax, refund, settlement or approved trading obligation | Connects the position to a documented need |
Accountable owner | Treasury owner and operational contact | Establishes who monitors and acts on the position |
Displayed balance | The amount shown by the relevant system | Provides the starting record, but does not prove usability |
Accessible balance | Value available after control, eligibility, network, conversion and delivery conditions are considered | Supports the actual funding decision |
A displayed stablecoin balance is not automatically an accessible balance. Treasury may still need to confirm wallet authority, network availability, service access, conversion or redemption conditions, recipient requirements and any final banking step. The position register should record unresolved conditions instead of treating the full balance as deployable.
For a proposed USDGO route, the register should identify Anchorage Digital Bank N.A. as issuer and list each relevant OSL Business service as a separate dependency. S1S2
The following table is an enterprise evaluation framework. Its fields should be completed for each approved source-and-destination pair and configured to the company's obligations, risk appetite, contracts and tested operating routes.
Required policy field | Decision rule | Record to retain |
|---|---|---|
- | - | - |
Balance threshold | Set the target balance, operating floor and operating ceiling for the destination position. | Forecast obligations, current accessible balance and approved buffer rationale |
Transfer trigger | Initiate a review when an approved obligation enters the funding horizon and the destination is expected to fall below its floor. | Forecast, source surplus, destination need and route-status check |
Owner | Name the treasury owner, initiator, approver and release authority. Separate these roles where the control model requires it. | Authority matrix, instruction and approval record |
Counterparty limit | Set distinct exposure limits for the issuer, custodian, provider, liquidity counterparty, bank and trading venue. | Approved limit, current and projected exposure, approver and review date |
Conversion/redemption window | Confirm when conversion or redemption can be requested and when the resulting value is expected to become usable for the obligation. | Current terms, quote, instructions, operating window and receiving endpoint |
Exception threshold | Define the financial, timing, data or control variance that requires a hold or escalation. | Alert, case record, owner, decision and release condition |
Bank fallback | Name the alternate bank route, its activation condition and the control that prevents duplicate payment. | Tested instructions, authorized owner and primary-instruction status |
Review frequency | Set both a scheduled review and event-driven review triggers. | Policy version, evidence cutoff, approver and change record |
The policy should not use a generic percentage, amount limit or funding horizon simply because another company uses it. Those settings depend on expected obligations, forecast accuracy, access conditions, concentration tolerance and the time required to activate a fallback.
If the route includes USDGO, OSL Business Treasury or OSL Business Payments, each should have its own approved conditions and review evidence in the record. S1S2S3
The policy should produce one of three clear outcomes:
Transfer. The destination is forecast to fall below its operating floor, the business obligation is approved, the source retains its required balance, the route is available and projected exposures remain within every applicable limit.
Hold. The funding need exists, but an approval, access condition, quote, eligibility check, counterparty limit or completion record remains unresolved.
Use fallback. The obligation cannot wait for the primary route, the policy's fallback condition has been met and the alternate route is available. Treasury must first confirm that the original instruction has not completed or cannot still complete.
The transfer amount should be no greater than the documented destination shortfall and the available source surplus. It must also stay within the destination ceiling and all projected counterparty limits. A faster route does not justify moving more value than the policy permits.
For a proposed USDGO movement involving OSL Business, the decision therefore depends on current asset, service, counterparty and route evidence rather than brand approval alone.
Prefunding should begin only when an approved obligation enters the company's funding horizon and forecast accessible value would otherwise fall below the operating floor. The rule should identify the obligation, expected date, source position, required delivery form and owner.
A sweep rule addresses the opposite condition. When settled receipts, released collateral or a revised forecast moves a position above its operating ceiling, treasury should decide whether to return, convert or relocate the excess. The approved destination and post-transfer exposures should be checked before the sweep is released.
Conversion or redemption should have its own trigger. It may be required when the beneficiary needs fiat currency, the policy does not permit continued stablecoin exposure or treasury needs to reduce a counterparty concentration. Before acting, the team should confirm current eligibility, operating windows, quoted terms, available liquidity and the receiving endpoint. No public policy template can establish those conditions for a specific route.
When USDGO is the proposed asset, its conversion or redemption conditions should be checked separately from the terms of any OSL Business Treasury or OSL Business Payments service used in the route. S1S2S3
One transfer can create several exposures at the same time. The stablecoin issuer, custodian, wallet operator, service provider, liquidity counterparty, settlement bank and trading venue may each represent a different risk. If one organization performs more than one role, the policy should show both the role-level exposure and the combined concentration.
Counterparty limits should be checked before and after the proposed movement. A transfer should be held when the destination needs funds but the movement would exceed an issuer, provider, bank or venue limit. Treasury can then reduce the amount, use another approved counterparty or activate another approved route. The need for liquidity does not override the limit.
The Financial Stability Board's recommendations for global stablecoin arrangements emphasize governance, risk management, data and recovery or redemption planning at the arrangement level. Corporate treasury policy is a separate control layer, but those themes help explain why an enterprise should examine each dependency instead of approving only the token name. S5
For a USDGO route, this means recording Anchorage Digital Bank N.A. issuer exposure separately from exposure to the selected OSL Business service. S1S2
The enterprise should assign accountability across the full rebalancing decision:
Function | Policy responsibility |
|---|---|
- | - |
Treasury | Own forecasts, target balances, transfer decisions and funding priorities |
Risk | Define exposure methodology, counterparty limits and breach treatment |
Finance | Own accounting treatment, transaction matching and reconciliation |
Operations | Track instruction status, delivery evidence and exceptions |
Compliance and Legal | Review entity eligibility, jurisdictions, counterparties, contracts and required controls |
Technology | Maintain access, integration, data and change controls where systems are connected |
A service provider may execute part of the route or supply records, but it does not replace the enterprise's internal policy owner. The authority to initiate, approve and release a transfer should be documented. Any deviation should have a named escalation owner and a recorded release condition.
Where OSL Business Treasury or OSL Business Payments participates, the enterprise should document which step the service supports and which decisions remain with its own teams. S1
Consider a group with an approved source position in one region and a forecast supplier obligation in another. The destination position is expected to fall below its floor before the obligation is due, while the source has value above its own required balance.
This situation does not automatically produce a transfer. Treasury must confirm that the two legal entities may use the selected structure, the USDGO asset and network are approved, the chosen service and counterparties are available, conversion or redemption conditions match the required delivery form and every projected exposure remains within policy. Intercompany, tax, accounting and transfer-pricing treatment also require the appropriate specialist review.
If those conditions are satisfied, the policy can produce a transfer decision for the amount required to restore the destination target. If a provider limit would be exceeded or a required confirmation is missing, the result is hold. If the obligation cannot wait and the policy's bank-fallback condition is met, treasury can activate that route after checking the original instruction status.
The same logic can apply to an approved trading-venue position. A documented margin or settlement requirement may trigger prefunding, while an operating ceiling limits venue exposure. When the requirement falls, a sweep rule can return excess value to an approved treasury position.
If an OSL Business service is proposed for the movement, its role should be tied to current route terms rather than assumed from approval of USDGO. S1
Within this framework, USDGO is the asset under review. Anchorage Digital's launch materials identify Anchorage Digital Bank N.A. as the issuer, and its USDGO reserve page provides reserve-attestation materials. The enterprise should retain the current issuer, reserve, terms, network and redemption evidence in the asset record. S2S3
OSL Business Treasury may be evaluated when the route requires foreign exchange, stablecoin conversion, liquidity or treasury management. OSL Business Payments may be evaluated when the movement connects to a collection, payment, settlement or payout workflow. Current eligibility, jurisdictions, pricing, limits, service availability and operating terms should be confirmed for the specific route. S1
These roles require separate approvals. Approval of USDGO does not approve an OSL Business service, and approval of a service does not remove issuer, asset or route review. The policy should record USDGO, Anchorage Digital Bank N.A., the relevant OSL Business service and every other counterparty as distinct dependencies.
An exception threshold should identify the event that changes the normal decision. Examples can include a projected limit breach, missing approval, unresolved instruction status, unavailable conversion, incomplete delivery evidence, a data mismatch or a delay beyond the company's permitted window. The policy should name who detects the exception, who can pause the movement, who decides the response and what evidence is needed before release.
The bank fallback should be specific enough to operate under pressure. Record the alternate account or provider, authorized initiator and approver, required payment data, activation condition and duplicate-payment control. A fallback is not effective merely because a bank account exists; the route, instructions and authority should be maintained and tested under the enterprise's own procedures.
Cross-border stablecoin arrangements can still face differences in access, interoperability and legal treatment. The Bank for International Settlements has also noted that stablecoins do not automatically resolve the challenges in cross-border payments. A fallback remains necessary when the complete route cannot meet the business obligation. S6
For a route using USDGO with OSL Business, escalation records should identify whether the exception sits at the asset, issuer, OSL service, liquidity counterparty or bank layer.
The review frequency should match the company's exposure and operating activity. The policy should state a scheduled review date rather than relying on an informal check. It should also require a review after a material change, including:
a new legal entity, asset, network, provider, bank or trading venue;
a change to issuer, reserve, redemption or service terms;
a new jurisdiction or delivery form;
a limit breach, failed transfer, delayed completion or reconciliation exception;
a change to approval authority, wallet access or system integration; or
activation or failure of the bank fallback.
Each review should preserve the evidence cutoff, decisions, approvers and version history. PwC's treasury guidance similarly treats stablecoin use as an operational and control decision that requires governance, reconciliation and testing, rather than a transfer-only question. S4
A USDGO-related review should therefore refresh Anchorage issuer and reserve-attestation materials as well as the current terms for any relevant OSL Business service. S1S2S3
A corporate stablecoin treasury rebalancing policy converts forecasts and exposures into controlled transfer, hold or fallback decisions. It identifies each position, sets a target, floor and ceiling, establishes movement triggers, limits counterparties, assigns owners and defines what happens when the primary route cannot be used.
USDGO and OSL Business services can be evaluated within that policy. They do not replace it. The enterprise remains responsible for deciding where value may sit, how much may move, who may approve it and what evidence is required to close the decision.
The questions below show how the policy applies when an enterprise evaluates USDGO and the relevant OSL Business service.
Create a policy for each approved source-and-destination pair. Record the legal entities, accessible balances, target, floor, ceiling, asset and network, service providers, counterparty limits, owners and fallback. Transfer only when the documented need and every policy condition are satisfied.
Where USDGO and OSL Business are proposed, approve the asset and service roles separately.
Base the buffer on forecast obligations, forecast variation, access conditions, concentration tolerance and the time required to use an alternate route. A generic percentage cannot account for the company's actual operating and risk requirements.
Selecting USDGO or an OSL Business service does not determine the enterprise's buffer.
No. Usability can still depend on wallet authority, approved networks, service access, conversion or redemption conditions, recipient requirements and a final bank-delivery step.
A USDGO balance used with OSL Business still requires these route-level checks.
Use the approved fallback when the primary route cannot meet the obligation and the policy's activation condition has been satisfied. Confirm the status of the original instruction before releasing another payment.
The same control applies when a USDGO and OSL Business route is the primary route.
USDGO is evaluated at the asset layer. OSL Business Treasury may be assessed for foreign exchange, conversion, liquidity and treasury workflows, while OSL Business Payments may be assessed for collections, payments, settlement and payouts. Each role and counterparty requires separate review and approval.
This framework is provided for operational planning and does not constitute legal, accounting, tax, investment or regulatory advice. Stablecoin treasury workflows can involve issuer, liquidity, counterparty, operational, technology, legal and market risks. Each enterprise must approve its own limits, owners, evidence requirements and fallback arrangements.
References to USDGO and OSL Business do not mean that a route is available or suitable for a particular enterprise.
A cross-border stablecoin payout route should remain unapproved until the business can document the payer entity, beneficiary type, origin and destination, asset and network, local-delivery...
Cross-Border Stablecoin Payout Route Review Template: Eligibility, Local Delivery and Completion Evidence
Use this stablecoin infrastructure decision tree to choose a hosted, API, orchestration or hybrid model based on ownership, controls, records and fallback.
Who Should Own the Payment Workflow? A Stablecoin Infrastructure Decision Tree for Platforms
Download a provider-neutral stablecoin accounting data dictionary for mapping transaction IDs, statuses, fees, conversions, exceptions, journals and ledgers.
Stablecoin Accounting and Reconciliation Data Model: From Transaction ID to Month-End Close
Enterprises using stablecoins for cross-region treasury rebalancing need a written policy that defines where value may be held, when a transfer may begin, who approves it, how much exposure...
Corporate Stablecoin Treasury Rebalancing Policy: Liquidity Buffers, Counterparty Limits and Fallback Rails
Find current and historical USDGO issuer, reserve-attestation and redemption evidence, with report dates, coverage periods, evidence limits and update status.
USDGO Reserve, Attestation and Redemption Evidence Hub for Enterprise Review
Compare USDGO and USDC for corporate USD settlement using the same evidence date and a route-based treasury selection scorecard.
Which Stablecoin Should a Business Use for USD Settlement? A Treasury Selection Scorecard