Security
Access control, encryption, OIDC single sign-on for dedicated cloud and on-premises, and how TrackRecords isolates portfolio data
TrackRecords is built for investment teams that process holdings, transactions, limits and risk results. The platform has been in production since 2013. Access is limited to authorised users. The administrative console is separate from the working terminal.
On this page
Encryption in transit
All browser and API traffic uses HTTPS / TLS. The public cloud service scores A+ on SSL Labs. Dedicated-cloud and on-premises deployments terminate TLS on the organisation's certificates.
The application database is not exposed on the public internet. It is reachable only on the private network of that environment.
Authentication
How users sign in depends on the edition.
SaaS
Cloud SaaS uses email and password, then two-factor authentication by email: a one-time code must be confirmed before the session starts. Failed attempts are logged.
Dedicated cloud and on-premises: OIDC
Dedicated cloud and on-premises sign-in is OpenID Connect (OIDC). The organisation uses its own identity provider, or a Keycloak instance deployed with the stack. Typical outcomes:
- Single sign-on with the firm's existing directory (the same accounts as email, VPN and other internal tools)
- Groups in the IdP map to TrackRecords roles and permissions. When a person is removed from a group, access is taken away on the next token check, not only at first login
- Access tokens are validated (including introspection). Disabled local accounts cannot use a still-valid IdP token
- The admin console can be restricted to SSO, or to SSO plus a break-glass password, depending on the organisation's policy
API calls from the terminal use a session JWT after login. Machine integrations can use named API tokens; tokens are stored hashed, not in clear text.
Roles, permissions and portfolio sharing
Authorisation is separate from authentication.
- Module permissions control which parts of the terminal a user can open (portfolios, risk, limits, API, reports and so on).
- Portfolio sharing is per book: owner, editor or viewer. A colleague sees only the portfolios that were shared with them.
- Users can be disabled without deleting history.
- The admin console (users, roles, connectors) is a different surface from the investment terminal.
The same checks apply to the snapshot API and the transaction API.
Isolation by edition
| Edition | Where data lives | Sign-in | Extra controls |
|---|---|---|---|
| SaaS | Shared certified cloud; reference and market data included | Email + 2FA | TLS A+, managed backups and updates |
| Dedicated cloud | Isolated environment and database for that firm | OIDC | Optional IP allowlist; we operate the servers |
| On-premises | Your servers and network | OIDC | Data stays in the client perimeter; connectors attach internal sources |
Dedicated cloud is not a slice of the SaaS tenant: it is a separate contour. On-premises keeps holdings, transactions and market data inside the organisation. See Pricing for how the editions are packaged.
Audit and operations
- Sign-in attempts are logged (success and failure, method, IP): password, OIDC and API.
- Operating systems, web servers, databases and libraries are patched on a regular schedule.
- Monitoring is in place to detect anomalies and respond to incidents.
- Backups are taken regularly so data can be restored after a failure. On-premises backup policy follows the client's operations.
For a security questionnaire or an OIDC integration, use Contact.