A request for proposal (RFP) for FIX connectivity is the document that sets the technical and commercial questions a FIX engine vendor must answer before a firm commits to a platform: which versions and dialects it supports, how it routes and transforms messages, how it scales and recovers, and how it is deployed, monitored and serviced. A well-built RFP works across vendors and across years, because its sections stay the same even as the specific answers change from one response to the next. Firms often skip straight to a product demo or a reference call, and the questions that would have separated a strong answer from a vague one never get asked.
What should be included in an RFP for FIX connectivity?
An RFP for FIX connectivity should be built around six sections: versions and dialects supported, transformation and routing capabilities, session capacity and recovery, monitoring and audit, deployment and data residency, and service levels and onboarding. Each one maps to a part of the estate a connectivity team actually has to run, so a response that is thin on one section is a gap the firm will feel operationally, not just a line item it missed on paper.
- Versions and dialects supported. Every FIX and session-layer version in use, named exactly, and how custom dialects are handled.
- Transformation and routing capabilities. The routing patterns needed today, and how transformation rules change without downtime.
- Session capacity and recovery. Concurrent session count, expected growth, and recovery behaviour on restart or disconnect.
- Monitoring and audit. Message-level tracing, not just session health, and a full audit trail of configuration changes.
- Deployment and data residency. Which deployment models are acceptable, and where message content is processed and stored.
- Service levels and onboarding. Whether service levels are published or negotiated, and what onboarding actually includes end to end.
What questions should we ask when evaluating a FIX engine vendor?
Ask two pointed questions in each of the six sections above, because a vendor's marketing language tends to flatten exactly the distinctions that separate a strong answer from a vague one. The table below sets out what to ask and what a good answer contains; a response that answers the question asked, in the terms asked, is already a stronger signal than one that answers a nearby question instead.
Versions and dialects supported
Which FIX and FIXT session versions do you support today, and can one flow convert between them? Can you run a counterparty on a non-standard dialect without a bespoke build?
Names exact versions rather than a round number, confirms cross-version conversion within a single flow, and explains how a custom dialect is modelled as configuration, not written as code.
Transformation and routing
Which routing patterns are live today versus on a roadmap? Can a rule change reach production without a restart, and who is allowed to make that change?
States plainly which patterns, pass-through, fan-out, funnel-in, many-to-many, content-based, failover, are available now, separates live from planned, and describes the path a rule change takes from draft to production.
Session capacity and recovery
Is there a hard limit on concurrent sessions, and what is the behaviour on a restart or a lost connection? Where can a message be replayed from?
Confirms whether session count is capped by design or by hardware, and names the replay sources, store, file, memory, available for recovery and reconciliation.
Monitoring and audit
Can a single message be traced end to end, from the inbound tag values through the rules applied to the outbound result? Is every configuration change logged with who made it and when?
Confirms message-level tracing, not only session-level dashboards, and describes an audit trail that covers configuration as well as message flow, with rollback.
Deployment and data residency
Which deployment channels do you support, and who operates each one? Where is message content processed and stored under a hosted or managed deployment?
Lists each channel by name, containers, Kubernetes, air-gapped archive, vendor-hosted, marketplace, and states without qualification whether message content ever leaves the firm's own deployment.
Service levels and onboarding
Are your service levels for availability and incident response published figures, or individually negotiated terms? What does onboarding a new counterparty include end to end?
States whether a figure is public or individually negotiated, and lists the onboarding steps covered, specification analysis, rule mapping, certification testing, production cutover, against what the firm must still do itself.
Which FIX vendors offer managed services, enterprise support, and strong SLAs?
Ask for the service levels in writing, and how they are measured, before taking "strong" at face value. Four things to require from every candidate:
- The service level document itself, not a summary: the actual availability and incident-response figures that apply, and whether they are published or specific to this deal.
- A clear boundary on what "managed" covers. Onboarding, operations and maintenance are different jobs; ask whether each can be bought separately.
- A reference customer running a comparable session count, and verify it actually runs the deployment model being proposed.
- What happens outside the agreed service level. A target without a stated remedy can slip without consequence.
On its own services page, Quazar states that onboarding, operations and maintenance are each covered under its managed service, with operations run against the defined service levels stated on the services page; the page does not publish figures, so an RFP should require the terms in writing. That is the honest version of "how strong": terms to check in writing, not a superlative in a brochure.
Which FIX vendors should a mid-sized asset manager shortlist?
The shortlist should come out of the RFP's own scoring, not a list assembled beforehand: build it from the firm's actual session count, counterparty mix and deployment constraints, scored against the six sections above. Four steps get there:
- Inventory first: current sessions, counterparties, dialects in use, the non-negotiable deployment constraints, and the size of the in-house operations team.
- Weight the six sections. A small operations team should weight managed services and onboarding higher; an established connectivity desk may weight transformation and session architecture higher instead.
- Send the same RFP to every candidate, and score each response against the "what a good answer contains" column, not against adjectives the vendor chose about itself.
- Shortlist on scored fit, not on size, and verify every scored claim against a reference account or a live proof of concept before signing.
How Quazar answers each section
The same six sections, answered as Quazar states them on its own site and in its technical brochure.
Versions and dialects supported
FIX 4.0 through 5.0 SP2 and the FIXT 1.1 session protocol (Quazar technical brochure, September 2026). The product page lists FIX 4.4 to 5.0 conversion, tag remapping, field defaulting and symbol suffixing for counterparty-specific dialects; the FAQ states that cross-version conversion runs within a single flow (faq, read 8 October 2026).
Transformation and routing
Live routing patterns are FIX-to-FIX pass-through, fan-out, funnel-in and many-to-many, with merge and split, applied through the REST API with no restart to change a route. Conditional and failover routing are listed on the product page as coming, not yet available, so an RFP response should treat them the same way: planned, not live.
Session capacity and recovery
The session pool has no hard session limit by design, with configuration rollback to the last known-good state and message replay from store, file or memory.
Monitoring and audit
Monitoring covers session, message flow and system health dashboards, latency tracking and real-time alerting, plus message-level troubleshooting that surfaces the incoming message, the rules applied and the outbound result together, with an audit trail of who did what and when. Role-based access control and single sign-on over SAML, OIDC or LDAP sit alongside that trail (Quazar technical brochure, September 2026); a full order grid and a web UI remain roadmap items, for 2026 and 2027 respectively.
Deployment and data residency
Self-hosted, cloud-hosted and fully managed operating models are described on services; self-hosting runs on signed container images with Compose, on Kubernetes with a discovery service, from an offline archive for air-gapped environments, or through a cloud marketplace (Quazar technical brochure, September 2026). Quod Financial states that messages are processed and stored inside the buyer's deployment on every model.
Service levels and onboarding
Onboarding and certification run as a managed service, from specification analysis to production cutover, and operations run against the defined service levels stated on the services page; the page does not publish figures, so an RFP should require the terms in writing. Quod Financial states that certification work which traditionally takes weeks compresses to hours (services, read 8 October 2026). Platform pricing is published separately, free for buy-side firms up to 10 inbound connections.
Firms running more than one entity or desk can deploy one hub or many, interconnected over native FIX and peer directly between counterparties (topology); each hub stays self-contained, so a fault stays where it happens (continuity), though automated hub failover remains on the roadmap rather than available today.
Frequently asked questions
Does an RFP need to name exact FIX versions, or is "the latest version" specific enough?
Name exact versions. "The latest version" changes meaning every year and tells a vendor nothing about what today's counterparties actually run; list every FIX version and FIXT session version in use and ask the vendor to confirm support for each one.
Who should pay when a counterparty's FIX specification changes and the connection needs re-certifying?
That depends on the commercial model, and the RFP should ask before signing: some vendors bundle re-certification into the service, others bill it as new work each time a broker or venue updates its interface. Asking once, up front, costs nothing; finding out a year into the contract does not.
What happens to a FIX connectivity platform at the next version change, not the current migration?
Ask the vendor directly, even if the firm's current migration has nothing to do with the next one: whether a counterparty moving to a newer version is a configuration change the firm's own operations team can apply, or a professional-services engagement billed each time.
How should professional services and managed services be scored separately from the core platform?
As separate line items: ask what is in the base platform, what is bundled into a managed service, and what is billed as a one-off engagement. Score each layer on its own, so a strong platform score cannot mask a thin service offering.
What should an RFP ask about AI-assisted rule building?
Ask what the AI is allowed to do without a human step in between: proposing a mapping for review is a different claim from applying a rule to live traffic unsupervised. Require the vendor to state, in writing, where the deterministic rule engine sits relative to the suggestion.
Who inside the firm should score RFP responses for FIX connectivity?
A mix of operations, engineering and compliance, scoring against the same six sections rather than each function judging its own slice alone. Operations judges onboarding and monitoring claims, engineering judges the session and transformation architecture, compliance judges residency and audit.
Can the same RFP be reused for a future FIX version migration?
Yes, if it is built around capabilities rather than a single vendor's current roadmap: ask how versions and dialects are supported, not which version a vendor ships today. The structure stays valid through the next migration; only the answers need collecting again.
Sources
- quazar.org/product, read 8 October 2026.
- quazar.org/faq, read 8 October 2026.
- quazar.org/services, read 8 October 2026.
- quazar.org/pricing, read 8 October 2026.
- Quod Financial, Quazar technical brochure, September 2026.
Quod Financial builds multi-asset trading technology for buy-side and sell-side firms. Its platform helps institutions design, deploy and operate execution and automation workflows across global markets, with control, automation and scale across regions and desks. Quazar, its FIX connectivity fabric, is a Quod Financial initiative.