Security at VERA
What is in place today, what is not yet, and how to report a problem. We state gaps plainly because a review that finds an undisclosed gap costs more trust than a disclosed one. A fuller Security & Trust Overview is available to evaluating institutions on request.
What is in place
| Area | What we do |
|---|---|
| Sign-in | Two-step sign-in is required on every account, including VERA’s own operator accounts. Ten wrong passwords in a row lock a login for 15 minutes, and for longer on each repeat. Sessions are short (30 minutes by default, or one hour for people assigned to an active project team), fixed at sign-in, and never renewed silently. |
| Approvals | Every approval is signed with the approver’s own key. VERA never holds an approver’s private key or signing passphrase. Accounts are role-bound, and the same person cannot give both approvals on a release. |
| Encryption and keys | All traffic uses TLS. Sensitive fields, including settlement account details, are encrypted at rest with AES-256-GCM. Service secrets are held in Google Cloud Secret Manager, and the attestation-signing key is held in a cloud key-management service. |
| Audit record | Every sign-in, approval, release, refusal and administrative action is written to an audit log in which each entry carries a hash of the one before it, so a removed or reordered entry shows. Examiners get read-only access with CSV and PDF exports. |
| Public record | Only a hash is published to a public ledger. No names, amounts, account numbers or documents. During the pilot the ledger is its test network. |
| Backups | A full copy of both databases is made every night and kept for 35 days in a private storage bucket outside the database provider. A backup file has been restored into a clean database and checked against production. |
| Monitoring | Each service is checked from outside every minute. Failures, bursts of server errors, start-up failures and failed backup runs raise an alert to the operator. |
| Data location | United States: Google Cloud us-east1, and Neon (on Amazon Web Services us-east-1) for the database. |
What is not yet in place
- No SOC 2 report. Our controls are designed with reference to the SOC 2 Trust Services Criteria, but we have not completed a third-party SOC 2 examination.
- No independent penetration test yet. We will cooperate with a test commissioned by an evaluating institution, under agreed rules of engagement.
- No multi-region failover, and no recovery-time commitment until a full recovery of the live platform has been timed.
- No connection to a bank’s core system or payment rail. None is required for a pilot.
We will update this page when any of these changes.
Service providers
Google Cloud (hosting, key and secret management, backup storage), Neon (managed PostgreSQL), Cloudflare (DNS, edge and system email), and the public XRP Ledger (hash only). See the Privacy notice for what each can reach.
Reporting a security problem
Email [email protected] with “Security” in the subject line. Please include what you found, where, and the steps to reproduce it. We will review every report and reply.
Please: do not access, change or keep data that is not yours; do not disrupt the service; do not test against a customer’s live data; do not use social engineering or physical attacks; and give us reasonable time to fix a problem before you disclose it publicly. We do not run a paid bug-bounty program.