Crypto Banking Solutions: How the Infrastructure Works and How to Choose One

The term covers three different things. For a crypto exchange or OTC desk, it means finding a bank or payment institution that will hold fiat and process transfers. For a neobank or a bank, it means adding custody and buy/sell/hold functions through a custodian or core-banking vendor. For anyone running a crypto-fiat product, it means the infrastructure that ties those pieces together: ledger, wallets, rails, liquidity and compliance.

This guide explains each layer, how money actually moves through it, where regulation draws the lines, and how to choose between provider-based, white-label and custom setups. Where we reference our own work, we label it and describe the original project context. Merehead builds and integrates the technology behind these products. It is not a bank, custodian or card issuer, and every regulated function described below requires a licensed partner or the operator's own license.

What Are Crypto Banking Solutions?

Search results for this term mix regulated crypto banks, custodians, core-banking vendors, account providers for crypto companies and software agencies. They all sell into one of three needs.

If you only need a bank that will open an account for a crypto company, start with our overview of crypto friendly banks. The rest of this article focuses on the second and third meanings, where product and engineering decisions matter most.

How crypto banking solutions differ from traditional banking and pure crypto software

Who Uses Crypto Banking Solutions and Why

Banks exploring the technology beyond custody can review how blockchain can be used in banking. These groups buy different products, but they run into the same engineering questions. Who holds the keys? What counts as the source of truth for balances? What happens when a bank transfer and a blockchain transfer disagree?

The Crypto Banking Stack: Seven Layers

Every crypto banking product combines the same layers. Operators rarely build all of them. The layers they buy still have to connect cleanly to the ones they build.

1. Accounts and the ledger

The ledger is the product. A fiat balance in a crypto banking app is not money sitting inside the app. It is a ledger entry that has to match a bank account the operator controls, and a crypto balance has to match on-chain holdings and any custodian's records.

Our experience comes from a custodial exchange with a fiat module, built as 12–13 backend microservices on Kubernetes. The accounting rules that mattered most were not algorithmic. They were business rules that are easy to get wrong:

2. Wallets and custody

Custody options range from a qualified custodian holding keys on the operator's behalf, to the operator running its own key infrastructure, to non-custodial wallets where users hold keys; our guide on how to create a crypto wallet app covers the user-facing side. Custodial setups typically split funds between hot wallets for day-to-day withdrawals and cold storage for reserves. For a deeper look at threat models, see our guide to crypto exchange security.

On the custodial exchange mentioned above, private keys for user deposit addresses and for hot wallets are encrypted in the database with two separate master keys, and secrets are managed in HashiCorp Vault. Separating the two key domains limits the blast radius if one of them is compromised or misconfigured.

The lesson we documented concerns rotation. An API key can be revoked and reissued. A master encryption key cannot simply be replaced in Vault: every private key encrypted under the old key must be decrypted, re-encrypted with the new one, and verified before the old key is retired. Otherwise the platform loses access to its own wallets. We recommend key versioning, where each encrypted record carries a key ID so migration can happen gradually.

Our production custody work has used encrypted key storage rather than MPC or HSM-based custody. If your provider uses MPC or HSMs, the rotation mechanics differ, but the question to ask stays the same: how do you rotate key material without losing access to existing funds? Teams building their own custody stack can compare approaches with our crypto wallet app development practice.

3. Fiat rails and on/off-ramps

Fiat moves over SEPA and SWIFT, ACH and domestic wires in the US, card acquiring, and local rails reached through bank APIs or payment service providers. The operator almost never owns these rails. It integrates with a bank, EMI or PSP that does.

Two practical points from our builds shape integration budgets. First, every bank exposes a different API with different logic. When we scoped a crypto processing platform for an EU client, we told the client that adding a new bank meant integrating it almost from scratch, not flipping a configuration switch. Second, fiat is always a dual system. The platform owns the accounting; the bank owns the actual movement of money. The two only meet through status updates.

4. Crypto payments and deposit attribution

Accepting crypto sounds simple until you need to prove who sent what. On a B2B cross-border payment platform that planned OTC lots from 100,000 USDT, we compared three models for receiving stablecoin payments:

The shared wallet exposed an attack during design review. User A pays 100 USDT to the shared address. User B opens a request for the same amount, finds User A's transaction in a block explorer, and submits that hash as proof of payment. Checking hash uniqueness in the database narrows the problem but does not solve it when several same-amount requests are open. A transaction hash proves that a transfer happened. It does not prove who sent it. We limited the shared model to small volumes from trusted counterparties and recommended unique addresses for recurring flows.

If crypto acceptance is your main use case rather than full banking, our guide on how to create a crypto payment gateway covers that narrower architecture.

5. Cards

