Security.

This page summarises Treasurii's security posture and controls. For institutional counterparties and prospective customers conducting security due diligence, our controls documentation is available under NDA — contact security@treasurii.co.uk.

1. Infrastructure

Data storage and residency

All customer data is stored in the EU (Supabase Ireland region). We do not store customer data in the United States or any jurisdiction outside the UK/EEA. Supabase operates on AWS eu-west-1 (Ireland) with point-in-time recovery enabled.

Hosting

The Treasurii platform is hosted on Vercel's edge network with our data plane in the EU. The marketing website (treasurii.co.uk) is served via Vercel's global CDN. No personally identifiable data is stored at the CDN edge layer.

Backups

Database backups are taken continuously via Supabase's point-in-time recovery (PITR) system. Backups are retained for 30 days and are stored in the same EU region as the primary data. Recovery time objective (RTO) is 4 hours; recovery point objective (RPO) is 1 hour.

2. Encryption

• In transit: All data transmitted between clients and Treasurii servers is encrypted using TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled. We use HSTS to prevent protocol downgrade attacks.
• At rest: All data stored in our database is encrypted at rest using AES-256. Encryption is managed by Supabase with hardware security module (HSM) key management.
• Secrets management: Application secrets and API keys are stored in environment variables, not in source code. We do not commit credentials to version control.

3. Access control

Row-level security

Treasurii enforces row-level security (RLS) at the Postgres database layer. Every query against customer data is filtered by organisation ID at the database level — not by application logic. This means that even in the event of an application-layer bug, one customer's data cannot be read by another customer's session. Multi-tenancy isolation is structural.

Authentication

All platform accounts require multi-factor authentication (MFA). We support authenticator app-based TOTP. SMS-based MFA is not offered due to SIM-swapping risk. Authentication is managed by Supabase Auth with JWT-based session tokens.

Role-based permissions

Within each customer organisation, access is controlled by a role-based permission system. Roles include Read Only, Trader, Treasurer, and Admin. Each role has a defined permission set. Permissions are enforced at both the API layer and the database layer.

Treasurii staff access

Treasurii employees do not have access to customer data in the production environment as part of their standard role. Any access for support or incident response purposes requires explicit authorisation, is time-limited, and is logged in the audit trail.

4. Application security

• Input validation: All user inputs are validated and sanitised at the API layer before reaching the database.
• SQL injection: We use parameterised queries throughout. Raw SQL string concatenation is prohibited by code review policy.
• CSRF protection: All state-changing requests require authentication tokens. We implement SameSite cookie attributes and CSRF token validation.
• Rate limiting: Public sign-up is rate-limited per IP and per email address to prevent abuse. AI parsing endpoints are rate-limited per organisation. Authentication endpoints are protected by Supabase Auth's built-in throttling.
• Dependency management: Dependencies are pinned and reviewed. We use automated dependency scanning to identify known vulnerabilities.
• Code review: All code changes require peer review before merging to production. Security-sensitive changes require review by a designated security reviewer.

5. Audit and assurance

Immutable audit log

Every action taken on the Treasurii platform generates an immutable audit log entry. The log is append-only — entries cannot be modified or deleted after creation, by any user including Treasurii staff. This is enforced at the database layer via row-level security policies that prevent UPDATE and DELETE operations on audit log records.

Independent assurance

Treasurii does not currently hold an independent third-party security attestation (such as SOC 2). Our controls are documented internally and available for review under NDA — contact security@treasurii.co.uk. We will update this page when independent attestation is in place.

6. Incident response

In the event of a security incident, Treasurii follows a documented incident response process:

• Detection: Automated monitoring alerts on anomalous behaviour, failed authentication attempts, and unusual data access patterns.
• Containment: Affected systems are isolated within 1 hour of confirmed incident declaration.
• Notification: Affected customers are notified within 24 hours of a confirmed breach. The ICO is notified within 72 hours where required by UK GDPR Article 33.
• Post-incident review: A root cause analysis and remediation report is completed for every P1 incident.

Service status is published at status.treasurii.co.uk.

7. Vulnerability disclosure

We welcome responsible disclosure of security vulnerabilities. If you have identified a potential security issue in Treasurii's systems, please contact us before publishing or sharing it elsewhere:

• Email: security@treasurii.co.uk
• Please include a description of the issue, steps to reproduce, and your contact details.
• We aim to acknowledge all reports within 2 business days and provide a resolution timeline within 5 business days.
• We ask that you give us reasonable time to investigate and remediate before public disclosure.

We do not currently operate a bug bounty programme, but we acknowledge responsible disclosures publicly where the reporter wishes to be credited.

8. Contact security

For security enquiries, vulnerability reports, or to request our controls documentation under NDA:

• Email: security@treasurii.co.uk