Bring signals, not proprietary logic

What is the problem with hosted strategy platforms?

They require you to hand over the logic. For a desk whose edge is the model, uploading it to a vendor is not a deployment decision, it is a disclosure decision, and it is usually declined, which means the desk gets no governance either.

The result is the worst of both: proprietary strategies running on unmonitored infrastructure with no pre-trade checks, no audit evidence and no consolidated exposure view, because the only platform that offered those wanted the source.

How does the protected path work?

Four steps. Private strategy logic stays outside; it emits a signed, time-bounded order intent; Stretus validates the source, identity and risk; and the order routes through controlled egress to an eligible broker connector.

The platform never sees the logic and does not need to. What it sees is an authenticated intent, which is exactly the surface a risk gate needs to act on. Everything that makes hosted execution governable, pre-trade checks, exposure limits, HALT-NEW, audit evidence, applies unchanged.

The path, expressed as responsibilities

YOUR INFRASTRUCTURE     proprietary strategy logic
                        owns: the edge. never transmitted.

SIGNED INTENT           order intent + signature + validity window
                        owns: authenticity and freshness.
                        a replayed or expired intent is refused.

STRETUS GATEWAY         source validation -> identity -> risk gate
                        owns: the veto. scoped credentials,
                        rate limits, optional IP allowlists,
                        HALT-NEW, exposure and loss checks.

CONTROLLED EGRESS       dedicated outbound IP where configured
                        owns: traceable connectivity for
                        broker-side allowlisting.

BROKER CONNECTOR        eligible account and segment only
                        owns: pre-trade risk, routing, execution.

Push or pull?

Either. Push from custom code or a connected signal source, or let Stretus poll an approved endpoint. API credentials carry scopes, rate limits, optional IP allowlists, rotation, and one-time secret display.

One-time secret display is a small detail that says something about the design: a credential that can be re-read from a settings page is a credential that lives in screenshots and support tickets. Showing it once and requiring rotation to replace it is the behaviour a security reviewer expects to find and usually does not.

Does a remote strategy go straight to live?

No. A remote strategy is saved as a draft and can move through paper observation before an eligible live deployment. Paper first is the default rather than an option.

That default exists because a remote strategy is the case where the platform has least visibility into what produced an intent. Observing behaviour against live prices with no capital at risk is the only way to establish that the integration does what its author believes before it does it with money.

What does controlled egress solve?

Broker-side allowlisting. Dedicated outbound-IP options give a traceable, stable origin for order connectivity where a broker requires whitelisted addresses, which, under NSE/INVG/67858 of 5 May 2025, may be updated at most once per calendar week.

That weekly limit is why a dedicated, stable egress address is worth more than it first appears. An architecture whose outbound address varies cannot satisfy the requirement at all, and one that can only change it reactively cannot fail over inside the same week.

Push and pull, compared

Either path produces the same signed, time-bounded intent and passes the same gateway checks.

What happens when an intent is refused?

The refusal carries its reason, expired validity window, failed source validation, an exposure or loss limit, a HALT-NEW state, or an ineligible account or segment, and appears in monitoring rather than failing silently.

That matters more for remote strategies than native ones, because the author's system is outside the platform and cannot observe the gate directly. A refusal with a stated reason is what lets an external engine correct itself instead of retrying a request that will never succeed.

What are the operational obligations on your side?

Keep the signing key secure and rotate it; keep the validity window short enough to be meaningful; handle refusals rather than retrying blindly; and register a secondary egress address before you need it, because a whitelisted IP can be updated at most once per calendar week.

None of those are unusual for a system that places orders, and all of them are cheaper to build at the start than to retrofit after an incident. The weekly IP limit in particular is the one that cannot be solved reactively, and it is the reason failover has to be designed alongside registration rather than after it.