Folio 05 · Insights · Article

Mar 8, 2026

Banking for crypto fintechs: the 12 questions banks always ask

Before a bank says yes, they ask the same dozen questions in some order. We list them, explain what a strong answer looks like, and outline what is usually missing from the first onboarding deck.

Editorial illustration for Banking for crypto fintechs: the 12 questions banks always ask

Crypto fintech banking conversations usually fail for predictable reasons: unclear flows, weak counterparty controls, incomplete licensing perimeter, or a deck that answers marketing questions instead of compliance questions. The fix is equally predictable — know the dozen questions every bank asks, walk in with the answers already written, and sequence the search so the slow institutions mature while the fast ones carry the launch. This article lists the questions, shows what strong answers look like, and covers the de-risking recovery path nobody plans for until they need it.

Why banks say no — the view from their side of the table

A bank onboarding a crypto fintech is pricing three things: the monitoring effort your flows will demand, the regulatory attention your sector attracts, and the probability that your compliance function is real. The first two are largely fixed; the third is yours to move. Banks rarely reject crypto businesses for being crypto businesses — they reject files whose pieces do not reconcile, because irreconcilable files are expensive to monitor and embarrassing to defend in their own audits.

That framing explains everything that follows: the work product that wins accounts is not persuasion, it is a file the bank's compliance team can take to their own committee without rewriting it.

The dozen questions, in the order they usually arrive

1. What exactly does the account do?

Operating expenses, client fiat, settlement with counterparties, safeguarding — each is a different risk conversation with different monitoring expectations, and mixing them in one ask is the fastest route to a no. Ask for accounts by function, and ask for the simplest one first if the relationship is new.

2. Where does the money come from, transaction by transaction?

Banks want the flow-of-funds diagram: who pays in, through what rails, what happens on-platform, and what the fiat leg looks like before it reaches them. One page per flow, boxes and arrows, amounts and counterparty types on the arrows. If the diagram needs a narrator, it is not finished.

3. What licence covers this, where?

The full perimeter: every jurisdiction served, every registration and authorisation held, and an honest account of the gaps with the plan for each. Banks check registers; a perimeter the bank discovers to be incomplete ends the conversation and salts the ground.

4. Who are your customers, and who is prohibited?

Target segments with realistic proportions, geographic exclusions, prohibited categories, and the screening configuration that enforces all of it. "Global retail" is not a customer description; it is a risk flag.

5. How do you do KYC, and who actually does it?

Tooling, verification methods, risk-rating logic, EDD triggers, and the names of the people who own decisions. Banks increasingly ask to see the back office or a sandbox demonstration — fluency here is worth more than any policy PDF.

6. How do you monitor transactions on-chain?

Which analytics provider, what risk scoring, what thresholds trigger review, what happens on a hit — with worked examples. The strongest answer includes a real (redacted) case: alert, investigation, decision, filing.

7. What is your exposure to mixers, sanctioned protocols, and high-risk exchanges?

Banks increasingly test counterparty wallets themselves; the answer should match what their tools will find. Bring a recent analytics report on your own addresses and your exposure policy with its thresholds. Discovering your exposure for you is not a job the bank wants.

8. Who are your counterparties?

Exchanges, OTC desks, liquidity providers, custodians, banking partners elsewhere — and the due-diligence files behind each. Most teams have contracts; few have risk files. The risk files are what the question is about.

9. What happened at your last bank?

De-risking history is checkable through references and, increasingly, shared industry intelligence. The honest version with context — sector exit, monitoring cost, a specific incident since remediated — beats the discovered version every time, in every market.

10. Who owns the company?

UBOs traced to natural persons, with source of wealth documented at the level the bank's own examiners will expect. Complex cap tables with token-linked entities deserve a pre-written explanation memo.

11. What volumes, today and in twelve months?

