Skip to content
Nexus Prop LLC

Architecture guide

The prop firm technology stack, layer by layer.

Every funded-trader firm runs the same six layers whether or not it has named them. This guide maps them, shows where the seams usually tear, and explains which boundaries are worth defending.
By Ethan Warmuskerken, Founder, Nexus Prop LLCLast reviewed

Key takeaways

  • Six layers: trader experience, trading and market data, risk and lifecycle, CRM and money, support, and observability.
  • Failures concentrate at boundaries where two systems each hold a partial copy of account state.
  • The layer most often underestimated is observability — the ability to reconstruct what happened.

The trader-facing layer

Signup, identity verification, purchase, the dashboard, education, competitions and payout requests. This layer determines conversion and a large share of support volume, because everything a trader cannot see for themselves becomes a ticket.

The common failure is that the dashboard reports numbers it computes independently, so what a trader sees and what the firm acts on diverge under load. See trader dashboard.

Trading, market data and simulated execution

The trading workspace, the data feed behind it and the engine that matches orders. This layer carries the licensing obligations and produces the fills everything downstream depends on.

The common failure is treating market data as a feature rather than a licensed input with reporting duties. The second is a matching engine whose behaviour cannot be reconstructed, which makes disputes unwinnable.

Risk and account lifecycle

Rule definition, continuous evaluation against live state, breach determination, resets, scaling and payout eligibility.

The common failure is splitting authority: rules enforced in the trading platform, eligibility computed in the back office, and no single record that reconciles them. See risk management.

CRM, identity, payments and payouts

The customer record, agreements, purchases, refunds, identity verification, payout requests and the money movement behind them.

The common failure is that the CRM holds a customer while the trading platform holds an account and nothing authoritative joins them, so a person with three accounts looks like three people — which is also how fraud hides. See operations CRM and fraud prevention.

Support and observability

Support is the layer where every other layer's gaps surface, and observability is what lets you answer rather than guess.

The common failure is having no way to reconstruct a specific trader's experience at a specific moment. If answering 'why did this account fail on Tuesday' takes an engineer and three exports, the stack has an observability problem regardless of how good its features are.

Where stacks break

BoundarySymptomUnderlying cause
Trading ↔ riskBreach the CRM cannot explainTwo systems computing drawdown independently
CRM ↔ tradingOne person appears as several customersNo authoritative join between customer and account
Risk ↔ payoutsPayout approved against stale stateEligibility computed from a copy, not the record
Support ↔ everythingSlow, hedged answersTicket adjacent to the account rather than attached
Data ↔ complianceLicensing questions nobody can answerMarket data treated as a feature, not a licensed input

Buyer checklist

  • For each layer, name the single system that is authoritative
  • For each boundary, state what is copied and how disagreement is detected
  • Confirm you can reconstruct any account's state at any past moment
  • Confirm one customer identity spans all their accounts and orders
  • Confirm market-data licensing scope is documented, not assumed

Map your stack with us.

Bring your current architecture, including the spreadsheets. The seams are usually obvious within an hour.