A Practical Architecture and API Walkthrough
Vaultless tokenization allows fintech platforms to process sensitive data without storing it or relying on encryption keys.
Rixon Technology is a patented vaultless, keyless tokenization platform built for fintech and payment organizations. Rixon replaces sensitive structured data with irreversible, governed tokens—without storing data, maintaining vaults, or using encryption keys. This reduces PCI DSS compliance scope, breach exposure, and total cost of ownership while supporting real-time transaction volumes at enterprise scale.
Rixon’s architecture is not Format Preserving Encryption (FPE) and does not rely on stored mappings or key management for token derivation.
Two Very Different Vaultless Tokenization Models
Teams searching for “vaultless tokenization” often encounter two very different architectural approaches:
Vaultless Tokenization Using Encryption Keys (FPE)
Vaultless tokenization that still depends on encryption keys, often implemented as Format Preserving Encryption (FPE).
Keyless, Vaultless Tokenization
Vaultless tokenization that eliminates both vault storage and encryption-key dependency for token derivation.
Rixon is the second category.
Rixon delivers patented vaultless tokenization and keyless ciphering designed to replace high-risk structured identifiers with governed tokens that remain usable in systems but meaningless if stolen.
How Keyless, Vaultless Tokenization Works
Rixon’s architecture is built on three foundational principles:
Keyless Ciphering
Rixon’s patented token derivation does not rely on symmetric encryption keys. Token computation uses secure, one-way deterministic methods, removing key compromise risk and traditional key lifecycle dependency.
Vaultless Tokenization
Tokens are generated on demand without lookup tables or centralized vaults. This eliminates a single high-value database that attackers could target.
Zero Data Storage
Rixon does not store or retain sensitive values. Only tokens traverse the platform, and sensitive data is processed ephemerally. This reduces persistent storage risk and limits sensitive data exposure.
Important Clarification: Vaultless Does Not Mean Format Preserving Encryption
Format Preserving Encryption (FPE) encrypts data while preserving its original format and length, relying on symmetric encryption keys.
Some vendors label FPE as “vaultless tokenization.” Rixon’s architecture is not FPE.
Although Rixon tokens can be format-compatible, token derivation does not rely on encryption keys and does not perform reversible encryption.
This distinction is critical:
- FPE shifts risk to key management
- Vault-based systems shift risk to the vault database
- Rixon removes both vault storage and encryption key dependency for token generation
COMPARISON
Vaultless Tokenization vs Vaulted Tokenization vs FPE vs Encryption
Each approach protects sensitive data differently. The key difference is where risk is concentrated: in a vault, in encryption keys, or removed from persistent storage entirely.
Data Storage
Rixon Vaultless
No sensitive data stored. Processing is ephemeral.
Vaulted Tokenization
Centralized vault stores original values.
FPE
Encrypted data is stored and reversible with keys.
Encryption
Sensitive data remains stored in encrypted form.
Key Dependency
Rixon Vaultless
No encryption keys required for token generation.
Vaulted Tokenization
May rely on encryption to protect vault data.
FPE
Requires symmetric encryption keys.
Encryption
Dependent on ongoing key management lifecycle.
Breach Risk
Rixon Vaultless
No vault or key to compromise. No persistent data target.
Vaulted Tokenization
Vault becomes a high-value attack target for attackers.
FPE
Key compromise exposes underlying sensitive data.
Encryption
If keys are exposed, encrypted data can be decrypted.
PCI DSS Scope Impact
Rixon Vaultless
Reduces systems handling sensitive data.
Vaulted Tokenization
Vault remains in scope.
FPE
Encrypted PAN may still be in scope.
Encryption
Data remains in scope despite encryption.
Scalability
Rixon Vaultless
No vault replication required. Supports real-time scale.
Vaulted Tokenization
Scaling requires vault replication and synchronization.
FPE
Scales, but adds key management overhead.
Encryption
Adds latency in real-time transaction flows.
End-to-End Workflow
1
Create an API Key
In the Rixon portal, generate a Service API key to authenticate tokenization requests. API keys should be stored securely, access-limited, and rotated according to internal security policies.
2
Define Token Definitions
Before tokenizing data, configure Token Definitions. A Token Definition determines the type of structured data being protected, the format the token should follow, and any constraints required by downstream applications.
This allows tokens to be stored and processed without storing original sensitive values.
• Data type being protected
• Token format and structure
• Application-level constraints
3
Configure Security Policies
Security policies define how tokenization and detokenization requests are governed across systems, identities, and environments.
• Which API operations are permitted
• Which identities may detokenize
• Policy passwords
• Access restrictions
This ensures detokenization is controlled, governed, and auditable.
4
Create a Session
A session is created using your API key, policy name, and policy password. The returned session token is used to authenticate tokenization actions.
curl -X POST \
https://<YOUR_ACCOUNT_DOMAIN>/api/services/evtservice/createsession \
-H “Content-Type: application/json” \
-d ‘{
“apiKey”: “<YOUR_API_KEY>”,
“policy”: “<THE_POLICY_NAME>”,
“policyPassword”: “<THE_POLICY_PASSWORD>”
}’
5
Tokenize a Value
Once a session is created, the client submits the value to be tokenized using the session token and Token Definition name.
curl -X POST \
https://<YOUR_ACCOUNT_DOMAIN>/api/services/evtservice/tokenize \
-H “Content-Type: application/json” \
-d ‘{
“sessionToken”: “<THE_SESSION_TOKEN>”,
“tokenName”: “<THE_TOKEN_DEFINITION_NAME>”,
“value”: “MySensitiveValue”
}’
What Happens Architecturally
Sensitive structured data enters the tokenization boundary.
The value is processed ephemerally in memory.
A governed token is generated.
The original value is not stored.
Only the token is returned to the client.
There is no centralized vault and no encryption key dependency used to derive the token.
6
Store and Process Tokens
Only tokens are stored across systems. Applications operate on tokens, allowing workflows to continue without exposing or persisting sensitive values.
7
Controlled Detokenization
Detokenization is treated as a privileged operation. Requests are evaluated through policy enforcement, role-based controls, and optional geographic restrictions.
• Role-based access control
• Policy enforcement
• Optional geofencing
• Full audit logging
8
Logging and Monitoring
Tokenization and detokenization activity is logged and monitored to support audit readiness, detect abnormal patterns, and identify suspicious access.
Where Encryption Fits
Encryption protects sensitive data at rest and in transit.
Vaultless tokenization reduces the presence of sensitive data across systems by replacing structured values with governed tokens.
Vaultless tokenization reduces:
• The number of systems containing sensitive data
• The persistence of structured sensitive values
• The overall exposure footprint across workflows
Encryption ensures stored data remains unreadable. Tokenization minimizes the presence of sensitive data in the first place.
Vaultless tokenization is not a replacement for encryption — it is an architectural complement.
Integration Patterns
Common deployment models include:
• Tokenization at ingestion from web forms or mobile applications
• Middleware-level tokenization before database persistence
• Batch tokenization for high-throughput processing
• Controlled detokenization within narrow audited services
For unstructured files or large media objects, encryption may be more appropriate, while tokenization is ideal for structured identifiers.
Conclusion
Vault-based tokenization concentrates risk in a centralized database.
FPE-based approaches concentrate risk in encryption key management.
Rixon’s patented vaultless, keyless architecture removes both the vault and the encryption key dependency for token generation.
This structural design reduces concentration risk, simplifies architecture, supports compliance alignment, and scales for high-volume payment environments.
Frequently Asked Questions
No. Format Preserving Encryption relies on symmetric encryption keys. Rixon’s patented architecture does not use FPE and does not rely on encryption keys for token derivation.
Token generation does not depend on symmetric encryption keys or traditional key lifecycle management.
No. It can reduce the number of systems storing or processing primary account numbers, which may reduce audit surface. PCI obligations remain.
Yes. Encryption protects data in transit and at rest. Tokenization reduces sensitive data exposure within operational systems. The two technologies are complementary.
Yes. Because there is no centralized vault database or key store, horizontal scaling can occur without replication bottlenecks.
Structured identifiers such as:
- Payment card numbers
- Bank account numbers
- National identifiers
- Customer account numbers
- Other relational sensitive data
Related Resources
For technical implementation guidance, see: A Fintech’s Practical Guide to Implementing Vaultless Tokenization
For PCI DSS scope reduction architecture, see: PCI DSS Scope Reduction & Compliance Architecture
For detailed Q&A on architecture, compliance, and integration, see: Vaultless Tokenization FAQs