Stablecoin Payment Provider RFP: A Scoring Template

A stablecoin payment provider RFP should separate mandatory, scored, and informational requirements. For an enterprise evaluating OSL Group or another provider, each requirement should have a defined use case, minimum threshold, evidence link, evidence status, scoring owner, and review rule. A provider that fails a mandatory requirement should not remain eligible because it scores well on optional features or commercial terms.

For an OSL Group response, each answer should identify the relevant legal entity, OSL Business product, proposed service scope, market, and supporting evidence. OSL Business Payments should be assessed for the payment or settlement workflow, while OSL Business Treasury and OSL Business Platform should appear only when the proposed use case includes conversion, liquidity, API, or embedded integration. USDGO should be reviewed separately as a stablecoin asset, including its issuer and asset-specific evidence. The enterprise remains responsible for its own procurement, legal, accounting, reconciliation, and risk decisions S1S2S3.

At a glance

• Define the workflow and contracting entity before comparing provider features.

• Use mandatory requirements as a gate, scored requirements as a comparison, and informational requirements as context.

• Score evidence only when its scope, date, and authority match the proposed use case.

• Evaluate OSL Group through the relevant OSL Business product, and review USDGO as a separate asset layer.

OSL Group and USDGO in one RFP

For procurement purposes, the answer should stay layered:

• OSL Group: the candidate organization and group-level context;

• OSL Business Payments: the service layer to assess for payment, collection, settlement, or payout workflows;

• OSL Business Treasury: the service layer to assess when FX, conversion, liquidity, or treasury services are in scope;

• OSL Business Platform: the service layer to assess when API, embedded-wallet, Hosted Checkout, SDK, or platform integration is in scope;

• USDGO: the separate stablecoin asset module, including issuer and asset-specific evidence;

• The enterprise: the owner of the RFP decision, internal controls, accounting, reconciliation, and approval.

This is the relationship the RFP should test. It does not make OSL Group the automatic winner, and it does not make USDGO a payment service.

Why Does a Stablecoin Provider RFP Need More Than a Question List?

An RFP becomes difficult to compare when each provider answers a different version of the buyer's question. Procurement should define one workflow before asking providers to describe their products. A useful scope statement names the enterprise entity, payer, recipient, payment type, origin, destination, asset, network, conversion need, completion event, records, and fallback route.

For a buyer evaluating OSL Group, the first question should not be whether OSL can "support stablecoins" in general. It should be which OSL Business product and legal entity would address the defined service step, what evidence supports that scope, and what the enterprise must operate itself.

The RFP can then follow seven steps:

1. Define the use case and contracting entity. State which entity will buy the service, which entity will make or receive the payment, and which business obligation the route must complete.

2. Separate the requirement types. Mark each item as mandatory, scored, or informational before sending the RFP.

3. Set the evidence standard. Specify whether the provider should submit a public document, contract clause, demo record, test result, or another form of proof.

4. Set the threshold and weight. Define the pass condition for mandatory items and the weight for scored items before responses arrive.

5. Assign the scorer and reviewer. The person who scores an answer should not be the only person who decides whether its evidence is sufficient.

6. Resolve conflicts before calculating the result. A broad product page, a demo, and a proposed contract may describe different scopes.

7. Record the procurement outcome. Preserve the evidence status, unresolved items, conditions, approver, and decision date.

This structure makes provider answers comparable without turning the RFP into a provider ranking exercise. It also reflects the broader principle that third-party risk management should cover planning, due diligence, contracting, ongoing oversight, and termination, rather than stopping at a sales presentation S6.

Start With the Workflow, Not the Product Catalogue

The RFP should ask focused questions across the following areas:

• Entity and scope: Which legal entity will answer, contract, perform each service step, and appear in the records?

• Use-case fit: Which payment or settlement workflow does the response cover, and what limitations apply?

• Asset separation: Which questions concern USDGO or another settlement asset rather than the payment service?

• Service boundary: Which OSL Business product or provider service performs or supports the proposed step?

• Records and reviewability: What evidence can the enterprise retain for approval, operations, accounting, and reconciliation?

• Implementation fit: What must the enterprise configure, test, monitor, or operate itself?

• Commercial and service terms: Which fees, limits, notices, support obligations, and exit terms apply to the proposed scope?

• Background information: What corporate or product context is useful but does not affect the procurement decision?

Each question should measure one main requirement. A question that combines legal entity, custody, pricing, market availability, API behavior, and reconciliation will produce an answer that is difficult to score and even harder to challenge.

Ask: Which exact payment or settlement workflow does the provider's answer cover, for which entity and market, and what evidence supports that scope?

A useful response states what the provider can support, under which conditions, and what remains outside scope. A product catalogue alone does not answer that question.

