Today, we are introducing Tenants. It’s a new entity at the top of the DFNS data model. A Tenant is the container that holds your multiple Organizations: one identity for your business, many fully segregated operating environments beneath it. Until now, an Organization was the top domain on DFNS. Every team, every environment, every client you served needed its own Organization, with its own users, its own passkeys, its own bill, and no structural relationship to the others. Tenants give those Organizations a parent, and give you the controls that only make sense from above.
The hierarchy now reads:
Why a layer above the Organization
Two needs kept arriving from opposite directions, and they turned out to be the same feature.
- The first is internal segregation. A treasury desk, an operations team, and an engineering group should not share one wallet estate. Production should never touch staging. A legal entity in one jurisdiction should not share configuration with one in another. The clean answer is separate Organizations, but separate Organizations meant separate identities: a team lead managing three environments juggled three sets of passkeys and three logins, and nobody could see across them.
- The second is serving clients. Banks, platforms, and payment companies building on DFNS increasingly hand environments to their own customers, each of whom must be completely isolated from the others, in their own applications, on their own domains, with no possibility of crossover. That is a business model, and it needs a data model.
Tenants serve both. Segregation stays absolute at the Organization level. Coordination becomes possible at the Tenant level.
What a Tenant is
A Tenant is the entity that owns Organizations. Tenant members can create Organizations, manage each Organization’s status and external settings, manage Tenant-level permissions and settings, choose where each Organization’s keys are stored, and manage billing. Everything below that line, the wallets, vaults, policies, permissions, settings, users, webhooks, integrations and all the other critical notions inside an Organization, stays with the Organization.
Mapping to how institutions are actually organized
Regulated groups are not one operating entity. They are a parent and its legal entities, booking centers in several jurisdictions, business lines with different mandates, and a hard wall between production and everything that is not. Tenants let the platform mirror that structure instead of flattening it.
The Tenant is “Acme Group.” Each Organization is whatever unit, team, branch, or subsidiary your governance recognizes: a legal entity, a booking center, a business line, an environment, or a client. Group functions that need to see across the estate, risk, internal audit, treasury oversight, hold Tenant-level read-only roles. Operating teams hold permissions inside their Organizations and nowhere else. The three lines of defense stop being an Organization chart and become an access model.
If your architects know cloud Organization hierarchies, the shape will be familiar: a management layer that provisions member environments and sets guardrails they cannot override, while each environment administers itself within those bounds. Tenants are that pattern applied to digital asset operations.
Organizations you can manage
Organizations now have a lifecycle you control. Create them. Suspend them, temporarily and reversibly, the moment your security team sees something it does not like, or when a client relationship pauses, or when a bill goes unpaid. Archive them out of the active list, and restore them if you need them back, because an Organization is a large container of history and configuration, and in regulated finance the record outlives the entity; we would rather you never face an irreversible delete you regret.
How much a Tenant sees and does inside an Organization is a choice and it can differ from a company to another, a team to another. A Tenant can hold no access to an Organization at all, appropriate when the Organization belongs to a client whose operations must be invisible to you. It can hold partial access, read-only oversight for a risk or audit function, or scoped rights over specific operations. Or it can hold full access, for the internal environments your own teams run day to day. The same Tenant can run all three arrangements at once, one per Organization, and change them as relationships evolve. Access and control are shaped to the need, rather than inherited from the hierarchy.
One identity, many Organizations
A new user type, the “Tenant User,” lives at the Tenant level and can be granted access to any Organization within it, with the same user ID and the same passkey everywhere. Switching between Organizations on the dashboard no longer means signing in again: a Tenant User exchanges a token for one scoped to the next Organization, while every action still requires a fresh credential signature, so convenience never dilutes control. Passkey domains are allowlisted at the Tenant level, matching how enterprise identity is actually administered. Organization users and end users are unchanged: they live inside a single Organization and can never cross its boundary.
Access is not permission
This is the design decision we are proudest of, and the one your auditors will recognize as separation of duties. Tenant members decide which Tenant Users may access which Organizations, the way an identity function provisions who belongs where. But access alone grants nothing: a newly admitted user holds zero permissions until that Organization’s own authorized members grant them, the way a system owner grants entitlements. Two keys, two roles, and neither can act alone. Least privilege is the default state, not a configuration you remember to apply.
And the joiner-mover-leaver process collapses to one action. When a Tenant revokes a user’s access to an Organization, every permission that user held there is revoked with it. Revoking their Tenant membership removes them from the entire estate at once. Offboarding a departing employee from twelve environments is one decision, immediately complete, and logged once.
Controls that flow down and cannot be lifted from below
Two kinds of control now sit above the Organization, and they come from two different places.
- The first is set by the Tenant. Some Organization settings are external: defined at the Tenant, read-only to the Organization. Which key store an Organization’s wallets live on. Hard limits on wallets, users, and volumes. Quotas that keep one environment from consuming another’s capacity. An Organization operates freely within these bounds and cannot widen them from inside, because the setting does not live at its level.
- The second sits above even the Tenant. Certain capabilities are governed by feature flags that DFNS enables or disables for a Tenant, at the Tenant’s request and under its agreement, and then enforces across every Organization that Tenant holds. Key export is the clearest example: when it is disabled for your Tenant, no Organization administrator can enable it, and neither can a Tenant administrator acting alone, because the control is held outside your company entirely and applied uniformly to all of it.
Segregation by design
What Tenants deliberately do not do matters as much as what they do. Policies, approval groups, and webhooks remain defined inside each Organization. For now, there is no Tenant-level policy that reaches down and overrides an Organization’s rules, because an Organization’s governance must be an unbroken chain from the people inside it, the chain the Governance Engine verifies. Integrations, KYT, Travel Rule, exchanges, staking, swaps, are configured per Organization. Every Organization keeps its own complete audit trail and its own integrity verification. If you want several Organizations to run the same policies, you can synchronize them programmatically; the platform will not do it behind your back.
And segregation extends to the hardware. Key stores (your MPC signing clusters, TEE, HSM, offline signer) are configured at the Tenant level, and each Organization is assigned its own when it is created. One client’s Organization can live on a dedicated HSM. Your production Organization can sit on a different key store than staging. Where keys live becomes a per-Organization decision made at the Tenant, which is exactly where a regulator would expect it to be made.
Bounded blast radius
Because every Organization is a hard boundary, an incident’s blast radius is one Organization. Should there be suspicious activity in one environment, the Tenant can suspend that Organization in seconds with everything else running untouched, while forensics proceed on that Organization’s own logs and its Governance Engine integrity status.
Production and staging on different key stores means a compromise of one is not a compromise of the other, and concentration risk across signing infrastructure becomes a Tenant-level decision rather than an accident of history. Regulators increasingly ask institutions to demonstrate operational resilience by design. The Tenant model makes the demonstration structural.
Use cases
- A global bank with entities in several jurisdictions. The group is the Tenant. Each booking entity, London, Frankfurt, Singapore, Dubai, is an Organization with its own key store in-region, its own KYT and Travel Rule providers configured to local requirements, its own approval groups drawn from local staff, and hard limits set by the group. Group risk holds read-only access across all four. A supervisor examining the Frankfurt entity receives Frankfurt’s audit trail, complete and scoped, and nothing else.
- A bank offering custody to other institutions. Each client bank is an Organization on a dedicated key store, its own staff holding the permissions inside it. The provider bank holds Tenant access, but Tenant access cannot grant itself permissions inside a client’s Organization, because only the client’s authorized members can. The provider can suspend the Organization, bill it, and impose limits on it; it cannot approve or move the client’s funds unless the client’s own governance says so. The regulatory separation the contract promises becomes a property of the data model.
- A private bank or asset manager with segregated mandates. One Organization per fund, per mandate type, or per business line, discretionary and execution-only apart, each with policies matched to its mandate and an audit trail its administrator and auditor receive in isolation. Positions never mix; evidence never bleeds.
- A payments platform serving enterprise clients. Each client is an Organization running on the client’s own domain, provisioned through the Tenant API as onboarding completes, with quotas allocated per client so no one account can exhaust another’s capacity, and suspension available for compliance holds or non-payment without touching any other client. One contract with DFNS, one bill, hundreds of isolated environments.
- Environments across the delivery lifecycle. Development, UAT, and production as three Organizations: a shared signing cluster for development, a dedicated HSM for production, and the same policy set synchronized programmatically, so governance changes are tested in an isolated Organization under production-identical rules before they touch production.
- Corporate events. An acquired business’s existing Organization attaches to the acquirer’s Tenant without re-platforming; a divested unit’s Organization detaches to its own. Archived Organizations keep their complete history for as long as retention rules require.
What this changes for you
- Security. Suspend an Organization in an incident without touching anything else. Offboard a person from every Organization in one revocation. Keep production keys on a different root of trust than development. Hold one passkey per human, while every action is still individually signed.
- Compliance. Separate client funds, legal entities, and jurisdictions into Organizations with their own settings, integrations, and key stores. Impose hard limits and disable capabilities from above, where the Organization itself cannot lift them.
- Proof and logs. Every Organization remains its own evidentiary unit: a complete audit trail, a Governance Engine integrity status that independently verifies its database has not been tampered with, and its own policy history. Tenant-level actions, who was granted access where, which Organization was suspended and when, are logged in their own right. What you present to one entity’s examiner, or one client’s auditor, is that entity’s record and no one else’s.
- Segregation. Teams, entities, environments, and customers each get a real boundary, not a naming convention.
- Automation. Organization lifecycle management is exposed through the Tenant API, with self-service and programmatic Organization creation, including key store selection, rolling out so that provisioning a new environment becomes an API call.
- Billing and cost allocation. One contract, one bill, one set of limits tracked at the Tenant and aggregated across Organizations, with quotas allocable per Organization. For groups that charge back infrastructure to business units, the Organization boundary is the cost center.
What changes for existing customers
The Tenant model is opt-in. Existing Organizations continue to run exactly as they do today, and customers who have no need for multiple Organizations will see no change in their daily operations. When you are ready for a second Organization, for a new entity, a new environment, or a new client, ask us to migrate you to the Tenant model: support@dfns.co. We will create the Tenant around your existing Organization, work with you to decide who becomes a Tenant User, and hand you the container with nothing about your current setup disturbed.
Where this goes next
The roadmap follows the two needs that created Tenants:
- fully self-service Organization provisioning through the API, Tenant-level service accounts for automated environment management, Tenant-scoped personal access tokens, SSO for Tenant Users, custom Tenant-level permissions beyond the built-in admin and read-only roles
- and tooling to bring long-standing Organizations into the multi-Organization model.
The direction is to give the people responsible for the whole estate the controls that belong at the top, and leave the boundaries between Organizations exactly as hard as they are today.
Get started
- Learn more about onchain core banking: dfns.co
- Explore the platform and documentation: docs.dfns.co
- Talk to our team about Tenants: sales@dfns.co