This section is a general industry explanation; we have not run a card program ourselves. A crypto card program usually involves an issuing bank that sponsors the BIN, a program manager, a card processor and a network such as Visa or Mastercard. Either crypto is converted to fiat at the moment of authorization, or the user pre-funds a fiat balance from crypto before spending.

The issuer and program manager set most of the rules: KYC depth, spending limits, supported jurisdictions, dispute handling. For the operator's engineering team, the work is integrating authorization webhooks with the ledger so that a card payment reserves and then settles the right balance.

6. Liquidity and conversion

Conversion between crypto and fiat, or between crypto assets, depends on liquidity from exchanges, OTC desks or market makers. Choosing a crypto liquidity provider is only half the job. The platform also needs rebalancing and a plan for when the provider is unavailable.

Two patterns from our work transfer directly to crypto banking products:

• Rebalancing with fixed routes. On an EU-oriented custodial exchange, a managed-rate liquidity module shows external exchange balances in the admin panel and moves funds back to internal wallets over pre-configured withdrawal addresses. Fixed routes reduce operator error, but the addresses have to be reviewed regularly.
• Trading without the provider. On the custodial exchange with a fiat module, the external liquidity provider can be switched off. Orders then match internally instead of trading being blocked, and liquidity returns when the provider is re-enabled.

7. Compliance and the APIs that connect everything

Compliance is covered in detail in its own section below. The API layer ties all seven layers to the product: webhooks from banks and KYC vendors, blockchain node events, and outward APIs for partners. In our white-label exchange platform, API keys carry granular permissions such as read-only or deposit access, plus expiry dates. B2B partners should never receive broader access than their integration needs.

How Money Moves: Deposit and Withdrawal Lifecycles

Most support tickets in crypto-fiat products are really questions about state: "Where is my money?" A clear lifecycle answers that question for users, operators and auditors.

Crypto deposit lifecycle

1. The node or node provider detects an incoming transaction to a user's address.
2. The platform waits for the required number of block confirmations.
3. The deposit is screened by KYT before the balance is credited.
4. Clean funds are swept from the deposit address to a hot wallet.
5. The balance is credited, or the transaction moves to a hold state for AML, 2FA or manual review.

On one exchange deployment, we observed these end-to-end crediting times. They depend on the confirmation policy and network congestion, and they belong in customer communications.

On a custodial exchange we worked on, a transaction can be in one of these statuses: pending, on hold after an AML check, on hold after a manual restriction, manual review, completed, or rejected. Each status corresponds to a specific compliance stage, not just a UI label.

Fiat withdrawal lifecycle

On the custodial exchange with a fiat module, we found an inconsistency: withdrawal funds sometimes stayed in the order and were sometimes debited only after approval. The model we settled on:

1. The user requests a withdrawal, and the amount is held against the request.
2. An operator approves or rejects the request in the admin panel.
3. On approval, the amount is fully debited from the user's balance and removed from the request hold.
4. On rejection, the amount returns to the available balance.
5. The bank executes the payment outside the platform; the platform records the logical state, not the bank's internal processing.

Compliance and Transaction Monitoring in Practice

The regulatory map

The overview below is a general orientation for the US and EU, not legal advice. Licensing strategy needs qualified counsel in each target jurisdiction; for exchange-style products, our guide on how to build a crypto exchange covers licensing alongside the tech stack.

KYC and KYB

Across several exchange projects we integrated SumSub for KYC, including a dual-path setup: a national mobile identity app for local users and document upload for international users. Each path has different webhook payloads and status transitions, so the backend maintains two verification state machines.

KYB for business accounts is a longer workflow. On the B2B payment platform, a company moves through document submission, a "verification required" state, an agent agreement generated from the company's details, and final administrator approval.

The agreement is attached to the company, not to individual payment requests, so every request reuses one current version. The platform also compares the uploaded signed PDF with the original template. In testing, it flagged three letters added to the agreement number and two changed digits in a registration number, and showed the exact sections for a human reviewer to decide.

KYT: a configurable pipeline, not a single check

On the custodial exchange, transaction monitoring runs on three configurable thresholds:

• Auto approve below a set amount, bypassing paid screening.
• Enhanced check above a second threshold, where all active analytics providers are queried in parallel and the highest severity wins.
• Manual review above a third threshold, where the transaction is held for a compliance officer.

Several design decisions made this work in production:

• Normalized risk categories. Provider responses are mapped to about 70 categories, even when a provider returns more than 150. Switching vendors does not require rewriting business logic.
• Risk portion, not total amount. Risk is measured on the share of the transaction linked to risky sources, shown as a percentage and as a USDT amount.
• Deposit-only skip rule. A moderate-risk deposit can be credited automatically if its risky portion is below a threshold. We deliberately did not apply this rule to withdrawals, so risky funds cannot leave through it.
• Timeouts. One provider sometimes took up to an hour to respond, so the system falls back to the results that have already arrived.
• Automatic address regeneration. When the AML check rejects a deposit, the deposit address is archived and a new one is issued across supported networks. A manual rejection does not trigger this.
• Diff-based audit logs. Every configuration change is stored with old and new values. Changes to critical parameters require TOTP confirmation.
• Two report formats. JSON remains the source of truth, and a PDF export per provider serves compliance teams, auditors and banking partners.

