What is vaultless tokenization?

TL;DR: What a vaultless token actually is, why it's computed rather than looked up and how to keep it straight from the three other things enterprise software calls a token.

“Token” might just be the most overloaded word in enterprise software. Put “millions of tokens per second” on a datasheet and an ML engineer reads inference throughput, a payments engineer reads card credentials and a platform engineer reads a session-token incident. If you read it as data security tokenization, take a bow, you knew it on sight. Most do not. 

This article focuses on the vaultless data security token: A stand-in for a sensitive value that is computed from it, rather than looked up in a table. With a well-designed tokenization system, a data security token can stand in for a sensitive value so faithfully that every schema, validation check and join accept it as the real thing and it hands whoever steals it nothing they can use. Useless in the wrong hands, fully functional in yours. That is the true value of vaultless tokenization.

Four types of tokens

The four types of tokens can cause confusion. They share a skeleton, take a value, hand back a stand-in and control the path back. But past that skeleton, they have almost nothing in common. So the definitions come first.

1. The data security token: The one this series is about

This is a surrogate designed so the surrounding records keep working while the actual value is gone. An account number is replaced by something the schema accepts as an account number. 

This token comes in two flavors:

• Non-deterministic tokenization returns a different token per value every run. This boosts security but breaks cross-dataset linking.

• Deterministic tokenization returns the same token for the same value on every node and for every run. Deterministic tokens are typically used for analytics and fraud detection. The joins still run, but the real value is elsewhere. 

Every claim in this series is about the vaultless, deterministic token. The others are here because they're what it keeps getting confused with.

2. The subword token

In an ML pipeline, tokenization means splitting text into units from a learned vocabulary so a model can operate on integers instead of raw characters. The vocabulary is public. Decoding is a published operation anyone can run. There is no secret anywhere in this process and it protects nothing. It exists so a model can read.

3. The payment token

Card networks issue surrogate credentials through a token service provider. The token on your phone can genuinely move money, but only within its domain restrictions: a specific device, merchant or channel. Steal it and it's useless anywhere else. The design goal is the opposite to that of a data security token: a payment token isn't supposed to be inert, it's supposed to work in exactly one place.

4. The auth token

A JWT or OAuth bearer token is a claim: This caller is who they say they are so they can access the tool until a specified time and date. The token is signed, usually not encrypted. Anyone can decode a JWT and read its contents. The security lives in the signature and expiry. Note that in the case of authentication tokens, there is no stored value the token stands in for. 

What you get 

Now let’s put all four through the same test: what does a thief get? 

• A stolen payment token still works somewhere. 

• A stolen auth token acts as its owner until it expires. 

• A stolen batch of subword tokens decodes to the text, which was never secret anyway. 

• A stolen data security token gets the thief nothing at all: no capability, no domain where it works, no path back to the original without calling the algorithm with an explicit policy grant. 

Meanwhile, the systems holding that same token lose nothing either. The schema accepts the tokens, the joins run, the pipelines process it like the real value. Useless in the wrong hands, fully functional in yours. Everything this series says about data protection builds on that combination.

Vaulted vs. vaultless tokenization 

This series is all about the vaultless data security token. So, let’s start by defining what a vaultless tokenization system is and how it’s different from a vaulted tokenization system. Read on for all the details.

How vaulted tokenization works

The classic tokenization architecture is vaulted. A secured database stores the pairing between each plaintext value and its token. Tokenizing inserts a row, detokenizing queries one. Everything about the security model follows from the existence of that table, which has to be hosted, replicated, backed up and defended for as long as the tokens circulate. 

How vaultless tokenization works

Vaultless tokenizationhas no table. To create the token, the system parses the plaintext to isolate any characters requiring preservation. The remaining sensitive data is transformed into derived protected values by algorithm and merged back with the preserved sections to deliver a secure, utility-ready token.

Here’s a concrete example, with a made-up card number:

(Token) 6390 1234 5678 9113   →   (Value) 4417 8302 6647 1050

(16 digits in, 16 digits out, both pass a Luhn check; the schema, the length validation and the joins never notice)

Run the same input through a node in another region, against the same tokenization engine and you get the number on the right again. Magically, nothing was stored to make that happen and nothing was consulted.

That example breaks the conventional and intuitive picture of a token: the random, meaningless string that points to a row somewhere. With vaultless tokenization, it's wrong twice:

1. There is no row. Nothing was stored at creation, so there's nothing to query, nothing to replicate, no central record of which tokens even exist. 

2. The token isn’t random, it’s derived. Under the same configuration, the same value yields the same token on every run, which is what keeps data joinable across systems that never talk to each other. That determinism does real work, and it has costs, which come later.

Most of the advantages that come with vaultless architecture follow from these capabilities. Two nodes in different regions produce identical tokens for the same input without coordinating, which is why the architecture works federated and even air-gapped. Throughput scales with compute because there's no shared store to contend with. Capital One Databolt is packaged as a containerized solution that scales horizontally in the customer's own environment. There's no accumulating repository of plaintext token pairs for an attacker to target and no vault availability sitting in the path of every protected read. They read as separate capabilities, but are one fact.

Common misconceptions about vaultless tokenization

The vaultless tokenization argument invites four comparisons.

1. Isn’t vaultless tokenization just a vault with extra steps?

No, though the vault does buy real things. Since a vault stores the mapping, its tokens can be fully random, with no mathematical relationship to the plaintext at all. It can hand out totally random tokens for the same value in different contexts. It can revoke one token by deleting one row. 

