Security Whitepaper

How PayHQ protects the details that decide where money goes.

PayHQ is multi-tenant SaaS: your invoices and supplier bank details are stored and processed on infrastructure we operate in the EU, with a few disclosed paths beyond it (the always-on Cloudflare edge; and, when you opt in, Resend inbound, the Telegram intake bot, and a connected Microsoft 365 mailbox where an operator enables it carry invoice content, while outbound email and alert channels carry metadata — see Sub-processors). That means we own the controls end to end — so this document describes them, and names the residual risk behind each one.

1 · Product security model

The product is built so that a changed bank account is never a silent update and sensitive payment details are not shown casually.

Masked review, gated reveal. The supplier registry and the invoice-detail view mask bank details by default at the API; cleartext reveal is permission-gated and every reveal is recorded in the audit trail. One API surface — the read-results endpoint of the API-key integration API — is still being brought under the same server-side masking.
Versioned bank details. Supplier payment methods are versioned, never overwritten; a change requires a reason and a reviewer before it becomes trusted.
Deterministic, explainable decisions. The trust verdict a reviewer sees is deterministic and explainable — anomaly signals stay advisory, not a black box.
Workspace isolation. Each workspace is isolated; records never cross workspace boundaries. Isolation is enforced at the application and query layer with workspace-scoped composite foreign keys. There is no database-level row-level-security backstop today.
Audit trail. Supplier changes, reveals, reviews, and approvals are recorded in an audit trail. The trail is not yet tamper-evident, and read/authentication events are not yet recorded — cryptographic tamper-evidence is on the roadmap.

2 · Our internal security program

The claim we protect most

Invoice extraction runs on OCR and language models we host ourselves; invoice content is not sent to any third-party AI, OCR, or analytics service, and no model is trained on your data. The worker enforces this in code — it fails closed unless the OCR/LLM endpoint is self-hosted or on the operator's explicit allowlist, and in our own deployment that allowlist contains only self-hosted hosts. This is a binding processor obligation in our Data Processing Agreement.

Authentication. Account passwords are hashed with Argon2id. Multi-factor authentication and SSO are not available today and are on the roadmap, gated on production launch and enterprise demand.
Encryption at rest. Uploaded invoice documents are encrypted at rest with AES-256-GCM (per-object nonce, object-key-bound AAD). Structured supplier bank details are stored in our EU database but are not yet encrypted at the column level; database-column encryption is on the roadmap. We do not claim blanket 'data encrypted at rest'.
Encryption in transit. All traffic to PayHQ is encrypted in transit using TLS 1.2/1.3, terminated at the edge and the application ingress. Internal traffic between the application, database, and object storage currently runs unencrypted on an isolated single host; enabling internal TLS is on the roadmap. We disclose this rather than imply end-to-end encryption everywhere.
Key management. Artifact encryption currently uses a single static key without rotation; rotation and versioned keys are on the roadmap (R-KMS-01).
Hosting. Customer data is stored in the EU with Hetzner in Finland (Helsinki, HEL1-DC8). Beyond the always-on Cloudflare edge, a couple of opt-in paths (Resend inbound and the Telegram intake bot) can carry invoice content outside the EU when a workspace enables them, as can a connected Microsoft 365 mailbox where an operator enables it; a Google/Gmail connector is a planned path. All are named on our sub-processor list, rather than claiming data 'never leaves the EU'. Physical and environmental controls for our infrastructure are inherited from our hosting provider, Hetzner, at its ISO 27001-certified Finnish datacentre.

3 · What stays with you

A few controls are yours to run, and we make them explicit rather than assume them.

Deciding who in your team may authorise a supplier bank-detail change.
Approver-role hygiene — keeping reveal and approval permissions tight.
The scopes you grant when connecting a mailbox or intake channel.
Retaining your existing payment verification during the pilot — PayHQ is advisory, not the sole gate (see the pilot terms).

Control mappings

Where reviewers want a framework hook: the controls above map to UK GDPR Art. 5, 28, and 32; ISO/IEC 27001:2022 Annex A.8.24 (cryptography), A.8.15–A.8.16 (logging and monitoring), and A.5.14/A.8.2 (privileged access). The CAIQ self-assessment gives the per-domain detail.