Permissioned blockchain for financial services

Permissioned blockchain infrastructure for financial services: why DORA changes the build

For a bank or consortium member, a Fabric or Besu node is an ICT risk question before it is a platform question. DORA, Regulation (EU) 2022/2554, makes the node part of the financial entity's ICT risk framework, so the choice of ledger software follows from how the node's services, keys and data will be governed, evidenced and exited. DORA has applied since 17 January 2025 to 20 types of financial entity, from credit and payment institutions to insurers and crypto-asset service providers, and it applies directly without national transposition. Covered entities must keep a register of information on all contractual arrangements for ICT services, and must document and test exit strategies for services that support critical or important functions. DORA also sets no certification scheme for this work. The operator has to assemble the evidence itself, so the design should produce it from the start.

On platforms, the short answer depends on governance more than licensing. Hyperledger Fabric, licensed under Apache-2.0, suits a multi-party network that needs channel-level privacy between members and a formal ordering service run under shared rules. Besu, also Apache-2.0, suits networks that run proof-of-authority or QBFT consensus and where the operator wants an Ethereum-compatible client. Both licenses are open, so the license does not decide anything. What decides it is who runs the ordering or validator nodes, who can admit or remove members, and how contract or chaincode changes are approved. Confirm these answers with the consortium before any platform choice is made, and record them, because the same answers feed the contract register and the exit plan.

Which regulations and controls shape a financial services ledger node

This table maps the regulatory and control requirements most likely to apply to a bank or consortium member running a Fabric or Besu node, with the evidence an assessor will expect and what each requirement changes in the build. Read each row against your own licence status, jurisdiction and whether the node touches cardholder data or Swift. Several rows apply only to specific entity types, so confirm applicability with your compliance and legal teams before scoping.

Requirement	What it asks for	What it means for the build
DORA Article 28(3): register of information	A register of information covering all contractual arrangements for ICT services, including the node hosting and HSM providers.	Every cloud, hosting, HSM and managed-service provider behind a node needs a register entry. Keep node operators, cloud regions and key custodians in one inventory that the ledger team maintains.
DORA Article 28(8): tested exit strategies	Documented and tested exit strategies and transition plans for ICT services that support critical or important functions.	Test moving a member node, its ledger data and its keys to another host. Confirm that Fabric or Besu data can be exported and that the rebuild steps are written down and rehearsed.
DORA Article 30(2): contract terms	Contracts must state where services are provided and data processed, require advance notice of changes, and cover data return on insolvency or termination.	Name the hosting regions and key storage locations in the contract. Require notice before changes to node infrastructure, and require ledger and configuration data return at exit.
DORA Article 26(7): threat-led penetration testing	The only authority-issued attestation DORA provides for is that a threat-led penetration test met the requirements. The ECB states that the core requirements of DORA TLPT and TIBER-EU are identical.	Scope the node, orderer or validator infrastructure, HSM integration and identity services into the testing plan where they support critical functions. Confirm with your supervisor how TLPT results are documented and accepted.
FTC Safeguards Rule: MFA and logging (16 CFR 314.4)	Multi-factor authentication for any individual accessing any information system unless the Qualified Individual approves an equivalent control in writing. Logging of authorized user activity and change management procedures.	Applies only to non-bank financial institutions under FTC jurisdiction. Require MFA on CA administration, peer and orderer administration, and node operations consoles, and log administrative actions into a central store.
SEC Rule 17a-4(b): record retention	Broker-dealers must preserve certain business records, such as bills, bank statements and business communications, for at least three years, with the first two easily accessible.	Applies to broker-dealers. Decide which ledger records are books and records, set retention on the ledger and backups, and plan how records are retrieved within the two-year window.
SEC Release 33-8810: IT general controls	For SOX Section 404 scope, examples of IT general control areas include program development, program changes, computer operations, and access to programs and data.	Applies to issuers with internal control over financial reporting. Chaincode or contract changes, Fabric and Besu upgrades, node operations and CA or key access all fall into these areas and need approval records and reviewed access lists.
PCI DSS v4.0.1 (applies only if in scope)	Applies where the node or adjacent systems store, process or transmit cardholder data or could affect that environment. v4.0.1 is the only active version.	Only relevant if card data or sensitive authentication data flows through the ledger or its integrations. If it does, define the cardholder data environment boundary and plan for a Report on Compliance or Self-Assessment Questionnaire through your payment brands.
Swift Customer Security Controls Framework v2026 (applies only if connected to Swift)	32 controls, 26 mandatory and 6 advisory. Members must have controls independently assessed and attest compliance annually in the KYC-SA application.	Applies only if the member connects to Swift. Map Swift-connected systems to the controls and plan the annual independent assessment as a recurring cost and evidence activity.

