Product Specification & Commercial Terms · Bruno Core
Bruno Challenge — Prop Trading Infrastructure
Evaluation and funded-account infrastructure for brokers and proprietary trading firms,
built as a module of Bruno Core. Challenge rules are enforced inside the trading engine
that executes the orders, not by a dashboard reading the account from outside. This
document covers the rule engine, risk enforcement, operator platform, integration
topology and published pricing.
4 min
Breach to failed challenge, unattended
6
Configurable liquidation strategies
100%
Challenge fees retained by operator
What Bruno Challenge is § 01
A prop trading module inside Bruno Core. It uses the same trading engine, the same
account infrastructure, the same admin platform and the same permission model as the
rest of the suite. There is no second system to operate and no bridge between them.
| Product class |
Evaluation and funded-account infrastructure (white-label), delivered as a Bruno Core module |
| Operator type |
Regulated brokers adding a prop product · proprietary trading firms · multi-brand operators |
| Challenge structures |
One-stage evaluationTwo-stage evaluationFunded account |
| Risk enforcement |
Engine-level. Loss limits are enforced by the same order management engine that executes the trade, not by a scheduled job inspecting balances. |
| Branding |
Operator-branded trader portal and operator dashboard. Engine attributed to Tradesocio in technical documentation only. |
| Commercial model |
Monthly licence by active account count. No setup fee, no minimum term, no revenue share on challenge fees. |
Challenge lifecycle § 02
Every step below runs without operator involvement except the funding decision, which is
deliberately held as a manual approval because that is the moment real capital is committed.
- Operator publishes a challenge product. Account size, targets, limits and payout terms are set once and validated against the trading group that will enforce them. A product whose advertised rules do not match what the group enforces cannot be put on sale.
- Trader purchases. The entry fee is taken and the purchase is idempotent on the order reference, so a duplicate submission cannot create two challenges.
- Account provisioned at the advertised size. A live trading account is created and funded with the amount the product advertised.
- Trader trades. Positions, equity and progress are visible to the trader in real time. One trader can never see another trader's challenge.
- Stage passed, next stage provisioned. On a two-stage product, passing stage one automatically opens the stage-two account.
- Funding approved. An explicit operator action, gated behind an approved identity check on the trader.
- Breach handled automatically. The engine closes every open position, blocks the next order, and the platform fails the challenge — recording the reason and the exact breach time in the challenge history.
- Payout requested and reviewed. Request, approve, reject and hold. A payout with no profit behind it is refused.
Rule engine specification § 03
| Account sizes | Operator-defined. No platform ceiling. |
| Profit target | Configurable per stage. Two-stage products carry an independent target on each stage. |
| Maximum daily loss | Percentage of account. Enforced by the engine intraday. |
| Maximum overall loss | Percentage of account. Enforced by the engine. |
| Trailing behaviour | Loss limit can trail peak equity rather than the static starting balance. |
| Minimum trading days | Configurable per stage. |
| Consistency rule | Best-day share of total profit, configurable, disabled by default. |
| Profit split | Configurable per plan. |
| Payout cycle | Configurable per plan. |
| Reset | Priced per plan. |
| Rule sets per operator | Each distinct set of limits is enforced by its own trading group. One group included; additional groups priced in § 08. |
| Settlement currency | USD |
Risk enforcement and liquidation § 04
This is the part that separates infrastructure from a dashboard. A tool that sits beside a
trading platform can only observe an account between polls. A breach that happens inside
that window is a breach the operator carries.
| Enforcement point |
Inside the order management engine. A breached account is blocked at the order gate — the next order is refused by the engine, not by the portal. |
| Liquidation strategies |
Six configurable strategies, selectable per challenge group. |
| Breach detection |
The reconciler does not rely on the engine's own account status flag. It reads the
recorded breach event, so an account whose liquidation did not complete cleanly is
still correctly failed. This is a deliberate design decision, not a fallback.
|
| Reconciliation interval |
Every five minutes, independently gated by a scheduler switch and a module switch. |
| Measured outcome |
Breach to failed challenge in four minutes with no human involvement, verified against the live engine on a funded account. |
| Finality |
A breach is terminal at the engine level. Recovery is by issuing a new account, which the operator controls. |
Operator platform § 05
| Admin surfaces | Five |
| Operator endpoints | 54 |
| Discrete permissions | 18 |
| Per-brand settings | Module behaviour configurable per brand |
| Plan management | Create, price, publish and withdraw challenge products |
| Challenge oversight | Full lifecycle state, stage history, breach record with timestamp and reason |
| Account oversight | Live equity, risk state and open positions per challenge account |
| Payout review | Request queue with approve, reject and hold |
Integration and deployment § 06
| Existing infrastructure |
Bruno Challenge is designed to sit alongside an operator's existing retail book rather
than replace it. MT4 and MT5 infrastructure is retained, client bases are not migrated,
and active retail order flow is not interrupted.
|
| Liquidity connectivity |
Native FIX to liquidity providers. No third-party bridge provider is required, and no per-volume bridge fee is incurred. |
| Group topology |
Challenge accounts are provisioned into dedicated prop trading groups, isolated from retail groups. One group per distinct rule set. |
| Account isolation |
Challenge accounts are excluded from retail account caps, from net deposit reporting and from customer balance reporting, so prop capital never appears as client money. |
| Trader funding route |
Entry fee is taken from the trader's account balance held with the operator. |
| Charting |
TradingView Advanced Charts, embedded in the trader portal. |
Commercial terms § 07
A monthly licence based on how many accounts were active in the month. No setup fee, no
minimum term, and no share of what your traders pay you.
Setup
$0
Every tier, both products
Minimum term
None
Month to month
Revenue share
None
Operator keeps 100% of challenge fees
Billed on
Active
Accounts active in the calendar month
Challenge Add-On — for operators on Bruno Core
| Accounts active in the month | Monthly licence | Setup |
|---|
| Up to 500 | $3,000 | $0 |
| Up to 2,000 | $6,000 | $0 |
| Up to 5,000 | $10,000 | $0 |
| Above 5,000 | By agreement | $0 |
Prop Firm Launch — includes the Bruno Core OMS base
| Accounts active in the month | Monthly licence | Setup |
|---|
| Up to 500 | $5,500 | $0 |
| Up to 2,000 | $8,500 | $0 |
| Up to 5,000 | $12,500 | $0 |
| Above 5,000 | By agreement | $0 |
Options and definitions
| Additional rule sets | One rule set is included. Each additional set is $500 per month. A five-tier product ladder with genuinely different limits requires four additional sets. |
| Additional FIX connection | $2,000 per month per connection. |
| Active account | An account that was live during the calendar month. Accounts created but never used are not billed. |
| Annual commitment | Optional. A twelve-month term attracts a discount against the monthly licence; there is no obligation to take one. |
| Currency | All figures USD, exclusive of applicable taxes. |
Competitive position § 08
| Capability | Bruno Challenge | Dashboard-layer platforms |
|---|
| Risk enforcement | Enforced by the order management engine at the order gate | Dashboard layer reading the account between polls |
| Liquidation strategies | Six, configurable per challenge group | Typically a single fixed strategy |
| Breach detection | Reads the recorded breach event, not the account status flag | Relies on the platform's own status reporting |
| Trailing loss on peak equity | Supported | Frequently unavailable |
| LP connectivity | Native FIX, no bridge provider and no per-volume bridge fee | Third-party bridge required, priced by volume |
| Order routing | Rules-based routing engine with hot reload | Not available |
| Existing MT infrastructure | Retained — no forced migration of the retail book | Full platform replacement commonly required |
| Challenge fee revenue | Operator keeps 100% | Varies; revenue-share models are common |
| Setup fee | None | $0 to $3,000 depending on vendor |