A trading-interface version change can touch order entry, risk checks, reports and downstream reconciliation at once. MOEX’s August notice scheduled new ASTS Bridge interfaces Broker59 and BrokerRisk59, alongside securities-market report and system-message changes, for 14 September 2026. Moscow Exchange: planned securities and FX market system changes, 7 August 2026
Follow the evidence
Trace how the event could reach markets, then inspect a competing explanation.
Compare explanations
Switch lenses to see what each account explains—and what remains uncertain.
The notice bundles interfaces with report and message changes, so broker validation should cover connected downstream systems.
The notice bundles interfaces with report and message changes, so broker validation should cover connected downstream systems.
A firm with a well-isolated gateway and validated compatibility layer may need only a narrow change, depending on its implementation.
The notice grouped interface, report and message changes
MOEX said the planned changes would take effect from 14 September and listed new ASTS Bridge broker-interface versions Broker59 and BrokerRisk59 for the securities market. Moscow Exchange: planned securities and FX market system changes, 7 August 2026
The same notice included changes to trading and clearing reports, additional bond attributes, system messages and error codes, and settlement-mechanism support. It also said the T1 test environment had been updated to version 2026-3 and was available for connection. Moscow Exchange: planned securities and FX market system changes, 7 August 2026
The exchange described planned system changes and provided an attached detailed change list. The announcement does not report that every broker completed its migration or that the changes caused a disruption. Moscow Exchange: planned securities and FX market system changes, 7 August 2026
Version labels matter only when linked to a tested workflow
The operational risk sits at interfaces between the exchange gateway, a broker’s order-management system, risk controls, clearing workflow and client reporting. A message can parse correctly while a field mapping, enum value or downstream reconciliation still behaves incorrectly.
A structured migration can reduce uncertainty if a firm tests representative orders, rejects, cancels, risk-limit breaches, report ingestion and recovery procedures against the updated test environment. A successful connection test alone does not demonstrate that every business process is ready.
Because several related changes were grouped in one notice, implementation teams should maintain an owner and test result for each item instead of marking the whole release complete based on one interface check. The listed changes are exchange-specific and should not be generalized to other venues.
Prove the full order-to-record path in the test environment
Confirm the deployed interface version with the exchange and identify every system that consumes its messages. Compare field dictionaries, error handling and reports with the attached change list, and record any backward-compatibility assumptions.
Run end-to-end cases in T1 for new orders, partial fills, cancels, rejection paths, risk events, clearing reports and restart or replay. Reconcile exchange output to internal ledgers and client statements, then obtain sign-off from operations, technology and compliance.
An alternative explanation for a broker incident around a release date could be a local deployment, connectivity provider or unrelated venue issue. Preserve timestamps and raw messages so a post-event review can distinguish exchange change from firm-specific implementation.