Fabric or Besu: which platform fits a bank or consortium member

The choice between Hyperledger Fabric and Besu depends on the trust model, the privacy design, and the version line your members can operate for years. Each card below names a fit condition and a check to run before the platform is committed to a DORA-scoped ICT register entry.

Fabric when members need channel privacy

Fabric suits a consortium where members must transact on separate channels and keep each bilateral relationship hidden from others. Its Raft ordering service is crash fault tolerant, so a five-node cluster keeps working through the loss of two nodes, provided a majority remains available. Fabric v3.0 also added a SmartBFT option that tolerates failures of up to, but not including, one third of ordering nodes. Confirm which ordering model your supervisor and members will accept before the design is frozen.

Fabric v2.5 for long-term support

Regulated members that cannot absorb frequent upgrades often choose the v2.5 line, which the Fabric documentation identifies as the long-term support release for production users. The v2.5.16 patch shipped on the same day as v3.1.5, so the two lines receive patch releases in parallel. Fabric v3.0 removed Solo and Kafka consensus and the v1.x chaincode lifecycle, so existing networks must migrate before moving to 3.x. Ask your partner how security patches are applied to the LTS line and who approves each one.

Besu for proof-of-authority private networks

Besu fits a consortium that already runs or plans an Ethereum-compatible smart contract stack on a private network. It supports proof-of-authority consensus through QBFT or IBFT 2.0, and each node can apply local node permissioning to limit connections to known participants and account permissioning to govern onboarding and suspension. Because these controls are configured per node, the consortium must agree on a single governance process and confirm that every member applies it consistently. The current release line is 26.10.0.

Check existing Besu designs for removed features

Besu has removed several features that older private network designs may depend on, including Tessera privacy, onchain permissioning, and Clique consensus. Besu 26.4.0 removed Clique, so a pure Clique network can no longer start or produce blocks. Before a bank or consortium member relies on an existing design, map each feature in use against the current release notes and record the result in the change file. A design built on a removed feature is an ICT change that needs testing and an approved migration plan.

Plan the JDK 25 runtime for Besu

Besu 26.6.0 requires JDK 25 to build and run, which makes the Java runtime a controlled component of the node image rather than a default host package. Banks typically need the JDK version approved, patched, and included in the vulnerability management process, and it must be pinned in the build pipeline so every node in the consortium runs the same tested stack. Ask your partner how JDK updates are tested against Besu releases and how an unsupported JDK would be detected before deployment.

When neither platform fits

Some consortia should not run the ledger themselves. If members cannot staff node operations, key custody, and upgrades, or if the arrangement would place a critical or important function on infrastructure the institution cannot exit, the consortium should review a managed service. DORA requires every ICT services contract to state where services are provided and data processed, and it requires tested exit strategies for services that support critical or important functions. Treat a managed option as an ICT third-party arrangement and assess it on those terms.

How operations differ on Fabric and on Besu

Fabric operations center on ordering, identity and channel configuration. Upgrades follow a fixed sequence in the Fabric upgrade guide, and the v3.0 line adds prerequisites that must be completed before any binary changes. Fabric CA is part of the operating model because it issues and revokes every enrollment certificate on the network, so its lifecycle belongs in the same change plan as the nodes.

