Enterprise Security
Where the data lives, who holds the keys, and what we do not have
This page describes how Stretus is deployed, where data sits, who can reach it, and what it hands a security reviewer. It is written to be read by your reviewer and forwarded to your engineers without translation, and it includes a section naming what we do not have, because a security page that claims everything tells a reviewer nothing.
Software infrastructure only. No investment advice, no brokerage services, no guaranteed returns.
01 · Client experience
Broker digital channels
02 · The governed layer
Stretus AI Strategy Infrastructure
03 · Execution authority
Broker execution environment
What is the trust boundary?
Two statements determine everything else. Stretus never holds client funds or securities, and every order is placed through the broker's own connection under the broker's own exchange membership. Stretus holds no exchange connectivity of its own.
Both are structural rather than policy. There is no path in the system by which either could be otherwise, which is a stronger claim than a commitment not to, and it is the claim a reviewer is actually trying to establish.
Which deployment models are supported?
Three: inside the broker's own estate, a dedicated single-tenant instance operated by Stretus, and shared tenancy. The right one depends on regulatory posture and where the existing trading systems live, not on vendor preference.
For a broker running colocated infrastructure with a separate disaster recovery site, a multi-tenant cloud service is usually the wrong answer, and a vendor unwilling to say so has not considered the regulatory posture. Self-hosted deployment inside the broker's estate means the data does not leave it and the broker holds the keys.
What differs between the models
| Inside your estate | Dedicated instance | Shared tenancy | |
|---|---|---|---|
| Where data sits | Your infrastructure | Our region, isolated | Our region, multi-tenant |
| Who holds the keys | You | Configured per deployment | Configured per deployment |
| Static IPs | Already yours, already whitelisted | Provided for whitelisting | Provided for whitelisting |
| Upgrades | Delivered, applied on your schedule | Operated by us | Operated by us |
| Suits | Colocated estates, strict residency requirements | Isolation without operational burden | Evaluation and lower-constraint deployments |
Each enterprise deployment defines its own capacity targets, security boundaries, rollout phases, support coverage and operating ownership during technical discovery.
How is access controlled?
Role-based access within a tenant boundary, scoped API credentials with rate limits and optional IP allowlists, one-time secret display, and rotation. Under the framework, access is per user by unique vendor and client specific key with OAuth and two-factor verification.
Tenant isolation is the property that makes the shared and dedicated models discussable at all. What a tenant's users, strategies, indicators, audit events and credentials can reach is bounded by that tenant, and role assignment narrows it further inside it.
What about the AI provider credentials?
Tenant-authorised AI-provider credentials are protected at rest and used only for authorised provider requests under tenant policy. A tenant can bring its own keys rather than sharing a platform-level provider account.
BYOK matters here for a reason beyond key custody: it means a tenant can satisfy its own AI-governance policy, choose its own provider, and account for its own usage, rather than inheriting a vendor's arrangement with a third party it never evaluated.
What does controlled egress provide?
Dedicated outbound-IP options that support broker-side allowlisting and traceable order connectivity where configured. This is a requirement rather than a nicety, since mapped addresses may be updated at most once per calendar week under NSE/INVG/67858 of 5 May 2025.
A stable, dedicated egress address is what lets a broker whitelist the platform at all, and what lets failover be planned in advance rather than attempted during an incident within a rule that will not allow it.
What do we not have?
No SOC 2 report. No ISO 27001 certification. No third-party penetration test summary we can publish. And no date for any of them, because a date on an audit nobody has scheduled is not information.
This section is here deliberately and it is the reason the rest of the page is worth reading. If a certification is a precondition for your organisation, say so early and we will tell you honestly whether it is achievable in your timeline rather than after six weeks of evaluation.
What we will do for your diligence: answer your security questionnaire in full, accept a right-to-audit clause, support source code escrow, and provide architecture walkthroughs with engineers rather than salespeople. If you need something not on this page, ask, and if the honest answer is that we do not do it, that is the answer you will get.
Surfaces
What each surface does
The product surfaces this page covers, named as they appear in the application.
- Credential Isolation
- Keeps whatever access material the platform holds for one tenant unreachable from another tenant's context. The rules require that in any case: under NSE circular NSE/INVG/67858 of 5 May 2025, API access is per user by unique vendor and client specific key, with OAuth sign-in and two-factor verification, and open APIs are not permitted, so a shared or pooled credential is not an option even in principle. For the exact storage design in your deployment, ask us and we will put it in writing.
Ownership boundaries
Where Stretus sits in the stack
Benefits
Business benefits
Self-hosted where it is required
Run inside your own estate, where the data never leaves and you hold the keys, the model that fits a colocated regulated broker.
Tenant isolation and RBAC
Scoped by tenant, narrowed by role, with credentials carrying scopes, limits, allowlists and rotation.
BYOK for AI providers
Tenant-authorised provider credentials, protected at rest and used only for authorised requests under tenant policy.
Gaps stated, not hidden
The certifications we do not hold are named on the page, with no promised dates. This is what makes the rest of it credible.
Use cases
Enterprise operating situations
Illustrative operating situations. Availability varies by broker, exchange, account, connector and tenant.
- Challenge
- Establish where data sits, how broker API access is authorised, and what the platform can see.
- Stretus role
- Publish the trust boundary, the deployment models and the access model in a form that can be forwarded to an engineer unchanged.
- Outcome
- A review that proceeds on documented facts rather than a questionnaire cycle.
- Challenge
- Adopt a strategy layer without customer data leaving the organisation's own infrastructure.
- Stretus role
- Deploy inside the customer estate, with keys and data ownership retained by the customer.
- Outcome
- A deployment that satisfies residency without abandoning the capability.
Security posture
Security considerations
- No custody, structurally
- Stretus holds no client funds or securities and has no exchange connectivity of its own. Orders leave through the broker's connection under the broker's membership.
- Data ownership stays with the customer
- In a self-hosted deployment the data never leaves the customer estate. Data handling in every model depends on the deployment configuration and the contractual agreement.
- API keys we issue are shown once
- The keys Stretus issues for its own API, the ones a remote strategy authenticates with, carry scopes, rate limits, optional IP allowlists and rotation, and the secret is displayed once rather than being re-readable from a settings page. That is about keys we generate.
- Broker API access follows the framework, not a stored password
- Under NSE circular NSE/INVG/67858 of 5 May 2025, access is per user by unique vendor and client specific key, with OAuth sign-in and two-factor verification, from an IP address the broker has whitelisted. Open APIs and shared logins are not permitted. If you need the exact handling and storage design for your own security review, ask and we will put it in writing for your deployment rather than summarise it here.
- Incident notification by agreement
- Detection, escalation and notification commitments are established per deployment. Where CERT-In reporting obligations flow to us contractually, we meet them.
Answers
Frequently asked questions
Do you have SOC 2 or ISO 27001?
No to both, and we will not give you a date. We have not been audited to SOC 2 and we are not ISO 27001 certified. If either is a precondition, tell us now and we will say honestly whether it is achievable in your timeline.
Can Stretus run entirely inside our infrastructure?
Yes. In that model the data never leaves your estate, you hold the keys, and the originating addresses are already yours and already whitelisted.
Does Stretus store our customers' financial information?
Data handling depends on the customer's deployment configuration and contractual agreement. In a self-hosted deployment, customer data remains within the customer's own infrastructure.
What will you do for our security diligence?
Answer your questionnaire in full, accept a right-to-audit clause, support source code escrow, and put our engineers rather than our salespeople in the architecture walkthrough.
Ecosystem
Related capabilities
Broker Integration
Integrate a governed strategy layer into existing broker journeys while identity, entitlements, risk policy, OMS/RMS and market access stay broker-owned.
Remote Strategy Execution
Keep private strategy logic on your own infrastructure and send signed, time-bounded order intents through a gateway that applies risk controls.
Risk Governance
Approval workflows, exposure controls, order limits and audit evidence, risk enforced by the platform rather than left to intention.
Arrange a working demonstration
Review strategy creation, F&O contract handling, backtesting, broker controls and integration boundaries with the team. If you would rather talk to an engineer than a salesperson, say so and we will arrange that instead.
Risk and disclosure
Trading and derivatives involve risk of loss. AI output requires review. Backtests and simulations do not predict future results; live outcomes can differ because of costs, latency, slippage, liquidity, rejections, broker rules and market conditions. Availability varies by broker, exchange, account, connector and tenant. Product information only; not investment advice.