Centroid Solutions for Forex Brokers: Bridge, Liquidity & Risk Architecture

Contents

• The product portfolio, in current naming
• Reference architecture
• CS 360: connectivity, execution and liquidity management
• C 24: what actually belongs to the risk suite
• CS Drive: hosting and co-location
• PropShield and prop-firm exposure
• Naming corrections and attribution discipline
• Multi-asset scope and symbol discipline
• Migration and parallel running
• Where Centroid fits — and where it does not
• CTO and operations evaluation checklist
• FAQs

The Product Portfolio, in Current Naming

Reference Architecture

  Liquidity providers (any number, your choice)
                    │  FIX
                    ▼
  ┌──────────────────────────────────────────────┐
  │  CS 360  (connectivity & execution engine)   │
  │                                              │
  │  pricing · liquidity management              │
  │  aggregation & redistribution                │
  │  execution & routing                         │
  │  execution risk controls                     │
  │  real-time exposure & P&L monitoring         │
  │  reports                                     │
  └───┬─────────────────┬────────────────┬───────┘
      │                 │                │
      ▼                 ▼                ▼
  Trading           FIX API          Downstream
  platforms         clients          takers
  (MT4/MT5 etc.)                     (redistribution)
      │
      ▼
  Client terminals

  ── separate products ──────────────────────────
  C 24        real-time risk suite: market-risk
              measurement · simulations &
              forecasting · recommended actions
  CS Drive    hosting: Equinix LD4 · NY4 · TY3 · SG3
              co-location & cross-connects
  PropShield  cross-firm intelligence for prop firms

The dashed separation is deliberate. Brokers regularly assume that buying the engine brings predictive risk analytics with it. On Centroid's own product pages those are distinct: CS 360 covers execution risk controls and real-time exposure and P&L monitoring, while simulation, forecasting and recommended actions belong to C 24.

CS 360: Connectivity, Execution and Liquidity Management

CS 360 is presented as a centralised environment for managing pricing, liquidity and execution. Its documented capability set includes connecting to any number of liquidity providers of your choice, trading platforms and FIX API clients; managing, customising and redistributing liquidity on your own terms; institutional-grade execution and routing; real-time monitoring of exposures and P&L; comprehensive risk controls and reports around execution; and resilience through redundant low-latency infrastructure with fail-over, data backup and enterprise-level DDoS protection.

The redistribution capability is the most commercially interesting part for a subset of firms. If your model includes serving downstream takers — a prime-of-prime arrangement, a group serving affiliated entities, or a broker distributing tailored streams — then an engine designed to customise and redistribute liquidity is doing something a plain platform bridge is not. Provider mix, tiering and downstream terms are the commercial work around it, covered in liquidity solutions and our aggregator evaluation checklist.

On the platform side, connectivity into MetaTrader does not remove platform work. Symbol specifications, group execution modes, markup placement and session configuration remain platform administration, and the platform-side mechanics are set out in MT5 for forex brokers.

C 24: What Actually Belongs to the Risk Suite

C 24 is described as a real-time risk management suite whose documented focus is measuring the level of market risk and improving risk-adjusted performance, running complex simulations on trading data with forecasting capabilities, producing recommendations for actions, and issuing risk alerts and analytical insights against different market conditions.

Two implications for a brokerage. First, procurement: if your requirement is forward-looking risk analytics, that is a C 24 conversation and should be scoped and priced as one. Second, governance: a recommendation engine is not a decision-maker. Somebody must own the limits, the escalation authority and the record of what was done and why. That is the function of RiskMan as a consolidated oversight layer, and of a 24/7 dealing desk where continuous cover is not available internally. The judgement question itself is examined in running a dealing desk.

CS Drive: Hosting and Co-location

CS Drive is the infrastructure product rather than the software engine. Centroid names data centres in Equinix LD4 (London), NY4 (New York), TY3 (Tokyo) and SG3 (Singapore), and describes allowing clients to co-locate and cross-connect their trading servers in the same suites as their trading engine and liquidity providers, for performance and price-feed stability.

