Sourced news briefing

Federal Reserve Board published the development on 24 September 2026. The Board requested comment on two proposals for Board-supervised payment-stablecoin issuers. The first would require full backing with permissible reserve assets, including certain high-quality liquid assets, and would set capital and risk-management standards. It also addresses safekeeping of reserve assets and clarifies certain activities for supervised banks. The second proposes an application process for supervised banks seeking to issue payment stablecoins. The comment period closes 60 days after Federal Register publication.

This briefing reports only the source announcement. These are proposals, not final rules, and their scope is limited to the entities and activities described by the Board. The remaining sections are independent FixPays analysis for merchants; they are not claims made by the Federal Reserve Board.

Independent analysis: reserve and redemption evidence

A merchant accepting or settling in a stablecoin needs to understand who issues it, what supports redemption and which intermediary actually owes the merchant money. Identify the issuer and redemption counterparty. Document the approved token, network and wallet addresses. Define what happens if redemption is delayed or suspended. For implementation, name an accountable owner, the authoritative system, the exception route and the evidence retained after each decision.

The file should include current issuer disclosures, provider terms, asset and network approval, and an escalation threshold for price or liquidity stress. Review the arrangement by entity, market, currency, payment method and customer journey where those dimensions matter. A provider announcement cannot replace contract review, testing or a documented assessment of the merchant's actual operating model.

Independent analysis: custody and operational control

Reserve rules for issuers do not remove a merchant’s wallet, key-management, screening, transaction-finality or provider concentration risks. Separate initiation and approval of wallet movements. Control address changes independently. Test recovery from provider or network interruption. For implementation, name an accountable owner, the authoritative system, the exception route and the evidence retained after each decision.

Evidence should connect access logs, allowlists, screening results, transaction hashes, accounting entries and final bank credits. Review the arrangement by entity, market, currency, payment method and customer journey where those dimensions matter. A provider announcement cannot replace contract review, testing or a documented assessment of the merchant's actual operating model.

Independent analysis: legal and accounting boundaries

The same token may be used for customer payment, treasury transfer or provider settlement, but those uses create different contracts and accounting events. Map each flow separately. Confirm customer disclosures and refund treatment. Obtain jurisdiction-specific advice before launch. For implementation, name an accountable owner, the authoritative system, the exception route and the evidence retained after each decision.

A flow diagram should show title, liability, conversion, fees and the point at which the merchant recognizes settlement. Review the arrangement by entity, market, currency, payment method and customer journey where those dimensions matter. A provider announcement cannot replace contract review, testing or a documented assessment of the merchant's actual operating model.

Independent analysis: merchant implementation checklist

Verify whether every provider and issuer sits within the proposal’s stated scope. Connect that control to the treasury map and retain the result in a counterparty file. Test a successful transaction and a realistic failure, then record what changed, who approved the response, how customers were treated and whether finance could reconcile the final outcome.

Document reserve, redemption and custody dependencies. Connect that control to the approved-asset register and retain the result in a wallet-control log. Test a successful transaction and a realistic failure, then record what changed, who approved the response, how customers were treated and whether finance could reconcile the final outcome.

Test a refund after conversion between fiat and stablecoin. Connect that control to the refund workflow and retain the result in a reconciliation archive. Test a successful transaction and a realistic failure, then record what changed, who approved the response, how customers were treated and whether finance could reconcile the final outcome.

Reconcile a transaction across chain, provider and bank records. Connect that control to the provider agreement and retain the result in a legal change register. Test a successful transaction and a realistic failure, then record what changed, who approved the response, how customers were treated and whether finance could reconcile the final outcome.

Set thresholds for network, liquidity and counterparty incidents. Connect that control to the treasury map and retain the result in a counterparty file. Test a successful transaction and a realistic failure, then record what changed, who approved the response, how customers were treated and whether finance could reconcile the final outcome.

Keep proposed requirements separate from current binding obligations. Connect that control to the approved-asset register and retain the result in a wallet-control log. Test a successful transaction and a realistic failure, then record what changed, who approved the response, how customers were treated and whether finance could reconcile the final outcome.

Commercial review should cover service levels, settlement timing, data duties, incident handling, customer support, termination rights and migration assistance. Finance should model both normal volume and stressed conditions rather than relying on a headline feature or a successful demonstration.

After launch, monitor authorization, abandonment, unmatched items, reversals, refunds, complaints, fraud, support effort and settlement differences using stable definitions. Segment results sufficiently to expose a corridor, method or product that performs differently from the portfolio average.

A controlled pilot should define scope, duration, success measures, stop conditions and rollback ownership. Preserve transaction traces and customer communications so reviewers can distinguish a product limitation, integration defect, user error, provider incident and deliberate risk decision.

Finance should reconcile the treasury map with the approved-asset register on a stated timetable. Unmatched items need aging, ownership and escalation thresholds. A manual journal can correct accounting, but it should never erase the original variance, the investigation evidence or the reason a difference occurred.

Customer support needs status language that reflects the underlying system rather than guessing from a single dashboard. Staff should distinguish authorization, acceptance, processing, settlement, reversal and refund, then use a counterparty file to locate the authoritative reference before promising a time or outcome.

Risk teams should compare new behavior with established baselines while allowing for legitimate changes in channel and geography. Monitoring should reveal concentrated failures and unusual sequences without treating every unfamiliar pattern as fraud. Confirmed weaknesses belong in a wallet-control log with an owner and response date.

Data governance matters because a new payment route often adds identifiers, vendors and cross-border transfers. Record which party receives each field, why it is needed, how long it remains available and how an access or correction request reaches the responsible organization.

Provider due diligence should be refreshed when the product, contracting entity, settlement account or subcontractor changes. Review permissions, financial and operational dependencies, security responsibilities, complaint cooperation and termination support. Evidence should describe the current service rather than an earlier sales presentation.

Review beneficiary identity pricing data retention complaint fulfilment relevant merchant payment customer provider settlement refund dispute reconciliation risk compliance operational contractual financial technical security privacy support exception approval testing incident change ownership decision evidence implementation monitoring governance records carefully.

What it means to Merchants

For merchants, the proposals make reserve quality, custody structure and redemption mechanics more concrete due-diligence questions. The development does not by itself establish availability, eligibility, pricing, legal permission or a FixPays capability. Merchants should compare it with their entities, products, markets, provider terms and live controls, then ask specific questions and test the full payment lifecycle before changing production.