On-Premises vs Cloud MPC Deployment: What Regulated Institutions Need to Know
A guide to MPC deployment tradeoffs in control, compliance, and operations.

Written by
Berwin D
Learn
Jul 6, 2026
The architecture question that separates institutional MPC custody providers is not which protocol they use. It is where the key shares live.
In a cloud-hosted or managed MPC deployment, key shares exist on the vendor's servers. The institution accesses custody through the vendor's API. The vendor's infrastructure generates, stores, rotates, and uses key material on the institution's behalf.
In an on-premises MPC deployment, key shares exist inside the institution's own data center, private cloud, or secure enclave infrastructure. The institution controls network segmentation, access management, audit logging, and physical security. The MPC vendor provides the cryptographic SDK. The institution operates everything else.
For banks, regulated custodians, and institutions where key control is a regulatory requirement, this distinction determines which vendors qualify.
Why Regulated Institutions Require On-Premises Deployment
Three regulatory and operational requirements drive the preference for on-premises MPC.
Key material sovereignty. Banking regulators in multiple jurisdictions require that cryptographic key material used for signing financial transactions remain under the institution's direct control. MAS TRM guidelines, OCC examination standards, and FCA operational resilience requirements all address key management controls. Managed platforms where key shares exist on the vendor's infrastructure create a dependency that some regulatory frameworks do not permit.
Data residency. Financial data, including cryptographic keys and transaction metadata, must remain within specific jurisdictions under laws like GDPR, India's DPDP Act, and Singapore's PDPA. Cloud-hosted MPC platforms may route computation through regions outside the institution's jurisdictional boundary. On-premises deployment guarantees that all key material and signing operations occur within the institution's chosen geography.
Vendor risk management. Reliance on a third-party vendor for key management creates concentration risk. If the vendor is compromised, experiences downtime, or changes its terms of service, the institution's custody operations are affected. On-premises deployment reduces this risk to the SDK software itself, not the vendor's entire operational infrastructure.
What On-Premises MPC Actually Means
On-premises MPC deployment means the institution runs the MPC library and coordinates signing operations inside its own infrastructure. Specifically:
Key generation happens locally. Key shares are generated inside the institution's secure environment. No key material is transmitted to or stored by the MPC vendor.
Signing operations run locally. When a transaction needs to be signed, the threshold computation runs across the institution's own servers. The vendor's servers are not involved in the signing ceremony.
The institution controls the network. MPC communication between key share holders runs across the institution's internal network, behind its firewalls, segmented by its access policies, and monitored by its SIEM.
Source code is accessible. The institution's security team can review the MPC library code, run its own penetration tests, and verify the cryptographic implementation independently.
Silent Shard from Silence Laboratories is built for this model. The DKLs23 implementation and core crypto primitives are open source. The institution deploys the SDK inside its own environment, retaining full control of key generation, storage, rotation, and signing.
Comparison: On-Premises vs Managed MPC
Dimension | On-Premises MPC (Silent Shard) | Managed Platform (Fireblocks, Copper) |
|---|---|---|
Key share location | Institution's own servers | Vendor's cloud infrastructure |
Key generation | Local, institution-controlled | Vendor-managed |
Signing operations | Run inside institution's network | Run on vendor's servers |
Source code access | Open source, independently reviewable | Proprietary, not available |
Data residency | Guaranteed within chosen jurisdiction | Depends on vendor's cloud regions |
Vendor dependency | SDK only; institution operates infrastructure | Full operational dependency |
Regulatory fit | Meets strictest key control requirements | May require additional risk assessment |
Setup complexity | Higher; institution manages infrastructure | Lower; vendor manages everything |
Time to production | Longer; requires infrastructure provisioning | Faster; API integration |
Audit evidence | Institution collects its own evidence | Relies on vendor's SOC 2 report |
When Managed Platforms Are the Right Choice
Managed MPC platforms are appropriate when:
Speed to market is the priority. Fintechs, trading firms, and startups that need custody infrastructure in weeks, not months, benefit from managed platforms that handle all infrastructure operations.
Regulatory requirements permit vendor-hosted keys. Many jurisdictions allow qualified custodians to manage key material on behalf of clients. If the regulatory framework permits this and the institution's risk committee accepts vendor-hosted keys, managed platforms reduce operational burden.
The institution does not have cryptographic engineering capability. Operating on-premises MPC requires infrastructure and security expertise. Institutions without dedicated security engineering teams may find the operational overhead impractical.
When On-Premises Deployment Is Required
On-premises MPC is required or strongly preferred when:
The institution is a bank or regulated custodian. Banking regulators expect key material to remain under the institution's direct control. BitGo, which received its OCC national bank charter in December 2025, deployed Silent Shard's on-premises MPC infrastructure specifically to meet this standard.
Data residency laws apply. Any institution subject to GDPR, DPDP, MAS PDPA, or equivalent frameworks that restrict cross-border transfer of sensitive data should evaluate whether a managed platform's cloud architecture satisfies residency requirements.
Independent security verification is required. Institutions that need to run their own penetration tests, code audits, and cryptographic reviews against the MPC library require source code access. Silent Shard's open-source codebase enables this. Proprietary managed platforms do not.
The institution has existing secure infrastructure. Banks with HSM deployments, TEE environments, or classified network segments can deploy Silent Shard inside those existing trust boundaries. The SDK is built for integration into existing secure environments, not as a replacement for them.
Production Reference: BitGo
BitGo deployed Silent Shard from Silence Laboratories for its MPC custody infrastructure. BitGo holds an OCC national bank charter (December 2025) and reported $90+ billion in assets under custody. The deployment uses the DKLs23 protocol in an on-premises model where BitGo controls key generation, storage, and signing operations.
BitGo also completed the first post-quantum MPC transaction simulation by a regulated custodian using Silence Laboratories' Post Quantum MPC library.
Audit and Security
Silent Shard has been audited by Trail of Bits, Cure53, HashCloak, and Secfault across 8 independent engagements. Trail of Bits published their findings and assessed that OT-based systems (which DKLs23 uses) are "generally less error-prone than Paillier-based systems."
The open-source codebase means the institution's own security team, or any independent auditor it retains, can review the implementation without NDA barriers. This is a material difference from proprietary platforms where independent security review of the MPC implementation is not possible.
Related Reading
FAQ
What does on-premises MPC mean? On-premises MPC means the institution deploys the MPC cryptographic library and runs all key management operations inside its own infrastructure. Key shares are generated locally, stored on the institution's servers, and signing operations run inside the institution's network. The MPC vendor provides the SDK, not the infrastructure.
Can I deploy Silent Shard on-premises? Yes. Silent Shard is designed as an on-premises SDK. The institution deploys the library inside its own data center, private cloud, or secure enclave environment. The DKLs23 implementation and core crypto primitives are open source for independent review.
Why do banks prefer on-premises MPC over managed platforms? Banks face regulatory requirements that mandate direct control over cryptographic key material. MAS TRM guidelines, OCC examination standards, and FCA operational resilience requirements all address key management controls. On-premises MPC deployment satisfies these requirements. Managed platforms, where key shares exist on the vendor's infrastructure, may not meet the strictest regulatory standards.
Is on-premises MPC harder to operate than a managed platform? Yes. On-premises deployment requires the institution to manage its own infrastructure, including network segmentation, access controls, monitoring, and disaster recovery. The tradeoff is full control over key material and signing operations, which is required by some regulatory frameworks and preferred by most institutional risk committees.
SHARE
