Today, we are introducing Validation Gate, a validation step that lets institutions place a final checkpoint on their own infrastructure, one that every signing request must pass before a signature is produced. The result is a stronger guarantee than any cloud-side control can offer on its own: even in the extreme case where DFNS’ infrastructure were compromised, the final decision on whether to sign stays with you.
It’s available now for both MPC and HSM-based deployments, enforced inside the signer that runs inside your own environment.
The problem: a control point that survives a total compromise
DFNS already enforces governance before anything is signed. The Policy Engine applies approval quorums, limits, allowlists, screening to every transaction and more. For the vast majority of institutions, that is exactly the control they need.
But the Policy Engine, in our SaaS model, runs inside DFNS’ infrastructure (not the case for hybrid and on-premises deployments). So the most security-conscious institutions, the ones who want a strong segregation of duties between the API and the signers and because they want a true zero trust model, ask a sharper question: what happens if DFNS itself is breached? In that worst case, an attacker, whether an external intruder or a rogue insider, could try to bypass the checks on the API side and reach the signing layer directly.
Validation Gate closes that gap. It gives the customer a last check, performed on their own infrastructure, immediately before a signature is produced. Even if an attacker reached the signing layer directly, the customer can detect the unexpected request and stop the signature from happening. Because the check runs inside the signer in the customer’s own environment, the protection does not depend on DFNS being intact. It moves the platform closer to a true zero trust design.
How it works
When the Validation Gate is configured, the signer calls a validation handler each time it receives a request to sign or export a key. The call is synchronous, like any other call in the signing path. The signature is produced if, and only if, the handler returns 200 OK. Any other response, or no response at all, cancels the operation.
The handler is an endpoint the customer runs on its own infrastructure. It receives the full context of the request, applies whatever logic the customer chooses, and returns approve or deny. This is the customer’s own code, enforcing the customer’s own rules, on the customer’s own systems.
What the validation handler receives
So the handler can make an independent decision, each request carries the full intent of the operation alongside trusted metadata attached by the driver itself:
- The intent: the API path and payload, for example a native transfer to a given address for a given amount
- The full transaction to be signed
- The initiator: user ID and username
- The source and destination addresses
- An external ID, usable as a caller-supplied proof of origin
- Signer-attested fields, added in the signing path directly: a hash of the transaction, the key ID, the request kind (signing or key export), the public key behind the key and the derivation path (for HD wallets)
That last set matters. Because the key ID and public key are attached in the signing path itself, the handler can bind the request it is approving to the exact key that will sign, rather than trusting the surrounding request alone.
Designed for zero trust, not bolted on
Two design decisions make Validation Gate meaningful rather than cosmetic.
First, it cannot be disabled through an API. If there were an endpoint to register or remove a handler, an attacker who had compromised DFNS could simply call it and switch the feature off. So no such API exists. Configuration lives at the signer level, set through environment variables and secrets in the customer’s own deployment:
VALIDATION_GATE_HANDLER_URL="https://validation.customer.xyz/validate"VALIDATION_GATE_HANDLER_SECRET="..."VALIDATION_GATE_CERTIFICATE="..."Second, the channel between the driver and the handler is authenticated, so the handler can be certain a request genuinely comes from DFNS’ signing layer and not from something imitating it. Two mechanisms are supported, and they can be combined:
- A shared secret, configured by the customer and used to sign the request body, which the handler verifies on receipt
- TLS, where the customer signs a certificate for the driver. This one is optional, for customers who operate their own PKI
Where it fits
Validation Gate does not replace the Policy Engine, it complements it. The Policy Engine remains the place to express rich, business-level governance: who can do what, up to which limits, with which approvals. Validation Gate adds a second, independent enforcement point that lives entirely on the customer’s infrastructure and answers a different question: is this signature authorized, checked one final time, by a system DFNS cannot touch?
Together they give institutions defense in depth across the full path of a transaction, from business-level policy inside the platform to a final, sovereign checkpoint at the moment of signing. For an institution whose mandate is to trust no single party with its assets, that is the difference between a strong control model and a complete one.
Availability
Validation Gate is available now for both MPC and HSM-based deployments, where the signer runs in the customer’s own environment, whether on-premise or hybrid. If you run DFNS with your own MPC cluster or HSM and want a final, self-controlled checkpoint before every signature, talk to us.
Get started
- Learn more about onchain core banking: dfns.co
- Explore the platform and documentation: docs.dfns.co
- Talk to our team about Validation Gate: sales@dfns.co
Frequently asked questions
What is Validation Gate? Validation Gate is a customer-controlled validation step that places a final checkpoint on the customer’s own infrastructure, one that every signing request must pass before a signature is produced. It is available now for both MPC and HSM-based deployments, enforced inside the signer that runs in the customer’s own environment. Even in the extreme case where DFNS’ infrastructure were compromised, the final decision on whether to sign stays with the customer.
How is Validation Gate different from the DFNS Policy Engine? The Policy Engine expresses rich, business-level governance — approval quorums, limits, allowlists, and screening — and runs inside DFNS’ infrastructure. Validation Gate does not replace it; it adds a second, independent enforcement point that lives entirely on the customer’s infrastructure and answers a different question: is this signature authorized, checked one final time, by a system DFNS cannot touch? Together they give institutions defense in depth across the full path of a transaction.
Where does the validation check run? It runs inside the signer in the customer’s own environment, whether on-premise or hybrid. When Validation Gate is configured, the signer calls a validation handler each time it receives a request to sign or export a key. The call is synchronous: the signature is produced if, and only if, the handler returns 200 OK. Any other response, or no response at all, cancels the operation.
What information does the validation handler receive? Each request carries the full intent of the operation alongside trusted metadata attached by the driver itself: the API path and payload, the full transaction to be signed, the initiator (user ID and username), the source and destination addresses, and an external ID usable as a caller-supplied proof of origin. The signer also attaches, in the signing path directly, a hash of the transaction, the key ID, the request kind (signing or key export), the public key behind the key, and the derivation path for HD wallets — so the handler can bind the request to the exact key that will sign.
Can Validation Gate be disabled through an API? No. There is intentionally no API to register or remove a handler, because an attacker who had compromised DFNS could otherwise simply call it and switch the feature off. Configuration lives at the signer level, set through environment variables and secrets in the customer’s own deployment.
How is the connection between the driver and the handler secured? The channel between the driver and the handler is authenticated, so the handler can be certain a request genuinely comes from DFNS’ signing layer and not from something imitating it. Two mechanisms are supported and can be combined: a shared secret, configured by the customer and used to sign the request body, which the handler verifies on receipt; and TLS, optional, for customers who operate their own PKI.
Which deployments support Validation Gate today? Validation Gate is available now for both MPC and HSM-based deployments, where the signer runs in the customer’s own environment, whether on-premise or hybrid.