Integral FX: Liquidity, Pricing and Risk for Brokers

Integral provides cloud-based trading infrastructure that connects liquidity, pricing, execution, distribution and risk management. Its Integral FX platform supports configurable workflows for FX, CFDs and precious metals. For a brokerage, the central proposition is the ability to coordinate these functions under its own operating rules, whether it adopts the full platform or adds selected modules to an existing trading stack.

Integral FX product page. Image: Integral.

A platform organized around the trading lifecycle

Integral FX is presented as a workflow automation and orchestration platform. Its published instrument coverage includes spot FX, forwards, swaps, non-deliverable forwards, precious metals and CFDs. The distinction between instrument support and a production-ready service matters: a broker still needs appropriate liquidity arrangements, product definitions, client permissions and downstream processing for each market it intends to offer.

The platform can be deployed as a complete technology stack or as modular services. That gives firms two different implementation paths. A brokerage replacing fragmented infrastructure can consider a broader migration, while one retaining its client interface or existing risk system can assess a narrower connection. The practical question is where Integral becomes responsible for a trading decision and where that decision passes back to another application.

For example, an incoming order may require a client-specific price, a credit check, a routing decision, a hedge and a booking message. Treating those as a single controlled workflow makes it easier to identify the cause of a rejected or delayed trade. It also makes configuration governance important: changing a pricing rule should not inadvertently alter the hedging policy for a different customer group.

Liquidity, pricing and execution serve different purposes

Integral lists liquidity aggregation, an execution management system and a price engine as separate modules. Aggregation concerns the sources used for price discovery and execution; the price engine creates the prices offered to clients; the EMS handles execution logic, including configurable smart order routing, algorithms and order types. A broker should evaluate the hand-offs between these functions rather than treat connectivity alone as proof of execution quality.

The published platform description supports tailored pricing across products and synthetic strategies. This is relevant where different client segments require different spreads, depth or trading conditions. An institution serving both API clients and screen traders may need separate price streams while retaining a consistent view of the exposure generated by those streams.

During a demonstration, representative orders should be followed from the incoming quote through the final booking. Useful cases include insufficient available liquidity, a stale price, a partial execution and a rejected hedge. The assessment should establish which component owns each decision, what timestamps are recorded and how the brokerage reconstructs an execution when a client queries it. These are implementation acceptance criteria, not promises of a particular fill rate.

Distribution and white labels extend the same operating model

Integral describes distribution through APIs, branded white-label services and third-party platforms. Its white-label offering combines configurable interfaces with trading workflows. This allows a brokerage to consider how multiple client channels can use common pricing and risk infrastructure, while still presenting different interfaces or services to different customer groups.

A branded interface is only one part of this arrangement. Firms need to establish how users are provisioned, which products and accounts they can access, and how their activity is linked to the broker's own records. If an existing CRM remains the system of record for client relationships, the integration must define how account changes reach the trading environment and how execution information returns to operations.

Channel expansion should therefore be tested as an operational change. Adding an API client may introduce different traffic patterns and support requirements from adding another web user. Product availability, quote permissions and risk limits should remain deliberate settings, with responsibility assigned for approving changes and resolving inconsistencies.

MT4 and MT5 connectivity has a concrete deployment model

Integral's bridge documentation describes an MT4 plugin file or an MT5 executable, with the remaining functionality running in the cloud. It says symbol, security and account settings can be detected and configured with limited broker input. This is more useful for implementation planning than treating the service as requiring no local component at all.

The company describes prices arriving through the plugin rather than the native data feed, supported by rate filtering intended to reduce unnecessary updates and platform load. Monitoring covers CPU and memory use, latency and interruptions in symbol-specific data flows. Flexible drop-copy functionality supplies additional visibility into account activity and execution records.

Symbol-level controls include bid/offer spreads, depth aggregation such as best price or volume-weighted average price, and time-in-force settings. The published description also covers institutional order handling, including FOK and IOC. A brokerage should verify the mapping between its platform's order behaviour and the downstream execution instruction, especially where a partial fill, expiry or cancellation can affect the client position.

Acceptance testing should include the broker's actual symbol naming, contract sizes, decimal precision and account groups. Reconnection after a network interruption also deserves explicit testing: operations must be able to distinguish an unacknowledged request from a completed trade whose confirmation arrived late. Lightweight deployment reduces one kind of implementation burden; it does not remove the need for reconciliation and rollback planning.

Risk management connects exposure, hedging and credit

Integral's risk offering covers internalization, warehousing and hedging through configurable, event-driven rules. The published capabilities include portfolio-level net exposure, event-based auto-hedging and execution approaches such as TWAP and TWAP+. Risk can be analyzed across dimensions including currency, product, channel, customer segment and value date.

These dimensions matter because two positions that appear offsetting in aggregate may still create different settlement or product exposures. A brokerage needs a clear definition of what it nets, what it retains and what it hedges externally. The usefulness of the system depends on whether those rules match the firm's operating model and whether staff can explain an automated action after the event.

Credit controls include alerts as limits approach, trade pre-qualification and integration with external credit systems. The operational design should specify the authoritative source of limits, the frequency of updates and the response when a credit service becomes unavailable. Market-risk capacity and counterparty credit availability are related constraints, but they should not be treated as interchangeable.

Integral also describes automated booking, reporting, notifications, STP connections, role-specific dashboards and audit trails. These features connect dealing decisions with operational oversight. In practice, a good pilot should demonstrate an exception from initial alert through investigation and resolution, including who can override a rule and how that action is retained for review.

Infrastructure and interfaces shape the integration

According to Integral's product FAQ, supported connectivity options include FIX, ITCH, REST and WebSocket. The appropriate interface depends on the workflow and the data exchanged; a list of supported protocols does not establish that every operation is available through every interface. Teams should obtain the relevant specifications and agree message ownership, error handling, sequencing and recovery behaviour before committing to a migration plan.

Integral identifies Equinix NY4, LD4, SG1 and TY3 as hosting locations. Proximity to a liquidity provider can be relevant to connectivity design, but a data-center name is not a guarantee of a particular end-to-end latency. Client access, cross-connect arrangements, processing paths and the broker's own applications all contribute to the measured result.

The company states that its systems and processes undergo independent audits including SOC 2 Type II. Procurement teams should review the applicable report, service scope and customer responsibilities. Availability targets, incident escalation, recovery objectives and change notifications belong in the service assessment alongside security controls.

Commercial assessment should follow the selected scope

Integral says its SaaS technology uses a fixed subscription model rather than a brokerage fee for technology usage. This can make technology budgeting more predictable, but it should not be interpreted as eliminating liquidity, credit, connectivity or other third-party costs. The quotation should identify included modules, environments, support and any additional integration work.

Where Integral fits in a brokerage technology stack

Integral is most relevant to a brokerage evaluating the connected trading layer: how it obtains prices, distributes them, executes orders and manages the resulting exposure. The modular approach allows that discussion to start with a specific gap, such as MT4/MT5 connectivity or risk orchestration, and expand only when the integration case supports it.

A useful pilot follows a representative client transaction through pricing, execution, hedging and booking, then repeats the journey under failure conditions. The objective is to show that the chosen configuration produces understandable, recoverable outcomes for dealing and operations. That provides a firmer basis for supplier selection than the number of modules listed in a product catalogue.