From Stablecoin Pilot to Production Ops: The Integration Readiness File

Start with the stage, not the headline

The simplest way to avoid readiness inflation is to preserve each source’s own stage language.

The Bank of England describes its Synchronisation Lab as a non-live environment for building and testing prototypes against simulated settlement functionality. Nuvanté’s September 2026 announcement describes a stablecoin-clearing prototype tested against that Lab. That can support a feasibility discussion. It does not turn the Lab into live RTGS production settlement.

Visa and Nium use different language. Their August 2026 BLOOM announcement describes a pilot exploring stablecoin settlement seven days a week, including weekends and public holidays. That is evidence of a bounded trial and a settlement-window question being tested. It is not evidence that liquidity, controls, reconciliation, accounting close, exception handling and support all operate continuously.

Live product availability is another stage. Nium states that its Coinbase integration is live and available to clients for USDC-related funding and payment flows connected to fiat payout infrastructure. Circle separately announced CPN Managed Payments and documents managed flows that include screening, conversion, onchain movement, bank endpoints, reporting and reconciliation support.

Even “production” needs calibration. BCP publicly describes a first $GOVY transaction settled using tGBP and uses “in production” language. In the reviewed public evidence, that is still participant-authored evidence of a first transaction—not an independently verified record of recurring operating scale.

The practical lesson: stage labels tell you what kind of evidence to ask for next. They do not replace that evidence.

A successful transaction is narrower than a closed operating process

Current payment and stablecoin documentation makes that gap visible.

A payment flow can involve a business obligation, payment instructions, identity or screening data, fiat funding, stablecoin conversion, wallet or custody dependencies, onchain confirmation, bank payout, internal ledger posting, reconciliation records and exception states.

A transaction hash may be important evidence inside that chain. It is not the whole chain.

Circle’s current CPN documentation, for example, describes payment requests, beneficiary information, FX quotes, operational wallet funding, onchain confirmation, fiat payout states, webhooks and reporting. Coinbase’s Payment Acceptance documentation similarly exposes authorization, capture, refund, settlement, webhooks and transaction-level reconciliation files.

Those artifacts do not prove that every exception has been resolved. They do show why “the chain confirmed” and “the financial event closed” are different review questions.

A production-oriented review needs to preserve the state transitions that matter to finance operations:

• What obligation was the payment supposed to discharge?
• Which system became authoritative at each state?
• When did the onchain leg confirm?
• When did the fiat leg complete?
• When did the internal ledger post?
• When did reconciliation close?
• What remained unmatched or unresolved?
• Who owned the exception?

That is the difference between proving that a transaction can happen and showing how an operating process is expected to close.

24/7 settlement is a rail clock, not an operating model

Always-on or extended-hours settlement can be useful, but it is easy to overread.

SoFi’s September 2026 announcement says access to the SoFi Exchange Network enables U.S. dollar clearing and settlement 24 hours a day, seven days a week. Visa and Nium are exploring seven-day settlement in their BLOOM pilot. Stablecoin payment providers also document continuous or extended settlement capabilities.

But the Bank of England’s work on extending RTGS and CHAPS settlement hours surfaces a separate set of questions: liquidity management, value dates, accounting close, reconciliation, operating-model changes and staffing.

That distinction gives reviewers a useful frame: treat the operating model as several clocks rather than one.

1. Settlement clock — when the rail can accept and settle the relevant instruction.
2. Liquidity clock — when fiat and stablecoin inventory, redemption and FX are actually available.
3. Control clock — when required screening, authorization and approval functions operate.
4. Reconciliation and close clock — when books, reports and breaks are matched and closed.
5. Exception clock — when failed, delayed or ambiguous states are detected, owned and resolved.
6. Fallback clock — when an alternate rail or manual process can be invoked and tested.
7. Support clock — when the humans or systems responsible for escalation are available.

The Integration Readiness File

The file’s job is to make three things visible: what is documented, what is observed, and what is still missing.

A reviewer should be able to finish the file with an evidence disposition such as:

• DOCUMENTED FOR REVIEW
• PARTIAL — MISSING OPERATING EVIDENCE
• PILOT/LAB ONLY — NOT PRODUCTION EVIDENCE
• LIVE CAPABILITY — RECURRING OPERATING EVIDENCE NOT FOUND
• CLAIM BLOCKED — SOURCE OR SCOPE INSUFFICIENT

Those are evidence labels for review, not product certifications.

What recurring operating evidence would add

A technically successful implementation can show that APIs connect, a transaction can be created, chain state can confirm, a fiat leg can be initiated or a simulated settlement lifecycle can complete.

Recurring operating evidence asks harder questions:

• Did funding and liquidity remain available across the required operating window?
• Were transactions consistently mapped to the original obligation and internal ledger?
• Did reconciliation close, and what happened to aged breaks?
• Which exceptions occurred, who owned them, and how were they resolved?
• Did control functions operate through the required hours?
• Did fallback work when a preferred provider or rail failed?
• Were monitoring events complete and timely?
• What happened during incidents, degraded modes or liquidity stress?
• Was the process repeatable across the period, assets, corridors and counterparties being claimed?

For the central cases reviewed for this article, a complete public evidence set covering those dimensions was not found. That does not mean private operating evidence does not exist. It means the public claims should stop where the public evidence stops.

A better production-oriented discussion

The point of an Integration Readiness File is not to create a new badge.

It is to improve the quality of the conversation before a badge appears.

A pilot review can say what was tested, under what conditions, and—where results are reported—what worked. A launch review can say: this capability is available according to this source. A first-transaction review can say: these participants report that a live transaction occurred.

A production-oriented operating review should go further: here are the funding states, liquidity dependencies, controls, finality definitions, ledger mappings, reconciliation results, exceptions, monitoring paths, fallback evidence and named owners. Here is what was observed repeatedly. Here is what remains untested or unknown.

That gives reviewers a stronger basis for a decision because it preserves the difference between technical possibility, product availability and recurring operating evidence.

What this does not prove