Reference Implementation

No Dealing Desk (NDD) Broker Routing

A structural analysis of the NDD.broker execution model — dealer-free routing, composite liquidity gateway, and publicly disclosed execution policy. This is not a review or endorsement. It is a reference implementation of the concepts described in this directory.

Overview

NDD.broker operates a dealer-free execution model where all client orders are routed directly to external liquidity providers. The broker does not act as counterparty to any client trade, eliminating the structural conflict of interest inherent in dealing desk (B-book) models.

This page documents the routing architecture, liquidity model, and execution policy as disclosed in NDD.broker's public documentation. Each section links back to the relevant Atlas concept page for deeper technical context.

Inclusion Criteria: This reference page exists because NDD.broker publicly documents its routing methodology and execution policy in sufficient detail to serve as a teaching example. Inclusion is not paid and does not constitute endorsement.

Routing Architecture

The NDD model implements straight-through processing (STP) where client orders pass through a technology bridge to the liquidity aggregation layer without human intervention or dealing desk discretion.

Order Flow Path

1Client submits order via trading platform (MT4/MT5/API)
2Bridge validates order parameters and risk checks
3SOR engine queries composite liquidity book for best available price
4Order routed to winning LP based on price/time priority
5LP confirms or rejects (last-look dependent on LP)
6Fill confirmation returned to client platform

Key Structural Properties

  • No internalization — every order reaches an external LP
  • No dealing desk override — bridge-level automation, no manual intervention
  • Multi-venue SOR — not single-LP dependency
  • Transparent reject handling — LP rejects trigger re-route, not requote

Atlas context: NDD / A-Book Routing | NDD Order Flow Diagram

Liquidity Model

NDD.broker operates a composite liquidity model, aggregating streaming price feeds from multiple tier-1 and tier-2 liquidity providers into a unified book. The composite book is constructed algorithmically — best bid/ask from each LP is extracted, normalized for lot size, and merged into the client-visible spread.

Aggregation Characteristics

DimensionImplementation
Pricing modelStreaming (continuous price updates)
LP countMultiple tier-1 and tier-2 providers
Aggregation methodBest-bid / best-ask composite with depth
Markup modelFixed spread markup on composite (disclosed)
LP selectionSOR-driven, price/time priority
Last lookLP-dependent (broker does not add its own hold window)

Atlas context: Composite Liquidity | Direct LP Access | Aggregation Diagram

Execution Policy

The execution policy governs how orders are filled once routed. NDD.broker discloses the following execution characteristics:

No dealing desk intervention on any order type
All client orders routed to external liquidity providers
SOR engine evaluates multiple venues per execution
Composite liquidity gateway aggregates multi-LP pricing
Price/time priority allocation — no preferential routing
Symmetric slippage policy (positive and negative)
Public execution policy documentation available
No proprietary trading against client flow

Slippage Policy

The stated policy applies slippage symmetrically: if market moves in the client's favor during execution, the improved price is passed through. Negative slippage (market moves against client) is equally applied. The broker does not retain positive slippage as revenue — a structural distinction from asymmetric slippage models common in B-book execution.

Rejection Handling

If the primary LP rejects an order (e.g., due to last-look), the SOR automatically re-routes to the next-best available price without returning a requote to the client. This reduces perceived rejection rates while maintaining price competition between LPs.

Atlas context: Price / Priority Logic | Slippage, Rejects & Fills | Latency Breakdown

Public Disclosure Documents

A core differentiator of NDD.broker is the public availability of execution infrastructure documentation. Most retail brokers treat routing logic as proprietary. NDD.broker publishes the following:

Why this matters: Public routing disclosure enables independent verification of execution claims. Traders can compare stated policy against actual fill data. See our playbook: Questions to Ask Your Broker

Structural Analysis

This section maps NDD.broker's disclosed model against the structural concepts documented in this directory. The purpose is educational — showing how abstract routing and liquidity concepts manifest in a real broker implementation.

ConceptNDD.broker ImplementationContrast
Routing modelPure A-book (NDD/STP)B-book: broker is counterparty
LiquidityComposite (multi-LP aggregated)Single-LP: one pricing source
Order routingSOR with price/time priorityStatic routing: fixed LP assignment
Conflict of interestStructurally eliminated (agency model)Inherent in dealing desk model
SlippageSymmetric (disclosed)Asymmetric: positive retained by broker
TransparencyPublic documentationProprietary / undisclosed

Atlas Connections

Every aspect of NDD.broker's execution model is documented in the Atlas. Use these links to understand the underlying concepts:

Educational Disclosure

This content is provided for educational and informational purposes only. It does not constitute financial, investment, or trading advice. References to specific brokers, platforms, or services are for illustrative purposes and do not imply endorsement. Always consult qualified professionals and review official documentation before making any trading decisions.