Vaultless tokenization gives that up in exchange for removing coordination from the hot path. At enterprise scale, with a vault sitting in front of every protected operation, removing that dependency has proven to be the better trade for a lot of workloads. There’s also no vault to protect. 

A traditional vault relies on a massive, ever-growing centralized database to map tokens to plaintext. In vaultless systems, there is no database, just an algorithm. Databolt abstracts this complexity entirely, securely managing the cryptography behind the scenes so authorized systems can tokenize data and safely de-tokenize based purely on policy grant. 

2. Isn’t vaultless tokenization just a hash?

This confusion causes real incidents because hashing gets shipped as tokenization. A hash has no path back under any authority. Whatever you hash is gone for every legitimate purpose too. And for low-entropy values, it barely protects anything going forward. An unsalted SHA-256 of a national ID or a phone number can be reversed by enumerating the input space on a laptop. Salting fixes the enumeration and destroys cross-system consistency, at which point you've built consistent masking, not tokenization. 

Hashing is a choice of irreversibility, and it works fine as long as it's made as one.

3. Isn’t vaultless tokenization the same as format-preserving encryption?

This comparison comes up constantly, usually phrased as format-preserving encryption (FPE) versus format-preserving tokenization, and the honest answer starts with the overlap. FPE is encryption in the full sense, a keyed, reversible cipher standardized by NIST, built to keep its input’s shape. A format-preserving token is likewise the output of a reversible, format-preserving transformation and some vaultless products use an FPE cipher as the primitive underneath.

Encryption is the algorithm, tokenization is the system. The difference is what layer you're talking about. 

• FPE is a cipher mode: It transforms one value under one key and has nothing to say about anything else. 

• A tokenization platform is the system wrapped around a primitive like that: the algorithm, field templates that know what a valid SSN or PAN looks like, policy checks in front of every reversal and role-based access operation logs. 

Which system should be able to correlate customer records is a governance question and a cipher has no opinion about it. The system is where that opinion lives. Comparing the two head-to-head mostly produces confusion because one is a component (FPE) and the other is a control surface built around such components (tokenization platform).

4. Isn’t vaultless tokenization just masking?

Static masking is irreversible on purpose, which makes it the right choice when a value is never needed again (i.e. the card number on a receipt, the SSN in a support screenshot). The two aren't competitors in practice. Databolt, for example, combines tokenization with dynamic masking on read, revealing only the portions of a value a role's policy allows. The failure mode isn't masking itself. It's irreversibly masking data that a future analytics or ML training workload will need to join on, then finding out downstream, where nothing throws an error and the results are just quietly wrong.

Vaultless tokenization is designed around derivation

A computed token in a vaultless system behaves differently than a stored token from a vaulted system in two distinct ways that shape how a deployment runs. Neither is a flaw. Both are properties of derivation itself and both reward being planned for rather than discovered.

1. Custody carries the security load. Detokenization in a vaultless system requires access to the algorithm and a policy grant. With the bundle in hand, the original comes back and no vault is required, which is the point of the design. It also means the algorithm deserves the discipline usually reserved for encryption keys: Tight access scoping, no path for raw material to leave the controlled environment, etc. With custody run that way, detokenization stays what the design intends: an online, logged, policy-gated operation. 

2. Determinism does the joining work. In the deterministic approach, identical inputs produce identical tokens under the same bundle, which is what keeps data joinable across systems that never coordinate. It also means a field's frequency structure survives into its tokens. High-cardinality fields, account numbers, emails and national IDs take the full benefit. A field with few possible values keeps its statistical shape; however it's protected. This is the necessary asterisk on the theft test from earlier: A single stolen token yields nothing, while a stolen table of deterministic tokens over a low-cardinality field still shows which values repeat. Tokenize the identifiers, think harder about the enums. Databolt even lets you customize the tokenized values to whatever best fits your organization’s policies and workloads.

The security argument 

For a derived token, the claim is not that the token is meaningless. That phrasing belongs to vaulted designs. The strongest form of the claim, and the one that holds across every deployment model, is about how many independent things have to fail before plaintext comes back.

The pattern that gets the count to two is separating the material that computes tokens from the authority that approves recovery. Databolt's architecture is a concrete version of it, split into two planes. 

• A federated data plane: Tokenization runs inside the customer's own environment, wherever the data lives and sensitive data doesn't leave that boundary to get protected.

• The control plane: Holds configuration, access policy and centralized logging.

In every variant, the structure of the claim is the same: Recovering plaintext requires a client that connects to the algorithm (that data plane) and a policy grant (configured in the control plane). Those are separate things that fail differently, get attacked differently and get detected differently. 

Two locks, different keys, different doors.

Why now

For most of tokenization's history, the systems reading protected data were deterministic: SQL joins, exact-match lookups, batch reports, consumers that only care whether a surrogate is consistent. The consumers now include models and model grade protection on things nobody was measuring when these controls were chosen. 

Models care whether the surrogate looks like plausible data, the structure survives and the same entity stays recognizable across sources. A control chosen years ago to satisfy an audit now sits in the read path of every model that touches that data. Re-examining that choice is where this series goes next, starting from the fundamentals laid down here.

Conclusion

Most of the confusion around data security tokenization comes from the wrong mental model, which is often of a random string pointing to a row. That model is accurate for vaulted systems. 

For vaultless tokenization, it's wrong twice. There are no tokens and the tokens aren’t random, they are mathematically derived. That derivation is what makes it computable anywhere with the right bundle, joinable across systems that never coordinate and useless to anyone who doesn't have access to the algorithm and an explicit policy grant.

If you'd like to explore what this looks like in practice for your environment, book time with the Databolt team.