Fiat to crypto on-ramp at a fintech: from pacs.008 receipt to USDC on chain, with proof at every step

A fiat to crypto on-ramp is the flow in which a fintech or neobank receives a conventional payment, an MT103 or a pacs.008 credited to its account at a sponsor bank, and delivers an equivalent amount of USDC to a wallet the client has nominated. The institution validates the originator of the fiat, screens the destination wallet, sources or mints the stablecoin, applies any FX, executes the on-chain transfer and records evidence at every step. This article walks through each of those steps as an operating procedure, with the controls, the owners and the records an examiner or a sponsor bank will expect to see.

What does the fintech receive, and how does it know who sent it?

The fintech does not usually receive the SWIFT message itself. Its sponsor bank receives the MT103 or pacs.008, credits the fintech's account, and passes the payment details through a statement, an MT940 or camt.053, or through an API notification. What the fintech sees is therefore a second-hand copy of the originator data, and the first control is to demand that the sponsor pass it through in full. The ordering customer in field 50, the ordering institution in field 52, the remittance information in field 70, and the UETR in field 121 should all reach the fintech. If the sponsor strips them to a narrative line, the fintech cannot do the work that follows.

The fintech then matches the receipt to a client order. The order was placed in the fintech's own platform before the fiat was sent and states the client, the amount, the currency, the destination wallet address and the chain. A well-designed order generates a unique reference that the client must put in the remittance information. The decision rule is simple. If the reference matches and the originator name on the fiat leg matches the KYC or KYB record of the client who placed the order, the receipt is attributed. If the name does not match, the receipt is a third-party payment and holds until the fintech understands why. Third-party funding is the most common route by which an on-ramp is abused, because it separates the person who passed KYC from the person whose money is moving.

Two further checks run on the fiat leg. The ordering institution is screened against sanctions lists and against the fintech's list of institutions it will not accept funds from. The amount is compared with the client's expected activity profile. A retail client onboarded to buy small amounts who receives a six-figure wire has changed profile, and the fintech should treat that as a review event before it proceeds.

How is the destination wallet screened before anything is minted or bought?

The destination wallet is screened before any stablecoin is sourced, because once USDC leaves the fintech's wallet it cannot be recalled. The address is run through a blockchain analytics provider for direct and indirect exposure to sanctioned addresses, mixers, darknet markets, ransomware and stolen funds. The fintech also checks whether the address belongs to a known VASP, in which case the Travel Rule applies and originator and beneficiary information must be transmitted to that VASP in IVMS101 form, or whether it is self-hosted, in which case the fintech must satisfy itself that the client controls it.

Proof of control is a specific procedure, not an assertion. The common methods are a signed message from the address, a micro-transfer from the address to the fintech, or the use of a wallet the fintech itself provides to the client. The policy states which methods are accepted and for which client tiers. The verification result, the method and the timestamp go on the client's record and are re-used for later orders to the same address. A new address triggers a new verification.

Compliance owns the disposition of any wallet hit. Operations may not release a flagged address on the basis that the client is a good customer. The exposure categories, the provider, the rule version and the analyst decision are written to the case file for the order, and a refusal is followed by a return of the fiat rather than a delivery to an alternative address the client offers on the spot.

• The sponsor bank's credit advice with field 50, field 52, field 70 and the UETR passed through in full.
• The client order with its unique reference, destination address and chain, and the match result against the receipt.
• The originator name match against the KYC or KYB record, and any third-party payment review.
• The destination wallet screening result with exposure categories and rule version, and the VASP or self-hosted determination.
• The proof-of-control record for the destination address and the Travel Rule transmission where a VASP is involved.
• The stablecoin sourcing ticket, the FX rate applied, the on-chain transaction hash and its confirmation record.

Where does the USDC come from, and how is the FX priced?

The fintech has three ways to obtain the USDC it owes the client. It can hold a working inventory of USDC in its own wallet, bought or minted in advance, and pay each order from inventory. It can buy on demand from a regulated liquidity provider or exchange against the fiat it has just received. Or, if it has an issuer account, it can mint directly with the issuer by wiring dollars and receiving USDC to its wallet. Minting is the cleanest source of funds but the slowest for a single order, so most institutions combine an inventory for immediate delivery with periodic minting or purchases to replenish it.

