How OneSpend protects your financial data
Think of OneSpend like a bank vault. Your transaction data is locked inside a safe deposit box that only the application can open when you're logged in. Even the people who built the vault can't peek inside your box without the right keys being assembled at runtime. We don't hold a master key -- your data stays encrypted until the moment you need to see it.
Bank sends you a notification email
AI reads the email and extracts transaction details
Data is encrypted with your unique key
Only encrypted blobs are saved to the database
Data is decrypted only when you view it
Encrypted data is meaningless without the decryption keys assembled at runtime. Database dumps reveal nothing.
Each user has their own encryption key. There is no shared key or master password.
We have read-only Gmail access. We cannot send, edit, or delete any email in your inbox.
Your financial data is never shared with third parties, advertisers, or data brokers.
AES-256-GCM
Military-grade authenticated encryption
HashiCorp Vault
Industry-standard secrets management
CASA Compliance
Cloud Application Security Assessment
Attackers get encrypted blobs and wrapped keys. Without Vault (which runs separately with its own access controls), the data is computationally infeasible to decrypt. AES-256-GCM has no known practical attacks.
No single person has access to all components needed to decrypt data. Vault access is policy-controlled and audit-logged. Database access alone yields only ciphertext.
Encryption keys exist in memory only during active request processing. Vault tokens are short-lived and scoped. A compromised server cannot retroactively decrypt data at rest.
For developers, security researchers, and the curious
OneSpend uses envelope encryption to protect transaction data. This is the same pattern used by AWS KMS, Google Cloud KMS, and Azure Key Vault.
Vault Transit Key (KEK)
Master key that never leaves Vault. Used to wrap/unwrap user DEKs.
Per-User DEK (Data Encryption Key)
256-bit AES key generated on user creation. Stored only in wrapped (encrypted) form. Unwrapped in memory during request processing.
Encrypted Data Blobs
Transaction data encrypted with the user's DEK. Each blob includes IV and auth tag.
| Parameter | Value |
|---|---|
| Algorithm | AES-256-GCM (Galois/Counter Mode) |
| Key size | 256 bits |
| IV (nonce) | 12 bytes, cryptographically random per encryption |
| Auth tag | 128 bits (16 bytes) |
| KEK wrapping | Vault Transit engine (AES-256-GCM) |
| Blob format | IV (12B) || ciphertext || auth_tag (16B) |
| Threat | Mitigation | Residual Risk |
|---|---|---|
| Database breach | All data encrypted with per-user DEKs; DEKs stored only in wrapped form | Low -- ciphertext without keys |
| Vault compromise | Vault sealed at rest; requires unseal keys; audit logging; network isolation | Low -- requires multiple unseal keys |
| Application server compromise | DEKs exist in memory only during request; short-lived Vault tokens; no persistent key storage | Medium -- active sessions at risk |
| Insider threat | No single person has all components; Vault policies restrict access; audit trails | Low -- separation of duties |
| OAuth token theft | Tokens stored encrypted; scoped to gmail.readonly; refresh tokens rotated | Low -- read-only scope limits blast radius |
| Man-in-the-middle | TLS everywhere; HSTS headers; certificate pinning for API calls | Very low |
OneSpend's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically: