Introducing Governance Engine

A zero trust architecture for institutions managing digital assets, deployable on-premises, sovereign, and compliant by design.

Thibault de Lacheze-Murel
Thibault de Lacheze-Murel
| 14 min read

Today we are introducing the Governance Engine, a new service in the DFNS architecture that fundamentally changes how financial services can rely on a wallet platform. With the Governance Engine in place, DFNS becomes the first onchain core banking platform to deliver a true zero trust model end to end, where the customer no longer needs to trust the operator of the platform, not even DFNS itself.

The Governance Engine is one component of a broader Full System Integrity architecture we have been engineering for years, which we also refer to internally as the DFNS Zero Trust Security Model. It sits alongside our Validation Gate, Trusted Execution Environments (TEEs), hardware-rooted attestations, signature chains, and a number of other measures and mechanisms that together enforce data integrity from the user’s intent all the way through to the blockchain.

What follows is enough to understand why this matters, what the engine does, and how the flows work.

What we mean by Full System Integrity

The phrase “zero trust” gets used loosely in this industry. Most often it means “we have MPC and SOC 2.” That is not what we mean.

Full System Integrity is a concrete property: the customer should be able to verify, end to end and on their own, that every operation DFNS performs on their behalf corresponds to a legitimate user-signed intent applied to a legitimate, governed state. The customer should not have to trust DFNS to operate the wallet platform correctly. They should be able to detect deviation and stop it before any signature is produced.

That property is not achievable with a single feature. It requires a layered architecture in which several different components each close a specific gap in the trust chain:

  • Validation Gate closes the pre-signature gap. Before a transaction reaches the signing stack, it is structurally validated against the user’s intent, the wallet’s configuration, and a set of independent integrity checks.
  • Trusted Execution Environments (TEEs) close the runtime gap. The most sensitive cryptographic operations run inside hardware-isolated enclaves whose state cannot be observed or manipulated by the host operating system.
  • Hardware-rooted attestations close the identity gap. Every user identity is linked to a WebAuthn/FIDO2 credential and protected by hardware-backed credentials on the user’s device, like a YubiKey or an iPhone’s secure enclave.
  • Database isolation closes the blast-radius gap. Per-organisation logical isolation means that compromise of one customer’s data does not propagate to another.
  • Signature chains close the audit gap. Every state transition is signed, every signature is verifiable, and the chain of signatures forms a tamper-evident audit substrate.
  • Offline signers close the cold-storage sovereignty gap. Air-gapped, HSM-grade signing keys are generated and operated client-side while run through the same DFNS control plane as online keys.
  • Bring Your Own Chain (BYOC) closes the regulatory gap. Customer-operated permissioned networks (starting with Besu) plug into DFNS as first-class chains, so institutions keep full control of validators, membership, and data residency.
  • Governance Engine closes the data integrity and authorisation gap. It is the component that lets the customer verify, cryptographically and in real time, that the governance state inside DFNS has not been tampered with and that every action against it is the result of a legitimate signed intent.

Each of these layers is meaningful on its own. Together they produce a system in which the customer holds the veto over every signature, every state change, and every operational decision that touches their wallets. The Governance Engine is the layer that ties everything together. Without it, the other components are strong but standalone primitives. With it, they become a verifiable system.

One point deserves emphasis, because the list above is easy to misread. The integrity guarantee does not rest on the TEEs. It rests on two things the customer holds: the signing key, and the cryptographically committed governance state described below. Trusted Execution Environments harden the runtime. They are defence in depth, not the root of trust. An institution that cannot run enclaves, or chooses not to, still gets the full “verify, don’t trust” guarantee with the Governance Engine.

The problem the Governance Engine solves

Most platforms in this market today, including ours until now, ask the customer to trust the provider in at least one critical place. Even with strong cryptography (MPC, HSMs, TEEs), strong policies, and strong audit logs, the underlying database and orchestration layer that decides which user is allowed to do what, under which policy, against which wallet still lives inside the provider’s infrastructure. A sufficiently determined insider, a compromised admin, or a sophisticated supply chain attack against the provider can, in principle, manipulate that state and cause a downstream signing operation that the customer never authorized.

This is the gap. Cryptographic key safety is not enough. The integrity of the governance data around the keys, including users, credentials, permissions, policies, and historical transactions, is what determines whether the signing operation is legitimate. If that data can be tampered with inside the provider’s stack, the cryptography downstream becomes a beautifully secured execution of an illegitimate instruction.

Regulators have started to name this gap explicitly. DORA’s framing of ICT third-party providers as supervisory concerns, the Basel Committee’s evolving expectations on operational resilience of critical service providers, and the increasing institutional appetite for sovereign and on-prem deployments all point to the same conclusion: wallet infrastructure cannot remain a trust-me black box. It has to become verifiable. The Governance Engine is our answer.

What the Governance Engine is

The Governance Engine is a service that is deployed on the customer’s own infrastructure, on-prem or in a sovereign cloud, and runs under the customer’s exclusive control. It is small, stateless (almost, more on that below), and intentionally narrow in scope. Together with the signers, also deployed client-side, it gives the institution everything it needs to verify, in real time, that every operation DFNS is asked to perform corresponds to a legitimate, user-signed intent applied to a legitimate, governed state.

