Multi-tenant operations, from onboarding to credential isolation

Why does a broker care about the layer above their own console?

Because it determines their isolation guarantees. In a multi-tenant platform, the question that matters is not what your tenant can do. It is what another tenant cannot do to yours, and that is answered at this layer rather than in your own settings.

A security reviewer assessing a shared or dedicated deployment will ask exactly that. Credential isolation, tenant provisioning and settings resolution are the mechanisms that answer it, and publishing them is more useful than a general assurance that tenants are separated.

The control plane, surface by surface

This is the platform operator's surface, not the broker's. It is documented here because its guarantees are what a broker's security review actually depends on.

What does credential isolation mean concretely?

That whatever access material the platform holds for one tenant cannot be reached from another tenant's context, and that no shared integration credential ever stands in for per-client access, which the framework prohibits in any case.

Under NSE/INVG/67858 of 5 May 2025, API access is per user by unique vendor and client specific key with OAuth authentication and two-factor verification. Open APIs are not permitted. So the platform cannot operate on a pooled credential model even if it wanted to, and isolation is a compliance requirement rather than only a security preference.

Where a tenant supplies its own AI-provider keys, those are protected at rest and used only for authorised provider requests under that tenant's policy.

Why is the instrument catalogue a control rather than a data set?

Because contract resolution depends on it, and derivative correctness depends on contract resolution. Canonical underlying identity, series with venue and expiry, and contract-level strike, right, lot, expiry class and price precision all originate here.

That is why reference-data imports are validated rather than merely ingested. A malformed or stale catalogue does not produce an obvious error. It produces a resolution that is subtly wrong, and a strategy tested against a subtly wrong contract returns a plausible number.

Market-data mappings sit alongside it for the same reason: feed symbology that maps to the wrong canonical instrument is impossible to tell apart from correct data until it reaches a position.

What does production activation review gate?

Going live. A capability, tenant or configuration that works in a staging environment is not automatically production-eligible, and the review is the deliberate step between the two.

The onboarding pipeline makes the same point operationally: tenant info collected, admin account created, modules configured, and so on, stages that complete in sequence with the incomplete ones visible rather than assumed. A tenant that is two of six steps through provisioning shows as exactly that.

Broker and exchange procedures remain authoritative for each production rollout, so this review is the platform's own gate and not a substitute for yours.

What does a broker get from this being visible?

The ability to ask specific questions during a security review instead of general ones, and to get answers about mechanisms rather than assurances about intentions.

Concretely: how are our credentials isolated from other tenants; which modules are we entitled to and who can change that; how is the instrument catalogue our contracts resolve against validated; what has to happen before a change reaches our production environment. Each of those has a surface behind it.