Welcome to USD1rfp.com

What an RFP means for USD1 stablecoins

An RFP (request for proposal, a structured document used to compare vendors) is the right tool when a business needs more than a price sheet. In the context of USD1 stablecoins, a strong RFP is not mainly about who can issue or move coins quickly. It is about who can explain, in writing, how redemption works, how reserve assets are managed, who has legal responsibility, what compliance controls exist, and how the service behaves under stress. That matters because global authorities still do not use one universal legal definition for the kinds of assets described here as USD1 stablecoins, and the regulatory treatment can differ by function, risk, and jurisdiction.^[1][3][8]

For procurement teams, the practical goal is comparability. Two vendors may both say that USD1 stablecoins are backed one-for-one by U.S. dollars or short-dated instruments, yet the real user experience can be very different. One vendor may allow timely redemption at par (a one-for-one exchange rate) for all holders, while another may reserve direct redemption for a narrow class of institutional clients. One vendor may keep reserve assets with clear segregation (keeping assets separate from house assets), while another may rely on more complex legal arrangements that require deeper review. Treasury and international standard setters have repeatedly highlighted differences in reserve composition, disclosure, operational design, and user claims, which is why an RFP should push responders past slogans and into evidence.^[1][2][3]

It also helps to separate an RFP from nearby procurement terms. An RFI (request for information, an early market scan) is useful when your team is still mapping the market. An RFQ (request for quote, a price-led request) works when the service has already been tightly defined and commercial terms are the main unknown. A project involving USD1 stablecoins usually starts with more uncertainty than that. Legal rights, blockchain support (support for specific shared digital ledgers), sanctions controls, custody design, reporting depth, and outage handling can all differ in ways that affect the true cost of ownership. A detailed RFP creates a structured way to compare those differences before integration work begins.

A well-written RFP should therefore answer one question above all: if your organization uses USD1 stablecoins for payments, treasury movements, or customer balances, what must be true on the day everything is normal, and what must still be true on the day something goes wrong? International guidance places heavy weight on governance, redemption, disclosure, risk management, data access, and contingency planning. Your procurement document should do the same.^[1][2]

Start with the use case, not the token

The most common mistake in this area is to begin with the asset label instead of the business workflow. A procurement team should first describe what it wants to do with USD1 stablecoins in plain operational language. For example, a platform may want to buy USD1 stablecoins with U.S. dollars, distribute them to approved counterparties, and later redeem remaining USD1 stablecoins for U.S. dollars. A treasury team may want same-day settlement between affiliated entities. A marketplace may want short-term balances for sellers before cash redemption. Each of those use cases creates a different priority order.

The use case determines which questions belong in the RFP. If the main purpose is treasury movement, redemption rights, reserve quality, and liquidity planning (planning for how cash stays available during heavy outflows) usually carry the most weight. If the main purpose is customer payouts, wallet design, sanctions screening, throughput (how many transactions can be handled over a period), and support coverage may matter just as much. If the service is intended for multiple regions, the legal mapping becomes central because authorities can classify and supervise similar products through different frameworks. The Financial Stability Board notes that there is no universally agreed legal or regulatory definition for this product category, and its recommendations are meant to be applied in a technology-neutral, function-based way. In the European Union, the MiCA framework creates specific disclosure and redemption rules for e-money tokens. In the United States, the Treasury report focused on prudential and payment-system risks and highlighted differences in redemption rights, wallet structures, and reserve disclosures.^[1][3][8]

That is why the first page of an RFP for USD1 stablecoins should identify at least five basics. First, who will hold the asset: your company, your customers, or both. Second, where the users are located and where counterparties are located. Third, what funding path is expected, including bank wires, internal ledger moves, or on-chain transfers. Fourth, how quickly U.S. dollars must be available after redemption. Fifth, what failure scenario is least acceptable, such as a frozen address, a delayed redemption, a chain outage, or missing reporting data.

