Requirement
State the institutional outcome and relevant threat or failure model.
Control architecture
Control architecture for institutional deployments.
Gateway maps each requirement to an enforcement point, named owner, inspectable evidence, and defined recovery behaviour for the selected service boundary.
Control method
From requirement to inspectable operation.
The method keeps policy language connected to the system, people, and recovery path that must make it true.
Enforcement point
Name where architecture, policy, or operational process applies the control.
Owner
Assign Gateway, institution, or provider responsibility without ambiguity.
Evidence
Define what a buyer, auditor, or operator can inspect and when.
Recovery
Record bypass, exception, failure, restoration, and residual-risk behaviour.
Control domains
Three connected views of the production boundary.
Detailed controls vary by service, but every institutional design must address authority, operation, and evidence together.
Authority and information
Who may act, what each role may see, and which data or keys remain inside the selected boundary.
- Identity, role, and approval policy
- Privacy, disclosure, residency, and key control
Operation and resilience
How the service changes, fails, recovers, and remains observable across its operating life.
- Release, vulnerability, and change control
- Monitoring, incident response, backup, and restoration
Evidence and transition
What the institution can verify and how data, configuration, and responsibility move at exit.
- Control, test, incident, and service evidence
- Data return, portability, transition, and exit readiness
Privacy control plane
Explore Open Privacy Suite Control who may transact, see, disclose, and audit.
Open Privacy Suite supplies identity-aware policy, controlled views, authorised disclosure, and evidence for supported institutional EVM environments. The full operator and infrastructure boundary remains part of deployment design.
Deployment boundary
Your jurisdiction. Your deployment model.
Hosting, administration, keys, integrations, support, and recovery are scoped against the selected deployment pattern.
Cloud
A managed environment with the production envelope and service boundary defined in the applicable agreement.
Institution-controlled
Platform software deployed into the institution’s estate with component-level operating and support boundaries.
Regional
Eligible processing, storage, keys, and administration constrained to agreed jurisdictions, subject to provider availability.
On-premises
Selected capabilities placed within an institution-controlled environment where architecture and support scope permit.
Hybrid
Institution-controlled and managed components joined through explicit interfaces, evidence, and operational ownership.
Responsibility map
Every control retains a named owner.
Gateway, the institution, and selected providers keep distinct responsibilities. The applicable agreement records the final scope and evidence obligations.
Gateway
Technology delivery and operations, where contractedPlatform software, integration delivery, and the infrastructure controls, observability, incident response, support, and service levels included in the applicable agreement.
Institution
Product governance and retained obligationsCustomer relationship, asset and product policy, jurisdictional analysis, risk acceptance, regulatory obligations, and business approvals that remain with the institution.
Specialist providers
Contracted or regulated services, where applicableServices such as KYC/AML, custody, fiat access, liquidity, attestation, legal, or audit within each provider’s contracted and, where applicable, licensed or approved scope.
Ready to translate requirements into enforcement points, evidence, and recovery behaviour for a target service?
Discuss your control architecture