Security

Treasury infrastructure should be held to the same standard as the decisions it supports. This page documents Treasurii's security posture and controls: the data isolation model, the audit architecture, encryption, and how we handle incidents and disclosure.

For counterparties and prospective customers conducting security due diligence, our controls documentation is available under NDA; contact [email protected].

Common questions

1. Infrastructure

Data storage and residency

All customer data is stored in the EU (Ireland region). We do not store customer data in the United States or any jurisdiction outside the UK/EEA. Our infrastructure operates in an EU region (Ireland) with point-in-time recovery enabled.

Hosting

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

Backups

Database backups are taken continuously via a 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. Keys are managed with hardware security module (HSM) protection.
• 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 & data isolation

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.

Within each organisation, data is further isolated by legal entity. Users with access to one entity cannot access another entity's data unless explicitly granted permission. This isolation is structural, not policy-based.

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 uses 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 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.

This means that when an auditor, a board member, or a regulator asks to see the decision trail for any trade, the answer is a single export that traces from the original exposure through the hedge decision, booking, confirmation, and settlement, with timestamps, user names, and rate references at every step.

Standards

Treasurii's security controls are built in line with the ISO 27001 and SOC 2 frameworks. Full controls documentation is available for review under NDA. Contact [email protected].

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: [email protected]
• 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

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

• Email: [email protected]