Four-step upgrade: Back up the ledger and MSPs, upgrade orderer binaries in a rolling fashion, upgrade peer binaries in a rolling fashion, then update application channel capability levels. Channel capability levels are a separate step, so binaries can be running on a new release while channels still operate at the older level.
v3.0 prerequisites: Migrate any Kafka ordering to Raft, and move all channels to the v2.x lifecycle before upgrading. Fabric v3.0 removed Solo and Kafka consensus and the v1.x legacy chaincode lifecycle, so a network that skips these steps cannot complete the upgrade.
Gateway client compatibility: The Fabric Gateway client API works with both v2.5 and v3.0, so client applications can be upgraded on their own schedule. This lets the bank move application teams without forcing a network-wide change window.
Fabric CA lifecycle: Fabric CA registers identities or connects to LDAP as the user registry, issues enrollment certificates, handles renewal and revocation, and generates certificate revocation lists. Renewal and CRL publication must be monitored, because an expired or unpublished credential stops a member from transacting.
Release line choice: Fabric v2.5 is the long-term support release for production users, and v3.1.5 and v2.5.16 were both published on June 18, 2026, so both lines receive patches. Confirm which line your change policy approves before planning.

Before any Fabric upgrade, check the current release notes and upgrade documentation for the exact version pair, because the prerequisites change between releases.

Where the node connects to the rest of the bank

A permissioned node touches more of the bank than its own servers. Each connection below carries a different owner, failure mode and evidence trail, so the architecture team should confirm every one before the node design is fixed.

HSM and key custody path

Node signing keys and identity keys should sit in a hardware security module where the chosen platform supports it. Fabric documents HSM use for peer and orderer keys, and Besu node keys are a separate concern that must be planned on its own. Confirm with the bank's security architecture team which HSM family is approved, who holds the administrative roles, how key ceremonies are witnessed, and whether the HSM vendor is itself an ICT service in the register of information.

Identity source for Fabric CA

Fabric CA can use LDAP as its user registry, so enrollment follows the people and groups the bank already governs. This is the decision point where joiner, mover and leaver processes reach the ledger. Confirm which directory is authoritative, whether a dedicated directory is required for network identities, how certificate renewal and revocation are triggered when staff leave, and who approves changes to the registry.

Operations and metrics feeds to SIEM

Node operations and metrics endpoints are the main source of evidence for availability and security monitoring of the ledger. The bank's SIEM or monitoring platform needs to receive these signals with known retention and alert routing. Confirm which team owns alert triage for ledger nodes, whether logs from the peers, orderers or validators reach the central SOC, and whether the monitoring stack is itself covered by the bank's change and access controls.

JSON-RPC and gateway authentication

Applications and internal services reach a Besu node through JSON-RPC, and Fabric applications reach the network through the Gateway client API. Each entry point needs authentication, network segmentation and an allowlist of the callers that may submit transactions. Confirm which applications use which entry points, how API credentials are issued and rotated, and whether direct RPC access from workstations or third parties is prohibited by policy.

Core banking and settlement submitters

Core banking, payments or settlement systems usually submit transactions to the ledger, and their integration logic determines who can write records and under what conditions. This is where a ledger entry can trigger a financial consequence. Confirm which legacy systems write to the ledger, which business events they emit, how failed submissions are retried without duplicates, and who signs off on each new submitter before it goes live.

Backup and archive target

Backups serve two purposes: rollback before an upgrade and retention for the records the bank must keep. Besu's Bonsai database auto-upgrades on first start and older versions cannot open it, so a backup taken before the upgrade is the only rollback path. Confirm the archive location, its encryption and access model, the restore test frequency, and the retention period set by the bank's own records policy, which may differ from the records rules that apply to the bank's regulated businesses.

How a DORA-ready node rollout runs in phases

The sequence turns a consortium decision into a running Fabric or Besu member node that a supervisor can examine, with each phase closing on a written output. The phases are sequenced, not timed, and the durations come from the written scope agreed before work starts.

Scope the ICT services and register entries
The bank and DeployOpen confirm which ledger services support critical or important functions and whether the member falls within DORA scope. Each ICT service is recorded in the register of information required by Article 28(3), including the provider, the locations where services run and data is processed, and the functions affected. The exit strategy requirement in Article 28(8) is noted at this stage so later phases can meet it. The output is a signed scope document and a draft register entry for each service, which the member's compliance team reviews before design begins.
Design governance and permissioning with the consortium
The member and its consortium peers agree who runs which nodes, which channels or contract rules apply, and how membership changes are approved. DeployOpen translates those decisions into configuration: Besu node permissioning and account permissioning files for each node, or Fabric channel policies and organization definitions for a Fabric network. Onboarding, suspension and contract upgrade rules are written down as they will be enforced. The output is an approved permissioning design and a configuration baseline that every member has reviewed, so no party relies on undocumented access.
Build identity, keys and HSM integration
The team designs the certificate and key model before any node is deployed. For Fabric, this covers Fabric CA as the user registry or its LDAP connection, enrollment, renewal and revocation procedures, and the certificate revocation list process. For Besu, it covers node key generation and storage. Where the member uses a hardware security module, the design confirms which keys it protects and how the Fabric HSM integration is configured and tested. The output is a key inventory, a certificate lifecycle runbook, and a documented HSM dependency that the member's security team can review.
Build and harden in the member's environment
DeployOpen deploys the nodes, orderers or validators inside the member's own cloud account, data center or air-gapped network, so keys and data stay under the member's control. Hardening covers encryption in transit and at rest, multi-factor authentication for administrative access, logging of privileged activity, and monitoring endpoints for node metrics. Every infrastructure change is recorded in a change record that links to an approval. The output is a build record, a hardening checklist signed by the member, and change records that show how each component reached its current state.
Test failover, restore and upgrade paths
Before any live transaction is accepted, the team tests the failure cases the member's resilience policy depends on. Ordering nodes in a Raft cluster or validators in a BFT or QBFT set are stopped and restarted to confirm the network keeps operating within its fault tolerance. Backups of the ledger and MSPs are restored to an isolated environment. An upgrade is rehearsed on a lower environment using the same release line the production network will use, such as the Fabric LTS line or a stable Besu release, following the documented upgrade steps. The output is a test report with recorded results, a restore proof, and a rehearsed upgrade runbook with rollback criteria.
Prepare a TLPT-ready test plan
If the member is in scope for threat-led penetration testing, DeployOpen and the member agree a test plan that maps the scope of ledger nodes, identity services and HSM interfaces to the attack surface the supervisor would expect to see. The plan references Article 26(7), which provides the only authority-issued attestation under DORA, and records who is responsible for the threat intelligence and the independent testers. Where the member is not in TLPT scope, the same plan still supplies the security testing evidence for the ledger. The output is a written test plan that the member's risk function approves, with the independent testers and the authority engagement path confirmed in writing.
Go live with an evidence pack and exit plan
Go-live starts only after the register entries, permissioning design, key inventory, test reports and change records are complete. The evidence pack gathers these artifacts with the monitoring setup, the backup schedule and the incident contacts, and the member's compliance team signs it off. The exit plan, which Article 28(8) requires for services supporting critical or important functions, is tested with a documented transition to another provider or to a managed service, including data return under the contract terms. The output is an approved evidence pack, an exit plan with a test record, and a handover to the member's operations team.

What supervisors and auditors will ask for, and which component produces it

This table maps each record a supervisor, external auditor or testing firm is likely to request against the question it answers and the component that produces it. Read it as a checklist for designing evidence collection from day one, not as a list of attestations, since DORA and most financial rules do not provide a certification scheme. Where the record is produced by the bank itself versus an independent party is stated in each row.