This matters because feed stability complaints are frequently topology problems. If your trade server sits in one region, your engine in another and your main provider in a third, no amount of software tuning recovers the difference. Placement decisions belong with platform administration and market data planning, not after go-live.

PropShield and Prop-Firm Exposure

PropShield is described as an anonymous shared-intelligence network allowing proprietary trading firms to prevent cross-entity exploits — the practice of running the same abusive strategy across multiple firms that individually cannot see the pattern. For funded-trader operators this is a category of risk that platform tooling alone does not address, and it belongs in the same conversation as evaluation-phase rule design and payout controls in prop firm technology and prop firm operations.

Naming Corrections and Attribution Discipline

Multi-Asset Scope and Symbol Discipline

CS 360 is presented as multi-asset, and that is the part of an engine evaluation brokers most often under-test. Multi-asset support at the engine is only useful if the corresponding contract specifications, margin treatment and session definitions are correct at the platform, and if your provider actually streams the instrument at a size you can execute. In practice a new asset class is four pieces of work: a source that prices it, engine-side mapping and markup, platform-side symbol and margin configuration, and a support and dealing team briefed on how it behaves at open and close.

We would test each new class end to end before it appears in any client group: quote continuity across session boundaries, margin figures against a worked example, swap and financing application, rejection behaviour at size, and how the instrument appears in reporting. Where that discipline is missing, the first symptom is not an execution failure but a stream of client disputes about margin and overnight charges that nobody can reconcile.

Migration and Parallel Running

Most Centroid deployments are replacements, not first installations, and the replacement is where risk concentrates. A defensible sequence looks like this: agree the target routing and liquidity design in writing; build it in a test environment with your real symbol set; run the new engine in parallel on a limited group or a subset of symbols; compare fills, rejections and spreads against the incumbent over a full week including a high-volatility session; then cut over group by group with a rehearsed rollback and a named decision-maker for each step. Open positions and pending orders need an explicit plan of their own.

Two things are worth deciding before the first migration call. Who owns configuration after go-live — your team or the vendor — because that determines how quickly you can change a routing rule at 02:00. And what the exit looks like, since an engine you cannot leave becomes a commercial constraint rather than a technology choice. Sequencing, rehearsal and rollback planning for changes of this type is scoped as brokerage technology migration.

Where Centroid Fits — and Where It Does Not

CTO and Operations Evaluation Checklist

FAQs

What is CS 360?

Centroid Solutions' connectivity and execution engine — the product formerly called Centroid Bridge — described as a high-performance multi-asset institutional-grade engine that connects liquidity providers, trading platforms and FIX API clients and allows a firm to manage, customise and redistribute liquidity.

Is Centroid Bridge the same as CS 360?

Yes. CS 360 is the current name; Centroid Bridge is superseded naming that still circulates in older third-party articles.

What does C 24 do that CS 360 does not?

C 24 is the real-time risk management suite: market-risk measurement, complex simulations with forecasting, recommended actions and analytical risk alerts. CS 360 provides execution risk controls and real-time exposure and P&L monitoring, not predictive analytics.

Is Centroid a liquidity provider?

No. It is a technology and infrastructure provider. CS 360 connects to the liquidity providers you choose; the commercial relationships remain yours.

What is CS Drive?

Centroid's server hosting and infrastructure solution, with data centres named in Equinix LD4, NY4, TY3 and SG3, allowing clients to co-locate and cross-connect trading servers alongside their engine and providers.

Is Centroid suitable for prop firms?

Its portfolio includes PropShield, an anonymous shared-intelligence network aimed specifically at preventing cross-entity exploitation between proprietary trading firms, in addition to the engine and risk suite used by brokers.

Related Research

This guide is part of a four-part comparison of bridge and liquidity technology used by brokers:

• PrimeXM for Forex Brokers: XCore, Liquidity Integration & Operations
• oneZero for Forex Brokers: Hub, Routing, Liquidity & Risk Integration
• FXCubic for Forex Brokers: Private Bridge Architecture & Aggregation
• MT5 for Forex Brokers: Server Setup, Administration, CRM, Liquidity & Manager API