Encryption
VaultAP employs multiple layers of encryption to ensure that sensitive AP data is protected whether it is stored on disk, moving across a network, or being referenced in application logic.
Encryption at Rest
All data stored by VaultAP — invoices, vendor records, risk scores, audit logs, and configuration — is encrypted at rest using AES-256 (Advanced Encryption Standard with 256-bit keys). This is the same standard used by financial institutions and government agencies worldwide.
AES-256 encryption is applied at the storage layer, meaning data is encrypted before it is written to disk and decrypted only when read by an authorized process.
Encryption in Transit
All network communication between VaultAP clients (your browser) and VaultAP servers is encrypted using TLS 1.3, the latest version of the Transport Layer Security protocol.
TLS 1.3 provides:
- Forward secrecy — even if a long-term key is compromised in the future, past sessions remain protected.
- Reduced handshake latency — faster connection establishment compared to TLS 1.2.
- Removal of legacy cipher suites — only modern, secure algorithms are supported.
VaultAP does not support TLS 1.2 or earlier. All clients must support TLS 1.3 to connect.
Internal service-to-service communication within VaultAP's infrastructure is also encrypted using mutual TLS (mTLS), ensuring that no unencrypted data travels between backend components.
Bank Detail Hashing
Bank account details (account numbers, routing numbers, IBAN) require special treatment because they are high-value targets for fraud. VaultAP uses a layered approach:
- SHA-256 hashing with salt — Bank details are hashed using SHA-256 with a unique, randomly generated salt per record. The original values are not stored.
- Last four digits in plain text — Only the final four digits of each bank detail field are retained in plain text, allowing reviewers to verify account identity without exposing the full number.
- Comparison via hash — When VaultAP needs to detect changes in bank details (e.g., a vendor updates their account number), it compares hashes rather than decrypting stored values.
Because bank details are hashed (not encrypted), they cannot be retrieved or exported in plain text. If a vendor's full bank details are needed, they must be obtained directly from the vendor.
Key Management
VaultAP's encryption key management follows industry best practices:
| Practice | Detail |
|---|---|
| Key generation | Cryptographically secure random number generators are used for all key material |
| Key storage | Encryption keys are stored in a dedicated key management service, separate from application data |
| Key rotation | Keys are rotated on a regular schedule. Rotation is transparent and does not require downtime |
| Per-tenant keys | Each organization has its own encryption key, ensuring that a compromise of one tenant's key does not affect others |
| Access controls | Only the encryption service can access key material. Application code never handles raw keys |
For details on how per-tenant keys contribute to data isolation, see the Tenant Isolation page.