Evidence	Question it answers	Component that produces it
DORA register of information entry and Article 30(2) contract clauses	Which ICT provider supports the node, where is the service and data located, and what happens to data on termination or insolvency?	Bank's contract management and third-party register, produced by the bank; contract clauses negotiated by the bank and its legal team
Documented and tested exit strategy and transition plan for the node	Can the bank move its node or ledger role to another operator if the provider fails, and has that move been rehearsed?	Bank's ICT risk documentation and test records; the exit test itself is run by the bank with its provider
Change management records for Fabric or Besu upgrades	Who approved each upgrade, what was tested, and can it be rolled back?	Bank's change tickets and runbooks; pre-upgrade ledger and MSP backups stored by the bank (Fabric upgrade guide, Besu 26.10.0 notes)
Capability level change record for Fabric channels	When and under whose approval did the channel move to a new capability level, and did all members upgrade first?	Channel configuration history from the network operator, kept with the bank's change records
Access logs and MFA evidence, or the written equivalent control	Who accessed node hosts, keys and admin consoles, and did each person authenticate with MFA or an approved alternative under the FTC Safeguards Rule?	Bank's identity provider and SIEM for host and console logs; the Qualified Individual's written approval for any equivalent control
Fabric CA issuance, renewal and revocation records and CRLs	Which identities hold enrollment certificates, when were they issued, renewed or revoked, and is the revocation list current?	Fabric CA database and logs, produced by the bank as CA operator; CRLs exported and retained by the bank
Node and account permissioning configuration history	Which nodes and accounts were allowed to join or transact, who approved each change, and when?	Besu permissions configuration files under version control, and Fabric channel and MSP policy history kept by the bank
ITGC evidence for SOX 404 scope (program changes, computer operations, access to programs and data)	Are changes to ledger software, operations and access controlled well enough to rely on the financial reporting data it produces?	Bank's internal audit and IT controls, evidenced by change, operations and access records; the external auditor tests and opines on them
Retention records under SEC Rule 17a-4	Are required records kept for the required period, with the first two years in an easily accessible place?	Bank's archival system and retention policy; the broker-dealer owns retention, and the ledger export process is documented by the bank
Penetration test and vulnerability assessment record	Has the node estate been tested at the frequency the rules require, and were findings closed?	Independent testing firm produces the penetration test report; the bank produces the vulnerability scan history and remediation tracking

Questions to put to an implementation partner before signing

Start by asking the partner to map every node and every ordering or validator role to a named ICT service in your DORA contractual inventory, then to the entry for that service in your register of information under Article 28(3). Ask which roles support critical or important functions, because that classification drives the exit strategy duties in Article 28(8). Ask who approves a change to a Fabric CA registration or a Besu node or account permissioning file, how that approval is recorded, and whether a second person must confirm a change before it reaches production. For Besu, ask how the permissions configuration files are versioned and distributed to each member's nodes, since a mismatch between members is a governance failure, not only a configuration error.

Ask how private keys are generated, where they are stored, and how they are rotated, and require the partner to show the HSM integration for your chosen Fabric or Besu build against the Fabric documentation on hardware security modules. Then ask what happens when the HSM fails: who can restore signing, how quickly, and whether a tested failover path exists that does not expose key material. On the software side, ask how the partner handles the Fabric v3.0 prerequisites, including migrating any Kafka ordering to Raft and moving all channels to the v2.x lifecycle, or how it meets the Besu JDK 25 requirement. Ask for the partner's list of removed features (Tessera, onchain permissioning, Clique, and the EEA and PRIV privacy RPC groups) and confirm which of them your existing design depends on. Confirm the upgrade runbook starts with a verified backup of ledgers and MSPs, since Besu's Bonsai database cannot be opened by older versions after an upgrade.

Ask the partner to demonstrate, on a non-production network, how an exit or data return would run under Article 28(8) and Article 30(2), including where data would be returned and in what format. Then ask what evidence pack it produces: configuration baselines, change records, access reviews, backup restore tests and monitoring logs. Ask it to state in writing which items it cannot provide, because DeployOpen and other implementers prepare evidence but do not issue audit reports, attestations or certifications. Supervisors and independent assessors decide whether controls are effective, so ask who will act as the assessor and which parts of the pack they will need to review.

What buyers ask before hiring help to run permissioned blockchain nodes

What drives the cost of running a bank node on Fabric or Besu?

Cost follows the number of nodes you run per member, the HSM and key custody setup, certificate authority operations, monitoring, upgrades and the governance work across members. Hyperledger Fabric and Besu have no license fees, so you pay for infrastructure, HSM hardware or service, staff or partner time, and the coordination effort of a multi-party network. Ask any quote to split one-time work (architecture, HSM integration, first deployment, evidence baseline) from recurring work (patching, monitoring, certificate renewal, upgrade cycles). Under DORA, the contract register under Article 28(3) and the tested exit strategy under Article 28(8) are recurring obligations, so budget for keeping them current, not only for building them.

Can our bank operate permissioned blockchain nodes without an outside partner?