In other words: the customer no longer needs to trust DFNS to operate the wallet platform correctly. The customer can detect any deviation and stop a fraudulent signing process before it produces a signature, let alone reaches the chain.

The Governance Engine performs four interlocking functions:

  1. Validates the integrity of the critical data in the database. Users, credentials, permissions, wallet policies, and historical transactions are all governed. Any modification to these records inside DFNS infrastructure that has not gone through a properly signed user intent is detected and rejected.
  2. Validates wallet policies. When a signing flow triggers a policy, the engine independently verifies that the right policies were applied, that the correct approvals were collected, and that the approval set matches the configured threshold.
  3. Validates user permissions and intent. It verifies that the user requesting an action is who they claim to be, that their credential is part of the governed state, and that the user actually signed the intent corresponding to the action.
  4. Validates the blockchain transaction. Finally, before any signature is produced, the engine verifies that the blockchain transaction DFNS is about to sign matches the user’s signed intent, byte for byte.

If any of these checks fails, the engine refuses to authorise the signature, and the signer refuses to sign. The customer holds the veto.

Architecture

The architecture is built around two client-side components and a thin coordination layer on the DFNS side:

The Governance Proxy is the DFNS-side service that exposes the work queue to the customer’s Governance Engine. Everything that flows from DFNS to the customer side is treated as untrusted and is independently verified by the engine using cryptographic proofs.

A pull model, not a push model

One detail worth calling out before getting into the flows: the Governance Engine polls the DFNS proxy for work. It is never pushed to. The mTLS connection is always initiated from the customer side, and the engine processes the queue at its own pace, in strict chronological order.

This is deliberate. It means:

  • No inbound path from DFNS into customer infrastructure. The customer’s firewall remains closed to DFNS. The only traffic that crosses the perimeter is outbound, initiated by the engine.
  • DFNS cannot force-feed state. There is no API the DFNS side can call to “inject” a governance event. The engine consumes from a queue it has chosen to read.
  • Ordering is the customer’s to enforce. Because the engine pulls events in chronological order from the user actions queue, it sees the true sequence of governance events as they were recorded, not the order DFNS might wish to present them in.
  • Backpressure is natural. If the engine is slow, busy, or temporarily unavailable, no governance events are lost. They wait in the queue. When the engine resumes, it catches up.

In zero trust terms: the customer holds the clock, the customer holds the connection, and the customer holds the veto.

How it works at a high level

The architecture rests on a few key building blocks. We will keep this section deliberately at altitude.

Cryptographic state, not just logs

The critical governance data inside DFNS (users, credentials, permissions, policies, transaction history) is represented in a cryptographically committed structure held and signed by the customer’s Governance Engine. Every authorised mutation to that data produces a new committed state, signed by the engine. The engine retains the latest signed state locally.

This means the engine does not need to hold a full copy of the database. It only needs to hold the cryptographic root of the governed state. When DFNS infrastructure presents a record (a user, a credential, a policy, a wallet), the engine can verify cryptographically that the record is part of the governed state, using a compact proof. If DFNS ever serves a record that is not part of the committed state, the proof fails and the engine rejects the operation.

Conceptually, the engine maintains something like this:

struct GovernedState {
    root: Hash,            // cryptographic root of the governance tree
    version: u64,          // monotonically increasing state version
    signature: Signature,  // engine's signature over (root, version)
}

Every state transition (adding a user, registering a credential, modifying a policy) produces a new (root, version, signature) tuple. The signature is produced by a key that lives exclusively inside the Governance Engine, on customer infrastructure. DFNS never holds it.

This is the single most important property of the design. The engine does not have to trust anything DFNS sends it. It verifies.

User intent is signed by the user, verified by the customer

Every action that mutates governance data or triggers a signature requires a user-signed intent. The intent is bound, cryptographically, to the exact payload, path, and parameters of the action. It is signed using the user’s WebAuthn credential or other strong authentication material that lives outside DFNS’ control.

A user intent passed to the engine looks roughly like this:

{
  "action": {
    "payload": "{\"email\":\"alice@bank.com\",\"kind\":\"CustomerEmployee\"}",
    "method": "POST",
    "path": "/auth/users",
    "summary": "Create CustomerEmployee (alice@bank.com)"
  }
}

The engine then runs a sequence of independent checks against this intent, against the user’s public key (which itself lives in the governed state), and against the cryptographically committed root.

Every one of these checks is performed by the customer’s engine, on customer infrastructure, against the state the customer has signed itself. There is no way for DFNS to forge or replay an intent that the user did not sign, because the engine will detect it.

Chronological enforcement

Order matters. If users, credentials, permissions, and policies are added or modified out of order, the security model collapses. The Governance Engine processes governance events in strict chronological order, using the user actions queue as a verifiable stream. Every state transition is anchored to the previous one, producing a tamper-evident chain of governance over time.

Each op references the previous state version. An op that arrives out of order, or that references a stale state, is rejected.

Built for hybrid and on-prem, deliberately

