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.

Access control

• Staff access to production runs through AWS IAM Identity Center with single sign-on and multi-factor authentication required.
• There are no IAM users and no long-lived access keys in any of our AWS accounts. Credentials are short-lived and issued per session.
• Production, development and organisational billing are separate AWS accounts, so a mistake in one cannot reach the others.
• In the product itself, every list a user can request is scoped to the account they are acting as, in one place in the code that all of it passes through — the scoping is structural rather than a filter each endpoint has to remember to apply.

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 Amazon Bedrock. Your content is not used to train models, and it is not sent to a third-party model provider’s own service.

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.

Logging, monitoring and availability

• API activity across every one of our AWS accounts is captured in a central audit trail, retained long-term and written to storage separate from the accounts it records.
• Application logs are retained for twelve months and alert us automatically on error.
• Authentication events — sign-in, sign-out, token refresh — are recorded as structured audit events.
• Service health is published, without login, at status.tnxdata.com.

How we build

• Input is validated on a reject-don’t-encode basis: structured fields must match an exact format, free text refuses markup.
• The application is served under a strict Content Security Policy, with no unsafe-eval and no inline script.
• Dependencies are audited automatically, and the build fails on a high-severity advisory.
• Infrastructure is defined as code and reviewed as code — there is no console-clicked production resource that nobody can account for.

Testing

We run white-box penetration tests against the platform, with the tester given source access rather than left to guess. Findings are tracked in a register that carries across engagements, so a finding stays visible until it is fixed, retested, or explicitly accepted with a reason recorded.

Compliance

Our information security programme covers access control, cryptography, data management, incident response, business continuity, secure development, third-party management and physical security. Each of those is a written, approved policy rather than a practice we describe on a web page.

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 policies, our sub-processor list, and our most recent penetration test summary.

Access is requested and granted, not open. Ask for access from the Trust Centre itself and we approve it person by person, under NDA. That is deliberate: this material describes, in detail, how a system holding regulated fund data is built and defended. We would rather hand it to a named person at a named organisation than publish it and hope. If you are evaluating TNX and need it, request access — it is meant to be given, not guarded.

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.

We deliberately publish no email address here — a mailbox on a public page becomes unusable within weeks. The form below reaches the same people:

Report a security issue

Machine-readable contact details are published at /.well-known/security.txt, per RFC 9116.

Last updated 26 August 2026