When the monitoring vendor goes down

During testing of an exchange deployment, every enhanced-mode AML provider started returning HTTP 403. The system marked the affected transactions as clean, and the standard flow failed with an error. We classified this as a false-negative risk: the platform was effectively failing open. The fix requires the pipeline to hold transactions when screening is unavailable, not to pass them.

Ask every provider, and every internal team, the same question: what happens to a deposit when your KYT vendor is down?

Provider-Based vs White-Label vs Custom Infrastructure

The build-or-buy decision in crypto banking is mostly about who controls the ledger and who carries compliance responsibility, rather than about cost alone.

We have scoped hybrid variants in client engagements. In one, a tier-1 exchange held all custody and liquidity through a master account with user sub-accounts, and our backend acted as middleware between the product and the exchange's API. In another, part of the wallet infrastructure ran on the client's own nodes and part through external RPC providers, to balance regulatory requirements against infrastructure cost.

Each model has a dedicated guide. For pre-built platforms, timelines and pricing, see our white label crypto bank analysis. For a module-by-module view of the platform itself, read our breakdown of crypto banking software. If you have decided to build, our guide to crypto banking app development covers the process, stack and budget.

Implementation Challenges We See in Real Builds

The issues below come from exchange, payment and wallet projects rather than from a licensed crypto bank. They sit in layers that every crypto banking product shares: ledger, custody, fiat processing and compliance.

Most of these are not exotic bugs. They are gaps between systems: the front end and the backend, the platform and the bank, the vendor and the pipeline. Crypto banking products fail at those boundaries, which is where testing time should go.

Operational Resilience: Monitoring, Disaster Recovery and Running Costs

Regulators and banking partners increasingly ask how a platform detects incidents, how fast it recovers, and whether recovery has been tested. In the EU, DORA turns these expectations into legal obligations.

On an EU-oriented custodial exchange, the production setup looked like this:

• Application hosted on DigitalOcean, blockchain nodes on Hetzner.
• Logs in OpenSearch and infrastructure alerts in Slack.
• MySQL and PostgreSQL dumps stored in two regions, Frankfurt and Amsterdam.
• Cloudflare in front of the application for DDoS and web-attack protection.

When the client asked us to scope DORA-aligned site reliability for the same product, the targets were RTO of 2 hours and RPO of 30 minutes. Monthly infrastructure estimates from that scoping:

Three lessons carry over to any crypto banking stack:

• Nodes dominate the bill. In both non-Kubernetes estimates, blockchain nodes were the largest line item, well above application compute.
• A 2-hour RTO requires reserve nodes. Resyncing a single node can take longer than the recovery window.
• Response times cost people. Meeting a 15-minute first response and a 1-hour analysis target around the clock required a three-engineer on-call rotation, estimated at $2,800 per week.

On the custodial exchange, we also kept production and pre-production in separate Kubernetes clusters and did not merge the development environment into pre-production, even though merging would have lowered infrastructure costs. With a dozen interdependent services, a pre-production environment that receives ten deploys a day no longer mirrors production.

How to Evaluate a Crypto Banking Solution Provider

Whether you are choosing a BaaS partner, a white-label vendor or a development team, these questions separate production-ready answers from sales answers:

1. Which licensed entities hold fiat and crypto, and in which jurisdictions?
2. Is the ledger double-entry, and how is it reconciled against bank statements and on-chain balances?
3. How are pending fiat deposits separated from available balances?
4. How are deposits attributed to users: unique addresses, invoices or shared wallets?
5. Where are private keys stored, and what is the documented procedure for rotating master keys?
6. What is the confirmation policy per network, and how is crediting time communicated to users?
7. What happens to a transaction when the KYT vendor is unavailable?
8. Can AML thresholds and risk categories be changed without a code deployment, and is every change logged with old and new values?
9. How does KYB handle document verification and agreement integrity for business accounts?
10. Which liquidity providers are connected, and what happens when one is switched off?
11. What are the RTO and RPO, and when was the last restore test?
12. Who is on call, and how are hot wallet balance alerts routed?

Where Merehead Fits

Merehead is a software development company. We do not open bank accounts, hold client assets or issue cards. We build and integrate the technology layers that connect those regulated services:

• ledgers and admin panels;
• wallet infrastructure and blockchain node integration;
• KYC, KYB and KYT orchestration;
• fiat workflows;
• liquidity connections;
• monitoring and DevOps.

If you are planning that infrastructure, our crypto banking software development team can review your architecture with you.

FAQ