Security
How TNX Data is built, and what that means for your data.
TNX handles the paperwork behind regulated disclosures — capital account statements, fee calculations, the evidence a fund manager has to be able to produce on request. That is confidential material about identifiable people and identifiable positions. This page sets out what we do about it, in enough detail that your security team can check it rather than take it on trust.
Where your data lives
Each jurisdiction we operate in is a separate deployment, not a partition of a shared one. Australia, the United Kingdom and the United States each have their own storage, their own database, their own encryption keys, their own identity provider and their own API — running in that country’s own cloud region.
- Data does not move between deployments. There is no shared database behind them and no synchronisation job between them.
- Access to each deployment is geographically restricted at the network edge, so a request from outside the region is refused before it reaches the application.
- Documents emailed in are received and stored in-region, by that region’s own mail infrastructure.
The practical consequence is that residency is a property of the architecture, not a setting. There is no configuration under which a UK customer’s data is served from Australia, because the two are separate systems.
Encryption, and who holds the keys
Everything is encrypted in transit with TLS, and at rest with AWS KMS. Beyond the default, there are two arrangements for customers who want the boundary drawn further out:
- Bring your own key. Documents and extracted figures are encrypted under a key in your own AWS account, under a key policy you write. Revoking or disabling that key stops us reading your data — including data we have already stored. We never cache the unwrapped key between requests, precisely so that revocation takes effect immediately rather than whenever a cache happens to expire.
- Bring your own storage. Documents stay in your own S3 bucket and are read by us through a role you create, gated by a secret unique to that connection. They never land in our storage at all.
Where a document was encrypted under a customer key, the figures extracted from it are sealed under that key too — not just the file. A key you withdraw takes the numbers with it.
The record is append-only
Facts extracted from your documents are written to a store that is never updated and never deleted in place. A correction is a new entry, carrying who made it, when, and the reason they gave. Deleting a source document appends a retraction rather than erasing history.
That makes it possible to ask what a disclosure said at the time it was made, months later — which is the question an auditor or a regulator actually asks. It also means nobody, including us, can quietly change a number after the fact.
Artificial intelligence
Where the platform uses a model to read a document, it runs inside the same jurisdiction as the rest of that deployment, through a managed model service within our cloud provider’s own environment. How model processing is configured for a deployment, including data handling, is set out in that customer’s agreement.
Figures are extracted by deterministic rules, not generated by a model. Where the product explains a figure, it cites the identifier of the record it came from, so a claim on screen can be traced to the document behind it.
Trust Centre
Our Trust Centre is where the evidence behind this page lives. It shows the current state of our controls — monitored continuously, not asserted once a year — alongside the documents a security review actually asks for: our SOC 2 status, our policies, our sub-processor list, and our most recent penetration test summary.
Reporting a security issue
If you have found a vulnerability in TNX Data, please tell us. We read these as a priority, we will confirm receipt, and we will not pursue anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it.
Machine-readable contact details are published at /.well-known/security.txt, per RFC 9116.
To find out more about security and compliance at TNX, please visit our Trust Centre.
Last updated 17 September 2026