Skip to content

Crypto-as-a-Service Integration for Banks

In short

Protofire builds the bank's side of a crypto service, on a rented rail or on custody software the bank runs: the order flow from the app, client positions and statements in core banking, KYC and Travel Rule hooks, a daily reconciliation with the custodian and a tested switch to a second provider. The same build produces the engineering inputs for the bank's MiCA Article 60 file. On the bank's own custody, the keys stay in systems the bank operates.

Luis Medeiros

Reviewed by Luis Medeiros, Field CTO at ProtofireLast reviewed: October 2026

15+
proof-of-reserve and attestation deployments for a large auditing firm
250+
projects shipped since 2016
60+
networks integrated
$2B+
secured on the Safe deployments we built across 120+ EVM networks
Trusted by teams building on-chain

Crypto-as-a-service integration puts a licensed provider's crypto trading and custody inside a bank's own app and core banking. The provider's API covers execution and custody. Around it the bank needs its own side of the service, from the order screen in the app to the year-end statement, including the daily check that every client position matches what the custodian holds.

Protofire builds that side. We hold no license and custody no client assets: the licensed parties are the bank and, on a rented rail, its provider, and the contract between them sets which of the two serves the client.

What sits between the bank's app and the custodian

An order crosses the first five layers on its way to the provider. The last two check every position against the custodian and keep the records that the notification file and the DORA register draw on.

01

Bank app and e-banking

The channel clients already log into: product screens, risk disclosures and order entry in the bank's own design system and authentication.
02

Order gateway

Takes orders from the app, checks the client's eligibility and limits, and passes them to the provider with an idempotency key, which lets the provider discard a duplicate when the app retries.
03

Core banking seam

Books each trade against the client's cash account, holds crypto positions next to securities, and feeds statements, cost basis and tax data.
04

Client checks

The bank's existing KYC record and investor questionnaires, address screening, and Travel Rule data on every transfer.
05

Provider connector

One adapter per rail or custody stack behind a provider-neutral interface, so adding a second provider means writing one more adapter.
06

Reconciliation and indexing

Client positions checked against the custodian's records every day and, on the bank's own custody, against the chain, with each break routed to an owner.
07

Operations and evidence

Monitoring, incident runbooks and change records, and the ICT documentation the notification file and the DORA register draw on.
01

What the crypto-as-a-service integration covers

We connect the app to the provider's trading and custody API: quotes, orders, fills, fees and cancellations, and every state between them. A client sees a pending order as pending, and a filled one only once the fill is confirmed. Every request carries an idempotency key, and timeouts, partial fills and provider downtime each follow a defined path.

Crypto trades at any hour and most core banking systems book in cycles, so in design we fix what an order placed on a Saturday night does to the client's cash balance before the core books it. Where a provider sells both shapes, as Bitpanda Enterprise does with its "Our license" and "Bring-your-own license" models, the integration follows the one in your contract, because it decides whose terms and onboarding screens the client sees.

02

Rented rail or your own custody: what changes in the build

Both routes share the app, the order flow and the core-banking seam, and we build either one. The differences sit below that line. The key-management models behind own custody, from multisig to MPC and HSM, are compared in our crypto custody guide.

Rented rail
Your own custody stack
Who holds the keys
The provider, which holds the client assets
The bank, in HSM or MPC custody software it operates
What we connect to
The provider's trading and custody API
Custody software such as Ripple Custody, Taurus-PROTECT, Fireblocks or Utila, plus a broker or venue for execution
Reference for reconciliation
The custodian's position records
The chain, indexed, and the custody software's records
Key operations
None at the bank
Key ceremonies, signing policies, HSM or MPC procedures and chain upgrades, around the clock
Notification evidence
The outsourcing map and the provider's license status
The custody policy, key-management documentation and ICT security description
Switching later
Positions move between custodians through one adapter
Software or HSM vendor changes under the same key policy
03

Which rail fits your bank?

The licensed providers differ in license, shape and named bank clients, and some banks run custody themselves. Our guide to crypto-as-a-service for banks compares five providers and own custody, with a dated list of live bank deployments.

