Executive summary
A card program can show plenty of liquidity and still be unable to prove that its next settlement obligation is funded.
Consider a synthetic Saturday file. A card program has a USD 1.25 million net settlement debit due at 14:00 UTC. Its treasury screens show more than enough value across several balances, plus an approved credit facility. A reviewer finds that only USD 800,000 is demonstrably usable for this settlement bucket at the review time.
The question is not “does the company have money?” It is: what amount is due, which entity must fund this particular card-settlement obligation, where must usable funds be by the relevant cutoff, and what evidence proves that the obligation was ultimately settled and reconciled?
The proposed Prefunding Control File is a reviewer method for answering that question. The name does not assume that every card program uses an identical prefunding architecture.
Start with the settlement obligation
An authorization hold is not automatically a settlement obligation. Neither is gross card spend, forecast purchase volume or a cardholder balance.
Visa’s public rules define a Settlement Amount as a daily net amount, expressed in a Member’s settlement currency, that results from clearing and includes transaction and fee-collection totals. The rules also state that, after submission of a clearing record, a Member must be ready to settle within the timeframe Visa specifies for the applicable settlement service and settlement currency.
The reviewer should therefore identify the authoritative clearing or settlement record, its version, the amount basis, settlement currency, value date and the applicable cutoff.
Evidence gap: the reviewed public Visa rules do not disclose the program-specific cutoff needed for a real card-program control file. Do not substitute a generic time.
Who actually owes or funds the settlement leg?
A role diagram is not evidence of financial responsibility.
Visa’s public rules contain different responsibility provisions across Member, issuer, sponsorship and regional contexts. The reviewer therefore should identify the network Member or other obligated party from the applicable governing evidence, rather than infer responsibility from a title such as issuer, sponsor, program manager or processor.
A program manager may operate the customer ledger. A processor may create transaction records. A custodian may hold the stablecoin. A lender may provide settlement financing. None of those role names alone proves who owes the reviewed network settlement debit.
Which stablecoin leg are you reviewing?
A stablecoin-linked card does not tell you what asset the merchant receives. It does not necessarily tell you that the network settlement leg itself is stablecoin-denominated.
Visa’s 2023 announcement described USDC moving between Visa and issuer or acquirer partners to settle fiat-denominated card payments. Rain’s public Rizon description gives a specific architecture in which the merchant is paid in local fiat while Rain settles with Visa in USDC.
The control file therefore separates cardholder funding, network settlement, acquirer payout, merchant payout and any conversion or FX leg.
A balance is not yet usable funding
The settlement reviewer needs to establish what amount the correct entity can actually use for the correct obligation by the correct cutoff.
| State | Reviewer question | Can it be counted automatically? |
|---|---|---|
| Shown | Does a screen or statement display the amount? | No |
| Owned | Does the relevant entity own or control it for this purpose? | No |
| Eligible | Is the currency/token/network accepted for this settlement route? | No |
| Unencumbered | Is it free of segregation, pledge or other use restriction? | No |
| Transferable | Can it move before the relevant cutoff? | No |
| Received / accepted | Has the destination or provider recognized the funding event? | Only for the relevant funding leg |
| Usable by cutoff | Do all required conditions hold for this obligation and time bucket? | Yes, for the defined bucket |
Circle Mint documentation illustrates the state problem: it distinguishes available and unsettled balances, documents bank-rail cutoffs and operating windows, and notes that a bank-side issue can return a payout. Those are Circle-specific facts, not Visa settlement rules, but they show why “onchain” and “usable now for this obligation” are different statements.
Financing changes the evidence chain
Visa’s September 2026 material describes Credit Coop providing stablecoin-denominated revolving settlement financing and describes Rain using such a facility for daily Visa obligations.
In the Rain example Visa refers to a daily VSS-110 file.
The reviewed public sources did not provide a public VSS-110 schema, so
the name should not be expanded into an invented report structure.
Visa also describes just-in-time funding as the next phase. The control file therefore keeps financing states separate: committed, available, requested, approved, drawn and received.
Review rule: an undrawn facility is not received funding. A draw request is not a receipt. Code behavior alone is not a legal enforceability conclusion.
The Prefunding Control File
The reviewer file ties one obligation bucket to its evidence.
- Obligation: entity, program, network, governing record, report version, currency, amount basis, value date and cutoff.
- Amount bridge: gross, net, fees, holds and adjustments, with revised records protected from double-counting.
- Funding: opaque account/wallet role, owner, currency, eligibility, restrictions and usable-by-cutoff state.
- Financing: committed, approved, drawn and received kept as distinct states.
- Closure: funding reference, destination/provider acceptance, network settlement evidence and reconciliation.
Opaque references are sufficient. The reviewer template should not contain private keys, credentials, PAN data or runnable banking instructions.
A synthetic walkthrough
The following numbers are training assumptions, not actual network requirements or recommended liquidity levels.
| Item at 11:00 UTC | Amount | Classification |
|---|---|---|
| Net settlement obligation | USD 1,250,000 | Due at synthetic 14:00 UTC cutoff |
| Eligible settlement-account balance | USD 700,000 | Verified usable |
| Eligible/accepted settlement-wallet amount | USD-equivalent 100,000 | Verified usable |
| Segregated customer balance | USD 300,000 | Excluded |
| Approved but undrawn financing | USD 250,000 | Conditional; excluded |
| Transfer without provider acceptance | USD 150,000 | Pending; excluded |
Verified usable funding is USD 800,000. Within this one
entity/currency/cutoff bucket:
max(0, 1,250,000 - 800,000) = 450,000.
That USD 450,000 is an arithmetic evidence gap, not a recommended draw, liquidity buffer or transaction.
At 12:35 the synthetic case records an additional USD 450,000 as received and accepted. At 13:05 an onchain transfer confirms. The confirmation supports the transport event; it does not automatically prove the card network has recognized the obligation as settled.
At 14:12 the synthetic case receives network settlement evidence. At 15:00 the reviewer matches the authoritative settlement report, funding records, settlement evidence and ledger. The file can then move to evidence-complete for this synthetic example.
Exceptions are part of the file
Revised settlement reports, duplicate/retry events, pending transfers, token/network mismatches, financing eligibility failures, FX differences, reserve changes and chargeback adjustments should remain explicit breaks until their evidence is resolved.
A chain transaction proves the chain event it records. A provider receipt proves the provider event it records. A network settlement record proves the corresponding network event. Reconciliation is what connects them.
Reviewer checklist
- Obligation: what authoritative record/version establishes the amount?
- Responsibility: which entity owes or guarantees this settlement leg?
- Time: what cutoff, timezone and value date apply?
- Funding: what was genuinely usable by that deadline?
- Financing: what was merely approved versus actually received?
- Stablecoin/FX: what token, network and valuation evidence apply?
- Settlement: what evidence shows the relevant destination/network accepted it?
- Reconciliation: can the reviewer trace report → funding → settlement → ledger?
What this does not prove
The Prefunding Control File does not prove that every stablecoin-linked card program requires the same funding structure. It does not recommend self-funding, borrowing, a token, network, lender, custodian or provider. It does not establish legal enforceability, accounting treatment, regulatory classification or control effectiveness.
It does one narrower job: make the reviewer show the chain from the card-settlement obligation, through funds that were actually usable by the applicable deadline, to evidence of settlement and reconciliation.
Methodology and sources
This article uses public Visa rules and settlement materials, public provider documentation from Rain and Circle, and an author-created reviewer framework. Company-specific financing descriptions are attributed to the organizations publishing them and are not treated as audited control assurance.
- Visa Rules and Policy
- Visa Core Rules and Visa Product and Service Rules
- Visa stablecoin settlement with merchant acquirers
- Visa USDC settlement in the United States
- Visa Onchain Settlement Financing
- Visa financing stablecoin-linked card programs
- Rain / Rizon case
- Circle Mint: minting and redemption
Method status: the Prefunding Control File, evidence states and synthetic walkthrough are author synthesis, not an industry standard or Treasury Desk production feature.
Critique the method using public or synthetic cases. Please do not send private settlement files, account details, wallet credentials, private balances or other sensitive financial records.