Skip to content

Digital Asset Infrastructure for Banks and Credit Institutions

In short

Digital asset infrastructure for banks is the engineering layer between a bank's existing channel and the regulated crypto rails it rents: in-app trading and custody under a MiCA Article 60 notification, staking with per-customer reward records, credit against pledged crypto marked continuously, and euro stablecoin balances distributed from a licensed issuer, delivered inside the bank's own governance.

250+
projects shipped since 2016
$2B+
in assets secured through Safe across 120+ networks
Billions
in reserves attested on-chain
0
vulnerabilities across delivered projects
Trusted by teams building on-chain

Under MiCA, a credit institution can provide crypto-asset services on the authorisation it already holds: Article 60 gives banks a notification path, 40 working days, with a completeness check rather than a merits approval. So for most banks the licensing question is settled, and what remains is engineering.

Digital asset infrastructure for banks is the layer between the channel a bank already runs (its app, its core ledger, its controls) and the crypto rails it rents (custody technology, execution venues, validator operators). In practice it means order and position records reconciled per customer, key governance a risk committee approves, per-customer staking reward records, and compliance wiring that produces its own evidence.

Protofire builds that layer. We are an engineering firm with 250+ projects shipped since 2016 across 60+ networks and 95+ protocols, and the custody, attestation, and on-chain operations underneath a bank-grade product are systems we already run in production.

The digital-asset stack inside a bank's existing channel

The bank's channel and authorisation sit on top, rented rails below, and the engineered layer between them is where the product lives.

01

The bank's app and brand

E-banking and mobile, the channel customers already log into. Digital-asset products appear inside it, in the flow customers know.
02

Core integration & customer ledger

Orders, positions, statements, and tax records reconciled per customer against the core banking system.
03

Custody & key governance

Custody technology under the bank's control or a regulated sub-custodian: Safe multisig policies, MPC and HSM vendors, and segregation an auditor can trace.
04

Venue & liquidity connectivity

Execution against licensed venues and liquidity providers, with per-order records kept.
05

Product rails

Staking with per-customer reward records, credit against pledged crypto marked continuously, euro e-money token balances.
06

Compliance evidence chain

Travel Rule wiring, screening, and record-keeping that produce their own evidence for examination.
07

Monitoring & response

On-chain threat monitoring with pre-authorised automated response, bounded by limits the bank sets.
01

Who this is for

We build for four bank profiles. A retail or universal bank adding spot crypto trading and custody inside the app its customers already log into, on the banking authorisation it already holds. A central institution or group IT provider serving a network of legally independent member banks, building the capability once and activating it bank by bank.

A private bank or broker extending crypto custody it operates today with staking and Lombard-style credit against pledged crypto. And a bank that needs euro stablecoin balances in its product, distributed from a licensed issuer rather than issued in-house. The common thread is that the authorisation, the customer relationship, and the channel already exist; the digital-asset layer has to be engineered into them.

Brokers that operate under a CASP authorisation rather than a banking licence are covered on the CASPs and crypto exchanges page.

02

The regulatory position

Less than most bank boards assume, and the details are specific. For trading and custody, MiCA Article 60 lets a credit institution notify its regulator at least 40 working days before providing crypto-asset services; the review is a completeness check, with no power to refuse on the merits.

Staking is not a listed crypto-asset service, but ESMA Q&A 2067 (20 June 2024) treats staking-as-a-service as ancillary to custody, so custody obligations follow it, and Article 75(8) keeps the institution liable for client crypto-asset losses attributable to it. The lending itself sits outside MiCA scope as the rules stand in 2026 (Recital 94); MiCA gives no passport for it, so the loan runs on the bank's existing credit permissions under each country's credit and consumer-protection rules.

And a euro e-money token can be put in the product by contracting a licensed issuer, though distributing and custodying a third-party EMT is itself a crypto-asset service, and Article 50 bars passing any holding-linked yield to the client. On top of all of it sit DORA and the recast Transfer of Funds Regulation.

The regulation decides which products may exist. What it does not supply is the operational half: consent flows, per-customer records, segregation, and evidence.

03

What we build for banks

We build the engineered layer, and we operate it after launch. For custody, Safe multisig deployment and Fireblocks integration put key governance under policies a risk committee approves; we are an official Safe Guardian with $2B+ secured across 120+ networks.

For the compliance chain, compliance integration wires KYC, screening, and Travel Rule data flows into the bank's existing stack. For staking, we run validator infrastructure and build the per-customer reward attribution the rented stack does not produce: operators report per validator, while the bank's statements and tax reporting need rewards attributed per customer in its own core.

For credit against crypto collateral, white-label lending provides the collateral marking and liquidation machinery on a hardened base. Proof of Reserve attests balances continuously, oracle integration prices collateral on manipulation-resistant feeds, and managed on-chain operations keeps the whole stack watched 24/7. Before any of it faces customers, smart-contract audit hardens what will hold client assets.

05

An engineering partner a bank can put through procurement

