The short version
Search records and certificates: AU. Account credentials: AU. Card data: Stripe (AU + US, encrypted). Transactional email: US (Postmark), contains no PPSR data. Error logs: AU (Sentry), redacted before send.
Per-category breakdown
| Data category | Storage | Region | Encryption |
|---|---|---|---|
| PPSR certificates (PDFs from AFSA) | Cloudflare R2 | AU | AES-256 at rest |
| Due Diligence Records (your PDFs) | Cloudflare R2 | AU | AES-256 at rest; per-customer keys on Team |
| Search metadata (target ACN, timestamp) | Cloudflare D1 | AU | AES-256 at rest |
| Audit-chain entries (hashes only) | Cloudflare D1 | AU | AES-256 at rest |
| User accounts (email, role) | Clerk + D1 | AU primary; Clerk US for identity | AES-256 at rest; TLS 1.3 |
| Payment cards | Stripe | AU + US (Stripe-managed) | PCI-DSS Level 1 |
| Transactional email content | Postmark | US | TLS 1.3; emails contain record IDs, no PPSR data |
| Application error logs | Sentry | AU | PII scrubbed pre-send |
"Best-effort" residency, honestly
Cloudflare's AU region is a real, named region — D1 and R2 buckets created in AU stay in AU for storage. The edge (the bit that serves the request) is global; cached responses live wherever the request originated. For PPSR searches, the response goes back to your tool the first time and isn't cached at the edge; subsequent record retrievals may be edge-cached briefly. If you have a hard residency requirement for retrieval too, we can disable edge caching for your account on request.
Sovereignty
Cloudflare and Stripe are US-headquartered; the US CLOUD Act could in theory compel them to disclose AU-resident data to US authorities. We've never received such a request. If we do, we'll publish a warrant canary in /changelog.