Ten questions to ask before you buy.

OpenSanctions refreshes the consolidated feed daily. Caltury re-screens at risk cadence (high every 6 months, medium yearly, low every 3 years). Founding 5 customers get a full-roster sweep every 24 hours.

The screening source is the OpenSanctions consolidated dataset: DFAT (Australia), UN, OFAC, EU, HMT, plus PEP lists. OpenSanctions publishes daily updates and we read the latest version on every check. Re-screening cadence is enforced by a Vercel cron that wakes nightly and queues any customer due based on their risk band. New hits trigger an immediate email to the named compliance officer and a flag on the customer record.

The customer record stays in KYC pending. You get an email. You can fall back to a manual document upload, mark the verification reason, and the audit trail records both the Stripe failure and your override.

Stripe Identity returns one of verified, requires_input or canceled. We surface the failure reason verbatim in the customer file so you can see whether it was a document mismatch, a biometric mismatch or an abandoned session. The fallback path lets the compliance officer mark the customer as verified via alternative evidence (utility bill, passport scan you hold on file). The override is recorded with the officer's user ID and a free-text justification, both visible in the audit log.

Yes. Self-serve via Settings to Data. Returns a single archive with every customer, KYC verification, sanctions check, SMR, TTR, IFTI, transaction, training record, audit log entry and uploaded file. Plain CSV plus JSON, no proprietary format.

This satisfies APP 12 (access to personal information) and the AML/CTF Act 7-year record-keeping obligation. The export is generated on demand, usually completes within 60 seconds for a typical practice, and is downloadable from the dashboard for 24 hours. Larger practices (10,000+ customers) get an email link when the archive is ready. The contents include the raw Postgres rows so you could re-ingest them into a successor system without translation. No fee, no limit on how often you export.

Documented plan published at /security/incident-response with severity-tiered SLAs (P0 acknowledged within 1 hour 24/7), a live status page at /status, and a published disclosure policy at /.well-known/security.txt. Sole-founder caveat is real but the process is written down and applied.

Detection: Sentry captures every server error in production with PII scrubbed at SDK level; Vercel cron failures alert on the same channel; Supabase Auth anomalies surface in the dashboard; external reports come through security@caltury.com.au per the published disclosure policy. Triage: every incident is classified within an hour as P0 (data exposure or full service down), P1 (degraded service or sensitive-function failure), or P2 (functional or cosmetic). SLAs: P0 acknowledged within 1 hour 24/7 with a hot-fix in flight within 8 hours; P1 within 8 business hours; P2 within 24 business hours. Customer notification: P0 within 24 hours regardless of size, P1 within 72 hours if customer-affecting, P2 in the next monthly changelog. Notifiable Data Breach: assessment commences within 24 hours of a suspected eligible breach; OAIC and affected individuals notified within 30 days where the threshold is met. Public communication: /status updated within 1 hour of any P0 or P1; machine feed at /api/status for monitors. Post-incident: written postmortem within 14 days for P0 and P1, published if scope justifies. Honest gap: this is a sole-founder operation. There is no rotating on-call. You will get one named person (Ben Horne) on every escalation, not a 24/7 NOC. The 1-hour P0 acknowledge applies seven days a week including outside business hours.

Yes. Cyber A$1m, Professional Indemnity A$1m, Public Liability A$20m. Bound via DUAL (broker BizCover) on 15 May 2026, renews 15 May 2027.

The cyber policy covers first-party (incident response, forensic, business interruption) and third-party (privacy liability, regulatory defence) exposures. PI covers professional errors and omissions in the software's operation. PL covers the standard third-party bodily injury and property damage exposures. Certificates of currency and the specific policy references usually go out within a few business days from support@caltury.com.au with your procurement reference.

Yes. Daily Supabase snapshot with 7-day retention. Point-in-time recovery enabled. Weekly off-platform backup to a Caltury-owned S3 bucket in Sydney with object-lock compliance mode and 7-year retention. The off-platform copy cannot be deleted by anyone, including the root AWS account, until the 7-year lock expires.

Tier 1: Supabase Pro takes a daily snapshot of the production Postgres database and retains the last 7 days. Point-in-time recovery (PITR) lets us restore to any second in that window. Snapshots live in S3 under Supabase's account. Tier 2: a weekly off-platform backup runs every Sunday 04:00 UTC via /api/cron/off-platform-backup. The cron streams every compliance-bearing table (customers, KYC, sanctions, SMR, TTR, IFTI, transactions, training, audit_log including the hash-chain columns) to NDJSON, gzips, and uploads to a Caltury-owned S3 bucket in Sydney with object lock enabled in compliance mode and 2,557-day retention (7 years per AML/CTF Act ch 11). Compliance mode means even the root AWS account cannot delete or shorten the lock before expiry. Tier 3: every backup is recorded in the off_platform_backups table (migration 0068) with the SHA-256 of the payload, the S3 etag and the lock-until date so the founder can prove to a procurement reviewer that any given week's archive still lives in the immutable bucket. Bucket setup runbook is at scripts/off-platform-backup.mjs --setup.