This use-case framing also helps teams avoid overbuying. Some responders will emphasize every supported chain, every wallet feature, and every dashboard widget. Those can be useful, but they are secondary if the core legal and operational requirements are not yet nailed down. In many cases, fewer chains, clearer rights, and better reporting are more valuable than a wider technical footprint.

Redemption rights and reserve assets

For most buyers, this is the heart of the RFP. If a response is vague here, the rest rarely compensates for it. Ask the responder to describe redemption in exact terms: who may redeem, in what size, through which channel, at what fee, within what timing window, and under what conditions a delay can occur. If an intermediary fails, ask whether users can still reach the issuer directly or whether the failure of a wallet or exchange partner can block access. The Financial Stability Board recommends a robust legal claim and timely redemption, with no undue minimum thresholds or fees that become a practical deterrent. The U.S. Treasury report likewise observed that redemption rights vary widely across arrangements, including who can present coins for redemption and whether minimums, delays, or suspensions are allowed.^[1][3]

The reserve side deserves equally precise questions. A good response should identify what assets are held in reserve, who holds them, whether they are segregated, how often they are reported, and how quickly they can be converted into U.S. dollars during heavy outflows. The Financial Stability Board recommends conservative, high-quality, highly liquid reserve assets and emphasizes that reserve assets should be unencumbered, readily convertible, and protected through segregation from the issuer, group entities, and custodians. Treasury warned that public information about reserve assets has not been consistent across arrangements in either content or release frequency, and that different products have used reserve portfolios with meaningfully different risk profiles.^[1][3]