A natural question is: why not offer the Governance Engine as part of the standard DFNS SaaS platform, where DFNS operates everything for the customer?

The honest answer is that doing so would defeat the purpose. The whole point of the Governance Engine is that the customer holds a component DFNS cannot reach. If DFNS operates the engine too, even with the best intentions, the threat model collapses back into “trust DFNS.” The signatures the engine produces would be produced inside DFNS infrastructure, and the customer’s veto would no longer be enforced on the customer’s side. It would be security theatre rather than a security guarantee.

For that reason, the Governance Engine is available specifically for hybrid and on-prem deployments, where the engine and signer run inside the customer’s own infrastructure, in the jurisdiction the customer chooses, under the customer’s exclusive operational control. This includes:

  • On-prem deployments in the customer’s own datacentres.
  • Sovereign cloud deployments, including regional, EU, GCC, APAC, and government cloud environments.
  • Hybrid deployments where DFNS runs the orchestration plane in its SaaS environment but the engine and signer live on customer infrastructure.

This positioning is intentional, and it maps onto a specific class of customer. Institutions running DFNS purely as SaaS are typically optimising for speed, simplicity, and a managed operational footprint. That is a perfectly valid choice, and our SaaS platform continues to provide bank-grade security, SOC 2 Type II, ISO 27001, and the full set of certifications and controls institutional clients expect from a critical infrastructure vendor.

But certain clients, in particular regulated banks, financial market infrastructures, central banks, large custodians, and stablecoin issuers, are required to demonstrate operational and cryptographic control over their critical systems. Their regulators, their auditors, and their internal risk functions expect them to be able to answer the question “what happens if your wallet provider is compromised or coerced?” with something stronger than “we trust them.” For those institutions, the Governance Engine, deployed alongside the signer in their own perimeter, is the answer.

In short: SaaS is the right fit when speed and simplicity matter most. Hybrid or on-prem with the Governance Engine is the right fit when verifiable control matters most. Both models coexist on the same DFNS platform, and clients can move between them as their requirements evolve.

What changes for the institution

For an institution deploying DFNS with the Governance Engine, the security posture changes in four concrete ways:

  • Insider risk is structurally mitigated. A rogue DFNS operator, a compromised admin account, or a malicious change to the DFNS database cannot produce a signature. The most they can do is be detected.
  • Operational sovereignty becomes real. The Governance Engine and signer run on infrastructure the customer controls, in the jurisdiction the customer chooses. The customer’s keys, intents, and governance state never have to leave their perimeter. This is materially relevant for institutions under DORA, MiCA, BaFin, MAS, ADGM, VARA, and equivalent regimes, as well as for sovereign cloud and on-prem deployments demanded by central banks and FMIs.
  • Audit becomes deterministic. Every authorised action produces a verifiable cryptographic event. Auditors and regulators can independently reconstruct what happened, by whom, under which policy, and on which wallet, without relying on trust in any single party’s logs.
  • The wallet platform becomes a verifiable financial control. Wallets stop being an opaque dependency and become a programmable trust system whose behaviour the institution can prove, not just observe.

This is the property that institutional risk, compliance, and audit teams have been asking for from the wallet category for years. Until today, no one in the market has delivered it end to end.

A staged rollout, by design

We are rolling the Governance Engine out in stages. The reason is simple: institutional security is not a single feature, it is a layered architecture, and each layer materially improves the posture even before the next one ships. We are building it the way regulated infrastructure should be built: iteratively, deployable in production at each step, with clear threat-model mitigation at every layer.

The high-level sequence:

  1. Database integrity governance. The first wave protects user credentials, user permissions, wallet policies, and historical transaction data. After this step, no critical record can be silently modified or injected inside DFNS infrastructure. The threat model for insider tampering with the governance state is closed.
  2. Policy validation. The engine independently validates that the right policies were applied to a signing flow and that the right approvals were collected.
  3. Blockchain transaction validation. The engine verifies that the blockchain transaction matches the user’s signed intent before any signature is produced.

Once all three layers are in place, the customer has end-to-end verifiable governance from user intent to onchain signature.

What this means for the industry

The next generation of regulated institutional digital asset deployments, from tokenized deposits to stablecoin issuance to wholesale CBDCs to onchain capital markets, will require a different proof: not that the provider is trustworthy, but that the customer does not need to trust the provider. That is the bar we have been working toward, and it is the bar the Governance Engine clears, as part of the broader Full System Integrity architecture.

For institutions evaluating wallet infrastructure today, especially those building under DORA, MiCA, MAS TRM, FFIEC outsourcing guidance, or sovereign deployment mandates, this is the first time the market has had an answer that holds up to the question your CISO, your DPO, your auditor, and your regulator are all about to ask in parallel: who do we have to trust, and what happens if they are wrong? With the Governance Engine deployed in your perimeter, the answer is: no one, and nothing breaks.

If you are operating digital asset infrastructure at institutional scale, or planning to, get in touch. We will walk you through the architecture in detail under NDA, share the relevant patent filings where applicable, and help you evaluate whether the Governance Engine fits the threat model you are designing against.

Contact us