Customers get 60 days written notice and an automatic data export emailed at notice time. The export is in plain CSV plus JSON, importable into a successor system. The 7-year record obligation transfers back to you as the reporting entity, where it always sat anyway.

Caltury is a software vendor, not a reporting entity. The AML/CTF Act records obligation always sits with you. If Caltury winds down, the written notice and export get you back to the position you were in before subscribing, with a complete copy of every record we held on your behalf. Where the data lives during the notice period: production database stays live and accessible for the full 60 days so your day-to-day workflow does not break mid-notice. No charges during the notice period. The wind-down policy is part of the standard customer agreement (Terms of Service v4).

Yes. The export is plain CSV plus JSON. It includes raw Postgres rows so you can re-ingest into your own database, a successor vendor, or just keep it as the 7-year archive in flat-file form.

Schema documentation ships alongside the archive so a developer can understand the relationships between customer, kyc_verification, sanctions_check, smr, ttr, ifti, transaction and audit_log tables. Uploaded files (reviewer evidence, training certificates) come as their original PDFs in a /files subdirectory referenced by ID. Nothing in the export is gated behind a Caltury runtime. No special tools required to read it. Email support@caltury.com.au for the schema doc if you want to evaluate this before subscribing.

Yes. Append-only at the permission layer plus a SHA-256 hash chain on every row (payload_hash + prev_hash + row_hash columns) filled by a BEFORE INSERT trigger so every code path is covered. The chain is partitioned per org, so the audit log inside your own export is a complete, independently verifiable chain. Any post-hoc edit invalidates the row's hash and every subsequent row in that org's chain. Public verification endpoint at /api/audit/verify walks every org chain and confirms.

Two layers. Layer one, unchanged: the audit_log table is enforced append-only via Postgres permission grants (see migration 0037). The authenticated role cannot DELETE or UPDATE audit rows. Inserts go through the service-role key only, so end users cannot forge rows. Layer two, new in migration 0067: every row carries three hash columns filled by a BEFORE INSERT trigger. payload_hash is a SHA-256 of the row's canonical bytes. prev_hash is the row_hash of the immediately preceding row in the same org's chain (the all-zero sentinel for the first chained row of each org). row_hash is SHA-256(prev_hash || payload_hash). The chain is partitioned per org (migration 0073): a Postgres advisory lock keyed to the audit_log table plus the org serialises concurrent inserts into one org's chain so it cannot fork, while different orgs insert in parallel. Independent verification: GET /api/audit/verify walks every org chain from the sentinel forward, recomputes every row_hash from prev_hash + payload_hash, and recomputes every payload_hash from the row's current values via the SQL function audit_log_compute_payload_hash. Any mismatch identifies the first broken row. The verifier source is at apps/web/src/lib/audit/hash-chain.ts, exportable, so an external auditor can re-run the same verification against the audit_log they exported from /api/data/export — and because each org's chain is self-contained from the sentinel, that org-scoped export is a complete chain on its own. Rows that pre-date the migration are tallied as unchained and remain protected by the permission grants only.

An external CREST-accredited test has not happened yet. Published OWASP ASVS L2 self-audit at /security/audit-2026-05, weekly Dependabot dependency alerts, a public vulnerability disclosure policy at /.well-known/security.txt, and a scheduled external test trigger of first enterprise customer or 1 January 2027 whichever sooner.

What is in place today. (1) OWASP ASVS Level 2 self-audit published at /security/audit-2026-05 with per-control status, evidence, and an honest section on what a self-audit cannot prove. (2) Weekly Dependabot runs covering npm and GitHub Actions ecosystems; every dependency PR is reviewed in writing. (3) Coordinated vulnerability disclosure policy published at /.well-known/security.txt per RFC 9116 with named acknowledge SLAs (P0 within 1 hour 24/7, anything else within 8 business hours). (4) Customer-initiated pen tests coordinated in writing in the meantime, at no charge, with the report staying between Caltury and the customer. What is honestly still missing. No CREST-accredited external test has been performed at this revision. Without that, this question is Partial rather than Yes. The external test is committed for whichever lands first: a paying enterprise customer or 1 January 2027. Scope will cover the same surface the self-audit reviewed plus authenticated application logic; the report will be shared with that customer and published in summary at /security.