Real numbers with the growth assumptions visible. Banks price monitoring effort and set thresholds from these figures; volumes that triple unannounced break relationships faster than incidents do. Under-promising is as damaging as over-promising — it reads as either dishonesty or ignorance of your own business.

12. Who is your compliance officer, and can we meet them?

The meeting where the MLRO answers fluently — on flows, on typologies, on the worst client they ever exited — is the meeting that moves to onboarding. If the MLRO cannot carry that meeting, the hire is not finished.

What a strong answer looks like

Across all twelve, strong answers share a shape: specific, documented, and consistent with each other. The flow-of-funds diagram matches the volumes; the volumes match the licence perimeter; the perimeter matches the customer geography; the geography matches the screening configuration; the screening configuration matches the staffing. Banks read for reconciliation, and the file that reconciles is rare enough to be memorable.

The deliverable worth building once, properly: a banking pack — corporate documents, ownership memo, licence matrix, flow diagrams, AML programme summary, analytics report, volumes and projections, de-risking history, key-person bios. Every onboarding asks the same dozen questions; after the first complete pack, each application is mostly maintenance, and the pack doubles as the diligence room for investors and partners.

Sequencing the search

Approach institutions in tiers, in parallel:

  • Specialist crypto-friendly EMIs and PSPs — onboarding in weeks, pricing above mainstream, ideal for operating accounts and the launch phase.
  • Crypto-experienced banks — the middle tier where most stable relationships live; onboarding in one to three months for a clean pack.
  • Tier-one banks — months, relationship-led, realistic after track record exists; start the conversations early but plan nothing around them.
  • Safeguarding or client-money institutions where the licence requires them — a separate search with its own criteria, started first because it gates the licence itself.

Redundancy is policy, not paranoia: two providers per critical function, tested periodically, because the cheapest moment to open the second account is while the first is healthy.

After de-risking: the recovery path

If an account closes — and in this sector, assume one eventually will:

  • Get the reason in writing where possible; "commercial decision" often softens into specifics on a professional call between compliance officers.
  • Remediate whatever is real in the feedback, and document the remediation.
  • Update the banking pack with the event and its closure; the narrative you control beats the rumour you do not.
  • Lean on the redundant provider while replacing capacity — which is why the redundancy existed.

Institutions distinguish sharply between operators who arrive with their de-risking story told and remediated, and operators whose story arrives by other channels first.

Building the banking pack, document by document

The pack that answers the dozen questions before they are asked:

  • Corporate section: certificates, ownership chart to natural persons, UBO memo with source-of-wealth documentation, group structure with the regulated entities flagged.
  • Licence matrix: jurisdiction by jurisdiction, the authorisations held, the registers they appear on, and the gaps with their remediation dates.
  • Flow-of-funds diagrams: one page per flow, counterparty types and rails on the arrows, the requested account's role highlighted.
  • AML programme summary: ten pages, not a hundred — risk appetite, KYC methods, monitoring logic, screening configuration, governance, with the full policies available on request.
  • Analytics evidence: a recent third-party report on the firm's own wallet exposure, plus the exposure policy with thresholds.
  • Counterparty register: the exchanges, custodians, OTC desks, and liquidity providers, each with its due-diligence file reference.
  • Numbers: volumes by corridor for the trailing period, the twelve-month projection with assumptions, average balances the account should expect.
  • History: previous banking relationships, any de-risking events with the remediation story, and references who will take a call.
  • People: bios for the principals and the MLRO, with the MLRO's direct contact offered.

Maintained quarterly, the pack turns every new application into a cover letter plus attachments — and doubles as the diligence room for investors, auditors, and acquirers.

Pricing and terms: what to expect and what to negotiate

Crypto-adjacent banking is priced as a monitoring business. Expect, and plan around:

  • Monthly account fees and per-transaction pricing well above mainstream commercial banking, often with minimum monthly revenue commitments.
  • Onboarding fees for the compliance review itself at the specialist institutions — a filter as much as a fee.
  • Balance requirements or reserves, particularly where settlement risk sits with the institution.
  • Volume tiering: pricing that improves with track record is negotiable at the first annual review more readily than at onboarding — diary it.
  • Notice terms: the exit clause matters more than the price. Negotiate for notice periods long enough to migrate, and for "material change" definitions that are mutual rather than unilateral where any leverage exists.

