FXCubic: liquidity aggregation, execution rules, platform links and private deployment

FXCubic supplies the execution-connectivity and dealing-control layer used by brokerages. Its product combines liquidity aggregation, configurable routing and operational monitoring. It is not itself the liquidity counterparty merely because its system connects to liquidity providers. The company explicitly describes its business as technology rather than financial services.[8]

The architectural distinction is consequential: the bridge can influence the route and treatment of an order, whereas the financial contract determines the exposure that results. A brokerage comparing suppliers should identify whether it is replacing only connectivity, its dealing controls, or both. Combining those changes in one migration increases the number of behaviours that must be tested.

The platform page describes native MT4 and MT5 connection methods, support for multiple platform servers and a proprietary FIX API. It also describes distributing liquidity to other entities. Technical distribution capability is not the same as permission to act as a financial intermediary or to redistribute every data source.[3]

The B2TRADER announcement broadens the documented platform set beyond the MetaTrader connection paths. It discusses crypto-related trading workflows and configurable execution controls. This supports recording an integration, not treating advertised product coverage as identical across every connected broker, instrument or regulatory jurisdiction.[6]

No complete public cash tariff, setup-fee schedule or universal minimum commitment was established from the inspected official pages. The commercial entry point is a direct enquiry. An enterprise quote should identify the licensed instance, platform connections, support and any separately supplied infrastructure rather than treating “bridge” as one interchangeable item.[5][2]

Private hosting makes infrastructure an especially important cost boundary. The architecture page says the system can be hosted independently and that the supplier can suggest hosting arrangements. That does not make servers, connectivity, backups or operational support free. Nor does it establish that a hosting provider’s availability promise is automatically part of the software agreement.[2]

The deployment model places the broker’s own instance at the centre of the operating design. The provider describes vendor access as something the client grants rather than an automatic consequence of centralised hosting. A practical handover should therefore document administrative roles, access revocation, patching responsibilities and the recovery owner.[2]

Before cutover, a broker needs a controlled copy of its routing rules and an agreed baseline for client, group and symbol behaviour. It should test rejects, disconnections, stale prices and a restart with outstanding orders. These are acceptance criteria suggested by the product’s role; they are not a claim that FXCubic publishes one universal migration process or that such a migration was performed here.

A particularly important distinction is between changing the software and changing execution policy. If a migration also alters mark-ups, routing or internalisation rules, a before-and-after comparison is no longer measuring only the new connection. Retaining an approved configuration record makes it possible to identify which layer caused a changed outcome.

The contact page distinguishes its London business-contact location from the registered address shown in the footer. Public contact information does not establish staffed emergency hours. The broker’s support schedule should identify an after-hours escalation route, severity definitions and who is authorised to alter a live execution rule.[5]

FXCubic’s website states that it does not provide financial services. It is therefore inappropriate to attach retail broker protections, deposit coverage or a liquidity-provider licence to the software company. Equally, using its tools does not prove that a customer’s dealing arrangement is compliant or that every connected counterparty is authorised.[8]

The distinction is most visible in a system that can support different routing and internalisation approaches. Software flexibility is a capability, not a recommendation to adopt a particular execution model. The broker must determine which configuration is consistent with its client terms and applicable obligations; the vendor’s growth or profitability language is not used as independent evidence.

Banyan Software announced its acquisition of FXCubic on 15 November 2023 and identified the business as founded in 2016. The transaction is a corporate-ownership fact, not evidence of a change to every customer’s contract or an increase in regulatory protection. FXCubic remains the relevant product-company identity in this directory.[7]

The official company material positions FXCubic around retail and institutional brokerage technology. This profile accordingly treats the platform adapters, aggregation and risk functions as parts of one provider rather than separate directory companies.[4]

Operator

FXCubic Ltd

Service scope

A technology-provider reference covering liquidity-bridge architecture, platform interfaces, customer-controlled deployment, commercial boundaries and operational evidence.

Customer types

Retail brokerages; Institutional brokerages; Liquidity distributors

Delivery

On premises; API

Pricing publication

Quote only

Platforms

MT4 plug-in; MT5 gateway; FIX API; B2TRADER integration

Implementation

Private-instance deployment with customer-defined hosting and access arrangements.

Support

Company contact routes are public; negotiated emergency support was not verified.

Permissions and regulatory scope

The company expressly identifies itself as a technology supplier rather than a financial-services provider.

Provider metadata checked 20 Oct 2026Source 1Source 2Source 3Source 4Source 5Source 6Source 7Source 8

The technology description includes account-level rules, scheduled configuration profiles, copying controls, exposure views and downloadable execution/price analysis. These are provider-described features, not a measured assurance of uninterrupted prices or loss-free execution. Marketing expressions about eliminating slippage or protecting brokerage profit are not adopted as performance conclusions.[1]

An informative operational review would preserve the original price, routed instruction, acknowledgements and final execution together. The aim is to distinguish market movement, a rejected route, a rule-driven delay and a display problem. A dashboard alone cannot settle that attribution without consistent timestamps and identifiers. This is why evidence retention and export access belong in the commercial discussion, even when the initial purchase is described simply as a liquidity bridge.