The inventory model raises a treasury question that the compliance team must also understand. Inventory is the fintech's own asset until it is delivered, so it sits on the balance sheet, is exposed to the custodian or to the fintech's own key management, and must be reconciled daily to the on-chain balance. The policy sets a maximum inventory, a replenishment trigger and a named owner. An inventory that drifts upward because nobody set a ceiling is the kind of finding that appears in a first examination.

FX applies when the fiat received is not in the stablecoin's currency. A client who sends euros and wants USDC needs a rate. The fintech either locks the rate at order time and carries the movement until the fiat arrives, which can be a day or more on a legacy rail, or quotes an indicative rate and fixes it when the fiat is credited. The client agreement must say which, and the rate actually applied must be recorded against the order. If the fintech marks up the rate, the mark-up must be disclosed as a fee where consumer rules require it.

An on-ramp is a promise made in fiat and kept in stablecoin. Every control between the two exists to make sure the person who made the promise and the person who receives the stablecoin are the same person, or are known to each other for a reason the institution can explain.

How is the on-chain delivery executed and confirmed?

Delivery is a signed transaction from the fintech's operating wallet to the client's verified address, for the exact amount in the order net of any disclosed fee, on the chain the client selected. The operating wallet is funded from the inventory wallet or the cold store in amounts sufficient for the day, with the transfer between them subject to a separate approval. Signing authority for the operating wallet is limited to the payment system and, for manual exceptions, to named individuals under a multi-signature or approval policy. A single engineer with a private key on a laptop is not an acceptable control at any volume.

The fintech records the transaction hash, block height and confirmation record, and marks the order as delivered only when the confirmation depth in its policy is reached. It then sends the client a confirmation that carries the hash so the client can verify independently. If the sponsor bank requires it, the fintech also sends a pacs.002 or equivalent status back through the sponsor so that the fiat leg is closed as fulfilled rather than left as a plain credit with no downstream record.

What does the fintech keep as proof of each step?

Proof is a case file per order, created when the order is placed, and written to by every subsequent step. It contains the items listed above, each time stamped by the system and each attributed to the person or automated rule that produced it. The file should be exportable as a single package, because that is how a sponsor bank's compliance team or a regulator will want to see it, and it should be tamper evident so that a later edit is visible as an edit.

Two aggregate records sit alongside the case files. A daily reconciliation ties fiat received at the sponsor to orders attributed, orders attributed to USDC delivered, and USDC delivered to the movement in the operating and inventory wallets. Any difference is an exception with a name against it. A hold register lists every order held, the reason, the age and the closure. Both are what an examiner asks for first, and both are what a sponsor bank will ask for monthly.

What goes wrong, and how are failures and returns handled?

The common failures are a fiat receipt with no matching order, a matching order whose originator does not match the client, a destination wallet that fails screening, a chain that is congested or halted at the moment of delivery, and a client who provides the wrong address. Each needs a written path. Unmatched receipts are returned to the ordering institution through the sponsor after a set period, by pacs.004 or an MT103 return carrying the original UETR, and are never converted. Third-party payments are held for enhanced review and returned if the relationship cannot be explained.

Failed wallet screens are refused and the fiat returned, with a report filed where the exposure warrants it. Chain problems delay delivery and the client is told; the fintech does not switch chains without a fresh instruction and a fresh wallet verification. A wrong address supplied by the client is the client's loss once delivered, which is why proof of control is confirmed before delivery and not after, and why the confirmation the client receives before delivery shows the address in full.

Where StableNet fits

StableNet, built by SpendTheBits, runs the fiat-to-crypto on-ramp as one of its nine settlement flows: it accepts an inbound MT103 or pacs.008, validates the originator against the KYC or KYB record, screens the destination wallet, applies KYT and sanctions and PEP screening, transmits Travel Rule data in IVMS101 form where a VASP is on the receiving side, and delivers USDC or USDT on public blockchains in minutes while the institution keeps custody of its own wallets. Every step is written to a tamper evident audit trail keyed to the UETR, and the pacs.002 status report closes the fiat leg with the on-chain reference. The B2B2C model lets a fintech or neobank offer the flow to its own consumers through an API-first integration, and the compliance workbench gives the compliance team the hold register and case file described above. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.