How Institutional Cybersecurity Is Evolving with Digital Asset Infrastructure
Infrastructure and operational compromises accounted for roughly 76% of funds stolen in crypto hacks during the first half of 2026, despite representing only around 15% of incidents, according to TRM Labs. Across the same six months, attackers carried out a record 207 hacks and stole $972 million.
Cosmos brought together Maghnus Mareneck, our Co-CEO, and Marshall Lipman, VP of Strategy at Hypernative, for a roundtable on how financial institutions can manage risks as they adopt digital asset infrastructure. Hypernative is a proactive on-chain security platform that combines real-time monitoring, transaction security, fraud prevention, compliance screening, and automated response.
Hypernative is also part of the Cosmos Partner Network, which brings together specialized service providers across custody, compliance, security, and infrastructure to help financial institutions accelerate tokenization and digital asset initiatives.
Read the roundtable for practical perspectives on the security controls that financial institutions should consider when operating digital asset infrastructure. This discussion also examines how you can build digital assets around the security, risk, compliance, and approval processes they already use.
1. As digital assets become part of regulated financial infrastructure, what does “institutional-grade security” mean for a bank or financial institution?
Hypernative
For a bank, institutional-grade security means being able to prove control over digital assets at every moment of every day. As on-chain markets never close and settlement is final, controls built around end-of-day reconciliation arrive too late.
In practice, I look for four things: continuous visibility into every contract, wallet, oracle, and bridge the assets depend on; independent verification of what a transaction will do before anyone signs it; policies enforced automatically and consistently; and a tested response that can contain an incident in seconds.
Then there's the evidence. A regulator or auditor wants to see the control working, with an audit trail behind it, so we, at Hypernative, hold ourselves to those standards, which is why institutions like BNY, DTCC and Circle work with us.
Cosmos
For a bank, institutional-grade starts with meeting the obligations it already carries. Digital asset infrastructure has to meet the same regulatory, risk, and audit requirements as every other system the bank runs, and it has to fit into the processes its teams already use to approve, monitor, and report on activity.
The bank needs a structure it can explain to a regulator, with a defined set of operators, clear rules on who can issue, move or change an asset, and clear accountability at each layer when something goes wrong. It also needs operational control over its environment, including where its data is held and which counterparties it connects to.
At the same time, a tokenized deposit ledger that falls out of sync with the core banking system creates a second source of truth and more reconciliation work. That is why the Cosmos Tokenization Suite synchronizes tokenized deposit ledgers with existing cores, including Fiserv, FIS, Jack Henry, Temenos, and Hogan.
The infrastructure also has to stay manageable for the people running it. Every new vendor, integration, and connection is one more thing for operations, risk, and security teams to oversee. Any connection to another ledger should introduce no new threat vectors wherever possible. Security starts with that architecture. Specialized partners like Hypernative then monitor and protect the activity that runs on it.
2. Financial institutions already have established processes for security, compliance, risk, and approvals. How do you introduce digital asset infrastructure without creating a parallel operating model that becomes difficult to manage?
Cosmos
Start by treating digital asset infrastructure as an extension of the systems the bank already runs. If a tokenized deposit program has its own approvals, its own key management, and its own reconciliation, the institution ends up running two operating models side by side and maintaining every control twice.
So the ledger has to connect to what the bank has today. The Cosmos Tokenization Suite uses pre-built adapters for core banking systems. Each enrolled account gets a tokenized twin that stays in sync with the core, and the general ledger is reconciled against it. Sanctions screening, KYC enforcement, transfer limits and velocity checks are built into the payment flow, and routing follows the bank's internal policy.
Banks already have custody, compliance and security vendors they trust, and the Suite integrates with existing digital asset custody providers. When a bank needs a capability it doesn't have yet, the Cosmos Partner Network offers specialized firms across custody, KYC/KYB, compliance monitoring and on-chain security, Hypernative among them. That reduces the complexity of sourcing those providers individually.
3. Security has traditionally focused heavily on detecting and responding to incidents. What changes when institutions can identify and stop risky activity before a transaction is completed?
Hypernative
In traditional cybersecurity, detection and response work because you usually have time to investigate and recover. Because on-chain transactions are typically final once settled, effective security starts earlier, in the seconds before a signature and the minutes before an attack executes.
That changes two things. First, when every transaction is simulated and checked against the bank's policy before it's signed, risky activity gets stopped while the assets are still in place. Bybit lost $1.5 billion when signers approved a transaction that looked routine on their screens. Simulation would have shown it was handing over control of the wallet.
Second is time. Attackers leave traces while they prepare, including funding wallets and deploying contracts. Monitoring that activity gives security teams a critical window to intervene, often before the first malicious transaction executes. Across our customers, that approach has prevented more than $3 billion in losses.
4. Digital asset infrastructure can operate continuously, while financial institutions still depend on approvals, defined responsibilities, and escalation procedures. How should institutions decide what to automate and what should remain under human control?
Hypernative
My rule of thumb is to automate containment and keep people on decisions. Containment actions that are reversible and approved in advance are good candidates for automation. Pausing a contract or blocking a transfer to a sanctioned address are typical examples. An exploit can drain funds within a single block, so waiting for someone to wake up and log in has a real cost. And if an automated pause turns out to be a false alarm, the team can unpause quickly. Therefore, the downside there is small.
Anything irreversible, or anything that changes the institution's risk position, should stay with people. Things moving reserves, changing permissions, approving a new counterparty, or deciding when to resume operations after an incident.
The important part is that humans evaluate their exposure fully prior to participation and prepare appropriate control and policies ahead of any program. Automation then carries out what the organization has already agreed to, with a full audit trail. That only works if the signal is trustworthy, which is why Hypernative is invested so heavily in keeping our false positive rate below 0.001%
Cosmos
Programmable infrastructure works best when banks already define who approves what, which limits apply, and when an issue escalates. Once those rules are agreed, the ledger can apply them around the clock.
Recurring, rules-based activity is a good fit for automation. Instant cash sweeps, programmable escrow and weekend payments all work this way, because the conditions are set in advance and every action leaves a traceable record. Changing those conditions should stay under human control. Raising a limit, onboarding a counterparty, connecting to a new network, or upgrading the ledger should go through the same sign-off the bank uses today.
Each automated process also needs a named owner before it goes live, plus an escalation path for when it behaves unexpectedly. That matters most for weekend payments, when the usual team may be offline.
5. A bank’s digital asset environment may involve ledger infrastructure, custody, wallets, compliance, security monitoring, and other specialized providers. Who is responsible for making sure risks do not fall through the gaps between them?
Hypernative
Every provider in the stack secures its own layer. The custodian protects keys, the wallet provider manages signing, the ledger runs the network, compliance screens counterparties. Attackers go looking for the seams between them.
In Bybit’s case, for example, the attackers compromised the signing interface, a layer nobody was independently verifying, and the signers approved what looked like a routine transfer. Each vendor could say its piece worked.
So the institution needs one security view that spans the whole environment. It goes back to what I was saying previously: you have to start with a live inventory of every contract, wallet, oracle, and bridge the assets depend on, including the ones you don't operate on. A misconfigured third-party oracle can put your asset at risk even when your own code is flawless.
From a security partner I'd expect coverage across every chain and custodian the bank uses, plus integration into its SOC (Security Operations Center) and incident process so an alert reaches the person accountable for acting. While accountability stays with the bank, our job is to make sure no part of the environment falls outside anyone's view.
Cosmos
Most gaps open at the handoffs between providers. A custodian's signing flow has to line up with the ledger's permissions, and a compliance alert has to reach the team that can act on it. I believe that before launch, a bank should map each of those handoffs and agree with every provider where its responsibility starts and ends.
However, a tokenized deposit program can need custody, KYC/KYB, wallet infrastructure, compliance monitoring and on-chain security, and each one means another evaluation and integration. We launched the Cosmos Partner Network to shorten that process. Its first cohort of 17 specialized firms works with the Cosmos Tokenization Suite to help global financial players accelerate their digital asset initiatives.
Cosmos provides the digital ledger and tokenization layer, and each partner brings its own integrated services and products, such as KYC/KYB verification, custody, and regulatory compliance monitoring. We're happy to work with Hypernative, who brings real-time monitoring, transaction security and automated response across those handoffs, so a threat that starts with one provider can be caught before it reaches the rest of the bank's setup.
6. When an institution issues a tokenized deposit or another tokenized asset, what does protecting that asset throughout its lifecycle require?
Hypernative
Issuance is the milestone everyone plans for, and it's the start of the job. A tokenized deposit carries the bank's legal and regulatory obligations every day it exists, and a single failure can breach both at once. An unauthorized mint can create unbacked liabilities and put the token in ineligible hands within one block. We think about protecting it in four phases.
Before issuance, you establish who is allowed to hold the asset, and you keep checking. Holders change status and sanctions get applied to existing addresses, so eligibility screening has to continue long after onboarding.
Before each privileged action, you verify every mint, burn, holder-list change, or upgrade against the bank's own records before anyone signs. This is also the main defense against insider risk, because it judges the action itself, even when the person signing is authorized.
While the asset is live, you monitor it continuously. Supply against the off-chain book, the redemption queue, changes to roles and signers, and any transfer outside the permitted holder list. When something goes wrong, you respond in seconds. The bank decides in advance which signal triggers which action, such as pausing the contract or revoking a compromised role. Each action is scoped and reversible, so the decision gets made in calm conditions and the system simply executes it.
Then there's the activity around the asset. Sanctioned counterparties, fraud patterns, impersonation tokens and unusual redemption flows all need continuous monitoring, with a response ready to go, whether that's freezing an address or pausing transfers.
7. Recent digital asset incidents have exposed weaknesses in keys, signers, permissions, infrastructure, and operational processes, not only vulnerabilities in code. Where do you think institutions are still underestimating their exposure?
Hypernative
The biggest blind spot is treating strong key management as the finish line. Banks invest heavily in MPC, HSMs and multisig, but many of the large losses came from legitimate keys signing something harmful. In the Drift exploit, signers were persuaded to pre-sign transactions that the attacker could execute later without fresh approval.
It’s important to keep an eye on how privileged access shifts over time. Admin roles, upgrade rights, mint authority, and pause keys get reviewed carefully at launch and then left alone. Signers change roles and permissions accumulate, often with no one watching them continuously.
The fix for both is the same, namely independent verification before every signature, and continuous monitoring of every privileged action after it.
Cosmos
First, I'd look at connections to other ledgers. A tokenized deposit program rarely stays on one network for long, and each new connection makes the bank dependent on how the other side is secured. As we've written before, if transacting across ledgers carries higher risk, participants need to price that risk. They can only do that when the risk is visible to the people approving the connection.
The same applies to change more broadly. Ledger upgrades, new counterparties and new vendors all change the bank's exposure, so each one should go through the same security review and sign-off as the original deployment.
Open source helps, because banks and their auditors can review the code they depend on. Treating security as part of the operating model means that review is built into how the bank approves every change.
8. Three years from now, which security or operational control that institutions may consider optional today do you expect to be treated as a baseline requirement for digital asset operations?
Hypernative
I’d say independent pre-transaction verification. Today many institutions see simulation on top of their custody stack as an extra layer. Within three years I expect auditors and regulators to ask for it the way they ask for dual control on a wire today. Signing a transaction you can't independently verify will look as outdated as releasing a payment without a callback.
Alongside that, continuous monitoring with pre-approved automated response will become standard for anyone issuing or holding tokenized assets. The operational resilience expectations coming from the OCC, FCA, MAS and MiCA already point in that direction. The institutions that build these controls now will scale faster, because they'll already have the evidence regulators ask for.
Cosmos
I expect continuous reconciliation between the tokenized ledger and the bank's core systems to become a baseline. End-of-day reconciliation leaves hours in which the token supply and the bank's books can drift apart, and that gap gets harder to accept once payments settle around the clock.
Interoperability is the other area. As banks connect to more networks, I expect them to require that the connection layer is open source and openly governed, so their teams and auditors can review the code and no single company controls the protocol their payments run on. That is how we approach the Inter-Blockchain Communication Protocol (IBC).
About the Authors
Marshall Lipman has over 15 years experience in finance, strategy, and business development in both Web2 and Web3 roles. He is the VP of Strategy at Hypernative where he focuses on strategic partnerships and new growth verticals. Marshall previously led business development for Balancer, one of the largest decentralized exchanges in the EVM ecosystem and was the cofounder of GuardianUI, a frontend security company for crypto applications. Before joining the Web3 industry full-time in 2021, Marshall led business development for JTV, one of the largest ecommerce companies in the US and began his career in commercial banking.
Maghnus Mareneck is Co-Founder and Co-CEO of Cosmos Labs, the entity behind the Cosmos blockchain ecosystem, the largest network of blockchains in the world with over $90B in market cap secured. He leads go-to-market and partnerships, and has been active in the cryptocurrency industry since 2013. Prior to Cosmos Labs, Maghnus co-founded Skip Protocol, which was acquired by the Interchain Foundation in 2024. He holds dual degrees in Economics and Computer Science from The Wharton School.
