Instead of replicating passports, phone numbers and addresses across 40 systems, they live in a single vault. CRM, billing, BI, logs and backups exchange deterministic tokens. Original data never leaves the vault without an audit trail.
A single customer's phone number sits in CRM, billing, support, BI, logs and three generations of backups. Every copy is a potential breach. Every location is a separate audit.
The Provyn vault inverts the problem. PII is stored in one place - a secured boundary with HSM, audit and strict RBAC. Into every other system you put a token - an irreversible identifier you can store, transfer, join and analyze, but from which the original data cannot be recovered without explicit permission and an audit record.
| Before Provyn | With Provyn | |
|---|---|---|
| Where PII lives | 40+ systems | 1 vault |
| Compliance scope | entire stack | 1 component |
| Backups contain PII | yes | no |
| Analytics sees PII | yes | no |
| DSR (subject erasure request) | manual sweep of every system | 1 API call |
| CRM breach | incident, real PII | tokens only |
On the left - your systems. In the center - the Provyn API. On the right - the vault. Blue lines are tokens, flowing freely across your stack. White lines are PII, moving only between API and vault, with every access recorded.
An API key on staging, one library (provyn-sqlalchemy, provyn-django, @provyn/node). First token within 20 minutes of your first commit.
When a new record enters a system, the application calls POST /v1/tokenize with the PII fields. Provyn returns tokens with the same semantics - same domain, same format, deterministic.
Your application database holds tokens. SQL, joins, lookup by phone - everything works, because identical input produces an identical token. Analytics builds metrics on tokens. LLMs go through AI Proxy.
When an operator needs to see PII, the application calls POST /v1/detokenize with a reason. Provyn returns the data and writes an audit record: who, when, why, IP.
In the dashboard: how many tokens were created, who detokenized what, anomalies in access patterns. Append-only log, aligned with SOC 2 and ISO 27001 controls.
Encryption, HSM integration, deterministic tokens, RBAC, append-only audit, webhooks. Everything a CTO needs to sign off on the architecture.
The numbers a CTO checks in the very first meeting: latency, throughput, HA, data residency.
| Encryption | AES-256-GCM (per-tenant DEK via Vault Transit) |
| Keys | HashiCorp Vault / external HSM / local fallback |
| Protocols | REST (JSON), gRPC, GraphQL |
| Latency p50/p99 | 4 ms / 12 ms (localhost); +~100 ms RTT |
| Throughput | 230+ ops/s on tokenize · 300+ ops/s on detokenize |
| Bulk endpoint | POST /v1/bulk/tokenize - up to 1000 records/request |
| SDK | Python (sync + async), Node.js, Java, Go |
| ORM integrations | SQLAlchemy, Django ORM, Prisma, Sequelize |
| Data residency | Multi-region: EU / GCC / APAC / LATAM · on-prem |
| High availability | Active-active PostgreSQL, Redis Sentinel, Vault HA |
| Compliance | GDPR · PDPL · PIPL · LGPD · SOC 2 · ISO 27001 |
Four characteristic patterns - from legacy migration to multi-system architecture under a strict regulator.
17 systems, one customer. Before Provyn - 17 copies in scope. After: a vault plus tokens across all 17. The antifraud model receives a phone_token and still finds patterns - determinism preserves feature engineering.
100M+ contacts in BigQuery. PII cannot reach BI - the analytics team must stay out of scope. We tokenize during ETL, cohorts are built on tokens, and pinpoint detokenization goes through the proxy.
The strictest scenario - special categories of PII. Provyn on-prem with an external HSM. The clinician sees the record through the app; the vault logs every read. Downstream systems receive only what they are entitled to.
PostgreSQL with 15M orders. One ALTER TABLE plus an overnight bulk tokenize - and the whole database drops out of scope. Zero downtime: a nullable column is added, the script tokenizes, the old column is dropped.
Integration requires no rewrite of your business logic. Shadow mode lets you roll back at any stage.
A key on the sandbox. pip install provyn-sqlalchemy. First POST /v1/tokenize within 20 minutes. Tokens visible in the dashboard.
Mark PII columns with Tokenized(). New records are written as raw + token. We verify that joins and lookups still work. The raw column is still there - you can roll back.
Bulk-tokenize historical data (in the background). Switch reads to tokens. Drop the raw columns. DELETE FROM vault WHERE subject_id = X clears old snapshots.
If your question isn't here, email sales@provyn.cloud - we reply within one business day.
No. Vault data is replicated in a PostgreSQL HA cluster with WAL backup. Plus escrow - an encrypted backup on your side, decryptable with your key. Even if the Provyn service is unavailable, your data is recoverable without us.
Correct - and you don't have to. In the on-prem model, HashiCorp Vault (or your HSM) lives inside your perimeter and keys never leave it. We supply the service and the admin console; the keys are yours.
Yes. SDKs for Python (SQLAlchemy, Django), Node (Prisma, Sequelize), Java (JDBC interceptor), Go. Legacy migration is via ALTER TABLE ADD COLUMN phone_token plus a batch script. A well-worn pattern.
Detokenize requests are cached in Redis on the client side (encrypted). Hot tokens → <1 ms. Cold → <12 ms p99. For a 15M-record migration, the bulk endpoint runs at ~10k ops/s.
You choose the region: EU, GCC, APAC or LATAM, or fully on-prem. Data does not leave the jurisdiction you select, satisfying local data-residency requirements.
By volume of operations, not by record. Pricing on request. A free tier is available for PoC (100k ops/month).
30 minutes with an architect. We map which systems are in scope, show the SDK for your stack, and estimate the migration timeline.