The negotiating asset is always the same: a pack and a monitoring history that make the account cheap for the institution to keep. Discounts follow operational cleanliness, not persuasion.

Three onboarding patterns from the field

  • The reconciled file: a licensed EMI with a crypto product brought the full pack, the MLRO led the call, and the analytics report matched the bank's own test of the firm's addresses. Onboarded in five weeks at the specialist tier; tier-two bank followed in a quarter on the same pack.
  • The discovered perimeter: a platform described its flows as "pure technology" until the bank's review found custody-like control of client assets in the terms of service. The application died not on the facts but on the discovery — the same model, disclosed and argued upfront, banks elsewhere.
  • The recovered exit: an operator de-risked during a sector-wide pullback returned eighteen months later with the closure letter, the remediation log, and two clean years at a specialist PSP. The tier-two bank that had exited them re-onboarded — institutions remember files, and a documented recovery reads as maturity, not stigma.

The pattern across all three: outcomes follow the file, not the pitch.

Timeline expectations by tier

Calibrate the project plan to how each tier actually moves:

  • Specialist EMIs and PSPs: application to live account in two to six weeks for a complete pack; the variable is the compliance questionnaire turnaround on your side.
  • Crypto-experienced banks: one to three months, including at least one substantive call with the MLRO and, increasingly, a wallet-analytics test run by the bank itself.
  • Tier-one institutions: a quarter to a year, relationship-led, often gated on a track-record threshold — eighteen to twenty-four months of clean operations is the unwritten entry ticket.
  • Safeguarding institutions: their own diligence cycle, started first; licence timelines depend on it, which makes it the critical path more often than any regulator.

Run all tiers in parallel from one pack, let the fast tiers carry the launch, and treat the slow tiers as a pipeline rather than a milestone.

Questions teams ask

Do we need a bank, or will EMIs do?

For operating accounts and most flows, licensed EMIs and PSPs are sufficient and faster. Safeguarding obligations and certain settlement arrangements pull actual credit institutions back into the stack — check the licence conditions before assuming.

How many institutions should we approach?

Six to ten in the first wave, across tiers, expecting a third to engage seriously. The pack makes parallel processing cheap; sequential applications waste the year.

Does a tier-one licence solve banking?

It moves the conversation — an MPI or EMI authorisation answers the perimeter question credibly — but the dozen questions remain, because the bank's risk is operational, not legal. Licensed firms with weak packs still get declined.

What is the single highest-leverage improvement?

The MLRO meeting. Banks bank compliance functions that happen to run crypto companies. Build the function, let it speak, and the conversations change tone.

Get a provider shortlist built for your flows

Banking and provider selection as a workstream: shortlists, introductions, and the pack that survives compliance review.

Editorial disclaimer

This article is general information only and is not legal, regulatory, tax, investment, or financial advice.

Want these questions run against your setup?

Field notes record what regulators and banks actually ask. Send your stack — licence, accounts, providers — and we return the questions your file would face first, plus the fixes that close them.

Elena Korniets

Elena Korniets leads SKY7 research on crypto, CASP and VASP licensing routes, with a focus on how authorisation scope, custody model, AML governance and local substance change the practical value of a file. Her notes compare national registration regimes with MiCA-era CASP authorisation, highlight where a seller claim needs regulator evidence, and translate technical permissions into buyer diligence questions. She writes for founders, operators and acquisition teams that need to understand whether an exchange, custody, brokerage or token-services model can be supported by the entity being reviewed. Elena pays particular attention to perimeter language, passporting assumptions, safeguarding, outsourcing and the documents a bank or supervisor will expect before onboarding or change-of-control review.