What Financial Institutions Actually Need From Blockchain Infrastructure

CDK Enterprise solves the problems that permissioned chains can't

SWIFT was built in 1973 because banks couldn't agree on a shared ledger. 

So they built a messaging system instead: a way to send payment instructions across a network of correspondent banks, each holding accounts with each other, each taking a cut, each adding time to settlement. It was an elegant solution to a coordination problem. It worked, and recent updates, like SWIFT gpi, have made transfers faster.

But not internet-levels fast. 

Blockchain brings internet speed to a shared ledger. That's it. Underneath all the jargon, that's what it is. And a shared ledger between institutions streamline’s SWIFT's correspondent banking chain: the intermediaries, the delays, the fees deducted mid-transfer—all upgraded with blockchain. 

This is what financial institutions are actually buying when they invest in blockchain infrastructure. 

Building a shared ledger for institutional use is genuinely hard, though. It has to be private enough to satisfy regulators and counterparties, flexible enough to meet compliance requirements that vary by jurisdiction and use case, fast enough for real transaction volumes, and connected to enough liquidity to be worth using.

Most enterprise blockchain deployments solve one or two of those. Most collapse the privacy question into a binary: public or private.

CDK Enterprise, built by Polygon Labs, launched with support from implementation partners like Gateway and Conduit, is designed differently. 

Privacy is a set of levers, configured around your specific regulatory environment, counterparty structure, and operational requirements. Chains built with CDK enterprise connect natively to Agglayer, a protocol to unify all of crypto. This enables cross-chain settlement networks and seamless connectivity to crypto’s liquidity.

A shared ledger that only reaches institutions already inside your network is a more expensive version of the problem you started with.

That's the problem CDK Enterprise is built to solve.

The problem with private chains

For most of the past decade, institutions approached blockchain in one of two ways. They either tried public chains, found them incompatible with disclosure requirements and data sovereignty obligations, and walked away. Or they went the permissioned route, building on Hyperledger Besu or other solutions, and got exactly what they asked for: a private network with full control.

The problem with the second path only becomes visible later.

Permissioned chains are isolated by design. Your counterparties need to be on your network. Secondary liquidity requires building it yourself. Interbank settlement works only if the other bank joins your consortium. Expanding your network means negotiating access, standing up new nodes, and managing a governance model that grows more complex with every participant.

These are the core use cases that make blockchain worth the investment for banks: interbank settlement, tokenized assets with real secondary markets, stablecoin systems that connect to the broader financial ecosystem.

All of them require connectivity that walled-garden infrastructure cannot provide.

Why CDK Enterprise makes sense right now

Two things have shifted the calculus enough to warrant a second look.

Zero-knowledge proofs have moved from academic research to production infrastructure. That matters because it resolves the core tension between privacy and verifiability. You can now prove a transaction is valid without exposing the transaction data itself. The proof is the verification. You get the compliance properties of a public ledger and the confidentiality of a private one.

Regulatory posture has also clarified in key jurisdictions. 

Stablecoin frameworks, tokenization sandboxes, and CBDC pilots have moved from exploratory to directive. The Monetary Authority of Singapore’s Project Guardian is a concrete example: a cross-industry initiative involving DBS, JPMorgan, SBI Digital Asset Holdings, and others, testing tokenized assets and institutional DeFi in a live regulatory sandbox. 

Institutions that treated blockchain as a research project are now facing infrastructure decisions with real timelines. Waiting has a cost.

What financial institutions actually need

Strip the technology away and the requirements are consistent across institutions:

• Transaction throughput that can support actual operational volumes
• Data that stays private to authorized parties while remaining auditable to regulators
• Compliance by architecture: GDPR, KYC, AML built into the system, not layered on afterward
• Access control that integrates with existing enterprise identity infrastructure
• Migration from existing deployments that doesn't require starting over
• A vendor with defined SLAs and accountability for operations
• Interoperability with counterparties and ecosystems the institution doesn't control

This is the same checklist any bank would apply to a core banking system vendor or a payments network provider.

CDK Enterprise: designed for your requirements, not a generic configuration

CDK Enterprise is a ZK-secured blockchain toolkit built specifically for institutional deployments. But the more important thing to understand is what it actually is in practice: an advisory, architecture, and operational engagement, not simply a product you configure yourself and run.

Polygon Labs, along with implementation providers (IP) like Gateway and Conduit, work with institutions to design the chain that fits their specific regulatory environment. The privacy architecture, the access model, the data residency approach, the node distribution, the compliance integrations: all of it gets designed for the institution's requirements.

That's a different model from buying software and deploying it. It's closer to how institutions engage with core infrastructure partners: you bring the requirements, they bring the expertise and accountability.

A spectrum of privacy, not a binary

The most important architectural decision in any institutional blockchain deployment is how privacy actually works. CDK Enterprise treats this as a configurable spectrum, not a fixed setting.

