RTX5 Connectivity: Providers and Certification Status
Review the platform, bridge and counterparty roles for a proposed connection. Adapter versions, message scope, client eligibility and certification must be confirmed for the selected route; this guide does not establish a live provider relationship.
Connectivity Begins with Defined Roles
An ECN or liquidity connection is one possible deployment arrangement. RTX5 provides the platform scope agreed with the broker; the bridge translates supported messages, and the counterparty supplies the contracted execution or price service. The actual model, permissions and commercial relationship require route-specific evidence.
Disclose the Execution Model
Identify the broker, execution counterparty, routing policy and any manual approval or intervention boundary.
Separate Prices and Charges
Request the source spread, broker markup, commission and other applicable charges for the actual account.
Document Counterparty Information
Confirm which identifiers the route discloses and who can access the routing and execution records.
Define Feed Aggregation
For a proposed multi-provider feed, specify quote precision, freshness and the selection rule.
Separate platform, bridge and counterparty roles
A connection involves software compatibility and commercial access. Understanding each participant's role helps define the route that a broker is actually able to use.
Swipe horizontally to view all columns.
| Role | Purpose | Scope to confirm |
|---|---|---|
| Trading platform | Provides the account, order and operational interface used by clients and staff. | Client/server version, supported order workflow, permissions and reconciliation records. |
| Bridge or gateway | Translates and transfers agreed market-data or order messages between systems. | Adapter version, protocol dialect, message coverage, symbol mapping and recovery behavior. |
| Liquidity provider / counterparty | Provides the agreed quotes or execution relationship under its own commercial arrangements. | Eligibility, trading agreement, credit/collateral requirements, instruments and execution terms. |
| Market-data provider | Supplies data under a defined entitlement and distribution agreement. | Real-time/delayed scope, depth, history, usage rights and external charges. |
Provider Names Require Connection Evidence
Banks, market makers and prime brokers describe potential counterparty categories. No provider roster or live Tier-1 network is verified by this guide. A connection record should identify the provider, version, message scope, environment, status, reviewer and limitations.
Bank Price Feed Scope
For a proposed bank feed, request the named provider, instrument coverage, data rights and adapter version.
Non-Bank Provider Scope
Identify the specific market maker and the supported quote and execution contract before describing a connection as live.
Prime Broker Eligibility
Confirm credit arrangements, account eligibility, permitted routes and the owner of the prime-broker adapter.
Order Identity and Privacy
Record the identifiers sent to each counterparty and review permitted access; anonymization is not assumed.
Provider Review Records
Request dated measurements of fill outcomes, quote freshness and rejection reasons before changing route priority.
Provider Acceptance: Define the eligibility, contractual and technical review for each requested route. Keep researched, testing, certified and live states distinct, and retain the dated acceptance record rather than inferring approval from a provider name.
Check adapter coverage and certification status
For each requested route, obtain a versioned scope record. No named provider is given a new live or certified badge by this guide.
Swipe horizontally to view all columns.
| Coverage | What the route record should specify | Evidence to review |
|---|---|---|
| Protocol and session | Application/session versions, dialect, session count and connection ownership. | Adapter release, counterparty configuration and accepted session tests. |
| Market data | Snapshot/incremental messages, instruments, depth and subscription behavior. | Subscription, recovery and stale-data handling results for the agreed feed. |
| Orders and reports | Supported order types, cancellation/replacement, execution reports and rejects. | Accepted, partial, filled, cancelled and rejected order examples with reconciliation. |
| Recovery | Reconnect, sequence recovery, replay/duplicate handling and state reconciliation. | Disconnect test showing the final order/account state agrees across systems. |
| Availability | Responsible owner, tested build/date, environment and outstanding limitations. | Certification or acceptance record appropriate to the route and live environment. |
Swipe horizontally to view all columns.
| Stage | Meaning | What it does not establish |
|---|---|---|
| Researched / planned | A route has been identified or scoped for possible work. | An implemented adapter, certification or production access. |
| In development / testing | Implementation or tests are underway within a defined scope. | Completion of counterparty acceptance or general availability. |
| Certified for a stated scope | An identified version and message set passed the applicable acceptance process. | All versions, messages, accounts or commercial arrangements. |
| Live for an agreed deployment | The accepted route is enabled for the specified production environment. | Automatic entitlement for every broker or client. |
Record Provider and Broker Charges Separately
Actual spreads, commissions and market-data charges depend on the broker, account and provider agreement. The instrument rows below identify fields to confirm, not live prices or a commitment to raw spreads without markup.
| Instrument | Spread Evidence | Commission Terms |
|---|---|---|
| EUR/USD | Not published | Schedule required |
| GBP/USD | Not published | Schedule required |
| USD/JPY | Not published | Schedule required |
| AUD/USD | Not published | Schedule required |
| Gold (XAU/USD) | Not published | Schedule required |
| Crude Oil (WTI) | Not published | Schedule required |
| S&P 500 (US500) | Not published | Schedule required |
| NASDAQ 100 (US100) | Not published | Schedule required |
| Bitcoin (BTC/USD) | Not published | Schedule required |
| EUR/GBP | Not published | Schedule required |
No indicative spread or commission values are published here. Obtain the dated schedule and applicable units, markup, currency, minimum charge and liquidity conditions for the selected account.
Make Each Routing Decision Reviewable
Routing behavior depends on the broker policy, adapter capabilities and counterparty agreement. Validate acceptance, partial fill, rejection, timeout and recovery cases on the selected route; no universal speed or fill outcome is promised.
Route Selection Contract
Record the permitted destinations, account scope and selection criteria before testing an order-routing workflow.
Price and Eligibility Comparison
Compare only executable quotes available to the account under its actual size, credit and routing constraints.
Multiple Feed Handling
Specify connection state, quote age and sequence recovery for each independently supported provider stream.
Unknown Outcome and Recovery
If a request times out, reconcile its original identity before rerouting; a timeout alone does not prove non-execution.
Routing Audit Record
Expected records link order ID, configuration version, selected route, timestamps and execution reports.
Routing Policy: Disclose how price, size, credit, quote freshness and venue eligibility affect selection. Version and approve policy changes, and retain enough data to reproduce the decision for a test order.
Compare Proposed Account Cost Structures
These are examples of commercial structures a broker might offer. They are not RTX5 account products, available account-opening offers or a guarantee of a common execution route.
Raw-Spread Proposal
A broker may propose source spreads plus a separate commission. Confirm markup, units, minimum charges and provider eligibility in the actual agreement.
Spread-Inclusive Proposal
A broker may combine costs into its spread. Confirm what is included and any additional overnight, data or account charges.
Volume-Tier Proposal
If a broker offers volume tiers, document the thresholds, effective dates, calculation basis and adjustment rules.
Institutional Proposal
Account eligibility, credit, routing and commercial conditions require a named counterparty agreement and signed quote.
Review Depth Before an Execution Request
Order-book depth is route- and data-entitlement-specific. The supported display, number of levels and order types must be verified on the selected build; visible liquidity does not guarantee a fill or eliminate market impact.
Depth Message Scope
Confirm whether the adapter supplies snapshots, incremental updates or only the best bid and offer.
Price Levels and Units
Record depth limits, quantity units and instrument precision for each supported feed.
Depth Display Availability
Verify the named client build and display mode before relying on a heat map or depth visualization.
Large-Order Assessment
Compare requested size with licensed observable depth while recognizing that quotes may change before execution.
Iceberg Order Scope
Request the supported order contract and counterparty acceptance for displayed and reserve quantities.
Additional Venue Eligibility
Dark-pool or block-order access requires a specific agreement and verified adapter; it is not implied by ECN connectivity.
Disclose the Actual Execution Arrangement
No-dealing-desk wording requires evidence of the deployed routing policy and intervention boundaries. This guide does not establish an exclusive RTX5 execution model; the broker should explain how the selected configuration handles and reports client orders.
Broker Execution Policy
Identify whether the approved deployment routes externally, matches internally or combines modes, and disclose the responsible counterparty.
Price Change Handling
Specify how the supported order type treats a changed price, including rejection, partial fill or price improvement.
Order Eligibility Rules
Document risk, credit and session restrictions and test the permitted rejection reasons without promising rejection-free execution.
Slippage Measurement
Compare requested and executed prices with direction, size and timestamps; review positive and negative outcomes separately.
Conflicts and Responsibilities
Disclose broker, provider and platform commercial roles rather than claiming technology removes every conflict.
Configuration Evidence: Request the approved routing version, relevant staff permissions and test records for any override path. Platform architecture alone does not establish the broker policy or a guarantee that intervention cannot occur.
Define How Multiple Feeds Are Compared
These are proposed aggregation requirements. Availability of normalization, weighting and failover must be demonstrated on the named adapter and platform build. Keep original messages and resulting feed records for review.
Quote Normalization
Confirm symbol mapping, precision, units and timestamps with paired source and normalized-message fixtures.
Provider Selection Policy
Document any weighting inputs and tie-breaker rules; test the actual implementation before relying on ranking.
Latency and Freshness Policy
Specify the measured timestamp boundary and the maximum quote age accepted by the route.
Stale Quote Handling
Expected output identifies rejected stale quotes and shows that they cannot be used for a new execution request.
Feed Health Review
Agree monitoring fields, alerts and operator actions for dropout, stale data and inconsistent sequence state.
Scope an Institutional Connection
Institutional connectivity requires route-specific technical and commercial approval. Provider access, order sizes, priority rules and network capacity are not established by the account category alone.
Counterparty Eligibility
Agree account qualification, credit and available instruments with the actual execution provider.
Spread and Commission Terms
Request the provider and broker schedules, volume conditions and effective dates; software licence prices are separate.
Order Size Acceptance
Verify maximum size, lot increments and partial-fill handling with the selected adapter and account.
Disclosed Routing Priority
Document the policy and permitted priority rules rather than assuming a preferential institutional queue.
Prime Broker Connection Scope
Confirm the prime broker relationship, credit access, adapter version and supported message set.
Rebate Terms
Any volume rebate requires an approved schedule, recipient, calculation basis and reconciliation policy.
Connection Review: Bring expected volume, instrument coverage, account eligibility and required messages to a scoped review. The proposal should identify supported components, responsibilities, fees and acceptance evidence.
Review included connections and external access costs
Platform connection inclusion and a provider's commercial terms are separate parts of a connectivity proposal. Define both before comparing the total cost.
Swipe horizontally to view all columns.
| Plan | Connection-fee scope | Items to define in the quote |
|---|---|---|
| Entry | Bridge and eligible FIX connections may be separately chargeable under the agreed route contract. | Adapter, protocol, session/message scope, connection count and applicable add-on. |
| Standard | Bridge/gateway and FIX 4.4/5.0 connection fees are included for the agreed connection scope. | Which connections are included and how any additional route or session is priced. |
| Enterprise / Main Label | Bridge and FIX connection fees are included; final entitlement and deployment scope are set in the order form. | Provisional commercial scope, account cap, included connections and deployment responsibilities. |
Qualify a Route for a Systematic Strategy
A strategy evaluation must account for disconnects, rejected orders, partial fills and market changes. No high-frequency capacity, deterministic latency or rejection-free outcome is established by this connectivity preview.
Acknowledgement and Fill Boundaries
Measure acknowledgement separately from execution confirmation; acknowledgement does not establish fill certainty.
FIX Version and Message Scope
Request the adapter dictionary, supported messages, session behavior and certification record for FIX 4.4 or 5.0.
Deployment Location Scope
Identify proposed hosting regions and network paths in the quote before requesting a dated latency test.
Complex Order Acceptance
Mass quotes or multi-leg orders require explicit adapter support and tested partial-failure behavior.
Execution Quality Measurements
Request time-bounded fill, slippage and latency observations with instrument, workload and routing context.
Qualify Coverage for Each Trading Session
The sessions below are planning categories, not evidence of active providers or guaranteed depth. Confirm the route calendar, timezones, instrument coverage and support responsibility for each requested session.
Asian Session (Tokyo)
European Session (London)
North American Session (New York)
Sydney Pre-Market & Overlap Periods
Session Transitions: Test quote expiry, session boundaries, holidays, reconnects and reduced-liquidity behavior for the actual provider calendar. Record the accepted order policy during unavailable or stale-price conditions.
Define the Provider Review Evidence
These monitoring fields form an acceptance checklist. No automatic weighting system, published provider ranking or completed network-wide review is established by this guide.
Fill Outcome Review
Define the order population and report accepted, filled, partially filled, cancelled and rejected outcomes separately.
Spread Observation
Record timestamps, instrument and account conditions when comparing available quotes across eligible providers.
Rejection Reason Review
Retain provider reason codes and distinguish account, risk, session and technical failures.
Quote Timing Review
Measure quote age and transport timing with the clock method and percentile distribution disclosed.
Provider Review Record
Require reviewer, date, scope and limitations alongside observed results and proposed route changes.
Report Availability: A published quality report requires an actual dated artifact and defined methodology. No quarterly report or independently reviewed network measurements are supplied on this page.
Execution Evidence Required Before Publication
The cards below describe required evidence records, not historical quarterly results. Actual fill, spread and rejection observations have not been published here; certification requires the applicable named artifact and scope.
Order Outcome Record
Expected output: the order population, fill and partial-fill counts, cancellations and rejection reasons with the measured period.
Price and Cost Record
Expected output: requested and executed prices, spread/markup conditions and commission units for the same instrument and account.
Recovery Record
Expected output: original order identifiers, timeout and reconnect events, reconciled state and proof that retries did not duplicate execution.
Provider Review Record
Expected output: adapter version, environment, reviewer, test date, limitations and approval for the stated connection status.
Evidence Availability: No downloadable transparency report or independent audit is supplied by this page. Request the scoped records at support@orrnn.com and publish a report only after its owner, date, data rights and limitations are confirmed.
Discuss a Proposed Provider Connection
Use a scoped enquiry to describe a potential liquidity or data route. Technical acceptance and the commercial relationship require independent confirmation; an enquiry does not establish partnership, certification or access to an active trader network.
Review Scope
Proposed Route and Instrument Scope
Describe the account eligibility, instruments and expected workload for the requested connection; no order-flow volume is promised.
Commercial Responsibilities
Agree provider charges, broker charges, data licensing and any compensation in the signed arrangement.
Adapter and Session Review
Supply the proposed dictionary, message set, session settings and responsible integration team.
Acceptance Measurements
Define quote freshness, order outcomes and recovery measurements with their test conditions.
Named Integration Contacts
Identify the broker, adapter and provider owners responsible for approval and ongoing incident handling.
Information to Provide
Next Step: Email support@orrnn.com with the provider identity, required messages, environment and expected workload. Response timing and integration delivery are agreed during review; no partner portal or fixed response commitment is published here.
Questions About RTX5 Connectivity
Review the required roles, terms and route-specific evidence before integration.
Understand Connectivity Before Integration
Use these topics to prepare the connection review. The API and FIX guides describe proposed contracts and expected outputs; route-specific tutorials require named versions and tested fixtures.
Understanding ECN vs Market Maker Execution
Compare external routing, internal matching and hybrid arrangements by their disclosed counterparty, pricing and intervention policies. No model alone establishes execution quality.
How ECN Spreads Are Formed
Understand how source quotes, eligible quantity, markup and commission contribute to a quoted price. Review actual account terms before comparing costs.
Reading the Level 2 Order Book
Confirm the depth entitlement, supported message format and client display. Visible size may change and does not guarantee execution.
Evaluating Your Execution Quality
Define fill, slippage, rejection and latency measurements with scope and timestamps. Compare actual records rather than an unsupported network benchmark.
Review Your Provider
and Adapter Scope
Bring the requested provider, instruments, message set and environment to a connectivity review. Confirm eligibility, fees, supported versions and acceptance records before describing the route as live.