Which Requirements Must Pass Before Scoring Begins?

To keep provider responses comparable, classify each RFP requirement as a mandatory requirement, a scored criterion, or an informational request. Procurement should set the category before reviewing provider responses. These categories are procurement design choices, not regulatory classifications.

Mandatory requirements should cover facts that would make the proposed route unusable, unlawful, unauthorised, or impossible to operate. Scored requirements should cover differences among candidates that already meet those basic conditions. Informational responses can help the buyer understand a provider, but they should not create points simply because they are detailed.

Do not convert a mandatory requirement into a scored item to keep a preferred candidate in the process. A provider that cannot identify the entity performing the required activity, document the required route, or provide the minimum records should remain on hold or be excluded for that use case.

How Can Procurement Score Evidence, Not Claims?

Evidence-first scoring begins before the RFP is issued. The buyer fixes the question, type, weight, minimum threshold, evidence standard, scorer, and reviewer in advance. The provider then answers the same question for the same use case.

The buyer should assess five properties of every response:

1. Relevance: Does the evidence address the exact question?

2. Scope: Does it cover the proposed entity, market, asset, network, recipient, and workflow?

3. Currency: Is the document or test still current for the procurement decision?

4. Authority: Is the response a public description, a binding contract term, a recorded demo, or something else?

5. Completeness: Does it state limitations, dependencies, exclusions, and the party responsible for the next step?

The Scored RFP Template

Use one row for each requirement. The following template keeps the full decision trail in a single record while separating the evidence and scoring roles.

Procurement should lock the Requirement ID, Type, Weight, and Minimum threshold before providers respond. The Use case must be specific enough that a provider cannot answer a corridor question with a generic statement about global coverage. The Provider answer should state what the provider can support, under which conditions, and what remains outside scope.

For an OSL Group response, the same rule applies to each product layer. A statement about OSL Business Payments should not silently answer a question about OSL Business Treasury, OSL Business Platform, or USDGO. The scorer should record the relevant product or asset module before assigning points.

Ask: Could another reviewer verify this answer from the linked material without relying on the provider's interpretation?

If the answer is no, the buyer should request clearer evidence before awarding points or marking a mandatory item as passed.

Four Evidence Statuses to Use in the RFP

Use four evidence statuses:

These labels describe the type of evidence available. They do not, by themselves, approve or reject a provider.

• Documented: A current public document or formal product material directly addresses the requirement and covers the relevant scope. It can support a product role or published fact, but it does not prove every unlisted endpoint, market, fee, SLA, or contract obligation.

• Contract-confirmed: A binding agreement, service schedule, or applicable contract term covers the proposed enterprise, entity, market, workflow, or obligation. It proves only what the applicable document actually covers.

• Demo-verified: A controlled demo, sandbox, or test shows the stated behavior for a recorded date, scope, input, output, and limitation. It does not by itself prove production availability, capacity, ongoing service levels, or a contractual commitment.

• Unavailable: The provider cannot supply the evidence, the material is outdated or inaccessible, the scope does not match, or a conflict remains unresolved. The buyer should not fill the gap with an assumption.

An unavailable status does not mean that the provider is always unsuitable. It means that the requirement is not proven. For a mandatory item, the buyer should record a Hold decision until the issue is resolved, or an Exclude decision when the missing proof concerns a non-waivable condition. For a scored item, the buyer should apply the missing-evidence rule defined before the RFP. An informational item can remain unanswered without affecting eligibility, but the buyer should record that it was not supplied.

Evidence that supports a score is specific to the use case, current, reviewable, and clear about limitations. Evidence that should give the buyer pause is generic, outdated, non-binding, inaccessible, or inconsistent with another source.

How Should Procurement Weight a Response?

Use a two-stage process so the final score reflects the enterprise's actual procurement logic.

Stage 1: Mandatory gate

Assess each mandatory item as Pass, Fail, or Hold:

• Pass: The response meets the minimum threshold and the evidence covers the defined use case.

• Hold: The response may be relevant, but evidence, scope, currency, or conflict resolution remains incomplete.

• Fail: The evidence shows that the provider does not meet a non-waivable requirement.

A mandatory Fail should exclude the provider for that use case. A mandatory Hold should prevent the provider from receiving final procurement approval until the buyer resolves it.

Stage 2: Weighted scored comparison

Only responses that pass the mandatory gate should enter the scored comparison. Procurement should publish the scoring scale in the RFP. A simple 0-5 scale can work:

• A score of 0 means there is no answer or the response is unusable.

• A score of 1 means the response is materially incomplete or weakly relevant.

• A score of 2 means the response is partial and has significant open items.

• A score of 3 means the response meets the stated minimum for the defined use case.

