What stablecoin operations expose about your financial controls

A payment went out at 2am on a Sunday. It settled in seconds. The approval flow it was supposed to pass through still assumed a business day, a batch window, and a human at a desk who would not be back until Monday. By the time anyone looked, the funds were gone, the counterparty was confirmed, and there was nothing to recall.

Nothing about that payment was exotic. The stablecoin behaved exactly as designed: instant, final, and indifferent to your office hours. What it exposed was older than the digital asset. The control around the payment was built for a world where money took one to two days to move, and that world quietly stopped existing the moment your company started settling onchain.

And this is no longer an edge case. Stablecoins have moved out of crypto and into mainstream finance: companies now pay suppliers, settle invoices, and hold operating cash in them.

That is the real shift. The risk in holding stablecoins is often priced as if it lives in the asset: the peg, the issuer, the chain.

The risk that actually bites lives in the seam between settlement-in-seconds rails and controls designed for settlement-in-days. Stablecoins did not create that gap. They removed the latency that had been hiding it.

The risk you price is not the risk that bites

Issuer, peg, chain and reserve backing are real risks. But they are not where the operating model breaks.

The asset moves the same way every time. Your operating model does not.

The mismatch is between two clocks: the clock the money runs on, which is now seconds, and the clock your controls run on, which is still inherited from ACH, wires and nightly batch processing. A control that fires after settlement is not a control on a rail that settles instantly. It is a record of something you can no longer change.

That is the reframe the rest of this piece runs on. The gap is measured in time and steps: when the money moved, when approval resolved, when screening ran, when the transaction reached the system of record, and when evidence became available.

Four gaps where the lag shows up

The lag is not abstract. It surfaces in four specific places in a treasury operating model, the same timing defect read off four different desks. None of these are blockchain problems. Each is a control-timing problem that stablecoins have made visible, and the same gap appears in your own records the moment you can see both rails at once.

The four gaps, in the order finance teams tend to hit them:

• Settlement versus approval. The payment settles before the approval workflow resolves. Your policy says two signers and a business-day review. The rail says done. Stablecoins settle 24/7/365 with finality in seconds, and payment flows do not wait for office hours: in our analysis of cross-chain USDC settlement, institutional transactions clustered on an exact three-minute cycle around the clock, the signature of scheduled treasury operations running on machine time, not a business-day cadence.
• Screening versus execution. Sanctions and counterparty screening run on a schedule. Settlement runs in real time. When the screen and the rail disagree on timing, the screen loses: the money has already moved by the time a freeze takes effect. Our study of onchain enforcement found more than 6,000 addresses that were already at a zero balance when they were frozen, with the typical freeze arriving anywhere from 24 hours to a week after the funds had left.
• Wallet activity versus the ERP. A transaction settles onchain in seconds and only lands in your system of record at month-end if someone remembers to label the address. Until then, it lives in a spreadsheet that does not reconcile. The onchain counterparty universe can outrun manual labeling: the same cross-chain analysis counted 545,258 unique senders in a single year of USDC flows, 62.8% of whom transacted only once. That is the environment your treasury reconciles against, a long tail of addresses your books have never seen.
• Audit expectation versus producible evidence. Your auditor expects a statement. What you can hand them is a block explorer link and assurance that the address is yours. That is not audit-grade, and the issuer denylists you might lean on instead are incomplete: that same enforcement study found only about 36% of OFAC-listed stablecoin addresses are actually blacklisted by their issuers, so 'it is flagged if it is risky' is not a control you can sign off against.

With stablecoins, the settlement clock sped up, but the control clock did not. None of these gaps is unsolvable by hand, but manual discipline does not help with a counterparty you have never seen until after it has paid you, and no amount of labeling moves a control to before the money moves. The reason this is hard to see from inside one team is that no single tool in a conventional treasury stack watches both clocks at once.

Why single-rail tools cannot see the seam

A fiat-first treasury management system is good at what it was built for. It sees bank accounts, balances, forecasts, and approvals on rails it understands. It does not see a wallet. When stablecoin support arrives, it often arrives as a tab: a place to paste an address and a balance, not a control surface that screens transfers before they broadcast.

A chain-first explorer has the opposite blind spot. It reads the onchain side fluently, every hop and every counterparty, and knows nothing about the bank account the funds came from or the policy that should have governed the transfer. It is a forensic tool, which means it is built to tell you what already happened.

Each tool sees one rail clearly. The gap that hurts you lives in neither rail alone. It lives in the seam between them - in the moment a payment crosses from your bank context into an onchain settlement your fiat system cannot reach, and your explorer can only describe after the fact. You cannot measure a lag you can only see half of.

To close the gap, something has to watch both clocks on the same record before the transaction executes.

What closing the gap actually takes

Seeing both rails is only the first step. The control also has to move to the only point where it still has authority: before the transaction executes.

A batch that runs every hour instead of every night is still a control that fires after settlement on a rail that settles in seconds.

This is what pre-execution enforcement means: a control runs at the moment of intent, before the money moves and the transfer becomes irreversible, and it can block. Sanctions screening, counterparty risk, and your own business policy rules resolve while you can still act on the answer, not after the funds have left. On an instant-finality rail, that is the only place a control is still a control.

Closing the gap requires a single record across both rails. Onchain wallet activity and bank activity need to reconcile to the same source, rather than two systems that meet at month-end. Range connects wallets, custodians, exchanges, and bank accounts into one real-time view: all your sources, one ledger:

• The Unify layer, where Treasury, Transaction Reconciliation, Counterparty Management, and Reporting and Intelligence close the wallet-versus-ERP gap and feed enriched onchain data into the accounting tools you already run.
• The Protect layer, where Transaction Screening, Counterparty Risk and Travel Rule, Threat and Fraud Prevention, and Treasury and Portfolio Risk close the settlement-versus-approval and screening-versus-execution gaps.

Audit-ready records are produced as a byproduct of both layers, so the answer to the auditor's question is a record, not a forensic project. Total financial control across stablecoins and fiat is the outcome of those two layers add up to.

Crucially, Range is the onchain compliance and risk layer fiat tools were never built to provide. It does not replace your compliance vendor or accounting system. It integrates with them and adds the treasury context they were not built to hold: the same counterparty matched across a wallet, a bank account, and a CEX deposit address, screened on the same record before anything settles.

Range currently protects $30B+ in customer assets, screens tens of billions in payment volume each month, and connects 10,000+ banks, custodians, and wallets to a single ledger. Across the market, we track 99.41% of all stablecoin payments, regardless of token or chain. The point of those numbers is not breadth for its own sake. It is that watching both clocks at once is only possible if you can see both rails everywhere they run.

The teams whose controls survive

There is a version of stablecoin treasury that treats the onchain side as a tab in the old system: a use case bolted onto a model built for fiat. It works until the first payment you actually need to stop, and then the seam shows.

The teams whose controls hold are the ones that move the control to where the risk actually happens: before execution. They put stablecoins and fiat on one ledger, screen onchain transactions before settlement, and keep the audit trail tied to the transaction from the start.

The coin was never the hard part. The plumbing around it, the reconciliation, controls, audit trail, and counterparty risk, is the work. That is the work Range was built to do.

Identify the gaps in your own controls. Book a demo.