Roles
We avoid naming partners in user-facing copy by design — the architecture is visible, the regulated entities are clearly identified to investors and auditors. Public docs say “banking partner” / “card issuer” / “tokenization partner”.
EU data residency
Every response carriesX-Data-Residency: EU. Concretely:
- Postgres hosted in the EU
- Banking partner in Berlin (EMI)
- PostHog product analytics on the EU endpoint
- All logs and audit events stay in EU infrastructure
GDPR posture
All PII is automatically redacted by the runtime logger (
email, firstName, lastName, phone, address, companyName, dateOfBirth).
PCI DSS
Card data (PAN, CVV, expiry) is handled exclusively server-side under AES-256-GCM at rest. The agent never sees PAN/CVV in any code path —requireIntent and the credential boundary enforce this architecturally. You do not need PCI DSS certification to integrate Ovra.
Sacred invariants we enforce
- PAN/CVV never leave the server toward agent context.
requireIntentis non-negotiable.- Strict agent-isolation via
at_*tokens. - Money-moving POSTs require
Idempotency-Key. - Append-only audit and decision logs (PG RULES rewrite UPDATE/DELETE to NOTHING).
- All IDs from
crypto.randomBytes. - SHA-256-hashed API keys +
timingSafeEqualfor all secret compares. - Webhooks fail-closed in production; HMAC-signed; SSRF + DNS-rebind block.
- EU data residency.
What we do not claim today
- No SOC2 yet. Compliance posture (SOC2 Type 2, ISO 27001) is on the post-pre-seed roadmap. Investors and enterprise buyers can request our security questionnaire and DPA.
- No live mode yet. Sandbox-only through pre-seed. Live with real KYC and SEPA opens in v1.3+.
- No money-services license at the Ovra entity. We are tech-only; the banking partner holds the license.
Public-trust pages
For German market compliance, the marketing site exposes:/impressum/datenschutz/agb
Next
Sandbox
What’s simulated vs real today.
Intelligence
Audit log details that satisfy auditors.