The bank crypto-in-app blueprint lists what a rented rail leaves out, from the core-banking connector to statement and tax output, and its full version adds the DORA third-party pack. Central institutions serving independent member banks can start from the network rollout blueprint.

04

From signed contract to first client order

On The Protocol Roundtable, the panel was asked which myth keeps a mid-sized bank with a working pilot out of production. Rado Patus, Lead Product Manager at Protofire, answered: "Usually there is that myth that I need everything approved before anything goes live.

And that approval never comes." He told the other panelists that each of them had "started with one flow, one counterparty, one approval, one product." Several banks opened with two assets: Zürcher Kantonalbank, Commerzbank, BBVA and KBC each started with bitcoin and ether.

1

Map the seams

We trace an order, a position and a transfer from the app through core banking to the provider or custody software, and list every system and owner they touch. Then we settle the open choices with you: cut-off handling, the first asset list, and whether external transfers are allowed. Deliverables: an integration design, the outsourcing and ICT map for the notification file, and a build plan.
2

Build against the sandbox

We build the gateway, the core-banking seam, the client checks, the provider connector and the reconciliation against the provider's test environment, or against your custody software in a test setup. Deliverable: the integration running end to end in test, with daily reconciliation reports.
3

Staff pilot

Bank staff trade with real money in production under low limits for a full statement cycle, so operations sees real reconciliation breaks, and their fixes, before clients do. Deliverable: a reconciled period and the evidence pack for the go decision.
4

Launch in waves

Clients get access in groups the bank chooses, and limits rise as the operations data allows. Deliverable: crypto trading and custody live in the bank's own app.
5

Operate

24/7 monitoring, incident response and provider changes under runbooks you approve. If the bank's own team takes over, it receives the code and the runbooks. Deliverable: the crypto service in daily operation, with Protofire or the bank's team on call. Three things set the scope: the provider or custody software you choose, your core banking system and the assets you plan to list.
05

Products a bank can add on this integration

Spot bitcoin and ether trading in your own app and e-banking
Crypto positions beside securities in the portfolio view and statements
A longer asset list, added one asset at a time
Staking on assets you already custody (see the staking blueprint)
Credit against a client's crypto (see the credit blueprint)
Euro stablecoins in the same app, with issuers compared in our euro stablecoins guide
Tokenized fund units next to securities; our fund tokenization guide compares providers
Crypto for business clients, as PostFinance added in May 2026
A crypto service for partner banks, as Zürcher Kantonalbank runs one
One central service for member banks (see the network blueprint)
06

Our production work closest to this integration

On Swarm Markets, a venue that launched under BaFin licenses and where every wallet is KYC-verified, Protofire built the DEX core and the subgraph data layer. Our open-source subgraphs on The Graph date back to 2019; reconciling a bank's own custody against the chain uses the same kind of indexing.

We also built Safe deployments across 120+ EVM networks and maintain Solhint. We can integrate Fireblocks and other MPC custody software for a bank that runs it. Staking, credit and the rest of the bank stack are covered under digital asset infrastructure for banks.

“Every request carries an idempotency key, and timeouts, partial fills and provider downtime each follow a defined path.”

Reserve checks and indexing we have delivered
15+proof-of-reserve and real-time attestation deployments

Protofire built and operated the reserve-data pipeline behind a large auditing firm's real-time attestation of asset-backed tokens. A bank running its own custody needs the same daily check: client positions in the core matched against balances on chain.

Large auditing firm
18M+subgraph queries a day served across 15+ networks during the engagement

Protofire wrote and open-sourced subgraphs for Maker, Curve, Compound governance, UMA, Lens and other protocols. On a bank's own custody, this kind of indexing lets client sub-ledgers be reconciled against onchain balances.

FAQ

