Infrastructure & Security

This page documents the technology stack that runs the strategies. Allocators who evaluate operational risk will find the answers they need here; the full technical DDQ is in the Due Diligence Questionnaire.

Execution topology

Execution latency

For the paper-traded research portal, execution is end-of-day — latency is not a material factor. For live execution under a white-label KVG or Haftungsdach structure, orders are issued directly by the strategy pod via broker API, with typical signal-to-order latency in the sub-second range. Fill latency is the broker’s venue latency (milliseconds for IB smart-routing).

Key management

• Non-withdrawal broker keys. All trading API keys are scoped to trade-only permissions where the venue supports it (IB, Binance, Alpaca). Withdrawal / transfer scopes are never enabled on any key used by an automated strategy.
• Kubernetes Secrets. Keys are mounted from Secret objects with restricted RBAC. They are never present in container images, never in git.
• Rotation. Keys are rotated at least quarterly, immediately on any suspicion of compromise.
• Audit trail. Every order issued by a strategy pod is logged to Postgres with full parameters — orders can be replayed against the same signal.

Data integrity

• Append-only Postgres. portfolio_worth rows are inserted, never updated. This gives allocators a tamper-evident performance record — a compromised row would be visible as a gap or out-of-order timestamp.
• Strategy code versioning. Every strategy is a git-tracked file in the open-source framework. The exact commit running in production is identifiable from the deployed container image tag.
• Reproducibility. Given a Postgres snapshot and the git SHA of the strategy, any external reviewer can recompute every number published on this site.

Monitoring & alerting

• Liveness / readiness probes on all deployments; /healthz on the public nginx.
• Daily CronJob success / failure is logged; a missed generator run triggers a manual review.
• Drawdown thresholds. Each strategy carries a -25%-from-seed kill switch. Breaching the threshold suspends the strategy pending human review.
• Exception aggregation. Errors are captured in structured logs; persistent failures notify the founder by email.

Business continuity

• Open-source framework. Strategy code is fully public; a third party can re-deploy any strategy from the published source without access to our infrastructure.
• Postgres backups. Daily off-site encrypted backups of the strategy and performance schema.
• Key-person risk. Documented with external counsel; see Due Diligence Questionnaire § 5.4.
• Vendor dependency. The platform depends on the availability of broker APIs and Yahoo Finance. If any single vendor is unavailable, affected strategies are paused (not failed over to untested routes).

Security posture

• TLS everywhere (Let’s Encrypt, auto-rotated).
• Separate namespaces for site serving and strategy execution.
• Cross-namespace traffic restricted to required connections (Postgres, broker outbound).
• No inbound internet access to the strategy pods — all signalling is outbound.
• Dependency security: uv lockfile + regular pip-audit review.

Third-party verification (roadmap)

Direct broker-API feed integration with a neutral verification service (Myfxbook, Collective2, or similar) is planned for the live-execution structure. The paper-traded research portal is self-reported by design — allocators seeking independently verified performance should request the managed-account or KVG track record, which is audited by the licensed partner.