When a financial institution onboards a new vendor, the procurement process is well-established: domicile verification, background checks, financial health assessment, IT security review, and compliance with recognized security frameworks like ISO 27001 or SOC 2. These are sensible controls, developed over decades to manage the risks that matter most in traditional vendor relationships. But traditional finance is moving onchain, and existing frameworks weren't built for this vendor landscape.
Blockchain service providers introduce two distinct categories of risk that standard procurement doesn't address. The first is vendor smart contract risk: custody solutions, tokenization platforms, and stablecoin issuers each require blockchain-specific due diligence around smart contract security and operational controls that standard frameworks don't prescribe.
The second is infrastructure risk: the blockchain networks, bridges, and oracles that vendors build on often have no legal counterparty, no contractual recourse, and no single owner accountable for security.
SOC 2 and standard procurement protocols aren't enough. A vendor can satisfy every line of a traditional compliance framework and still be running smart contracts that have never been independently audited and introduce new vulnerabilities with each code change. The result is a structural gap: institutions conduct thorough due diligence on the vendor organization while deferring to that vendor's own judgment on the smart contract layer through which client capital actually flows.
The vendors financial institutions most commonly engage in onchain workflows each carry a distinct risk profile:
Beyond direct vendor relationships, institutions also take on risk from the blockchain infrastructure their vendors build on, often without a formal counterparty to hold accountable:
One of the more underappreciated aspects of onchain financial infrastructure is how many smart contracts sit between an institution and its clients. In a tokenized asset workflow, client capital may pass through contracts governing issuance, transfer restrictions, custody, settlement, and cross-chain bridging, each embedded within a different vendor's solution, carrying its own security posture, and representing an independent point of failure.
Institutions need to think about this as a supply chain: whether every smart contract within a vendor's solution that interfaces with client capital has been audited, how recently, by whom, under what methodology, and whether the audit scope actually covered the deployed code.
Third-party risk deferred is institutional risk retained. Allowing a vendor to set its own security standards for the smart contracts embedded in their infrastructure is risk deferral without accountability, and regulated institutions are unlikely to find that acceptable when examined by supervisors.
Each link in this chain of capital flows is a unique attack vector. It is up to each institution to require guardrails around each smart contract with standards on what is and is not tenable.
The incentive structures in the blockchain vendor market make this more acute. Building a robust security program requires significant time, investment, and organizational maturity. Many blockchain vendors are early-stage and venture-backed, and security is often one of the last functions to be fully developed as companies scale. Without contractual requirements or independent standards mandating a minimum security posture, there is no consistent baseline across the market, and no reliable mechanism for an institution to assess where a given vendor actually stands.
This is not hypothetical. The major digital asset losses in recent years were predominantly caused by smart contract vulnerabilities, key management failures, and operational security gaps, none of which standard procurement frameworks are designed to surface. Financial institutions have the instinct to demand security assurances from vendors, but standard procurement frameworks weren't designed to test for these specific risks, and a vendor's self-attestation is not a substitute for independent assessment.
Alongside existing financial, legal, and IT controls, institutions engaging blockchain vendors should be asking a distinct set of questions across the full risk profile of the onchain infrastructure involved. OpenZeppelin's Technical Risk Assessment framework organizes these into five domains:
|
Domain |
Key Questions |
|
Blockchain Infrastructure Risk |
What is the consensus mechanism, and how robust is the validator set? How is governance structured, and what is the track record for upgrades and incident response? What does historical uptime look like? |
|
Collateral and Reserve Risk |
For vendors involving tokenized assets or stablecoins, what is the quality and liquidity of reserves? How is custody handled, and is there independent Proof of Reserves attestation? |
|
Market and Liquidity Risk |
What is the trading depth and volatility profile of the assets involved? For pegged assets, how stable has the peg been under stress conditions? Are there supply concentration risks? |
|
Operational Control and Key Management |
How are privileged functions controlled? What multisig configurations are in place, and how is role separation enforced? What are the recovery procedures if keys are compromised? |
|
Smart Contract Security and Dependencies |
What audit methodology has been applied to each, by which firm, and when? How is new or upgraded code reviewed before deployment? How are contracts monitored in production, and what is the incident response procedure? What is the disclosure policy for identified vulnerabilities? |
A vendor that cannot provide clear answers across these domains has not operationalized institutional-grade risk management. That's a meaningful signal for any institution's risk assessment.
Extending due diligence in this direction requires institutions to build internal literacy around blockchain security risk, or to bring in advisors who are well versed on both blockchain and institutional frameworks. Risk and compliance teams don't need to become security engineers, but they do need enough fluency to evaluate vendor responses, identify gaps, and escalate appropriately.
This is also a governance question. Who within the institution owns smart contract risk for third-party relationships: IT, legal, or a dedicated digital assets risk function? In most institutions, this accountability is currently spread across teams, and the fluency needed to assess these risks doesn't always sit where the accountability lands. Establishing clear ownership is a precondition for building a coherent program.
OpenZeppelin has conducted over 1,000 security engagements across the full spectrum of blockchain vendors and infrastructure, from custody solutions and development shops to L1 and L2 networks, bridges, oracles, DeFi protocols, and tokenization platforms. That depth of experience is the foundation of our Technical Risk Assessment, which provides a structured methodology for evaluating onchain counterparties across contract security, key management, monitoring, governance, and incident response readiness. For institutions focused on the operational and off-chain surface of their blockchain vendors, our Blockchain Operational Security Assessment evaluates the controls that standard procurement frameworks miss: key custody practices, multisig configuration, signing infrastructure, deployment pipelines, and privileged-action monitoring.
The procurement process for blockchain vendors must evolve as adoption across banking and financial services grows. Otherwise, every security incident or compliance failure makes institutional entry harder for the clients who follow. Firms that build the right vendor risk frameworks now will be better positioned to safeguard client capital as institutional adoption onchain continues to grow.
Why isn't standard vendor due diligence sufficient for blockchain service providers?
Standard compliance frameworks are principles-based and high-level by design. They don't prescribe smart contract security testing, audit cadences for onchain code, or the operational controls specific to blockchain infrastructure. A vendor can fully satisfy standard frameworks and still present meaningful unexamined risk at the smart contract layer.
What is smart contract risk and why does it matter for financial institutions?
Smart contract risk is the risk that the onchain code governing an institution's transactions contains vulnerabilities, is inadequately monitored, or is upgraded without proper security review. It matters because client capital flows directly through these contracts, and losses from exploits are typically irreversible.
How does blockchain risk vary by vendor and infrastructure?
Vendor risk and infrastructure risk are distinct categories that require different due diligence approaches. Vendors like custody solutions, audit firms, and development shops can be evaluated through traditional counterparty frameworks, supplemented by blockchain-specific questions around smart contract security and operational controls. Infrastructure choices, such as which blockchain network, bridge, or oracle to build on, carry a different risk profile entirely, often with no legal counterparty, no contractual recourse, and no single owner accountable for security. Applying a uniform checklist across both categories will miss the most important risks in most cases.
What regulatory frameworks are relevant for EU institutions?
Institutions subject to DORA and MiFID II (for tokenized securities) face specific third-party risk management obligations that extend to technology infrastructure. MiCA adds requirements for issuers of digital assets regarding system and infrastructure security. Neither framework currently provides smart-contract-specific guidance, but both establish clear expectations for managing technology risk across the operational stack.
How can financial institutions assess the smart contract security of a blockchain vendor?
By requesting a full contract inventory, audit history and methodology, upgrade and deployment procedures, and monitoring practices. OpenZeppelin's Technical Risk Assessment framework and Blockchain Operational Security Assessment provide structured methodologies for evaluating both the onchain and operational layers, calibrated to the specific type of vendor being assessed.