Crypto to fiat off-ramp for banks: from USDC receipt to MT103, leg by leg

A crypto to fiat off-ramp for banks is the sequence of controls that turns a stablecoin receipt into a conventional payment instruction. The bank receives USDC from a corporate client into a wallet it controls, screens the wallet and the funds, verifies the originator and the beneficiary, converts the stablecoin to fiat, and emits an MT103 or a pacs.008 to the beneficiary's bank. Each leg has an owner, a control and a record. This article walks through the flow leg by leg, from the moment the transaction confirms on chain to the moment the SWIFT message leaves the bank, and describes what the audit trail must contain at the end.

What arrives when a corporate client sends USDC to the bank?

The trigger is an on-chain transfer of USDC to a deposit address the bank has assigned to the client. That address is not a general-purpose vault. It is a receiving till, issued per client and, in a well-run programme, per expected payment, so that an inbound transfer can be matched to a payment instruction the client lodged in advance. The instruction carries the beneficiary name, account, bank identifier, currency, amount and purpose. Without it, the bank is holding unexplained value and cannot begin the compliance work.

The operations team watches for confirmation depth appropriate to the chain rather than the first block. The policy document states the number of confirmations, or the finality checkpoint, that counts as received for each network the bank supports. Until that point, the ledger entry is pending and nothing downstream moves. Once reached, the bank books the receipt to a client sub-ledger, records the transaction hash, block height, sending address, receiving address, token contract, amount and timestamp, and opens a case file keyed to that hash. The case file is the spine of the audit record.

One decision rule is worth stating at the outset. If the inbound amount does not match the lodged instruction within a tolerance the bank has set, the payment holds. Overpayments and underpayments are common when a client's treasury system rounds or when a sending exchange deducts a fee. The bank should never guess the client's intent. It asks.

How does the bank screen the wallet and the funds before they are accepted?

Wallet screening is the control that has no equivalent in a fiat inbound wire. The bank runs the sending address, and the transaction hash, through a blockchain analytics provider before the funds are credited to the client's available balance. The output is a risk score and a list of exposure categories: sanctioned addresses, darknet markets, mixers, ransomware, stolen funds, high-risk exchanges, and indirect exposure by hop count. The bank's policy sets the thresholds. Direct exposure to a sanctioned address is an automatic freeze. Indirect exposure above a set percentage within a set number of hops is a hold and an analyst review.

The compliance function owns this control, not operations. Operations may run the screen, but the disposition of a hold belongs to a named analyst, and the escalation of a freeze belongs to the BSA officer or the MLRO. The screening result, the provider, the version of the risk rules, the analyst decision and the timestamp are all attached to the case file. Examiners now ask for this. A screenshot of a green tick is not sufficient; the record needs to show what the rule set was on the day.

A second screen runs on the client's own wallet if the client self-custodies. The bank should know, from onboarding, which addresses the client has declared. A receipt from an undeclared address is an exception, even if the funds are clean, because it breaks the expectation set at KYB. Many banks treat the first receipt from a new address as a re-verification event and require the client to confirm control of it, typically by a signed message or a small test transfer.

Who verifies the parties, and what does the bank verify against?

The originator is the bank's own client, already onboarded under KYB. The bank still checks that the person or system instructing the payment is authorised, that the client's risk rating permits the corridor and the amount, and that the payment fits the expected activity profile recorded at onboarding. An exporter that receives USDC from buyers and pays suppliers in three countries has a profile. A payment to a fourth country is not forbidden, but it is a question.

The beneficiary is verified against the instruction and against sanctions lists. Name, account and bank identifier are screened, and the beneficiary bank's BIC is checked against the list of institutions the bank is prepared to send to. Fuzzy matching on the beneficiary name, with the threshold documented, catches transliteration variants. A hit on the beneficiary is worked in the same case file as the wallet screen so that a reviewer sees the whole payment in one place.

Because the inbound leg was a stablecoin transfer, the Travel Rule applies to the crypto leg and the funds transfer rule applies to the fiat leg. The bank should hold originator and beneficiary information in IVMS101 form for the on-chain receipt, received from the sending VASP where one is involved, and be able to reproduce it. If the sending party is the client itself from a self-hosted wallet, the bank records that fact and the verification of wallet control described above. The point is that when the MT103 leaves the bank, the ordering customer data in field 50 must be reconcilable to the originator data on the crypto leg. A gap between the two is the first thing an examiner will find.

• Wallet screening result and rule-set version, attached to the case before credit to the available balance.
• Declared-address check against the client's KYB record, with re-verification for any new address.
• Sanctions and PEP screening of the beneficiary name, account and bank, with the match threshold recorded.
• Corridor and amount check against the client's expected activity profile from onboarding.
• Originator data on the crypto leg reconciled to field 50 or the Debtor block on the fiat leg.
• Named approver for any hold release, with four-eyes approval on releases above a stated amount.

