MarketFactory Whisperer and Reflector for FX Trading

MarketFactory supplies institutional foreign exchange connectivity and pre-trade risk technology. ION presents two products with distinct roles. Whisperer gives trading applications a common interface to external FX venues and liquidity providers. Reflector checks proposed orders against market and credit limits across venues and proprietary platforms. The distinction matters for buyers: connecting a venue is an engineering project, while deciding which orders are permitted is a risk policy decision that must work even when several venues are active at once.

Whisperer and the venue adapter problem

Institutional FX venues differ in their session behavior, instrument identifiers, supported instructions and responses. A common interface can reduce the number of adapters a trading team builds and maintains. ION lists connectivity to more than 150 APIs and points of presence in Chicago, New York, London, Singapore and Tokyo, using the labels CHI, NY4, LD4, SG1 and TY3. For procurement, the meaningful unit is the specific venue, endpoint, instrument and workflow required by a desk. A broad connection catalogue does not establish that a given venue supports every order type or is available at every network location.

Begin with the actual flow. A bank pricing engine may need to publish streaming prices to selected clients. A buy-side execution system may need to request quotes, compare responses and accept one within its validity window. A systematic desk may need to subscribe to a central limit order book and manage resting orders. These flows share network infrastructure but differ in how prices are displayed, when an order becomes firm and what the application must do after a disconnect. Test the venue behavior through the interface using production-like messages.

Instrument and workflow coverage

The Whisperer product page lists spot, forwards, non-deliverable forwards and swaps, as well as workflows such as request for quote, request for stream and executable streaming prices. It also describes maker and taker access, central limit order books and support for selected advanced order types and algorithms. Evaluate the combination that matters for each deployment. For an NDF, confirm how the API represents the fixing date, settlement date and settlement currency. For a swap, test how both legs are submitted and reported and how a failed submission is surfaced to the application.

Request a conformance matrix that identifies native venue features, normalized fields and any venue-specific extensions. Include a test for a requested instruction that the destination cannot accept. The trading application should receive an explicit response that operations can interpret. When a venue changes a protocol or adds a product, document who updates the adapter, what the change notice includes and how the desk tests the change before moving it into production.

Reflector pre-trade controls on the ION product page

Reflector and cross-venue risk limits

ION describes Reflector as a real-time pre-trade control layer with checks for net open position, daily settlement limits and pending orders. Its materials also list order-size and rate checks, configurable alerts and administration through a web interface or REST API. In a multi-venue setup, a desk can have several outstanding orders that would together consume more capacity than any one order suggests. A useful test sends concurrent orders to different venues close to a configured limit and examines how pending exposure is counted.

Use cases should be specific to the firm's operating model. A prime broker may want limits aligned to client and trading entity. An eFX desk may want group and currency-pair controls across strategies. A systematic fund may want size and order-rate limits that contain a malfunctioning strategy. Validate which controls the proposed configuration can express and how netting, margin or currency conversion is defined. Also test rejection, partial execution, cancellation and duplicate reports so operations can determine when capacity is reserved and when it becomes available again.

Measure latency where it matters

ION publishes microsecond figures for Whisperer and Reflector. Treat them as vendor figures for the respective products and ask for the exact test setup. The time observed by a desk can include application logic, network distance, risk checks, queuing and venue processing. Define measurement points for each segment and capture timestamps from both sides of the handoff. Compare normal sessions with peak message rates and recovery after a disconnect. A small internal processing delay is meaningful only when the full order path meets the desk's requirements.

Resilience tests should cover connectivity and risk state together. Simulate a venue going offline after an order is transmitted, restore the session and reconcile the order and exposure records before reopening the route. For the risk service itself, agree how the proposed deployment behaves if the service or its data becomes unavailable. Any bypass or restriction should follow the firm's approved operating policy, and the desk should be able to identify and audit the transition.

Where MarketFactory fits

MarketFactory belongs on the shortlist when an institution has multiple FX connections to maintain, wants consistent pre-trade controls across venues, or needs to solve both problems as part of one deployment. A buyer with a mature risk engine can evaluate Whisperer against its integration backlog. A desk with established connectivity can scope Reflector against specific exposure and order controls. In either case, compare proposals using the same venues, message types, measurement points and recovery scenarios, and require operational staff to demonstrate how they investigate a rejected or unresolved order.