Tools for Brokers: Trade Processor, Liquidity Bridging and Risk Tools
Tools for Brokers develops trading infrastructure for retail brokers, hedge funds and proprietary trading firms. Its Trade Processor liquidity bridge connects trading platforms with liquidity providers, while the wider TFB ecosystem covers plugin administration, money management and technical operations. For a brokerage running several platforms, the central proposition is a common execution layer: liquidity connections, routing decisions and operational data can be managed together rather than rebuilt for each trading interface.
The product range spans both the dealing desk and the technology team. Trade Processor handles connectivity and execution; TFB Toolbox administers applications and plugins; TFB PAMM supports percentage-based money management; and TFB Service covers infrastructure maintenance and migration. These components address different stages of the trading workflow, so their relevance depends on the broker’s operating model and existing systems.
Trade Processor liquidity bridge and execution engine. Source: Tools for Brokers.
Trade Processor as a shared execution layer
Trade Processor supports MetaTrader 4, MetaTrader 5, cTrader, Match-Trader and DXtrade. TFB also describes REST and FIX API connectivity for other trading platforms. This makes the bridge relevant to firms that operate more than one front end, as well as businesses building connections to proprietary applications or offering liquidity to other brokers.
The architectural distinction matters. A trading platform manages the user-facing trading environment, while a liquidity bridge coordinates the connection between that environment and execution destinations. Keeping those roles separate allows a broker to review its liquidity relationships without treating every change as a replacement of the trader-facing platform. It also creates a shared point at which the dealing team can examine execution rules and data.
A multi-platform deployment still needs a consistent instrument map. Symbol names, contract sizes, price precision, trading sessions and volume increments must agree across the platform, bridge and liquidity connection. A practical rollout starts with a representative set of instruments and order types, then expands once the complete order lifecycle has been reconciled.
Liquidity aggregation and provider connectivity
TFB says Trade Processor connects with more than 100 liquidity providers and allows clients to request connections to their preferred providers. Its private aggregation pools let a broker combine selected liquidity relationships within the same execution environment. The product page also lists six aggregation modes, giving dealing teams several ways to organise available liquidity.
A connectivity catalogue is distinct from an executable liquidity agreement. The providers a broker can actually use depend on commercial onboarding, credit arrangements, available instruments and the configuration of each connection. The useful comparison is therefore between the broker’s intended liquidity mix and the bridge’s ability to connect, route and report on that mix.
For example, a firm may want different provider pools for different instrument groups or client segments. The operational requirement is to make those choices explicit, then compare execution results across the pools. Access to several destinations is most useful when the dealing desk can explain which route an order followed and why that route matched the configured policy.
Routing, continuous execution and volume consolidation
Trade Processor combines routing configuration with tools for handling larger orders. TFB describes Continuous Execution as splitting a large order into smaller parts, executing those parts over time and calculating a volume-weighted average price for the combined result. This gives brokers a mechanism for controlling how an order reaches available liquidity instead of sending its entire size in one instruction.
The execution trade-off is practical: distributing an order changes the relationship between completion time and available depth. A dealing team should compare completed volume, execution duration and the final average price under representative conditions. These measures are more informative than treating order splitting itself as evidence of a better outcome.
Volume Consolidation addresses a different task. TFB describes the feature as consolidating positions across liquidity providers, including an end-of-day use case intended to reduce exposure and swap costs. It belongs in the broker’s position-management workflow, alongside reconciliation and funding, rather than being confused with the execution of a single client order. The appropriate schedule and provider scope depend on the firm’s liquidity arrangements.
Connecting trader intelligence with execution decisions
Trade Processor × DEXA links trader classification to execution controls. In TFB’s description, DEXA analyses changing trading behaviour and classifies flow, while Trade Processor applies that information to routing, A-book/B-book allocation and risk decisions. The integration connects an analytical input with the system that carries out execution policy.
The business application is a more responsive dealing workflow. Instead of periodically reviewing a client segment and manually reproducing changes elsewhere, a broker can design rules around the classification supplied to the execution engine. The important implementation detail is the mapping between a classification and a permitted action: the same analytical signal need not trigger the same response for every instrument, account or business model.
TFB presents the classification as AI-powered. That describes the vendor’s approach, not a published independent accuracy result. A controlled deployment can compare proposed decisions with actual trading behaviour before broad automation, retain an explanation of rule changes and give authorised staff a clear intervention process. These controls help the dealing desk understand the relationship between a signal and the execution decision it produces.
TFB risk-management product page. Source: Tools for Brokers.
Risk tools around the bridge
The bridge includes A/B-book switching, real-time data monitoring and a Backup LP function. TFB describes Backup LP as rolling execution over to a backup provider when the primary provider becomes unresponsive. Its risk-management offering also includes dynamic leverage tools and controls over bonus-credit use.
These functions operate at different points in the workflow. A backup connection deals with provider availability; routing and book allocation deal with execution policy; dynamic leverage changes the relationship between position exposure and margin. A broker benefits from treating them as separate controls with named owners, rather than combining them into one undifferentiated risk setting.
TFB offers cloud hosting and installation on the client’s site for Trade Processor. Deployment planning should therefore connect the hosting choice with monitoring, access rights, maintenance and incident response. For a backup route, testing should include the transition itself and the subsequent reconciliation of orders and positions, not simply whether a second connection is present.
Reporting and synthetic instruments
Trade Processor includes reporting and data-management capabilities, while TFB’s broader monitoring offering describes real-time alerts, internal analytics and regulatory reports. For operational teams, the most useful reporting path follows an order from receipt through routing and execution to the resulting position. This connects dealing decisions with the records used by finance, support and oversight functions.
The platform also supports synthetic symbols for constructing currency pairs or indices. This provides a product-configuration tool for brokers developing their own instrument range. The operational work includes defining the calculation, source prices, trading schedule and behaviour when an input is unavailable. A synthetic instrument needs consistent specifications across pricing, execution, account statements and the trader-facing description.
Reporting and product configuration meet at reconciliation. If a broker introduces a synthetic symbol or changes a route, the resulting activity must remain interpretable in its reports. Testing a small group of representative trades gives operations staff a concrete way to check that naming, quantities and prices remain consistent through the workflow.
Where PAMM, Toolbox and technical services fit
| Component | Published role | Operational focus |
|---|---|---|
| Trade Processor | Liquidity connectivity, aggregation, routing and execution | Provider pools, execution rules and position reconciliation |
| TFB Toolbox | Web console for plugins and applications | Configuration, access levels, live logs and monitoring |
| TFB PAMM | Percentage-based money-management allocation | Manager selection, fee allocation and statements |
| TFB Service | Technical maintenance, migration and automation | Server settings, data continuity and ongoing platform operations |
TFB Toolbox brings plugins and applications into a web interface. The vendor describes role-based access, four access levels, live logs, monitoring and controls for turning applications on or off. This is particularly relevant when several employees administer the same environment: responsibility for configuration can be separated from observation and routine support.
TFB PAMM serves a different business requirement. It supports a pool of money managers, percentage-based profit distribution, automated reports and statements, performance-fee allocation and multiple fee levels. For a broker offering managed-account services, the integration question is how allocations, fees and account reporting fit its existing account structure. PAMM is a service-delivery component, rather than another liquidity-routing mode.
TFB Service covers initial server configuration, database migration, account archiving, historical-chart work and changes to symbols, accounts and groups. The ecosystem page lists migration examples including MT4 to MT4, MT4 to MT5 and MT5 to cTrader. This makes technical services relevant to firms expanding their platform mix or maintaining an established installation, alongside firms implementing the bridge for the first time.
Planning a deployment around the broker’s workflow
A useful implementation sequence starts with connectivity, then moves to execution rules, reporting and operational ownership. The first stage identifies platforms, instruments and intended providers. The next stage defines routing and allocation behaviour. Reporting then checks whether the resulting transactions can be traced and reconciled. Only after that foundation is stable should broader automation be introduced.
Representative testing should include partial execution, a provider interruption, larger orders and a normal end-of-day reconciliation. Where DEXA is included, the same exercise can trace a classification through to the corresponding rule. Where PAMM is included, it should extend to allocations and fees. Each test should produce an observable result that the responsible business team can review.
TFB advertises onboarding assistance and 24/7 technical support, with a customer success manager for ongoing projects. The practical value of that support comes from connecting it to an agreed operating process: who can change configuration, who investigates an execution discrepancy and which information is available during an incident. For brokers combining multiple platforms and liquidity relationships, this operational structure is as important as the initial connection.
Subscribe Now
