FXCubic: Liquidity Bridging, Aggregation and Broker Execution
FXCubic develops liquidity bridging, aggregation and execution technology for brokers. Its software sits between trading platforms, external liquidity providers and a broker's internal dealing infrastructure, bringing pricing, routing, risk controls and transaction reporting into a common operating environment. The company provides technology rather than financial services, so its role in a brokerage is the connection and processing layer.
That position makes FXCubic relevant to firms reviewing how client orders reach liquidity, how execution policies differ between account groups and how a dealing desk investigates an exception. Its offering combines detailed configuration with a dedicated deployment model. Recent integrations also show the connectivity extending beyond MetaTrader into additional trading platforms and institutional digital-asset markets.
FXCubic’s official platform-integration page.
Where the liquidity engine fits
A brokerage's execution environment has several distinct jobs: receiving prices, presenting a tradable quote, checking an order against its routing rules, obtaining execution and preserving the resulting records. FXCubic brings these functions together through its liquidity engine and associated platform connections. This allows brokers to manage multiple liquidity sources without treating each connection as a separate operating system.
The company's technology material describes parallel connections to providers for aggregation or backup liquidity. For a broker, the practical question is how the chosen providers, instruments and account groups interact within the configured rules. A second price feed can provide an alternative route, but the broker also needs consistent symbol definitions, permitted order sizes and a clear record of what happened when the primary route became unavailable.
| Capability | FXCubic's described function | Operational application |
|---|---|---|
| Liquidity aggregation | Combines provider market depth and supports volume-based pricing | Build a price stream around available quantity |
| Execution rules | Maps account, group, symbol and order properties to actions | Apply differentiated routing policies |
| Configuration profiles | Stores settings and schedules changes | Prepare rules for different market conditions |
| Risk and reporting | Combines A/B-book monitoring with order-level analysis | Investigate exposure and execution exceptions |
| Dedicated deployment | Provides a separate system that can run on broker infrastructure | Define hosting, access and data responsibilities |
Aggregation based on market depth
FXCubic describes aggregation as combining market depth from liquidity providers into one depth table, then selecting available quantities from individual sources. Orders can be split between providers in parallel, while volume-weighted average price algorithms support customized volume-based feeds. The distinction matters for orders larger than the quantity available at the best displayed price.
A meaningful demonstration should therefore include different order sizes. A small order, a larger order crossing several depth levels and a partially available provider stream reveal how aggregation behaves under different conditions. The broker can compare the displayed quote, the relevant depth snapshot and the resulting execution records rather than relying on a top-of-book spread alone.
Execution assessment needs to connect those capabilities to the proposed environment: the broker's realized fills also depend on available liquidity, provider responses, connectivity and its own configuration. Testing with the intended instruments and order sizes establishes what the proposed environment can deliver.
Rules that reach the account and order level
The visual rule engine maps order properties to prioritized actions. FXCubic lists accounts, groups, symbols, order direction, order type, account net open position, order size and volume over a period among the available inputs. Network address and API-controlled custom variables provide further configuration dimensions.
Available actions include execution mode, processing time, routing, slippage settings, commissions and copy execution. This gives the dealing team a way to express different operating policies within the same system. For example, an instrument-specific route and a client-group rule may both apply to an order; the priority structure determines which instruction governs the outcome.
Configuration depth makes documentation important. The broker needs an intelligible explanation of rule precedence, authorized changes and the recorded reason for an execution decision. Walking through overlapping rules during acceptance testing can expose ambiguity before it reaches production. The objective is a policy that dealers and support staff can explain from the order record.
Scheduled profiles and feed-quality controls
FXCubic configurations can be saved as profiles and changed according to time and day. The company describes profiles for normal, volatile and calm markets, covering settings such as markups, maximum spreads, slippage rules, symbol-inactivity thresholds and B-book protections. Its February 2026 product explanation also discusses dynamic responses to conditions and feed-quality events.
The pricing engine is designed to identify frozen or delayed feeds and remove them from pricing. Smart routing can respond to a provider rejection by attempting another available route before confirming the original trader's order. These capabilities connect monitoring with execution, rather than leaving every exception to a manual response.
For an event-day workflow, the broker can prepare a defined profile, specify when it becomes active and determine how the system returns to normal operation. Acceptance testing should include a feed interruption, a rejection and a conflicting configuration change. Logs and alerts should show which condition triggered the action and which settings were effective at the time.
Risk, synthetic instruments and copy execution
The risk interface allows brokers to monitor A-book and B-book orders together. FXCubic describes manual trading from that environment for hedging, moving positions between providers and reviewing open positions or profit information. This gives a dealing desk a consolidated working view across internal and external execution activity.
Synthetic instruments can be created from instruments already defined in the system. For externally routed synthetic orders, the company states that the individual legs receive confirmation before the main trade is confirmed to the trader. Residual positions can be accumulated and hedged once they reach a tradable quantity. Product design therefore needs to account for leg availability, rounding and the treatment of residual exposure.
Copy-execution tools support forward or reverse copying and volume multipliers, including copying one order into several accounts with different settings. FXCubic also describes basket orders. Brokers assessing these functions should distinguish the technical replication mechanism from the commercial arrangements, permissions and disclosures required for the service they intend to operate.
Reporting that explains an execution
FXCubic's reporting interface provides individual trade analysis and downloadable reports across a chosen period. Listed details include slippage, execution time, liquidity-provider quote snapshots, profit information and the prices visible from the trader's perspective. Historical provider ticks can also be downloaded.
This creates a basis for investigating a specific event. If a client queries an execution, the dealing desk can examine the order, the contemporaneous provider prices and the route used. Aggregate reports then help determine whether an issue was isolated or associated with a particular instrument, provider or period.
Monitoring covers provider connections and latency, symbol idle times, hardware and disk capacity, with interface alerts or email notifications. Operational ownership still needs to be assigned: someone must receive the alert, judge its severity and retain the investigation record. Report retention and exports should be sized to the broker's transaction volumes and review requirements.
Dedicated architecture presented on FXCubic’s official website.
Dedicated architecture and platform connectivity
FXCubic states that each client receives a dedicated version of its system, with deployment possible on the broker's own infrastructure. Its architecture description says client data remains on that local system and vendor access is provided only when the client grants it. The company also describes configuration changes through the interface without restarting the application.
This model gives infrastructure teams a defined role in hosting and connectivity decisions. Server location, provider cross-connections, backups, monitoring and access procedures need to be agreed as part of deployment. A dedicated application establishes separation between client systems; the reliability of an individual installation still depends on its infrastructure and operating arrangements.
The platform page identifies MT4 and MT5 connectivity through in-house plug-ins and gateways, with order processing configurable by account, group or symbol. FXCubic's broader published product description also identifies FIX connectivity for other platforms and liquidity distribution. Compatibility discussions should use the exact platform version, server environment and required message flow.
What the 2026 integrations add
On March 17, 2026, FXCubic announced integration of its liquidity connectivity and risk technology with B2BROKER's B2TRADER platform. The announcement describes configurable execution parameters and routing for a multi-asset environment, including cryptocurrencies, CFDs and perpetual futures. For brokers using B2TRADER, this extends the platform choices through which FXCubic's processing layer can be used.
A September 14, 2026 announcement added connectivity to LMAX Group's institutional perpetual-futures offering through FXCubic Bridge. The business significance is an additional institutional market connection within the bridge ecosystem. It does not mean every broker automatically has the same instrument access, commercial agreement or permission to distribute those products in every jurisdiction.
Both announcements illustrate expansion of the connectivity network. In implementation planning, the broker should map the actual venue, instrument specifications, account relationship and reporting requirements to its intended product. A named integration is a useful starting point for that discussion, while the executable service scope belongs in the agreed configuration and provider arrangements.
Evaluating FXCubic around an operating workflow
FXCubic is most relevant when a broker needs greater control of the connection between prices, execution rules and dealing operations. Its combination of aggregation, detailed rule settings, dedicated deployment and order-level reporting gives procurement teams several concrete areas to examine. The reviewed product pages do not establish a universal price, so licensing, support, connections and migration services should be specified in a tailored quotation.
A useful evaluation follows one instrument and account group from provider feed to client quote, order submission, routing, fill and reconciliation. Adding an interrupted feed, a scheduled profile change and an execution query shows how the same environment handles exceptions. That sequence gives technology, dealing and operations staff a shared basis for deciding how FXCubic fits the brokerage's execution architecture.
Subscribe Now