Protofire is an engineering-led blockchain firm with 250+ projects shipped since 2016, across 60+ networks and 95+ protocols, with zero vulnerabilities across delivered projects. We are an official Safe Guardian, with audited multisig custody securing $2B+ across 120+ networks, the key-governance layer a risk committee signs off.

We are a core contributor to Chainlink and built enterprise-scale Proof-of-Reserve infrastructure attesting billions in reserves on-chain, the reserve-assurance layer an auditor stands behind. We helped build the world's first BaFin-licensed DEX for tokenized real-world assets, so a regulated, KYC-gated venue is work we have shipped, and we maintain Solhint, the Solidity linter used by over a million developers. The custody half and the evidence half of a bank's digital-asset stack are both systems we have built and operate in production.

The bank keeps the customer, the app, and the authorisation; the custody technology, venues, and validators are rented; the layer in between is what has to be engineered: the integration, the per-customer records, and the controls.

Custody, attestation, and venue engineering in production
Billionsin reserves attested on-chain

We built and operate real-time proof-of-reserve infrastructure at enterprise scale, covering billions in reserves, the reserve-assurance layer a bank's auditor stands behind.

Enterprise-scale PoRView project →
$2B+secured across 120+ EVM networks

As an official Safe Guardian, we deploy audited Safe contracts as institutional-grade custody, with separated operator and risk roles so no single key can move client assets.

Safe Multisig WalletView project →
50+trading pairs on the first BaFin-licensed DEX

We helped build the world's first BaFin-licensed DEX for tokenized real-world assets, with KYC and multi-tier permissioning, regulated-venue engineering under a German licence.

Swarm MarketsView project →

FAQ

Can a bank offer crypto trading and custody without a new licence?
In the EU, a bank can offer crypto trading and custody without a new licence: MiCA Article 60 lets a credit institution provide crypto-asset services by notifying its competent authority at least 40 working days before starting; the review is formally a completeness check rather than a merits approval, though supervisors expect the substance to be in place. The product can sit inside the bank's existing app rather than a standalone crypto app, which is how the live implementations run. The engineering burden lands on integration: connecting the e-banking channel and core ledger to rented custody and execution rails, with per-customer records and segregation an auditor can trace.
What does a bank build in-house and what does it rent?
The pattern across live bank implementations is consistent. Rented: custody technology (MPC, HSM), execution venues and liquidity, and validator operation for staking. Already owned: the authorisation, the customer relationship, the app, and the core ledger. Engineered: the layer in between, core-banking integration, per-customer position and reward records, key governance policies, consent flows, and the compliance evidence chain. That engineered layer does not exist off the shelf, and it is the part we build and operate.
How does a bank add staking to crypto custody it already runs?
Staking is not a listed MiCA crypto-asset service, but ESMA Q&A 2067 (20 June 2024) treats staking-as-a-service as ancillary to custody, so custody obligations follow it, explicit client consent is required, and Article 75(8) keeps the institution liable for client crypto-asset losses attributable to it. Operationally the validator side is rented from an operator, and the part that has to be built is the per-customer reward record: the ledger entry a client statement, a tax return, and an audit are all built from, and the same record feeds the bank's own DAC8 client-level crypto tax reporting, applying since 1 January 2026. We run validator infrastructure and build that record into the bank's core.
Can a bank lend against crypto collateral?
A bank can lend against crypto collateral, structured as a Lombard loan against a new collateral class. Crypto lending itself sits outside MiCA scope (Recital 94), and MiCA gives no lending passport, so the loan runs under the bank's existing credit permissions, subject to national credit and consumer-protection rules and counsel's reading in its jurisdiction. The engineering is the risk machinery: the pledged collateral is marked continuously against manipulation-resistant price feeds and margined at disclosed thresholds, with a margin call and then partial liquidation if the ratio is not restored, and every step recorded per customer. Capital treatment of the exposure and collateral enforceability stay with the bank's prudential and legal teams.
Can a bank offer euro stablecoin balances without issuing its own token?
A bank can offer euro stablecoin balances by distributing an e-money token from a licensed issuer, which delivers the same customer outcome at a fraction of the cost, time, and risk of issuing its own. Whether the bank later wants issuer economics, alone or through a consortium, is a separate treasury decision. Two constraints matter: distributing and custodying a third-party EMT is itself a crypto-asset service, so it must sit under the bank's crypto-asset permissions, and MiCA Article 50 bars passing any holding-linked yield to the client. We build the issuer integration, the balance and redemption flows, and the records behind them.
How does a banking network roll out crypto across member banks?
The central institution or group IT provider licenses and builds the capability once, then activates it bank by bank inside the app the member banks already ship. Regulation keeps the rollout decentralised even when the technology is central: each member bank makes its own regulatory step (in Germany, its own MiCA notification to BaFin), and the central arrangement sits inside each member bank's DORA ICT third-party risk framework, as a provider supporting critical or important functions, under the EBA outsourcing rules the banks apply to it. The per-bank activation is the repeatable engineering unit the whole model depends on.

Reviewed by Luis Medeiros, Field CTO at Protofire. Last reviewed: August 2026.

Book a call with Alejandro Losa

Schedule a call with our Web3 Solution Architect to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved

Message us on Telegram