When a treasury operation spans five legal entities across three continents, a single transaction approval can require sign-off from a CFO in Singapore, a compliance officer in Dubai, and a legal signatory in São Paulo. The infrastructure holding these approvals together is not a shared system. It cannot be. Each entity has its own regulatory obligations, its own data residency rules, and its own governance structure. The question enterprises face is not whether to distribute signing authority. It is how to coordinate distributed signing without creating a brittle, ad-hoc chain of manual confirmations that breaks under operational pressure.
Cregis operates across 50+ countries and has spent nine years building the Trust Layer infrastructure that answers this exact question. Secure. Efficient. Compliant.
TL;DR
- Multi-entity enterprises cannot rely on shared infrastructure for transaction signing because jurisdictional, regulatory, and governance boundaries make it legally and operationally untenable.
- MPC-based M-of-N signing is the technical foundation that allows geographically separated signatories to approve transactions without any single party holding a complete key.
- Approval workflows must be modelled as formal state machines, not informal email chains, to achieve auditability at scale [enterprisecms.org].
- Coordination without shared infrastructure requires careful design of quorum rules, fallback logic, and escalation paths per entity.
- Institution-grade security standards are the baseline for any institution attempting this architecture.
About the Author: Cregis is an enterprise-grade digital asset infrastructure provider with nine years of operational experience serving 3,500+ businesses across 50+ countries. The company's MPC custody and policy engine infrastructure is purpose-built for the multi-entity, multi-jurisdiction signing problems described in this article.
Why Can't Multi-Entity Enterprises Just Use a Shared Signing System?
The instinct to centralise is natural, but shared signing infrastructure introduces problems that compound across jurisdictions. A common signing system implies a common data store, a common key management environment, and a common audit trail. Each of those "commons" can conflict with local regulatory requirements.
Consider three concrete constraints:
- Data residency rules. Certain jurisdictions require that cryptographic material and transaction records remain within their borders. A shared cloud instance that replicates data across regions may violate this by default.
- Corporate governance separation. Regulators and auditors frequently require that entities within a group demonstrate independent governance. A shared signing environment can blur that boundary in ways that create liability.
- Liability isolation. If Entity A's signing infrastructure is compromised, a shared system can expose Entities B and C to the same failure. Isolation is a risk control, not an inconvenience.
This is why the multi-entity signing problem is, at its core, an architecture problem rather than a workflow problem [enterprisecms.org]. The right process cannot compensate for the wrong structure.
What Is M-of-N Signing and Why Does It Fit This Problem?
Building on the structural constraints above, the harder question is how to achieve coordinated authorization without a shared key. MPC-based M-of-N signing is the mechanism that makes this possible.
In a standard digital signature, one private key signs a transaction. Whoever controls that key controls the asset. M-of-N signing distributes that authority: the key is never assembled in one place. Instead, cryptographic key shards are held by separate parties, and a valid signature requires any M of those N parties to participate in a signing ceremony.
Think of it like a physical bank vault that requires three of five keyholders to turn their keys simultaneously. No single keyholder can open the vault alone, and the vault does not require all five. MPC applies this mechanism at the cryptographic level, meaning the "keys" never leave their respective holders even during the signing ceremony itself.
For a multi-entity enterprise, this maps cleanly:
| Signing requirement | MPC equivalent |
|---|---|
| Signatory per legal entity | Key shard holder per entity |
| Quorum of entities required to authorize | M-of-N threshold |
| No single point of control | No key shard constitutes a complete key |
| Jurisdiction-specific key custody | Shard stored in-jurisdiction per entity |
Cregis delivers MPC-based key distribution where each key shard can be held within the entity's own environment, which means signing authority is genuinely distributed without requiring a shared infrastructure layer.
How Should Approval Workflows Be Structured Across Entities?
Stepping back from the cryptographic mechanism, a separate concern is how approval states are modelled and managed across entities that do not share a system.
The answer is to treat the workflow as a formal state machine, not a set of informal confirmations [enterprisecms.org]. Every transaction request moves through defined states: initiated, pending review, partially approved, fully approved, or rejected. Each state transition is triggered by a verifiable action from a designated signer, and each transition is recorded immutably.
Multi-approver workflows typically follow three patterns [cognitoforms.com] [ideagen.com]:
- Serial approval. Each approver acts in sequence. Entity A must approve before Entity B is notified. Useful when there is a dependency, such as compliance review before treasury authorization.
- Parallel approval. All approvers are notified simultaneously. The transaction proceeds when the required quorum responds. Faster, but requires careful design of timeout and fallback rules.
- Conditional approval. The approval path changes based on transaction attributes. A transfer above a certain threshold routes to a senior signatory. A cross-border transfer triggers an additional compliance check.
For multi-entity environments specifically, conditional logic often carries the most operational weight [sysgenpro.com]. Different entities have different internal approval chains, different risk thresholds, and different regulatory reporting obligations. A workflow engine that applies a single approval path uniformly across all entities will either under-control some entities or over-burden others.
The policy engine must therefore be configurable at the entity level, not just at the group level.
What Happens When a Signer Is Unavailable in a Different Time Zone?
A related but distinct question is operational continuity. A three-entity quorum spanning Asia, the Middle East, and Latin America spans roughly 12 hours of working time. If a required signer is unreachable, the transaction stalls.
Robust multi-entity workflows address this through:
- Designated alternates. Each primary signer has a pre-authorized backup within the same entity, already registered in the signing environment.
- Escalation timers. After a defined window, the request escalates automatically to the alternate or to a supervisory approver [sysgenpro.com].
- Expiry rules. Transactions that do not achieve quorum within a defined period are automatically expired and must be re-initiated, preventing stale approvals from accumulating in queues.
These are not optional refinements. They are the difference between a workflow that holds under real operating conditions and one that works only in controlled demonstrations.
How Does Compliance Auditing Work Without Shared Infrastructure?
Without a central system of record, how does a group compliance or audit function verify that all entities are following policy?
The answer is that each entity maintains its own immutable audit log of signing events, and those logs are reported upward through a defined aggregation mechanism. The group-level view is assembled from entity-level records, not stored centrally by default.
This approach aligns with how regulators think about consolidated supervision: the group is responsible for the aggregate view, but each regulated entity is responsible for its own records [sysgenpro.com]. The audit trail must be entity-specific and independently verifiable.
Cregis's Trust Vault Security Framework supports this model. Its "Sign What You See" transparency mechanism records exactly what was signed, by whom, under what policy conditions, and at what time. That record is independently verifiable per entity without requiring cross-entity data sharing.
Frequently Asked Questions
What is M-of-N MPC signing? It is a signing method where a transaction requires a minimum number (M) of participants from a total set (N) to produce a valid signature. No single participant holds a complete key.
Can each legal entity hold its own key shard in its own jurisdiction? Yes. MPC architecture is designed so that key shards can be stored in separate environments. This supports data residency compliance without requiring a shared key management system.
What is the difference between serial and parallel approval? Serial approval requires each approver to act in sequence. Parallel approval notifies all approvers simultaneously and proceeds when the quorum is met [cognitoforms.com].
How do enterprises handle time zone gaps in approval chains? Through designated alternates, escalation timers, and transaction expiry rules that prevent stale approvals from creating risk or delay [sysgenpro.com].
Does removing shared infrastructure mean losing a group-level audit view? No. Entity-level audit logs can be aggregated for group compliance reporting without requiring a shared central system.
What certifications should a multi-entity signing infrastructure hold? At minimum: SOC 2 Type II, ISO 27001, and PCI DSS. These cover security operations, information management, and payment data handling respectively.
Is cloud-native MPC custody suitable for entities with strict data residency requirements? Cloud-native and self-hosted deployment are both valid approaches. The choice depends on each entity's specific compliance requirements, not on a general judgment about which is more secure.
About Cregis
Cregis is the Trust Layer: enterprise-grade digital asset infrastructure, purpose-built for institutions that need security, compliance, and operational reliability at scale. Secure. Efficient. Compliant. Its MPC-based custody platform, programmable policy engine, and global compliance certifications (SOC 2 Type II, ISO 27001, PCI DSS) make it the foundational infrastructure layer for enterprises managing digital assets across multiple entities and jurisdictions. Cregis currently serves 3,500+ businesses across 50+ countries, from banks and payment service providers to corporate treasury teams managing cross-border digital asset portfolios.
To learn how Cregis can support your multi-entity signing architecture, visit https://www.cregis.com/.
References
- How to Build Approval Workflows for Marketing Content at Scale | Enterprise CMS Guide (enterprisecms.org)
- Finance Workflow Automation for Multi-Entity Approval ... (sysgenpro.com)
- How to Set Up Approval Workflows with Multiple Approvers (cognitoforms.com)
- Implementing a document approval workflow with multiple approvers (ideagen.com)
