Every crypto exchange that lets customers fund accounts in pounds or euros has to connect two systems that were never designed to talk to each other: the traditional banking network, which moves money between regulated institutions, and the exchange's own ledger, which records what each customer is owed. Fiat deposit and withdrawal is the seam between them, and it is one of the most demanding parts of an exchange to operate — not because moving money is novel, but because every transfer has to be attributed to the right account, reconciled against an external record, and cleared against financial-crime and safeguarding obligations before it can be trusted.
This article examines that seam from an architectural standpoint: what a fiat on- and off-ramp is made of, where the hard problems sit, and what a decision-maker should expect in a platform's design. It stays at the level of concepts and controls rather than configuration, and it concerns the fiat layer within a wider crypto exchange software platform, where moving real money, rather than tokens, brings the traditional financial system and its rules directly into scope.
Two Ledgers That Must Agree
A fiat rail joins two independent records that must always agree. On one side is the bank or payment account where customer money actually sits, whose truth is the statement issued by a regulated institution. On the other is the exchange's internal ledger, which credits and debits each customer's balance as they trade, deposit and withdraw. A deposit is only real once both records reflect it; a withdrawal is only complete once money has left the external account and the internal balance has been reduced to match.
The engineering problem is keeping those two in step at all times, across timing differences, failed and returned payments, and partial or mislabelled transfers. Money can arrive at the bank before the exchange knows whom it belongs to, or a payout can be instructed internally before it settles externally. The infrastructure exists to close those gaps deliberately — to attribute, confirm and reconcile every movement — rather than assume the two ledgers stay aligned.
Deposit Rails and Attribution
A deposit begins on a payment rail. In the euro area that is usually a SEPA credit transfer, increasingly its instant variant; in the United Kingdom it is typically Faster Payments; cross-border amounts may arrive by SWIFT; and some venues accept card funding through an acquirer. Each rail differs in how quickly it settles, whether the payment can later be reversed, and how much information travels with it — differences that shape both customer experience and operational risk.
The recurring difficulty is attribution: when a credit lands in a pooled account, the exchange has to determine which customer it belongs to. A shared reference number that customers must quote is fragile, because people mistype or omit it, leaving payments to be matched by hand or returned. The stronger the attribution mechanism, the less manual intervention a deposit flow needs and the sooner funds can be credited with confidence — which is why the way an exchange identifies incoming money is a central design choice rather than a detail.
Virtual IBANs and Named Accounts
Virtual IBANs address the attribution problem directly. A vIBAN is a unique account identifier issued to an individual customer that routes to an underlying settlement account; because each customer pays into an address that is theirs alone, an incoming credit identifies its owner by the account it arrived at, without relying on a reference the sender has to enter correctly. Named accounts achieve the same end where a dedicated account is opened for each customer.
For an operator, virtual IBANs turn attribution from a matching problem into a routing one, reducing the manual handling that pooled accounts demand and making deposits credit-on-arrival for most customers. They are typically provided through a banking or payment partner, and the exchange integrates with that partner's rails — which is why fiat funding and the e-money platform software that underpins it are closely related capabilities. The value of a vIBAN scheme lies in how cleanly it attributes funds and how it behaves at the edges, since shared, corporate or third-party payments still need deliberate handling.
Withdrawal Controls and Payouts
Withdrawals reverse the flow and carry a different risk profile. Sending money out is where an exchange is most exposed to fraud, mistaken instructions and the movement of illicit funds, so a payout path is defined as much by its controls as by its rails. A withdrawal is checked against the customer's verified identity and available balance, screened before it leaves, and — for larger amounts — subjected to additional approval, so that no single instruction moves funds unchecked.
Because some rails allow payments to be recalled or returned, the infrastructure also has to handle money that comes back after it was sent, reversing the internal entry and re-crediting the customer correctly. Matching a payout to a beneficiary the customer has genuinely verified, rather than to a newly supplied and unchecked destination, is a core control against both fraud and money laundering. Outbound money follows a defined, evidenced path rather than an ad hoc one.
Reconciliation and Settlement
Reconciliation is the process that keeps the internal ledger and the external accounts in agreement, and it is continuous rather than occasional. Each entry on a bank or partner statement is matched to a movement the exchange recorded, and any difference — a credit with no matching deposit, a payout that never settled, a fee not accounted for — is surfaced as a break to be investigated and resolved. Settlement timing complicates this: rails clear on different schedules, so the two records are frequently out of step for legitimate reasons, and the system has to distinguish an expected timing gap from a genuine discrepancy.
Note: Reconciliation is not a periodic clerical task but a continuous control. A platform should evidence that every external movement is matched to an internal entry, that breaks are identified and worked promptly, and that the reconciled position — what is held, and for whom — can be demonstrated at any time rather than assembled after the fact.
An operator should be able to show its reconciled position at any moment: how much fiat is held, in which accounts, and against which customer balances. The table below sets out the common fiat rails and what to weigh for each.
| Rail | Attribution | Settlement | Reversibility |
|---|---|---|---|
| SEPA credit transfer | Identified by the account paid into; the instant variant carries richer data | Same day, or seconds on the instant scheme | Limited — recalls are exceptional and cooperative |
| Faster Payments | Account-based, though a reference is often required in pooled models | Near real time | Limited, but returns and indemnity claims occur |
| SWIFT | International; intermediary detail can obscure the true sender | Slower, often several days | Variable and largely manual |
| Card funding | Attributed to the card and cardholder | Fast to authorise | High — chargebacks make card deposits harder to treat as final |
AML at the Fiat Boundary
The point where fiat enters and leaves is also the point where financial-crime controls concentrate. A deposit is an opportunity to understand the source of a customer's funds; a withdrawal is an opportunity to check where money is going and whom it reaches. Payments are screened against sanctions and other watchlists, unusual patterns are monitored, and flows that do not fit a customer's established behaviour are held for review before they complete.
Doing this without stalling legitimate customers is the balance every venue has to strike, and it depends on screening and monitoring being built into the payment path rather than bolted on after settlement. Fiat and crypto movements are assessed together, so that the picture of a customer is not split across two disconnected systems. Grumpio's approach places AML screening software in line with the funding flow, so that checks run as money moves rather than in a separate queue that money has already passed.
Regulated Partners and Safeguarding
Handling customer fiat brings obligations that handling crypto alone does not. Money held for customers has to be kept separate from the operator's own funds and safeguarded, and in most designs the fiat leg runs through a regulated payment or e-money partner, or the operator's own permission, rather than the crypto business alone. Registration under the money-laundering rules, which a cryptoasset firm needs, does not by itself amount to authorisation to hold client money; that sits under the payments and e-money framework, and in the United Kingdom safeguarding expectations were strengthened during 2026.
Under the MiCA framework, a provider holding clients' funds must safeguard them and keep them segregated. The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning. The practical consequence for infrastructure is that client fiat must stay identifiable, reconciled and evidenced against the right customer at all times, which is a matter of regulatory readiness designed into the ledger rather than added later. Where the fiat rail, the partners and the deployment model should sit — including on-premises or dedicated arrangements that keep control with the operator — is a question that benefits from an independent view, the subject of fintech architecture advisory.
Summary and Next Steps
Fiat deposit and withdrawal is where a crypto exchange meets the banking system, and its infrastructure exists to keep two independent records — the external accounts that hold money and the internal ledger that records what customers are owed — in continuous agreement. Deposits must be attributed to the right customer, for which virtual IBANs and named accounts are the strongest mechanism; withdrawals must be controlled, screened and matched to verified beneficiaries; and every movement reconciled against an external statement and cleared against financial-crime and safeguarding obligations.
The practical next step is to describe the currencies, rails and volumes a platform will actually handle, and to assess any fiat design against that description: how deposits are attributed, how withdrawals are controlled, how continuously reconciliation runs, and how client money is kept segregated and evidenced. Judged that way, a fiat on- and off-ramp can be evaluated on how reliably it moves money and how well it stands up to reconciliation and audit, rather than on the list of payment methods it advertises.
A fiat on- and off-ramp is judged by attribution, reconciliation and control, not by the number of payment methods it lists. Grumpio designs and delivers exchange fiat infrastructure built around accurate attribution, continuous reconciliation and controlled, screened payouts.