Gato gHubOpening Markets, Unlocking Possibilities

    Gato gHub

    One order-routing network for buy-side and sell-side firms. It links you to brokers, venues, and liquidity providers. All through a single connection.

    gHub high-level system architecture
    At a Glance
    • 01

      Single connection

    • 02

      Fast time-to-market

    • 03

      Global scalability

    • 04

      Performance & security

    • 05

      Built-in compliance

    Capabilities

    Industry Standard FIX Protocols

    Full support for major FIX protocols across asset classes and counterparties.

    • Multi-version FIX support
    • Customizable message transformation

    Secure Connectivity

    Hardened transport built for institutional trading.

    • X-connect, VPN and TLS 2.0 encryption
    • Auto-reconnect with zero manual intervention

    DropCopy Send & Receive

    Full lifecycle DropCopy with NOE support.

    • Real-time send and receive
    • Native FIX message queuing

    Multi-Asset Coverage

    One platform for equities, options, and complex orders.

    • Equities, Options and Multi-leg Options
    • Unified routing across asset classes

    Third-Party Integration

    Plug into existing engines over FIX or APIs.

    • FIX and REST API connectivity
    • Flexible cloud or on-prem deployment
    Next step

    See gHub in action

    Walk through gHub with our team on a live environment using your workflows, venues, and reporting obligations.

    More in Trading & Execution

    Continue exploring the family

    About gHub

    How firms use gHub

    gHub is where order management and FIX connectivity meet: one session layer to exchanges, ATSs, market makers, and clearing firms, and one order state machine holding the parent and child orders that flow across it.

    Firms usually arrive at gHub for one of two reasons. Either they are maintaining a growing set of point-to-point FIX sessions, each with its own certification, tag dialect, and drop-copy quirks, or their OMS and their routing layer disagree about order state often enough that operations spends the morning reconciling fills. gHub collapses both problems into a single hub: venue profiles and certification templates ship preconfigured, sessions are monitored with sequence-number recovery and automatic resend handling, and every order event is written once to a lineage that risk, reporting, and reconciliation all read from.

    • Managed FIX sessions with certification templates per venue and counterparty.
    • One order state machine covering parent orders, child routes, and fills.
    • Drop-copy ingestion so an incumbent OMS can stay in place during migration.
    • Sequence recovery, resend handling, and per-venue latency and reject monitoring.
    • Normalised execution records shared with risk, reconciliation, and CAT reporting.

    Implementations usually start with a connectivity audit. We list every session the firm runs today, the venue on the other end, the FIX version and tag dialect in use, and who owns the certification. That list is normally longer than the firm expects, and it is the reason connectivity work drifts.

    From there, sessions move onto gHub in waves rather than at once. Flow runs in parallel until executions match on both paths, then the old session is retired. Because gHub keeps one lineage per order, the comparison is a query rather than a spreadsheet exercise, and reporting downstream never sees a gap.

    Can gHub run alongside my existing OMS?

    Yes. gHub is frequently deployed first as a connectivity and routing hub in front of an incumbent OMS, consuming drop-copies and normalising executions for downstream risk, reconciliation, and CAT reporting.

    Firms that later consolidate onto gHub's order management do so once flow and reconciliation match in parallel running.

    Which FIX versions and venues are supported?

    FIX 4.2, 4.4, and 5.0 SP2 for order routing and drop-copy, with venue-specific tag mappings maintained on our side.

    Connectivity covers US and international equities, listed options, futures, and FX destinations, including brokers, exchanges, ATSs, market makers, and clearing firms.

    How is latency handled?

    gHub deploys cloud or on-premise, close to the venues that matter for your flow, with a routing path engineered to keep pre-trade risk checks inline rather than in a separate hop.

    Session health, round-trip timings, and rejects are surfaced per venue so degradation is visible before it becomes a fill problem.

    What happens during a session outage?

    Sessions reconnect automatically with sequence-number recovery, and orders in flight are reconciled against venue state rather than assumed.

    Operations sees a single blotter showing which orders are confirmed, working, or unknown, which is the difference between a controlled recovery and a manual phone-in.

    How long does a typical gHub onboarding take?

    Connectivity for a first venue is usually live in weeks, not quarters, because venue profiles and certification templates already exist.

    The variable is your side: how cleanly current order and execution data can be extracted for parallel comparison.

    Can we keep our own smart order router?

    Yes. gHub can act purely as the session and order-state layer while routing decisions stay with your existing logic, or it can run Gato routing.

    Firms often keep their router and consolidate only sessions and state first.