This section of the RFP should therefore ask for the latest reserve disclosure, the reserve investment policy, the legal terms governing user claims, and the most recent independent review. If the responder provides an attestation (an independent accountant's report on selected information rather than a full examination of every risk), ask what exactly was tested, on what date, and whether the report covers only a point in time or a wider period. If the responder claims daily transparency, ask whether that means on-chain supply only, a published reserve report, or both. Those are not the same thing.

For teams serving European users, it is also sensible to ask how the responder aligns its disclosures with MiCA-style expectations. MiCA requires a crypto-asset white paper (a formal disclosure document) for relevant products, includes warnings that an e-money token is not covered by investor compensation schemes or deposit guarantee schemes, and states that holders have a right of redemption at any time and at par value, subject to stated conditions. Even if your use case sits outside the European Union, these requirements are a useful benchmark for disclosure clarity.^[8]

A practical RFP section on reserves should ask at least the following:

• What is the legal nature of the user's claim?
• Who can redeem directly for U.S. dollars?
• Are there minimum redemption sizes?
• Are there timing commitments for normal days and stress days?
• What assets are eligible for the reserve?
• What maturity, concentration, and liquidity limits apply?
• Who is the custodian of reserve assets, and how are those assets segregated?
• What publication schedule exists for reserve reporting?
• What happens if a banking, custody, or wallet partner becomes unavailable?
• What wind-down plan exists for orderly redemption if the product is discontinued?

If you only have room for one scoring gate in an RFP, make it this one. Fast integration is useful. Clear redemption rights are fundamental.

Network design, transfer rules, and settlement finality

Once redemption is defined, the next question is how USD1 stablecoins actually move. In this section, many responders will focus on speed. Your document should instead focus on transfer rules, settlement finality (the point after which a transfer is treated as complete and cannot be unwound), and operational dependencies. The BIS guidance says that a systemically important arrangement should provide clear and certain final settlement by the end of the value date and ideally intraday (within the same business day), supported by a clear legal basis and robust mechanisms that keep ledger state and legal finality aligned.^[2]

That is more demanding than a simple statement like "transactions settle in seconds." A public blockchain (a network that is openly accessible) may show rapid confirmations, but the business question is whether your finance team, compliance team, and counterparties all agree on the point at which value is final for accounting, risk, and customer support purposes. Ask responders to define finality per supported chain, to describe how they handle forks (chain splits into competing versions), network congestion, reorganization risk (risk that recent transaction history is revised), bridge risk (risk created when moving assets across chains through an intermediary or protocol), and chain-specific outages, and to explain whether internal transfers are recorded off-chain (inside the provider's own books) or on-chain (recorded on the shared ledger). Treasury noted that some arrangements use public blockchains while others rely on permissioned blockchains (networks with controlled access), and that these designs create different tradeoffs around transparency, responsibility, speed, and predictability.^[3]

Interoperability (the ability to work across systems and networks) belongs here too. If your team expects USD1 stablecoins on more than one chain, ask whether minting and redemption are centralized into one legal arrangement or split across multiple entities. Ask how supply is reconciled across chains, how bridge exposure is managed, and whether a transfer between chains is treated as a process that destroys units on one chain and recreates them on another or as reliance on a third-party bridge. The point is not to reject multi-chain support. The point is to see whether the responder can explain it clearly enough for risk, treasury, and audit teams to sign off.

Operational reporting should be tied to this section. Ask for settlement files, transfer status messages, reversal handling, failed transfer logic, address screening flow, and time stamps that support reconciliation (matching internal records to external records). If a responder says "we support real-time settlement," your follow-up should be "real-time according to which legal, technical, and accounting definition?"

Governance, legal accountability, and third-party reliance

Procurement documents often fail when they ask about features but not accountability. International guidance is much less forgiving. The Financial Stability Board says governance and accountability should be clear, transparent, and disclosed, including the roles of operators, reserve managers, custodians, and user-facing service providers. It also says arrangements should explain conflicts of interest, limits of liability, data responsibilities, and how reliance on third parties does not prevent compliance or resilience.^[1]

For a buyer, this means the RFP should ask for a legal-entity map. Which company issues USD1 stablecoins? Which company holds reserve assets? Which company operates user onboarding, wallet services, customer support, and transaction monitoring? Which law governs the user terms? Which court or dispute process applies? Which services are outsourced? If a validator set, node operator, custody partner, or bank fails, who is still responsible to the holder?

This section should also ask for change management (the process for approving and communicating service changes). If the issuer changes reserve policy, supported chains, redemption procedures, banking partners, or core smart contract logic, what notice must users receive? What approval process exists? What emergency powers exist, and who can use them? FSB guidance emphasizes disclosures around governance, conflicts, risk management, and user rights, while BIS guidance stresses that even novel or more decentralized designs still need clear lines of responsibility and timely human intervention when required.^[1][2]

A responder that leans heavily on the word decentralized without identifying accountable legal entities is not necessarily unusable, but it is asking the buyer to absorb ambiguity. That may be acceptable for a small experiment. It is not a strong answer for a serious treasury, payments, or enterprise balance-sheet use case.

Recovery and resolution planning also belongs here. Ask whether the responder has a recovery plan (how service continues after a severe disruption) and a wind-down plan (how activities are closed in an orderly way if continuation is no longer possible). The Financial Stability Board explicitly recommends recovery and resolution planning for arrangements involving USD1 stablecoins, along with clear data access and continuity of critical functions.^[1]

Custody model and wallet control

Custody (safekeeping of assets and the credentials that control them) can determine whether your use of USD1 stablecoins feels like a treasury instrument, a payments rail, or an operational hazard. Start by asking who controls the private key (the secret credential that allows control of a blockchain wallet). If the service is custodial, ask whether assets are held in segregated wallets, omnibus wallets (pooled wallets that hold assets for multiple clients), or internal ledger accounts. If the model is non-custodial, ask who manages key recovery, transaction approval, and policy enforcement for your staff.

This part of the RFP should connect directly to your use case. A company that only needs occasional redemption may prefer tighter controls, slower approval flows, and stronger separation of duties. A company making time-sensitive payouts may need broader availability, policy-based approvals, and more flexible funding paths. Neither approach is automatically better. The right question is whether the responder can explain how the custody model supports both safety and day-to-day operations.

International guidance gives useful benchmarks. The Financial Stability Board says reserve assets should be safely held, properly recorded, segregated, and protected against claims of creditors of the issuer or custodian. The BIS guidance likewise points to robust accounting practices, safekeeping procedures, internal controls, and legal protection for reserve assets placed in custody. Treasury also highlighted the importance of wallet providers in the transfer and storage chain and recommended stronger oversight for custodial wallet providers in the payment context.^[1][2][3]

A strong response should therefore cover wallet architecture, approval policies, disaster recovery, fraud controls, and incident handling for compromised keys or mistaken transfers. It should also explain whether insurance exists, what it covers, what it excludes, and whether it is provided by the responder, the custodian, or a third party. Insurance language should never substitute for an explanation of controls.

Compliance, sanctions, and cross-border rules

Any RFP for USD1 stablecoins should have a serious compliance section, even if the business case is narrow. FATF guidance says virtual asset service providers, or VASPs (businesses that exchange, transfer, or safeguard digital assets for others), have the same full set of obligations as other covered financial institutions for anti-money laundering and countering the financing of terrorism. FATF also highlights the difficulty of cross-border activity, the importance of risk-based supervision, and the need to manage Travel Rule requirements, which involve sharing originator and beneficiary information with covered transfers. Its 2025 targeted update adds that jurisdictions are still at different stages of licensing, registration, and Travel Rule implementation, and that risks linked to these products and offshore VASPs should be considered in supervisory frameworks.^[4][5]

In the United States, OFAC states that sanctions compliance obligations apply equally to transactions involving virtual currencies and those involving traditional fiat currencies. That means your RFP should not accept vague phrases such as "we screen wallets" or "we are compliant with sanctions laws." Ask instead which screening tools are used, how often sanctions lists are refreshed, how indirect exposure is handled, how the responder manages blocked property, what escalation path exists, how address clustering risk is evaluated, and what records are retained for investigations or reporting.^[7]

For cross-border use, ask the responder to provide a jurisdiction matrix. Where can it legally onboard business customers? Where can it support consumer-facing flows? Which countries are restricted? Which services are offered only through partners? How are respondent VASP relationships reviewed? FATF's guidance on cross-border relationships makes clear that weak or non-existent supervision in another jurisdiction raises money-laundering and terrorist-financing risk, and that firms should understand the controls used by counterparties.^[4]

This is also the right place to ask about peer-to-peer exposure. If your use case allows users to withdraw USD1 stablecoins to self-hosted wallets (wallets controlled directly by the user rather than by a service provider), ask what risk controls apply before and after the transfer, what monitoring continues after withdrawal, and what triggers enhanced review. If your use case is fully closed-loop (where transfers stay inside the provider's controlled system), ask how the responder prevents unintended external transfers. Either way, compliance design should match the operating model rather than sit beside it as a generic policy document.

Cybersecurity and operational resilience

Even a legally sound structure can fail through weak operations. NIST's Cybersecurity Framework 2.0 is particularly helpful for procurement because it is written for executives, acquisition professionals, and risk teams as well as technical staff. It highlights GOVERN as a core function and recommends using Profiles and gap analysis to compare the current state of controls with a desired target state.^[6]

That maps well to an RFP. Instead of asking only whether the responder "uses best practices," ask it to map its controls to a recognized framework such as NIST CSF 2.0 and to explain how governance, asset awareness, identity controls, monitoring, incident response, and recovery are handled. Ask for the responder's current profile, target profile, open gaps, and planned remediation dates if it already uses that language internally. If it does not, ask for equivalent materials in plain English.

The Financial Stability Board also expects comprehensive risk management, operational resilience, cyber safeguards, continuity planning, timely reporting of data, and access to information needed for oversight.^[1] Put those expectations into procurement terms. Ask about role-based access (limiting permissions by job role), privileged access (elevated system permissions), key management, logging retention, backup protection, disaster recovery testing, tabletop exercises (practice drills for severe incidents), penetration testing, and third-party risk management. Ask for recovery time objective (how quickly the service should be restored) and recovery point objective (how much recent data loss is acceptable after a disruption). Ask whether these commitments differ for issuance, redemption, custody, and API access.

A mature response will also address communication. During an incident, who is notified, how quickly, through which channels, and with what degree of detail? What events count as material (serious enough to matter to users or operations)? Can the responder produce a post-incident report that separates root cause, customer impact, remediation, and control improvements? Technical strength matters, but operational clarity matters just as much.

Data, reporting, and treasury operations

Many projects involving USD1 stablecoins look attractive until the finance team sees the reporting feed. An RFP should ask for examples of account statements, API responses, reconciliation files, transaction exports, reserve reports, fee reports, and support logs before a contract is signed. The Financial Stability Board recommends robust frameworks for collecting, storing, safeguarding, and reporting data, including protection of both on-chain and off-chain information.^[1]

Treasury and accounting users usually need more than a simple public transaction viewer. They need opening and closing balances, time stamps, chain identifiers, internal reference fields, fee attribution, user or counterparty identifiers where lawful, and a stable way to match redemptions to bank-side receipts. If the responder offers only CSV files (comma-separated files, a simple tabular export format), ask about field definitions and versioning (how changes are tracked over time). If it offers APIs (application programming interfaces, software connections used to exchange data), ask about pagination (how results are split across multiple pages of data), change notices, cutoff conventions (the time boundaries used for same-day processing), and historical data access. Machine-readable disclosure is also a theme in MiCA, which requires crypto-asset white papers to be made available in machine-readable form for covered products.^[8]

This section should also cover books-and-records support (support for retaining and exporting business records). How long is data retained? Can your auditor retrieve prior-period information? Can your team export raw activity if it decides to leave the platform? Are failed transfers and compliance holds clearly labeled? How are internal transfers distinguished from on-chain transfers? When the answer is "our dashboard shows that," the RFP should push for something more durable.

A good practical test is to ask the responder to walk through one full cycle: fund in U.S. dollars, receive USD1 stablecoins, send them to a counterparty, receive them back, redeem them, and reconcile every step across wallet records, platform records, and bank records. If the responder cannot explain that life cycle clearly before procurement closes, your operations team will have to learn it under pressure later.

Commercial terms and exit rights

Commercial review should come after the structural questions, not before them. Price matters, but it is meaningful only after rights, controls, and operating assumptions are understood. An RFP should ask for every fee tied to USD1 stablecoins, including issuance, redemption, custody, account maintenance, urgent support, address screening, compliance review, and any fee linked to blockchain network activity. If fees are passed through from a third party, ask which party sets them and how much notice is given before a change.

Service-level agreement, or SLA (a written commitment on uptime, response times, and support handling), belongs here as well. Ask for uptime commitments for APIs, custody actions, redemption requests, and reporting access. Ask what credits or remedies apply when service falls below the promised level. Just as important, ask which services are outside the SLA. Some providers commit only to the dashboard while treating redemptions or compliance reviews as best-efforts processes (services attempted without a firm timing promise). That may be acceptable, but it should be explicit.

Exit rights are often neglected until they are urgently needed. Ask how your organization can leave. Can it redeem all holdings in an orderly way? How quickly can data be exported? What notice applies if the responder stops supporting a chain, a region, or a product feature? Can frozen or under-review balances still be reported and tracked during offboarding (ending the vendor relationship and moving out)? Does the contract require assistance with migration to another provider? The Financial Stability Board's focus on recovery, resolution, and continuity makes these offboarding questions more than legal housekeeping. They are core resilience questions.^[1]

How to score responses

A scoring model should reflect the use case, but it should not treat every category as equally important. For many organizations, a sensible starting point is to give the highest weight to legal redemption rights and reserve transparency, followed by compliance coverage, custody and security, operational reporting, network design, and then price. The exact numbers will vary, yet the ordering often should not.

One practical method is to use pass-fail gates first, then weighted scoring. Pass-fail gates might include a named legal issuer, a clear statement of who may redeem, published reserve information, a sanctions control framework, a documented incident response process, and a data export path. Only responders that pass those gates move into detailed scoring. This approach mirrors the spirit of international guidance, which puts basic rights, risk control, governance, and operational resilience ahead of convenience features.^[1][2][6]

After the gates, your weighted review can compare the remaining responders on narrower dimensions. For example, a payout-heavy use case may assign more weight to wallet operations and support coverage. A treasury-heavy use case may assign more weight to reserve composition, redemption timing, and bank-side settlement. A cross-border use case may raise the weight on licensing, sanctions operations, and Travel Rule handling. The purpose of scoring is not to make the decision automatic. It is to make the tradeoffs visible.

Common red flags

Several warning signs appear again and again in weak responses.

The first red flag is a responder that says USD1 stablecoins are fully backed but does not identify the reserve assets, the custodian, the publication schedule, and the legal nature of the holder's claim. Treasury and the Financial Stability Board both stress that reserve composition, disclosure, and user rights can differ in ways that matter under stress.^[1][3]

The second red flag is heavy emphasis on chain count with little discussion of finality, bridge exposure, and reconciliation. BIS guidance makes clear that transfer rules, legal finality, and settlement risk matter as much as technical speed.^[2]

The third red flag is a compliance answer that lists policies but does not describe controls. FATF and OFAC both point toward risk-based, operational compliance rather than generic statements of intent.^[4][5][7]

The fourth red flag is unclear accountability. If the response does not identify the issuer, reserve manager, custodian, wallet operator, and governing law, your team is being asked to infer the answer from product language. That is not a sound basis for enterprise procurement.^[1][2]

The fifth red flag is the absence of a credible exit path. If a responder cannot describe how balances are redeemed, data is exported, and customer support continues through an offboarding event, the relationship may be easy to start and hard to leave.

Frequently asked questions

What should an RFP for USD1 stablecoins include?

At a minimum, it should cover the business use case, user locations, redemption rights, reserve composition, custody design, supported networks, settlement finality, compliance controls, cybersecurity, reporting, fees, and exit support. Those topics map closely to the areas stressed by FSB, BIS, Treasury, FATF, OFAC, NIST, and MiCA-style disclosure rules.^{[1][2][3][4][6][7][8]}

Is a reserve attestation enough?

Not by itself. An attestation can be useful, but an RFP should also ask what was tested, what date it covers, what exclusions apply, how often it is updated, what legal claim holders have, and how redemptions work in normal and stressed conditions. International guidance consistently treats disclosure as only one part of a broader control set that includes governance, redemption, custody, and risk management.^[1][3]

Are USD1 stablecoins the same as bank deposits?

No. A response should explain the difference clearly rather than imply that the two are interchangeable. Treasury discussed how arrangements for USD1 stablecoins can differ from insured bank deposits in legal claim, oversight, and treatment of reserves, and MiCA requires warnings that certain covered tokens are not protected by deposit guarantee schemes.^[3][8]

Should technical speed outweigh redemption rights?

Usually not. A fast transfer is useful only if your organization also understands who stands behind the asset, how quickly U.S. dollars can be obtained through redemption, what happens under stress, and how finality is defined. BIS and FSB place heavy weight on final settlement, risk control, and user rights rather than headline speed alone.^[1][2]

Can one RFP cover the United States, the European Union, and other regions?

Yes, but only if it forces each responder to map its legal structure and operational controls by jurisdiction. FATF highlights cross-border compliance complexity, MiCA creates specific disclosure and redemption expectations in the European Union, and U.S. authorities have focused on prudential, payment, and sanctions issues. A global RFP should therefore ask for jurisdiction-specific answers rather than one generic response.^{[3][4][5][7][8]}

In the end, a good RFP for USD1 stablecoins is less about predicting every future rule and more about forcing clarity today. It should show your legal team what rights exist, your treasury team what liquidity looks like, your security team how failures are handled, and your operations team what daily reconciliation will require. If a responder can explain those things with precision and supporting documents, it is giving you something far more useful than marketing confidence: it is giving you an operating model.