What is crypto-as-a-service integration?
Crypto-as-a-service integration connects a licensed provider's crypto trading and custody, or custody software a bank runs itself, to the bank's app and core banking. The provider executes orders and, on a rented rail, holds the assets. The integration carries orders from the app, books client positions next to securities, feeds statements and tax data, applies the bank's KYC and Travel Rule checks, and reconciles positions with the custodian every day. Protofire builds it on the licensed rail or custody software the bank chooses, and can operate it after launch.
Which providers and custody stacks can you integrate?
Protofire can integrate the rail in your contract or on your shortlist: in Europe usually Sygnum, Boerse Stuttgart Digital, Bitpanda Enterprise, Crypto Finance or Kraken Embed. It can also be custody software such as Ripple Custody, Taurus-PROTECT, Fireblocks or Utila, run under the bank's own notification or banking license with a broker for execution. Each sits behind its own adapter, so adding a second provider later does not mean rebuilding the app or the core-banking seam. If you are still choosing, our guide to crypto-as-a-service for banks compares the providers on license, shape and named bank clients.
How does crypto trading connect to a core banking system such as Avaloq or Temenos?
Crypto trading connects to a core banking system such as Avaloq or Temenos at three points: each trade books against the client's cash account, crypto positions sit next to funds and securities, and the core receives the data it needs for statements, cost basis and tax reporting. We build that connection against Avaloq, Temenos, finnova or an in-house ledger, and reuse an existing connector where one covers the job.
Can we reuse our existing KYC and investor questionnaires?
A bank can reuse its existing KYC record, client classification and investor questionnaires for crypto. They decide who may trade, which assets and up to what amount, so clients do not onboard twice. Screening of external addresses and Travel Rule data are wired into the same flow, or the product allows no external transfers at all.
Does the EU Travel Rule apply when a bank offers crypto?
The EU Travel Rule applies to a bank's crypto service: under the Transfer of Funds Regulation, every crypto transfer carries originator and beneficiary data, whoever runs the rail. For a transfer above EUR 1,000 to a self-hosted address, the crypto-asset service provider sending it must take adequate measures to assess whether the client owns or controls that address (Article 14(5)). We wire Travel Rule messaging and address screening into the transfer flow, or design external transfers out of the product.
What does engineering contribute to our MiCA Article 60 notification?
Engineering contributes the technical half of a bank's MiCA Article 60 file: the architecture and data-flow documents, the outsourcing map of every provider and subcontractor, the key-management and security description, and the entries for the DORA register of information. Delegated Regulation (EU) 2025/303 asks for those ICT, outsourcing and custody details, and we produce them from the system we build. Your counsel and compliance team decide what is filed; we do not give legal advice.
Does the provider's license cover our bank?
In the EU, a provider's MiCA license covers the services the provider performs. A bank that itself takes and passes on client orders performs a crypto-asset service and needs an Article 60 notification for it, even with a licensed provider behind it. Which licensed firms can notify under Article 60, and for which of the ten services, is set out in our MiCA license routes guide. That scope decides what the integration must record and evidence, from reception and transmission of orders alone to execution as well. Our guide sets out the rules route by route; which services your bank notifies is your counsel's call, and we build to that conclusion.
Can we switch crypto providers later?
A bank can switch crypto providers later if the switch is built in from the start. The bank's own position ledger stays the system of record, each provider sits behind one adapter, and a migration runbook moves positions between custodians with reconciliation before and after the cut-over. Where clients hold their crypto account with the provider directly, the switch also moves each client's account, which needs its own data and consent steps.
Where are the keys and client assets held on each route?
On a rented rail the provider's custodian holds the keys and client assets, and the contract with the client decides who is custodian of record. On the bank's own custody, the bank holds the keys in custody software it operates, under a key policy the bank's risk function signs off. Protofire holds no keys and no client assets on either route. If we run operations, our access is limited to what the bank's runbooks grant.
Should we build the integration in-house or with a partner?
A bank can build the integration in-house if its engineers already own the core-banking interfaces the integration touches and can keep up with a provider API that changes on the provider's schedule. Otherwise the connector is the part a partner builds. Protofire builds it, drawing on the indexing, Safe multisig and onchain operations work we run in production. At launch the bank decides whether we keep running it or its own team takes over the code and the runbooks.

Get a proposal

Tell us what you are building. An engineer reads it, we have a short call, and the written proposal follows within one business day.

Hi, my name's

Luis Medeiros

Budget

I accept the
Privacy Policy
I agree to receive new research announcements as well as information about Protofire services and special offers

An NDA is available from the first message and can cover anything you share. How it works

Message us on Telegram