Security

Access is by API key. Each key carries explicit scopes — a key issued to read basket data cannot place a trade, and a key scoped for the index cannot read exposure. Scopes are checked on every request, not at login.

Keys carry a mandatory expiry. There is no non-expiring key. Keys can be rotated without downtime and revoked immediately.

Test and live keys are separate namespaces, and live keys are only issued after due-diligence approval.

Every organisation's data is separated by row-level security in PostgreSQL. Isolation is enforced by the database itself, so a bug in application code cannot leak one organisation's data to another.

That isolation has a dedicated cross-organisation test suite that is a mandatory release gate — a build that cannot prove isolation does not ship.

Webhooks are signed with HMAC-SHA256 over the timestamp and the exact request body, so you can verify both that a message came from us and that it was not altered in transit. Signatures carry a timestamp, and stale ones are rejected — a captured message cannot be replayed later.

Credentials are held in a managed secret store. What our database holds is a reference to a secret, never the secret. Venue credentials are separated per organisation, so exposure of one is bounded to that organisation.

Every operator action against an organisation is written to an audit log. Loss-cut evaluations are logged whether or not they breached — the record exists to be evidence, not just a debugging aid.

Where the rules matter, the system stops rather than guesses. If the jurisdiction policy pack that carries statutory limits cannot be read, trading halts. There is no default and no fallback: a control that passes when unconfigured is not a control.

Enrichment — news and research — is the deliberate exception and degrades visibly instead.

Every change runs dependency-vulnerability and secret-scanning checks before it can merge. Linting failures are build failures.