How are FX and liquidation handled, and who carries the price risk?

Liquidation is the step where USDC becomes a fiat balance the bank can pay from. There are three common models. The bank redeems directly with the issuer, which requires an issuer account and settles to the bank's own bank account, usually in US dollars. The bank sells through a regulated liquidity provider or exchange, receiving fiat to a nostro. Or the bank holds the USDC on its own balance sheet as a working balance and pays the fiat leg from existing liquidity, rebalancing later. Each model has a different counterparty exposure, and the treasury policy should say which is permitted and up to what limit.

The FX question is separate. If the beneficiary wants euros and the stablecoin is dollar-denominated, someone converts. The bank can quote the client an all-in rate at the point of instruction and lock it, carrying the risk between instruction and liquidation for the minutes that takes, or it can pass through the rate achieved. The instruction should state which. The chosen rate then appears in the outgoing message: field 36 in an MT103 when fields 32A and 33B differ, or the ExchangeRate element in a pacs.008. That is not decoration. It is the evidence that the client received the rate they were promised.

The wallet that receives the client's USDC is a till, not a vault. Value should pass through it in minutes, and anything that sits there overnight is a control failure waiting to be explained.

Treasury owns liquidation and FX. Compliance owns the release of the funds to treasury. The two sign-offs should be visible as separate events in the case file, and treasury should not be able to liquidate funds that compliance has not released. In a bank where both functions share a single operations queue, the segregation is enforced by the workflow tool, not by trust.

What goes into the MT103 or pacs.008 that the bank emits?

The outgoing message is where the stablecoin leg becomes invisible to the beneficiary bank, and that is exactly the point at which the bank must be most careful about what it says. In an MT103, field 20 carries the bank's reference, which should be the case file identifier so that any enquiry maps straight back to the audit record. Field 32A carries the value date, currency and settled amount. Field 50 identifies the ordering customer, the bank's client, with the structured option where the receiving bank requires it. Field 59 identifies the beneficiary. Field 70 carries remittance information, and field 71A the charge bearer. The UETR sits in the header, field 121, and must be generated once and never reused.

In a pacs.008 the same content is structured. The Debtor and DebtorAccount blocks carry the client, DebtorAgent carries the bank, CreditorAgent and Creditor carry the receiving side, InterbankSettlementAmount carries what moves between the banks, InstructedAmount and ExchangeRate carry what the client asked for and the rate applied, and RemittanceInformation carries the purpose. The message travels inside a head.001 business application header that names the sender and receiver. The bank should not describe the source of funds as a stablecoin conversion in the remittance field unless the receiving bank has asked for it; the remittance information belongs to the underlying commercial transaction, and the source-of-funds record belongs in the bank's own file.

Charges deserve one rule. If the client is paying the beneficiary a fixed invoice amount, the instruction is OUR, and the bank prices its own fee separately. SHA silently reduces what the beneficiary receives and generates the enquiry that costs more than the fee saved.

What does the audit record look like when the examiner asks?

An examiner reviewing an off-ramp programme wants to see one payment end to end, chosen by them, and then a sample of exceptions. For the chosen payment the bank should be able to produce, from a single case identifier, the client's lodged instruction, the on-chain transaction hash and its confirmation record, the wallet screening output with rule version, the declared-address check, the beneficiary screening result, the compliance release with the approver's name, the liquidation ticket with the counterparty and rate, the FX rate quoted to the client, the outgoing MT103 or pacs.008 as sent, the acknowledgement or pacs.002 from the receiving side, and the ledger entries that tie the whole thing out.

For exceptions, the examiner wants the holds, the reasons, the time each was open and who closed it. A hold log with no closures over a set age is a finding. A hold closed by the same person who opened it, above the four-eyes threshold, is a finding. The bank should be able to run these queries itself and should do so monthly.

The practical test is whether every record above is tamper evident and time stamped by a system rather than by a person. Spreadsheets that reconstruct the flow after the fact are the pattern examiners have learned to distrust. The record should be written as the flow runs, not assembled when the request arrives.

Where StableNet fits

StableNet, built by SpendTheBits, runs the crypto-to-fiat off-ramp described here as one of its nine settlement flows, with SWIFT payout by MT103 or pacs.008 as well as local clearing over ACH, SEPA and EFT. The inbound USDC leg settles on public blockchains in minutes with on-chain auditability while the bank keeps custody of its wallets. Wallet screening, sanctions and PEP screening, KYT and Travel Rule data in IVMS101 form are built in, and every decision is written to a tamper evident audit trail keyed to the UETR that carries through to the pacs.008 and the pacs.002 status report. Integration is API-first, so the bank's existing payment hub emits the SWIFT message from data the platform has already validated, and the compliance workbench holds the hold log an examiner will ask for. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.