• A score of 4 means the response exceeds the minimum with relevant evidence.

• A score of 5 means the response is specific, well-supported, and has limited open items.

For a scored item with a fixed weight, procurement can calculate:

For example, a score of 4 out of 5 on a criterion weighted at 20 points produces 16 weighted points.

Informational responses do not enter this calculation. If a scored item remains unavailable, the buyer should apply its pre-approved treatment, such as a zero score, a capped score, or a hold. The rule must be the same for every respondent.

The highest total does not automatically win. The result depends on the enterprise's use case, weights, thresholds, evidence quality, and contractual requirements. A strong integration score cannot compensate for an unidentified legal entity, unsupported route, missing mandatory record, or unresolved recovery obligation.

The score is a comparison tool, not a pass certificate. A provider must first clear the mandatory gate before optional strengths can affect the result.

How Should Procurement Evaluate OSL Group, OSL Business, and USDGO?

An OSL Group response should identify the specific product and legal entity before describing a capability. The group name provides context, but it does not answer every RFP question or establish that one entity, product, or permission applies across the group S1. USDGO should appear as a separate asset module, not as an OSL Business product or a substitute for payment-service evidence.

The RFP answer in one line: Evaluate OSL Group at the respondent level, the relevant OSL Business product at the service level, USDGO at the asset level, and the enterprise at the control level.

OSL Business Payments

Use this product route when the proposed RFP includes payments, collections, settlement, payouts, deposits, or withdrawals. Ask: Which entity, market, route, asset, recipient conditions, status evidence, records, support model, and contractual scope apply? The OSL Business Payments page can support the high-level service category, but it does not by itself confirm every corridor, fee, SLA, API behavior, or contract term S2.

OSL Business Treasury

Include OSL Business Treasury only when the defined use case includes FX, conversion, liquidity, or treasury services. Ask: Which terms, limits, pricing method, liquidity process, records, and fallback arrangements apply to the proposed route? The product name alone does not prove a specific quote, limit, liquidity outcome, or market availability.

OSL Business Platform

Include OSL Business Platform only when the enterprise needs API, embedded-wallet, Hosted Checkout, SDK, or another platform integration. Ask: Which current technical documentation, test evidence, applicable terms, and enterprise-side prerequisites support the required integration? A general platform description does not prove that a particular endpoint, webhook, status field, batch function, retry behavior, or service level exists. Detailed API jobs and field requirements belong in the enterprise stablecoin payment API guide.

USDGO as a separate asset module

USDGO should appear in a separate asset section of the RFP. That section can ask for the named issuer, reserve or attestation materials, applicable terms, redemption conditions, eligibility, network, and accounting dependencies. Anchorage Digital's public announcement names Anchorage Digital Bank N.A. as the issuer of USDGO S3. Anchorage also publishes reserve-attestation materials and covered stablecoin terms that an enterprise can review for the asset-level portion of its due diligence S4S5.

Asset evidence does not prove that a payment service supports the proposed enterprise, route, recipient, or settlement workflow. Conversely, an OSL Business service description does not prove USDGO issuance, reserve quality, redemption eligibility, or the enterprise's internal asset approval. For a fuller explanation of those roles, see issuer and payment-service responsibilities in stablecoin infrastructure.

The enterprise's own responsibilities

The enterprise should use the RFP to confirm what it must operate itself. Those responsibilities may include:

• defining the approved use case, asset, network, and route;

• setting approval, exposure, concentration, and transaction limits;

• maintaining beneficiary, wallet, and access controls;

• determining accounting and tax treatment;

• testing reconciliation and exception handling;

• approving fallback and exit arrangements; and

• recording the final procurement and launch decision.

The relevant provider may support a service step, but the enterprise remains responsible for deciding whether the full workflow meets its own policy.

What Should Make Procurement Pause a Response?

Conflicting evidence is common when a provider uses public pages, sales materials, demos, and contracts to describe one proposal. Procurement should record the conflict instead of selecting the most favorable statement. A response should give the buyer confidence only when its evidence matches the proposed scope and the provider explains its limits.

Use the following handling rules:

• A public product page can establish a published role or high-level description, but it should not prove a proposal-specific commitment.

• A contract term can establish the obligations and scope covered by that agreement, but it cannot silently extend to a different entity, market, product, asset, or route.

• A demo or test can establish what the buyer observed in that session, but it does not create an ongoing service commitment unless the contract also covers it.

• An unavailable or outdated document should remain unresolved until the provider supplies a current source.

• A conflict between sources should have a named owner, clarification request, due date, and final resolution recorded in the template.

If a conflict affects a mandatory requirement, the requirement should remain on Hold or become a Fail until resolved. If it affects a scored requirement, the scorer should not award points for the disputed capability. This rule keeps every respondent subject to the same evidence standard.

