RTX5 Order Routing and Matching Architecture
Preview the route from order validation to execution reporting and reconciliation. Supported execution modes, component origin, deployment responsibilities and performance require named evidence; no proprietary Ultency ownership or measured latency is established here.
Define the Components Behind an Order
RTX5 execution architecture is described here as a deployment scope to verify. The component owner, licence rights and integration relationship for anything named Ultency require review; this page does not claim it is proprietary RTX5 technology or the engine behind every trade.
Document the Execution Mode
Identify external routing, internal matching or hybrid behavior and the responsible component in the deployment proposal.
Disclose Queue and Routing Rules
Record price, time, size and account eligibility rules, including permitted intervention or override paths.
Measure the Relevant Boundary
Separate client round-trip, gateway acknowledgement, internal processing and final execution latency.
Reconcile Execution Reports
Require stable order and execution identifiers, quantities, prices, timestamps and final account state.
Follow the order across execution boundaries
A routing decision, an execution and an account update are separate events. This reference flow helps identify the responsible system at each stage; the supported topology must be confirmed for the deployment.
- 01
Receive and validate
A client submits an order. The platform checks identity, account/instrument permissions and applicable risk conditions, then returns an accepted or rejected result for that request.
- 02
Apply the agreed routing policy
The routing layer selects the supported execution path under the account/group and symbol policy. Record the policy version and destination so the routing decision can be reviewed.
- 03
Process execution reports
The selected matching component or external counterparty reports fills, partial fills, rejects or cancellations. An accepted request is not yet proof of a completed execution.
- 04
Reconcile and publish account state
The platform associates execution reports with the order and updates the authoritative account record. Clients recover current orders and positions after a disconnect under the supported recovery protocol.
Architecture Requires a Named Build
These engineering topics define the evidence to request for an execution component. Lock-free structures, zero-copy processing, kernel bypass and clock precision are not verified implementation claims on this page.
Order State and Concurrency
Document how the chosen component orders concurrent changes and preserves a consistent order state.
Data Processing Boundaries
Identify validation, routing and reporting stages and measure their actual allocation and transport overhead.
Network and Protocol Scope
Confirm the supported transport, operating environment and failure handling; kernel-bypass technology is not assumed.
Price-Level Storage
Specify persistence, capacity and recovery behavior for the deployed order-book implementation.
Event Ordering
Use versioned fixtures to verify how timestamps, sequencing and concurrent requests affect an outcome.
Clock and Timestamp Evidence
Record the clock source, synchronization method and measured error before interpreting timing results.
Make Matching Rules Reproducible
A deployment must name its matching or routing policy and supported order types. The examples are evaluation requirements, not a declaration that FIFO, pro-rata or every order modifier is available in an RTX5 build.
Price-Time Priority Example
For a proposed FIFO mode, specify eligible prices and arrival ordering, then compare a fixture with its expected fills.
Alternative Allocation Policy
Pro-rata or iceberg handling requires an explicit supported contract and test cases; do not infer it from a general matching description.
Partial Fill and Remainder Policy
Define how the actual order type handles remaining quantity, cancellation and further execution reports.
Self-Match Prevention Scope
Document the identity boundary and supported cancel or reject action, then test matching orders from the same entity.
Minimum Quantity and Time in Force
Confirm accepted fields and outcomes for insufficient quantity, expiry, immediate-or-cancel and fill-or-kill requests.
Execution Policy: Record last-look, rejection and price-change behavior for the actual component and counterparty. A successful pre-trade check does not guarantee a fill, and a routing description does not establish a slippage policy.
Measure Latency with Its Test Conditions
No nanosecond stage timings or percentile results are published here. A benchmark should identify build, hardware, topology, workload, duration, clocks, measurement boundary and raw results for accepted and failed operations.
Order Receipt & Validation
Record arrival, schema validation, instrument and session checks at a clearly defined input boundary.
Order Book Insertion
Capture accepted queue or routing state and the actual timestamp precision used by the component.
Price Level Matching
Measure matching or external execution separately, including unfilled, rejected and partially filled orders.
Fill Confirmation Generation
Capture report creation with order ID, execution ID, quantity, price and measured clock context.
Execution Report Dispatch
Record dispatch and client receipt separately so internal timing is not presented as end-to-end latency.
Comparison Requirements: Compare implementations only with equivalent workloads and boundaries. A credible comparison needs named sources, dates and methods; this page supplies no industry ranking or independently benchmarked speed advantage.
Define the Order Book That Is Available
Order-book coverage depends on the execution component, provider entitlements and client build. No unlimited depth, historical archive or replay capability is established here; validate the requested scope with actual records.
Order State Representation
Define which orders and provider quotes are included and how adds, cancels, changes and fills update the view.
Source and Venue Boundaries
Identify eligible sources and their data rights before describing a consolidated order book.
Published Depth Scope
Confirm the number of levels, units, update type and supported client build for each instrument.
Derived Depth Metrics
Specify any imbalance calculation and verify its inputs and timing against an authorized fixture.
Snapshot and Retention Policy
Request the actual snapshot format, retention period, permissions and timestamp precision.
Replay Requirements
A replay needs licensed data, a supported format and documented timing and sequence semantics.
Evaluate Execution from Its Records
Execution quality depends on the agreed rules, available liquidity, account eligibility and market conditions. No zero-rejection, equal-latency or best-price guarantee is established by this architectural preview.
Counterparty Acceptance Policy
Identify any last-look or rejection policy and the boundary between broker validation and counterparty acceptance.
Slippage Observation
Compare requested and executed price by side, quantity and timestamp, including positive and negative outcomes.
Changed-Price Handling
Define the actual request and response contract for unavailable prices, expiration and rejected orders.
Execution Price Evidence
Retain the eligible price and quantity context for the selected routing or matching rule.
Execution Report Scope
Confirm fields for order and execution identifiers, price, quantity, remainder, timestamp and rejection reason.
Define the Workload Before Capacity Claims
Capacity is a measured property of a named deployment. This page does not establish linear scaling, millions of orders per second or unchanged latency during every market condition.
Capacity and Partitioning
Document any partitioning scheme and measure scaling with the stated instrument, account and order mix.
Queue and Backpressure Limits
Specify queue bounds, admission policy and what happens when arrival rate exceeds measured processing capacity.
Overload Response
Test rate-limit or rejection responses, retry guidance and recovery without assuming unlimited buffering.
Node Failure Acceptance
Reconcile accepted, pending and final orders after a failure before issuing new or repeated requests.
Operational Measurements
Request throughput, latency distributions, queue depth and resource usage with the workload and measurement period.
Required Stress-Test Output: Publish test inputs, duration, build and environment alongside throughput, latency percentiles, rejected requests, state differences and recovery results. No completed stress-test artifact is supplied here.
Test the Risk Boundary Before Execution
These are proposed pre-trade acceptance cases. Confirm the controls implemented by each named component and retain positive, denied and concurrent-request results before relying on enforcement.
Margin Check Scope
Specify the account snapshot, valuation and margin rule, then test both allowed and insufficient-margin requests.
Position Limit Acceptance
Test a request below, equal to and above the configured limit, including pending orders where applicable.
Instrument and Session Restrictions
Verify restricted symbols, sessions and account groups receive the expected denial with no execution.
Account Exposure Policy
Define exposure units, currency conversion and treatment of existing and pending positions.
Request-Rate Limits
Request numeric limits, scope and retry guidance for the actual API or session contract.
Operational Exception Review
Define alert ownership and review procedures for unusual order patterns; surveillance coverage requires separate validation.
Administrative Changes: Document who can propose and approve a risk change, its effective version and rollback path. API coverage, effective timing and uninterrupted operation must be verified rather than assumed.
Verify Each Connection Interface
Connectivity is adapter- and environment-specific. A protocol name is not certification; request the exact supported contract, owner, test date and limitations for every intended route.
FIX Dictionary and Sessions
Request supported FIX versions, messages, session parameters and adapter-specific certification records.
WebSocket Contract
Confirm schemas, authentication, ordering, reconnect and replay behavior for the published API version.
Client-to-Server Protocol
Identify the supported client/server pair and transport contract without assuming a proprietary binary protocol.
OMS Adapter Scope
Record the requested OMS version, supported operations, error mapping and acceptance results.
Prime Broker and Venue Eligibility
Identify the actual account, credit and route permissions with the counterparty before integration.
Execution Copy and Reconciliation
Where supported, define report-copy fields, sequence recovery and independent reconciliation responsibilities.
Define execution mode and deployment responsibilities
The following categories describe scope decisions. They are not an assertion that all modes are implemented or available in every RTX5 build.
Swipe horizontally to view all columns.
| Mode | Boundary to explain | Acceptance scenario |
|---|---|---|
| External routing | Which adapter/counterparty receives the order; who owns quotes, acceptance and execution. | Accepted, rejected and partial-fill outcomes; timeout and recovery against the agreed route. |
| Internal matching or execution | Which component applies the execution rules and how its order-priority policy is disclosed. | Deterministic handling of the supported order types, price/quantity rules and cancellation races. |
| Hybrid routing | Which versioned conditions choose a path and how the effective execution policy is presented. | Group/symbol boundaries, route selection, policy changes and consistent post-trade records. |
Swipe horizontally to view all columns.
| Concern | Agreed owner and evidence |
|---|---|
| Risk and permissions | Who configures and approves pre-trade checks, limits and overrides; demonstrate account/tenant isolation. |
| Infrastructure and recovery | Who operates hosting, network, failover and backups; identify recovery objectives and a tested recovery procedure. |
| Connectivity | Who maintains adapter versions, sessions, credentials, provider acceptance and external data rights. |
| Audit and change control | Who retains routing decisions, execution events and configuration versions; define access, retention and rollback. |
Specify Reviewable Execution Records
These are expected analytics outputs for acceptance. The actual dashboard, export schema, retention and access permissions must be verified on the selected build; no complete live reporting interface is asserted.
Order Lifecycle Record
Require traceable receipt, validation, routing, partial fills, modifications and final state with supported timestamps.
Defined Quality Measures
State the inputs and formula for any execution score rather than treating a composite value as self-explanatory.
Slippage Review
Group requested-versus-executed price differences by instrument, order type and measured period.
Rejection Reason Records
Retain permitted reason codes and distinguish validation, risk, session and counterparty failures.
Latency Distribution
Report the measured boundary and population alongside percentile distributions and clock limitations.
Reporting Export Scope
Agree required fields and formats with the responsible broker; software exports do not establish regulatory compliance.
Evaluate the Execution Path for a Strategy
Strategy compatibility requires a named runtime, order contract and workload. This page does not establish HFT suitability, rejection-free processing or stable fill latency under all conditions.
Timing Distribution for Strategies
Measure accepted and failed request timing under the relevant load rather than assuming deterministic fill time.
Queue and Priority Policy
Document the supported priority rule and what a modification, cancellation or reconnect does to queue position.
Complex Order Contract
Mass quotes and multi-leg requests need explicit supported schemas and tested partial-failure handling.
Hosting and Network Location
Co-location or cross-connect service requires an actual provider, quote and measured network path.
Strategy Routing Scope
Confirm supported destinations and routing rules along with the additional processing and failure boundaries.
Scope the Proposed Execution Deployment
An institutional proposal must establish component origin, licence scope, technical interfaces and acceptance responsibilities. This page is not an offer to license a proprietary Ultency engine or a published uptime guarantee.
Component Rights and Branding
Confirm ownership, licence rights and permitted product naming before proposing a branded execution component.
Configuration and Approval API
Request supported operations, role boundaries and a versioned change-and-rollback example.
Instrument and Mode Scope
Specify the asset classes, order types and matching or routing modes actually accepted by the chosen component.
Infrastructure Responsibilities
Identify hosting, network, monitoring and incident owners in the deployment proposal.
Service Terms by Quote
Agree availability objectives, measurement exclusions, support coverage and remedies in the signed service terms.
Email required instruments, order volume, execution model, interfaces and review criteria to support@orrnn.com. The responsible team can assess the proposed scope and identify the evidence still required.
Request an Execution ReviewPlan Recovery Around Accepted Orders
Recovery requirements must be demonstrated on the proposed environment. No active-active installation, geographic redundancy, sub-50 ms failover or zero-loss guarantee is established by this page.
Deployment and Redundancy Scope
Identify the proposed active and standby components, state ownership and failure detection policy.
Measured Recovery Time
Measure failure detection, restoration and reconciliation with the exact starting state and workload.
Site and Network Failure Scope
Document site dependencies and test the failure boundary covered by the agreed deployment.
State Replication Contract
Specify persistence, acknowledgement and recovery semantics; replication mode alone does not establish lossless recovery.
Order Reconciliation on Recovery
Compare accepted requests and execution reports before and after interruption, including unresolved and duplicate cases.
Keep Reporting Claims Within Verified Scope
The proposed audit workflow supports a review of execution records. It does not certify compliance with MiFID II, EMIR, Dodd-Frank or another framework; applicable obligations and reporting arrangements require the responsible broker review.
Audit Integrity and Retention
Confirm event fields, timestamp precision, write permissions, retention and export integrity with actual records.
Reporting Responsibility
Identify the broker and any reporting provider, their required formats and the supported integration scope.
Execution Review Evidence
Retain route policy, eligible quotes, execution reports and the method used to assess an order outcome.
Exception and Surveillance Scope
Document available review signals and operator actions; market-surveillance certification is not established here.
Verified Export Format
Request a sample export and confirm its schema, identifiers and completeness for the intended review.
Execution Specification: Evidence to Confirm
The table records missing deployment inputs, not released specifications. Populate them with named versions, measured results and approved responsibilities before accepting a proposal.
| Specification | Required Confirmation |
|---|---|
| Order Matching Latency (P50) | Not published; named benchmark required |
| Order Matching Latency (P99) | Not published; named benchmark required |
| Order Matching Latency (P99.9) | Not published; named benchmark required |
| Maximum Order Throughput | Workload-specific test required |
| Supported Order Types | Confirm each type and modifier against the supported contract |
| Supported Protocols | Adapter-specific version, schema and certification required |
| Order Book Depth (Price Levels) | Confirm client and feed limits |
| Maximum Simultaneous Instruments | Deployment capacity review required |
| Clock Synchronisation Precision | Clock method and measured error required |
| Failover Time | Dated recovery test required |
| Data Persistence Model | Confirm persistence and acknowledgement semantics |
| Deployment Options | Confirm supported hosting and responsibility split |
| Operating System Support | Named operating environment and build required |
| API Documentation Format | Versioned contract and tested examples required |
Questions About Execution Scope
Review supported modes, responsibilities and the evidence needed for a named deployment.
Benchmark Records Required for Evaluation
No historical benchmark results or independently audited performance reports are supplied here. These four cards define the evidence needed to support a scoped capacity and execution review.
Baseline Workload
Required output: build, hardware, topology, clocks, order mix, duration, raw samples and a reviewed baseline result.
Peak Workload
Required output: the same measurement boundary under the proposed peak load, including rejected requests and queue behavior.
Recovery Workload
Required output: interruption conditions, accepted requests, reconciled final states, recovery time and any differences.
Independent Review
Required output: reviewer identity, date, artifact link and the exact assessment scope; independence must be substantiated.
Evidence Availability: A report may be published once its named owner, date, methodology, raw results and limitations are confirmed. Use the execution enquiry to request an evaluation; no download is represented as available without an actual artifact.
Read performance numbers with their test conditions
Latency, throughput and recovery results are meaningful only with the measured boundary and workload. Use the same conditions when assessing whether a result applies to your intended deployment.
Swipe horizontally to view all columns.
| Evidence | Required context |
|---|---|
| Software and configuration | Named component, build/version, enabled risk checks, logging mode, order types and routing configuration. |
| Hardware and environment | CPU, memory, network, operating system, topology and whether the counterparty/client is local or remote. |
| Workload | Order arrival rate, number of sessions/symbols, order mix, market-data load, run duration and warm-up period. |
| Measurement | Start/end events, clock method, sample count and latency percentiles; distinguish order acceptance from fill confirmation. |
| Correctness and saturation | Rejected/dropped messages, duplicate handling, final state reconciliation and the conditions at which load exceeds capacity. |
| Provenance | Test date, responsible reviewer, test artefact/report link and the exact scope of any independent assessment. |
Review RTX5 Routing
and Matching Scope
Identify the execution mode, required interfaces and expected workload. Confirm component rights, supported builds and acceptance evidence before committing to a deployment.