Depending on the institution's regulatory environment and use case, design can be toggled around the right combination of:

• Private data availability via Conduit, so that even the underlying data layer is not exposed beyond authorized parties‍
• Granular privacy controls with IAM permissions geared to each user via Gateway's private RPC, private mempool, and private block explorers, so users only see transactions relevant to them, not the full chain state‍
• ZK validity proofs, meaning only cryptographic commitments are submitted to the chain, not raw transaction data. Counterparties and regulators can verify correctness without seeing underlying transactions‍
• Fully Homomorphic Encryption (FHE) via Zama, for use cases requiring computation on encrypted data without ever decrypting it, currently in implementation for Tokeny‍
• Granular access control, from whitelist-based permissioning down to address-level visibility settings, with integrations into Microsoft Entra and AWS IAM‍
• (Forthcoming) Integration with Miden, the programmable privacy network for the future of finance

The right combination depends on who the institution's counterparties are, which regulators have oversight, and what the chain is actually being used for. That's the advisory conversation. The technology supports a wide range of configurations. 

The design work is figuring out which one fits.

Two types of institutional chains, two different designs

Not every institution has the same primary requirement. CDK Enterprise deployments fall into two broad categories, each optimized differently.

Asset and settlement chains are built for institutions managing tokenized securities, interbank settlement, or digital asset issuance. The primary requirement is privacy. Counterparties need verifiability without exposure. Regulators need audit access without seeing raw transaction data. The architecture leans on ZK proofs, private DA, and role-based access, with throughput as a secondary concern.

Payment and transaction chains are built for high-volume, lower-latency use cases: stablecoin payments, real-time settlement, cross-border flows at scale. CDK Enterprise running on Gateway and Conduit's infrastructure supports up to 20,000 transactions per second. The architecture prioritizes throughput and finality, with privacy handled at the permissioning and access control layer.

Both chain types connect natively to Agglayer, which handles cross-chain settlement to whatever networks the institution's counterparties are on.

Under the hood: What CDK Enterprise actually delivers

Performance: Up to 20,000 transactions per second, a throughput range required for serious payment volume.

Compliance: GDPR compliance is architectural. Transactional data is stored in the institution's own databases, not on a shared ledger. KYC is handled out of the box through Billions identity. Auditors and regulators receive role-based access to verifiable activity logs without requiring exposure of raw transaction data.

Licensing: CDK is open source. The codebase does not require a commercial license tied to a token. For institutions evaluating infrastructure with five and ten year time horizons, this matters more than it might appear in an initial evaluation.

Operations: IP provide managed infrastructure with enterprise SLA, including security, DevOps, and ongoing support. This is not a self-hosted toolkit.

You shouldn't have to start over if migrating

Many institutions evaluating new blockchain infrastructure are already running on Hyperledger Besu. The standard concern is data continuity: what happens to existing transaction history, and how much downtime does migration require?

The Palm Network migration to CDK Enterprise is the reference case: zero downtime, full transaction history preserved.

The migration path from Hyperledger to CDK Enterprise is documented, has been executed in production, and does not require rebuilding institutional records from scratch.

Connecting to deeper liquidity through Agglayer

The part that gets underweighted in early infrastructure conversations is what connectivity actually unlocks downstream.

CDK Enterprise chains connect natively to Agglayer, the cross-chain settlement layer developed by Polygon Labs that’s unifying crypto liquidity. Agglayer uses ZK proofs to secure cross-chain asset movement, which means cryptographic finality rather than optimistic assumptions. Cross-chain settlement completes in under an hour rather than the multi-day windows that other bridge architectures require.

That means interoperability with other networks without additional integration work, without wrapping tokens into synthetic variants, and without settlement delays that create counterparty risk. A CDK Enterprise chain can bridge natively to Ethereum and to any other network connected to Agglayer.

• For interbank settlement: your counterparty doesn't need to be inside your network
• For stablecoin issuance: market access from day one
• For tokenized securities: secondary liquidity not constrained by consortium membership

Questions worth asking any platform

If your institution is evaluating enterprise blockchain infrastructure in 2026, the questions that matter most are not necessarily only about the technology itself:

• What is running in production today, with real transaction volumes, outside of a pilot?
• Who operates it, under what SLA, and with what incident response commitment?
• What happens to our existing data if we migrate?
• What does interoperability cost, and who captures that value?
• Is the codebase open, or does our infrastructure depend on a commercial license tied to a third-party token?
• Will the vendor design the architecture around our compliance requirements, or are we configuring ourselves into their standard offering?

The answers to those questions will separate infrastructure built for institutional requirements from infrastructure built for institutional marketing.

CDK Enterprise is deployed by implementation providers. To discuss your institution's infrastructure requirements, get in touch.