Chronicle Software: persisted messaging, FIX and trading-system components

Chronicle Software develops messaging, connectivity and application components for latency-sensitive financial systems. Its catalogue combines persisted queues, FIX engines and routing, state stores, market-data distribution and a matching-engine framework. The products are engineering components that customers integrate into their own trading systems, with separate modules for different processing and operational needs.[1]

Chronicle Ring supplies a further messaging choice. Its RingZero variant targets one writer and one reader, with a blocking mode for ordered delivery or a conflating mode for readers needing the latest update. Named, memory-mapped instances support communication between processes on the same machine; anonymous instances serve threads within one process. Fixed slot counts and message-size limits shape the buffer design.[6]

FIX Router forwards messages by rules, translates between FIX versions and exposes a Java mapper to inspect or change messages in transit. It can generate selective drop copies into Chronicle queues and split traffic between systems during migration. This is message-routing infrastructure; counterparties, session settings and business routing policies still belong to the deployed solution.[9]

FIX Management UI provides session status and sequence numbers, scheduling, routing-rule configuration and historical message searches by tags or session identifiers. Its input panels synchronize with YAML configuration. This gives operations staff a management interface alongside the code and configuration files used by developers.[10]

The FIX architecture supports YAML or Java configuration, QuickFIX-style XML schemas, multiple dialects, TLS authentication, message persistence and replay. It exposes timing probes and logs for monitoring tools. Replication and failover can use synchronous, asynchronous or customized acknowledgement behavior, so a deployment must choose its actual durability and latency tradeoff rather than treating high availability as one fixed setting.[11]

The Java Chronicle Queue repository carries an Apache 2.0 licence. Its Enterprise edition adds commercially licensed features including replication, encryption, asynchronous mode and specialist support. The public repository is therefore not a licence for every commercial component. C++ evaluation and Enterprise enquiries go through the sales team.[12]

Chronicle’s product enquiry route asks customers to identify the required modules and describe the project. Public product pages do not provide a fixed price schedule. The commercial proposal should state the licensed components, deployment footprint, environments, upgrades and support commitment; a per-core, per-session or unlimited-use charging model should not be assumed.[17]

The maintained Java support document lists Java 8, 11, 17, 21 and 25, with Java 25 introduced in the 2026 release series at BOM 2026.20. It supports Oracle JDK, OpenJDK distributions and Azul Platform Prime. The selected library release and runtime need to be pinned together; an older product page listing only Java 8, 11 and 17 is not the complete current compatibility statement.[13][11]

Chronicle’s August 2026 deployment guide requires explicit JVM module exports and opens for Java 17 and later. They enable off-heap access, memory-mapped files, serialization and runtime class generation; the Enterprise protection layer also needs reflective access. These flags belong in the production launcher, container entrypoint and test configuration. The guide directs customers with hardened JVM policies to confirm the minimum requirements for their particular product.[14]

Queue must use a supported local filesystem: its public guide explicitly excludes NFS, AFS and SAN-based network filesystems. Cross-host access uses Enterprise replication instead. Moving an existing queue onto shared storage is therefore not equivalent to deploying a supported replicated topology.[12]

Replication copies a source queue to one or more sinks, with exclusive write ownership on each sink to preserve message order. Restart reconciliation can backfill records from a sink before the source becomes usable. Acknowledgements are configurable; a local reader configured to wait for a replica can block indefinitely if no sink acknowledges. Recovery design must account for that behavior during outages.[15]

Queue replay can restart from the beginning, from a known index, from new messages or from missed messages, depending on configuration. These options support different recovery models. The same documentation shows materially different same-host and replicated latency results and identifies the operating system and disk subsystem as influential; published benchmark figures are not a universal production guarantee.[16]

Queue Enterprise includes access to Chronicle’s low-latency engineers and performance-diagnostic tooling such as Chronicle Tune. The work can involve bottleneck analysis and system tuning. Coverage hours, escalation procedures and incident-response targets need to be specified in the commercial support agreement; the product page does not publish a universal response-time schedule.[2]

The public terms, dated 6 April 2018, expressly govern use of the website. They do not specify an Enterprise software entitlement, redistribution grant or customer SLA. The applicable product licence and support agreement therefore need to accompany the commercial order.[21]

Chronicle’s privacy policy distinguishes its own collected information from end-user data supplied through a customer. For that latter data, it describes the customer as controller and Chronicle as processor, with the customer’s notices governing the end user. This is a stated processing-role distinction, not a substitute for the customer’s contractual data-processing arrangements.[20]

The matching framework supplies software for order processing and exchange construction. Its matching and risk-check functions do not themselves confer a venue licence, brokerage authorization or permission to distribute market data. The deploying institution remains responsible for the permissions associated with its business and connected counterparties.[8]

Companies House records Chronicle Software Ltd, company 08381496, as active. It was incorporated on 30 January 2013 and previously used the name Higher Frequency Trading Ltd until 18 December 2017. Its registered office is 82 St John Street, London EC1M 4JN.[19]

The company describes its founding in 2013 by Peter Lawrey and serves banks, exchanges, hedge funds and crypto trading firms.[18]

OpenHFT is the repository organization used for the published Chronicle Queue library.[12]

Operator

Chronicle Software Ltd, England and Wales company 08381496.

Service scope

Developer libraries for persisted messaging, FIX connectivity, state management, market-data distribution and matching systems.

Customer types

Banks; Exchanges; Hedge funds; Crypto trading firms; Financial engineering teams

Delivery

On premises; Hybrid

Pricing publication

Public and quoted pricing

Platforms

Chronicle Queue Enterprise; Chronicle FIX; Chronicle FIX Router; Chronicle FIX Management UI; Chronicle Services; Chronicle Queue Backed Map; Chronicle Ring; Chronicle Matching Engine Framework; Chronicle Market Data Distributor

Integrations

Java; C++; Rust; Python; FIX 4.0–5.0 SP2; FIXT 1.1; YAML; QuickFIX-style XML schemas; TLS; TCP/IP

Pricing scope

Open-source Java Queue core alongside commercial Enterprise licences and support; commercial prices require direct enquiry.

Implementation

Select modules and runtime versions, configure sessions or queues, and design storage, replication and replay behavior.

Support

Commercial engineering support and tuning; customer-specific coverage and response commitments require agreement.

Permissions and regulatory scope

Software and recording tools; deployed financial activities and data distribution require the institution’s own permissions.

Provider metadata checked 21 Oct 2026Source 1Source 19Source 20Source 21Source 18Source 2Source 3Source 4Source 5Source 6Source 8Source 7Source 9Source 10Source 12Source 17Source 11Source 13Source 15

The Market Data Distributor’s latest-value behavior is useful when a consumer needs the current state and should not delay the writer. A process that must retain every market event has a different requirement. Its design should explicitly provide the corresponding event recording and replay path rather than assume a current-value distribution component supplies a complete event history.[7]