Bloomberg is for analysts. TradingView is for retail. But what do prop firms, options market makers, and ETF desks at investment banks trade on? In most cases, the answer is T-Bricks (now Broadridge Trading and Connectivity Solutions).
T-Bricks is not a terminal in the traditional sense. It's a modular server-side platform in C++, engineered for one purpose: sending orders to exchanges faster than competitors while controlling risk in real time. 100+ institutional clients, connections to 150+ exchanges across three continents, over 300 ready-made trading applications.
Timeline: From a Stockholm Startup to Broadridge's $2.5B Acquisition
| Year | Event | Significance |
|---|---|---|
| 2008 | T-Bricks founded in Stockholm | Modular architecture vs monolithic OMS/EMS |
| 2012 | Nordic Capital acquires Orc Group | Orc — Swedish leader in derivatives trading |
| 2015 | Orc acquires T-Bricks | T-Bricks core becomes the foundation for Orc |
| 2016 | Orc + CameronTec merger → Itiviti | T-Bricks = flagship cross-asset trading + FIX infrastructure |
| 2021 | Broadridge acquires Itiviti for €2.14B (~$2.5B) | T-Bricks front-office + Broadridge back-office = straight-through processing (STP) |
| 2024 | Structured products scaling | Quoting 100K+ instruments simultaneously without latency degradation |
| 2026 | Central Risk and Liquidity Optimization | Unified risk console across all asset classes and desks |
Architecture: "Buy AND Build"
T-Bricks follows the Buy AND Build principle: you buy the optimized core and build your own algorithms on top. Three layers:
Layer 1: Core Engine (C++, Linux)
The core contains no trading strategies. It handles:
- Network connections to exchanges (TCP/UDP sessions)
- Parsing exchange protocols (FIX, ITCH, OUCH, Globex)
- Normalizing market data into a unified internal format
- Message routing between services
- Managing system state with minimal latencies
Architecture is distributed microservices. Each service can be placed on a separate server without bottlenecks.
Layer 2: Out-of-the-box Apps (300+)
Ready-made modules covering standard industry tasks:
| Module | Function |
|---|---|
| Volatility Surface | Calculation and management of volatility surfaces |
| Auto-Quoting | Automated quoting for options and structured products |
| Delta Hedging | Dynamic hedging of delta positions |
| Risk Limits | Pre-trade risk limit control in real time |
| iNAV Calculator | Indicative ETF NAV calculation |
| Smart Order Routing | Algorithmic best-price search across fragmented markets |
| RFQ Engine | Processing quote requests from institutional clients |
Key point: clients receive the source code of these applications. No black boxes.
Layer 3: Custom Apps (C++ SDK)
Proprietary firm algorithms. A developer writes a C++ plugin via the T-Bricks API, and it seamlessly injects into the running system without stopping the trading core.
Market Adapters
Each exchange interaction goes through a separate adapter. Modularity allows deploying unlimited adapters across global data centers (Equinix NY4 in New York, LD4 in London, TY3 in Tokyo), all managed from a single system.
C++ on the Critical Path: HFT Engineering Rules
Why C++ and not Python? Because every extra memory copy costs money. In HFT, data arrives as binary packets via UDP multicast at extreme speeds. Falling behind by a few microseconds = losing the trade.
Three Prohibitions on the Hot Path
1. Zero Dynamic Allocation: new on the critical path is forbidden. Instead — memory pools: thousands of objects pre-allocated before the trading session.
2. Lock-free Synchronization: Mutexes (std::mutex) make threads sleep. T-Bricks uses lock-free queues and atomics. Threads exchange data continuously.
3. OS Isolation: Trading algorithms are pinned to physical CPU cores (CPU core pinning). Data always stays in L1/L2 cache. Plus NUMA topology awareness.
Enterprise C++ vs HFT C++
| Aspect | Enterprise C++ | HFT C++ (T-Bricks) |
|---|---|---|
| Containers | std::vector with dynamic growth | std::array, fixed buffers |
| Synchronization | std::mutex | Ring buffers, atomics, lock-free queues |
| Polymorphism | Virtual functions (vtable) | Templates, CRTP (compile-time dispatch) |
| Networking | Linux sockets | Kernel bypass (Solarflare OpenOnload, ExaNIC) |
| Profiling | gdb, valgrind | LTTng (nanosecond tracing without slowdown) |
Hardware Layer
An algorithm is dead without the right hardware. Software and hardware in HFT are a single organism.
| Component | Enterprise IT | HFT (T-Bricks) |
|---|---|---|
| Location | Cloud (AWS, Azure) | Co-location (exchange data centers) |
| Transport | TCP/IP | UDP multicast, microwave links |
| NICs | Gigabit Ethernet | Solarflare/ExaNIC with kernel bypass |
| Logic | CPU (Xeon) | CPU + FPGA (hardware risk control) |
| Latency | Milliseconds | Single-digit microseconds |
What They Trade on T-Bricks
Options Market Making
The platform's historical dominance. When the underlying price (Apple) changes by a cent, the market maker must instantly recalculate the theoretical value of hundreds of related options and update quotes. T-Bricks provides server-side Greeks calculation and volatility surfaces in nanoseconds.
ETF Arbitrage and Liquidity
ETF contains a basket of assets. The algorithm aggregates prices of all components from all venues, calculates iNAV in microseconds, and quotes the ETF on the exchange. If the market price deviates from iNAV — arbitrage opportunity. Window: fractions of a second.
Structured Products
T-Bricks allows investment banks to simultaneously quote hundreds of thousands of structured products without latency degradation.
Order Internalization
Instead of routing a large institutional order to the exchange (which would move the price), the algorithm matches it against other clients or the firm's own liquidity. Result: saved commissions and better prices.
Central Risk (2026): The New Paradigm
In April 2026, Broadridge launched Central Risk and Liquidity Optimization on T-Bricks. The new architecture unifies:
- Smart Order Routing (SOR): Dynamic best-price search across all venues (exchanges, dark pools)
- Agency + Principal merger: Blurring boundaries between brokerage and prop trading
- Unified risk matrix: Centralized monitoring of positions, PnL, and exposure across all asset classes in real time
Comparison
| Feature | T-Bricks (Broadridge) | Bloomberg EMSX | Trading Technologies |
|---|---|---|---|
| Type | Server-side HFT platform | Terminal + EMS | Cloud trading platform |
| Core language | C++ | Proprietary | C++ |
| Custom SDK | ✅ C++ with app source code | ❌ API only | ✅ C++ / Python |
| FPGA support | ✅ (integration) | ❌ | ✅ (Decodex) |
| Co-location | ✅ 150+ exchanges | ❌ | ✅ |
| Centralized risk | ✅ (2026) | Partial | ❌ |
Links
- 🌐 Broadridge Tbricks: broadridge.com/tbricks
- 📄 Broadridge IR (NYSE: BR): broadridge.com/investor-relations
- 🏢 BHFT (prop firm using T-Bricks): bhft.com
Conclusion
T-Bricks is not software for retail traders. It's infrastructure powering the institutional market: options market makers, ETF desks at investment banks, prop firms like BHFT. Modular "Buy AND Build" architecture, source code access to 300+ applications, nanosecond latencies through kernel bypass and FPGA, and now — a unified risk console for the entire firm. Over 18 years the platform evolved from a Stockholm startup to the core of Broadridge — a company processing trillions of dollars daily.
