The usual advice on blockchain and banking is to choose a network, launch a pilot, and scale whatever works. That gets the sequence wrong. A successful transfer proves that software can move an asset, not that a bank can operate the service safely when funding fails, an approval expires, or a customer disputes the payment.
The enemy is pilot-to-production confusion, treating a working demonstration as evidence of an operationally complete service. Start with the obligations around the transaction, then choose the infrastructure that can enforce them.
Table of Contents
- Why Bank Blockchain Projects Stall Before Production
- How Blockchain Entered Banking Through Settlement Experiments
- Core Mechanisms That Change How Banks Operate
- Key Banking Functions and How Blockchain Reshapes Them
- Integration Models for Banks and Fintechs
- Risks and Controls for Institutional Deployment
- A Phased Migration Path for Incumbent Institutions
- Frequently Asked Questions About Blockchain and Banking
Why Bank Blockchain Projects Stall Before Production
Banks can approve digital-asset spending without resolving who owns the resulting service. Technology teams may own the integration while treasury controls funding, compliance approves counterparties, and finance discovers reconciliation gaps after transactions begin.
A 2026 survey reported by Cointelegraph covered more than 600 financial institutions: 88% had committed or planned digital-asset infrastructure budgets, but only 16% had reached production, more than half remained in planning or pilots, and only 15% of banks considered their governance infrastructure fully production-ready. Those findings point toward an operating-model problem, not merely insufficient interest.
A pilot can hide dependencies behind manual intervention. An engineer can retry a withdrawal, a treasury analyst can top up an account, and a compliance officer can approve an exception in a chat message. Production needs explicit authority, recorded decisions, and recovery procedures that don't depend on whoever remembers the original implementation.
Define the service before expanding the technology
The production boundary should identify:
- Accountability: Name the owner of funding, approval, release, reconciliation, and customer escalation.
- Exception handling: Specify what happens when a transaction is rejected, delayed, or confirmed without the expected banking entry.
- Financial exposure: Establish which entity holds the asset or liability while a workflow remains incomplete.
- Recovery authority: Decide who can suspend new instructions and authorize corrective action.
These are design inputs, not documents to write after launch. If teams can't agree on them, adding another network or wallet interface only creates more unresolved paths.
Practical lesson: Move a bounded workflow into production, not an entire blockchain strategy.
Treasury settlement, internal transfers, or controlled collateral movement are sensible candidates to evaluate because teams can define the participants and business purpose narrowly. That doesn't make them automatically low risk. It makes their risks easier to describe and test.
A consumer-facing product introduces additional distribution, support, and disclosure obligations. Don't take those on merely to make the project visible. A back-end settlement service can establish operational discipline before the institution changes its customer experience.
How Blockchain Entered Banking Through Settlement Experiments
Blockchain's institutional banking history is more useful than the replacement narrative. Central banks investigated whether programmable representations of money could improve settlement while preserving monetary control, rather than assuming commercial-bank payment systems should disappear.
An early BIS survey of central-bank digital currency work covered 63 central banks: approximately 70% were conducting or would soon conduct CBDC work, while about half had progressed beyond conceptual research, a share 15 percentage points higher than in 2017. Its wholesale examples included Project Jasper in Canada, Project Ubin in Singapore, and Project Khokha in South Africa.
The institutional progression is illustrated below.
Research participation isn't deployment
Those experiments tested an institutional question: could tokenized central-bank money support settlement between financial institutions without surrendering central-bank control? The early survey also distinguished experimentation from firm issuance plans. Technical feasibility was only part of the decision.
The BIS survey covering 2024 found that 85 of 93 central banks, or 91%, were exploring retail CBDCs, wholesale CBDCs, or both, with wholesale work generally more advanced. That establishes broad research participation, not uniform deployment or a common technical architecture.
For infrastructure teams, the useful distinction is between institutional legitimacy and operational readiness. Central-bank interest supports taking the architecture seriously. It doesn't settle a commercial institution's legal permissions, liquidity arrangements, or integration choices.
- Wholesale experiments ask how institutions exchange value and settle obligations.
- Retail distribution decisions concern how end users access money and which intermediaries serve them.
- Production authorization requires a specific legal and operating framework, not merely a successful experiment.
Commercial-bank liabilities deserve separate analysis. Visbanking's discussion of tokenized deposits mainstream banking provides context for that adjacent debate, but the engineering decision should begin with the underlying claim and its issuer.
The historical lesson is restraint. Evaluate blockchain as an institutional coordination mechanism first. Whether a customer ever sees a token is a separate product decision.
Core Mechanisms That Change How Banks Operate
Blockchain is relevant to banking when it changes how participants coordinate value, obligations, and records. Replacing a payment message with an on-chain instruction isn't enough if every surrounding process remains disconnected.
The architecture rests on linked mechanisms rather than a single speed improvement.
Programmable settlement and tokenization
Programmable settlement means expressing the conditions for a transfer in executable logic. In the BIS unified-ledger architecture, tokenized central-bank money, commercial-bank money, and financial assets could share a programmable environment where payment instructions, approvals, and linked account updates are coordinated.
Atomic execution means every linked leg settles or none does. That can reduce the exposure created when a party delivers an asset while waiting for the corresponding payment. It doesn't guarantee immediate settlement, sufficient liquidity, or successful recovery from an operational failure.
Tokenization supplies the representations that the program moves. The critical question isn't what the token looks like in a wallet. It's what enforceable claim it represents, who owes performance, and how the holder exercises that claim.
Event-driven state and the banking boundary
Event-driven operations make transaction progress explicit. Authorization, policy evaluation, signing, broadcast, confirmation, and reconciliation should remain distinguishable states, rather than collapsing into a single success response.
Consider a treasury transfer. The application can accept an instruction before the signing service approves it, and the network can confirm the transfer before finance matches the banking-side funding. Those events describe different obligations.
Stablecoin connectivity makes this boundary concrete. A Federal Reserve Bank of New York study matched stablecoin issuance and redemption events with Fedwire records and bank reserve balances, connecting blockchain activity to conventional settlement rather than treating it as isolated volume.
For technical orientation, Bridge Global's blockchain overview for CTOs offers broader background. The institutional design test remains more specific:
- Representation: What asset or liability moves?
- Execution: Which conditions must hold before release?
- Evidence: Which records establish completion across participating systems?
A confirmed blockchain transaction answers a network question. Finance still needs an answer to the business obligation.
Key Banking Functions and How Blockchain Reshapes Them
The practical unit of integration isn't the blockchain. It's the banking function, together with its controls, records, and accountable operators.
This map separates the functions that teams need to design.
Match each function to an infrastructure boundary
| Banking function | What changes | What must remain explicit |
|---|---|---|
| Payments | A blockchain rail can support transfers outside conventional operating windows | Funding availability, release authority, and customer status |
| Custody and signing | MPC can distribute signing participation | Ownership, access rights, and recovery responsibilities |
| Settlement | Network execution becomes part of the payment lifecycle | The institution's definition of business completion |
| Compliance | Policy decisions can become execution gates | Accountability for screening and exceptions |
| Programmable money | Transfer conditions can be embedded in software | Liability, redemption rights, and permitted use |
For the execution layer, BroSettlement provides distributed key generation, MPC signing, network broadcast, and a client-controlled Co-Signer. Treat that as infrastructure for implementing an institution's release policy, not as a substitute for deciding that policy.
BroWallet serves a different boundary: the user-facing wallet experience, including buy, sell, exchange, funding, and fiat withdrawal flows. A treasury-only project doesn't need to introduce that interface just because it uses the same underlying wallet infrastructure.
The stablecoin payment infrastructure guide is a useful internal companion when mapping these components to a payment product.
Separate observability from authority
Use WebSocket events to notify applications about deposits, confirmations, withdrawals, and policy outcomes. Feed those events into the append-only operating ledger, where finance can connect operational activity to reconciliation evidence.
Use scoped API keys to limit what each integration can request. Define idempotency so a retried instruction resolves to the existing business operation rather than creating another payout. Notifications, credentials, and retry behavior solve different problems; don't combine them into a broad application permission.
AI Agents need an equally explicit boundary. Per-agent wallets, role-based access, and audit trails can separate activity, while the Co-Signer retains the institution's release conditions. An agent may prepare a payment or classify an exception without receiving unrestricted authority to move funds.
The accompanying video provides another format for reviewing the topic.
Integration Models for Banks and Fintechs
Choose an integration model by deciding what role the institution intends to perform. Using another issuer's instrument, issuing a bank liability, and operating ledger infrastructure are different commitments. They can also overlap, so don't treat the categories as mutually exclusive technology packages.
The comparison below is an architectural assessment, not a guaranteed ranking. Permissions, counterparties, and existing systems can change the relative effort substantially.
Integration Model Comparison
| Model | Speed to Market | Regulatory Burden | Counterparty Risk | Operational Control |
|---|---|---|---|---|
| Third-party stablecoin | Potentially shorter when issuance infrastructure already exists | Distribution, custody, transfer, and jurisdiction-specific obligations | Issuer, redemption, banking, and network dependencies | Control over your workflow, not the issuer's operations |
| Bank-issued tokenized deposit | Dependent on banking, legal, and core-ledger readiness | Issuance authority and treatment require jurisdiction-specific review | Bank liability plus platform and participant dependencies | Greater control over issuance and deposit servicing |
| Bank-controlled ledger | Significant design effort where infrastructure must be built | Depends on assets, participants, and activities | External settlement and participant risks still need assessment | Greater platform control, with greater operating responsibility |
A third-party stablecoin lets a team evaluate a settlement service without building issuance first. The trade-off is dependency: the institution must understand redemption access, accepted counterparties, and what happens when the issuer or funding bank is unavailable.
Issuing a tokenized deposit shifts the question toward the bank's own obligation and servicing model. Counsel, finance, and supervisors need to determine the applicable treatment; the token format alone doesn't establish legal status, protections, or transferability.
Choose the obligation you can operate
A bank-controlled ledger offers discretion over participation and platform rules. It also requires the institution to govern upgrades, access, continuity, and dispute handling. Control creates responsibilities rather than removing them.
The blockchain digital infrastructure guide helps frame the component boundaries behind these options.
- Choose an intermediary role when the objective is moving an existing instrument through a controlled customer or treasury workflow.
- Evaluate an issuer role when the business requires a bank-native claim and the institution can support its lifecycle.
- Consider platform operation when participant governance and infrastructure control are central requirements.
Don't issue a new instrument to solve an integration problem that an existing instrument can address. Equally, don't accept an external issuer dependency merely because its API is easier to test.
Risks and Controls for Institutional Deployment
Blockchain doesn't eliminate banking risk. It changes the systems, participants, and operating windows through which the institution must manage it.
The control environment should cover the complete transaction, not just the signing ceremony.
Identity, transaction policy, and signing
FATF's updated virtual-asset guidance addresses risk assessment, licensing or registration, supervision, stablecoins, peer-to-peer activity, and the Travel Rule. For implementation, place applicable customer and transaction checks before release, with recorded decisions and an exception path.
The Travel Rule requirements summarized by Skadden cover originator and beneficiary identifying information for qualifying transfers, with FATF's de minimis threshold set no higher than $1,000 or €1,000. Implement the applicable jurisdictional rules rather than treating that threshold as a universal exemption.
NIST's key-management guidance treats cryptographic protection as an operational discipline; applying a 2-of-3 MPC design separates signing participation so no single participant is sufficient, but the surrounding institution must still define limits, allowlists, recovery, and incident authority. The digital asset custody guide provides related internal reading for evaluating those responsibilities.
Continuous operations and financial evidence
The U.S. Faster Payments Council's stablecoin cross-border payments discussion identifies operational, compliance, liquidity, regulatory-harmonization, interoperability, and legacy-integration considerations. Treat continuous settlement as a staffing and funding commitment, not merely a network feature.
Before release, require evidence that the following controls work:
- AML/KYC and sanctions gates: Incomplete information or unresolved screening blocks execution under the applicable policy.
- Signing separation: The Co-Signer evaluates authorized requests, with emergency access and recovery tested separately.
- Liquidity coverage: Treasury knows which balances are spendable and how to respond when replenishment is unavailable.
- Reconciliation discipline: Operators match instructions, network records, ledger postings, and banking entries, with named owners for breaks.
- Incident containment: Authorized staff can suspend new releases without claiming they can reverse an already executed network transfer.
Release gate: If an exception has no accountable operator and no funded recovery path, keep that workflow out of production.
A Phased Migration Path for Incumbent Institutions
Migration should produce evidence at each stage. Adding assets or participants before resolving the previous stage's exceptions makes failures harder to diagnose and responsibilities harder to enforce.
Sandbox and proof of concept
Start by testing the API contract, signing policy, and ledger behavior in a controlled environment. Include rejected instructions, missing approvals, interrupted connections, and repeated requests, not just successful transfers.
Ask finance to reconcile the test activity independently of the engineering team's dashboard. If finance needs an engineer to explain every balance movement, the evidence model isn't ready.
Narrow production pilot
Select a bounded back-end workflow with identifiable participants and an approved exposure limit. Treasury settlement, internal transfers, or collateral movement are candidates to assess, not automatic recommendations.
Write the entry criteria before processing live value:
- Governance coverage: Every transaction path has an owner and approved policy.
- Policy outcomes: Teams can distinguish valid approvals, legitimate rejections, and control failures.
- Reconciliation breaks: Finance can identify unmatched items, their age, and the responsible resolver.
- Incident response: Operators can demonstrate detection, escalation, containment, and recovery.
Measure these alongside throughput. A fast transfer with an unexplained balance is an unresolved financial obligation.
Controlled expansion
Expand a deliberate dimension, such as participant scope or asset coverage, while holding other variables stable. Reassess support needs, counterparty exposure, and treasury arrangements before making the change.
Don't use a clean pilot history to waive controls for a materially different flow. A new asset or redemption partner can introduce obligations the original pilot never tested.
Legacy integration
Normalize payment intent, identifiers, status, and reporting across the core banking environment. ISO 20022's payment-value-chain scope includes initiation, corporate-to-bank messaging, correspondent banking, infrastructure settlement, and cash reporting.
Treat message normalization as semantic work, not field copying. The same status label can mean accepted by an application, released to a network, or financially reconciled.
Define those meanings with operations and finance before automating downstream postings. Keep the core banking system's accounting responsibilities explicit rather than assuming a blockchain record can replace them.
Frequently Asked Questions About Blockchain and Banking
Does blockchain replace traditional banking infrastructure?
Not by default. A practical integration changes a defined workflow while retaining the banking systems responsible for accounts, customer relationships, reporting, and institutional obligations.
Ask a vendor to identify exactly which component it replaces, which records it produces, and which responsibilities remain with your team. If the answer is that everything moves on-chain, the operating design is incomplete.
How should banks handle settlement outside banking hours?
Decide whether the service is continuously operated or whether it only accepts instructions for later release. Customer disclosures and API statuses should reflect that distinction clearly.
For continuously operated services, establish an on-call authority model, available funding, and escalation procedures before expanding availability. An automated alert without someone authorized to act isn't an operating control.
What's the difference between a stablecoin and a tokenized deposit?
The buyer's central question is who owes the holder and under what terms. Evaluate the issuer, legal claim, redemption process, balance-sheet treatment, and applicable protections rather than relying on the token's name.
A wallet can display both instruments similarly while their legal and financial characteristics differ. Obtain jurisdiction-specific advice before representing either as interchangeable with an ordinary bank-account balance.
How long does implementation take?
There isn't a responsible universal timeline. The critical dependencies include the integration model, permissions, core-system interfaces, signing governance, and the quality of existing reconciliation processes.
Request a milestone-based plan with acceptance evidence. Separate sandbox access, technical integration, operational approval, and live release so that a completed API connection isn't presented as a completed deployment.
What should buyers require in a production demonstration?
Ask the provider to demonstrate a failed approval, an interrupted request, an unmatched banking entry, and a controlled service suspension. Review the resulting records with engineering, compliance, operations, and finance together.
The strongest demonstration isn't an uninterrupted happy path. It's evidence that your team can understand a failure, contain exposure, and explain the final financial position without reconstructing events from chat messages.
BroLabel offers modular wallet, signing, settlement, ledger, and fiat infrastructure for teams building controlled banking and payment workflows. Visit BroLabel to discuss a bounded settlement use case and map the sandbox tests, Co-Signer policies, and reconciliation evidence you'll need before release. Bro has your back!