Yes, if your team already has the skills to run Fabric or Besu, administer HSMs, and staff an on-call rotation. Without those skills, a partner can plan, deploy and hand over operations, but the bank keeps certain responsibilities regardless of who runs the nodes. These include ownership of the risk decisions, the permissioning policy, key custody decisions, the consortium governance and the supplier register entries for any outside provider. Confirm with your risk and legal teams how DORA's contractual requirements apply if a partner operates nodes on your behalf.

How long does it take to put a bank node into production?

The timeline depends on the written scope, the number of consortium members who must join, and your internal approval cycle, so no duration can be given before those are known. Plan separately for the technical build, HSM onboarding, certificate authority setup, member onboarding and the risk and supervisory review. Fixed-scope engagements at DeployOpen are agreed in writing before work starts, so ask for a timeline tied to named milestones and to the approval dates your committees already hold.

Does choosing Fabric v2.5 LTS change the implementation effort?

It can. Fabric v2.5 is the long-term support release for production users, and the Fabric GitHub releases page shows 2.5 and 3.x receiving patch releases in parallel. Staying on v2.5 avoids near-term migration work, but a v3.0 design brings different requirements: Kafka ordering must move to Raft, channels must move to the v2.x lifecycle, and the BFT ordering service is a new option. Ask your partner to document which line they recommend, the upgrade path to the next line, and how that choice affects your DORA exit and transition plans.

How do Besu's removed features affect an existing design?

Several Besu features you may have designed around have been removed. Besu 25.6.0 removed the Tessera privacy feature and onchain permissioning, Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups, and Besu 26.4.0 removed Clique consensus, so pure Clique networks can no longer start or produce blocks. Review any existing design against these removals, check the local permissioning files and any privacy or API dependencies, and plan the migration before an upgrade. The Besu 26.10.0 release notes also state that the Bonsai database auto-upgrades on first start and older versions cannot open it, so take a backup before every upgrade.

Does DeployOpen issue certifications or attestations for our blockchain nodes?

No. DeployOpen plans, implements, hardens and documents the systems and controls, and prepares the evidence your assessors will review. Independent auditors, certification bodies and, where applicable, the supervisory authority or scheme owner issue any report or attestation. DORA sets no certification scheme, and the only authority-issued attestation it provides for is that a threat-led penetration test met its requirements under Article 26(7). Ask your compliance team which evidence each assessor expects, and ask your partner to map controls to that evidence.

What does the bank need to provide before work starts?

Start by naming owners in risk, information security, architecture and the consortium, each with authority to make decisions. Provide access to change management records, existing network and identity designs, and the current ICT contract register. Decide early on the permissioning model, the node and member topology, and who holds custody of each key, because these shape the HSM design and the evidence set. Confirm how decisions are approved, since a delayed sign-off on any of these will move the schedule set in the written scope.

How DeployOpen scopes, builds and supports financial services ledger nodes

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including permissioned Hyperledger Fabric or Besu nodes for a bank or consortium member. Each engagement starts with a written scope that ties node, key and monitoring work to the ICT risk evidence the institution must produce.

How we scope

Agree in writing which Fabric or Besu nodes, channels or networks the engagement covers and which parties operate them.
Map ledger components to the institution's register of ICT contractual arrangements and its critical or important functions.
Confirm the target infrastructure, data locations and HSM model before any build work begins, since these shape the design.

How we build

Deploy ordering or validator nodes in the client's cloud accounts, data centers or air-gapped networks, with HSM-backed node keys.
Configure identity with Fabric CA or Besu permissioning files, and test that unlisted parties cannot connect or transact.
Set up monitoring, log retention and alerting, then test failover of the ordering service or validator set before go-live.

How we hand over

Document the network topology, identity hierarchy, key custody, backup procedures and upgrade runbooks for the client's operators.
Deliver evidence packs that map controls to the institution's internal audit and supervisory requirements, without issuing any attestation.
Train the client's operations team on node recovery, certificate renewal and the rolling upgrade steps for each release line.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, with scope agreed in writing.
Plan each upgrade against the vendor's release notes, including backup before any change that cannot be rolled back.
Run security testing of nodes, APIs and surrounding systems on a schedule the institution's risk policy requires.

Permissioned blockchain infrastructure for financial services