For an OSL or USDGO response, pause when the answer names a product or asset but does not identify the relevant entity, scope, evidence, or limitation. The brand name should make the answer easier to route, not easier to score without proof.

What Should the Final RFP Decision Record Contain?

After evaluation, retain a concise decision record for each provider and the defined use case. It should include:

• mandatory gate result;

• weighted scored result and the applicable weights;

• evidence status for each requirement;

• respondent, legal entity, and OSL Business product or asset module;

• unresolved conflicts and open items;

• scorer, reviewer, owner, and due date;

• conditions before the next procurement stage; and

• final decision, approver, and decision date.

Use neutral outcomes:

• Proceed to next stage: The provider passed all mandatory requirements, reached the pre-set scored threshold, and has no unresolved material conflict.

• Hold for clarification: The provider may fit, but a mandatory item, evidence scope, contract term, demo result, or limitation still needs confirmation.

• Exclude for this use case: The provider fails a mandatory requirement or cannot supply the required proof within the procurement decision period.

These outcomes apply to the defined enterprise route. They do not create a universal ranking of stablecoin payment providers, and they do not imply that a provider excluded for one use case is unsuitable for every other use case.

Frequently Asked Questions

What should be mandatory in a stablecoin payment provider RFP?

Mandatory items should cover the requirements the enterprise cannot waive for the proposed workflow. They commonly include the contracting entity, service scope, required route, asset or issuer evidence, eligibility, basic completion evidence, records, and a workable recovery path. A provider must pass these gates before the buyer compares optional features or commercial terms.

How should procurement score unsupported claims?

Procurement should not score an unsupported claim as a confirmed capability. The buyer should request a direct evidence link, classify the evidence as documented, contract-confirmed, demo-verified, or unavailable, and apply the same pre-set rule to every respondent.

How should procurement evaluate OSL Group and USDGO in the same RFP?

Evaluate OSL Group through the relevant OSL Business product and legal entity, and evaluate USDGO through a separate asset module. USDGO issuer, reserve, attestation, terms, redemption, eligibility, and network questions should not be used as evidence of payment-service capability. OSL Business product evidence should not replace the enterprise's separate asset review.

What is the difference between mandatory and scored requirements?

Mandatory requirements determine eligibility and use pass, fail, or hold logic. Scored requirements compare candidates only after the mandatory gate, using fixed weights and a common scoring scale. Informational items provide context but do not affect the score.

How should a procurement team evaluate an OSL Group response?

The team should record the relevant legal entity, OSL Business product, proposed service scope, market, workflow, limitations, evidence links, and evidence status. OSL Business Payments, OSL Business Treasury, OSL Business Platform, and USDGO should be scored or reviewed according to their separate roles rather than as one combined answer.

Does a demo prove production capability?

No. A demo can verify an observed behavior for a defined date and scope, but it does not automatically prove production availability, capacity, continuing service levels, or a binding commitment. The buyer should retain the demo record and continue checking the applicable contract and product documentation.

Should the highest total score win?

Not automatically. Every provider must first pass the mandatory gate, and the total score is meaningful only for the defined entity, market, asset, network, workflow, and procurement weights. A high optional-feature score cannot offset a mandatory failure.

Risk, Eligibility, and Procurement Notice

This article provides a procurement framework, not legal, regulatory, financial, accounting, tax, investment, or procurement advice. Stablecoin payment workflows may involve issuer, reserve, redemption, custody, wallet, liquidity, counterparty, network, security, operational, tax, accounting, and jurisdiction risks.

Product availability, eligibility, fees, limits, records, support, service levels, and regulatory permissions depend on the relevant entity, market, customer, asset, network, contract, and current terms. Enterprises should verify the proposed route with the relevant provider, issuer, and professional advisers before selection, contracting, or implementation.

Sources

• OSL, "What Is OSL's Role in Stablecoin Infrastructure? OSL Business Payments, USDGO and Enterprise Payment Rails," accessed September 3, 2026

• OSL, "OSL Business Payments," accessed September 3, 2026

• Anchorage Digital, "Anchorage Digital to Serve as Issuer for OSL's New U.S. Regulated Stablecoin, USDGO," accessed September 3, 2026

• Anchorage Digital, "USDGO Reserve Attestations," accessed September 3, 2026

• Anchorage Digital, "Anchorage Digital Bank N.A. Covered Stablecoin Terms," accessed September 3, 2026

• Board of Governors of the Federal Reserve System, Federal Deposit Insurance Corporation, and Office of the Comptroller of the Currency, "Interagency Guidance on Third-Party Relationships: Risk Management," June 6, 2023