Security

Every firm is its own workspace, and every case, client, document and audit entry belongs to one. Reads are constrained by row-level security in PostgreSQL, so another firm’s rows are not returned in the first place. That matters more than it sounds: the separation holds at the layer below the application, so it does not depend on every query being written correctly.

Writes go through server-side routes that check workspace authorisation explicitly, through a single shared helper rather than a check copied into each route. One implementation means one place to get right, and one place to audit.

Identity comes from a verified token on every request. Nothing is trusted because the browser asserted it. Server-side outbound requests are constrained by an allow-list, so the platform cannot be steered into fetching somewhere it should not.

Everything is encrypted in transit with TLS and at rest with AES-256 through our managed providers. That is the baseline, and for the most sensitive material we go past it: open banking access tokens are encrypted again inside the application with AES-256-GCM before they are stored, which is authenticated encryption, so tampering is detected rather than merely unlikely.

Object storage is private by default and reachable only through short-lived signed links. Nothing is served from a public URL, and a link that leaks has already expired. Provider keys and application secrets live in a managed secrets store and are never in source control.

The audit log is append-only by design. Entries are written through one controlled entry point and are not edited or deleted through the application, because a record a vendor can quietly revise is not a record.

Case creation and viewing, identity and document requests, evidence submission, risk score commitment, sign-off, approval and decline, certificate issuance, consent capture and reliance events are all recorded. Each entry carries the action, the case it touched, a structured payload, and the originating address and user agent.

It also carries what kind of actor took the action: a person at the firm, the client, the system, or an automated analysis. When a reviewer asks months later whether a human decided something, the log answers rather than implies.

People in a workspace hold one of two roles. Editing the compliance programme and adding users are administrator actions. Day to day case work is open to staff. Both are bounded by the workspace, so a role never reaches outside the firm that granted it.

A reporting entity whose checks are run by someone else has a role of its own. Its compliance officer is who signs a case off and who takes the certificate, and that role does not begin with the invitation: we confirm the person before it takes effect. An invitation on its own should not be able to hand over a sign-off right.

The people being verified never get an account at all. They work through a signed link that expires and is scoped to a single case, so there is no standing credential to phish, reuse or forget to revoke.

Primary infrastructure and customer data are hosted in Sydney, Australia, in AWS region ap-southeast-2, across three managed providers. There is no self-managed server or container fleet to fall behind on patching.

Some processing subprocessors, AI-assisted document analysis among them, run in other regions. We minimise what reaches them, and the transfer mechanisms we rely on are available on request.

Retention follows the statutory period that applies to the record, which is at least five years from the certificate date in New Zealand and seven in Australia. During that period records are kept even where deletion is requested, because keeping them is the firm’s legal obligation rather than our preference.

Raw open banking data that never becomes part of a certificate is deleted within thirty days. Requests for a copy of the personal information we hold are answered within twenty working days, in a machine-readable format.

We keep a documented incident response plan, available to your security team on request. Severity is set at triage and drives everything after it. A confirmed breach or an unavailable platform gets an immediate response, within four business hours. A major function impaired, or a credible vulnerability under investigation, gets one business day.

Affected firms are notified on the same clock. Where a privacy breach is likely to cause serious harm, the relevant regulator and the affected individuals are notified without undue delay. Every critical incident is followed by a blameless review within ten business days, with corrective actions tracked to completion, and the plan itself is reviewed at least every six months.