Market data multicast: public incident reports
Each entry was checked against the original source on 2026-10-03. The tables show what the original says. Where the source material said something different, that is called out separately.
Montreal Exchange, 2019-06-13: a network change stopped multicast from leaving
| Item | Details |
|---|---|
| Time | 2019-06-13, 1:30–6:00 a.m. |
| What happened | The trading system was working, but multicast data for HSVF (High Speed Vendor Feed) and OBF (Order Book Feed) was not forwarded externally |
| How it was found | Around 2:00 a.m. a participant called to say they were not getting trade confirmation details on their feeds. The exchange’s own monitoring did not catch it |
| Root cause | A network change the previous evening, which stopped multicast data from reaching external participants |
| Response | At 3:30 a.m. all instruments were put into pre-open. After the fix they reopened at 6:00 a.m., so participants could remove, modify or add orders first |
| Source | https://www.m-x.ca/f_avis_tech_en/19-007_en.pdf |
Lessons:
- Multicast changes need a change window and a rollback plan. After the change, confirm from the outside that the multicast really arrives. A healthy matching engine does not mean the feed is getting out.
- Watching internal system state is not enough. Monitor whether the feed can be received externally.
JPX / TSE FLEX, 2022-06-07: Line 1 down all day, Line 2 carried the feed
| Item | Details |
|---|---|
| Time | From about 07:00 JST on 2022-06-07, all day |
| Classification | Network incident. System: FLEX (market information system) |
| Impact | Line 1 of FLEX Standard (100M) and FLEX Full (100M), at Co-Location and access points AP1–AP4 |
| Groups | Line 1 of Standard group 014 and Full group 064 could not be distributed all day |
| User action | Keep running on the FLEX messages from Line 2. Standard (WB) and Full (WB) were not affected |
| Source | https://www.jpx.co.jp/english/systems/system-status/archive/20220607.html (WebFetch gets 403; curl with a browser user agent works) |
Lesson: A/B lines (Line 1 / Line 2) are not decoration. The feed handler must arbitrate per multicast group: if one group dies on the A side, use the B side for that group only. Do not mark the whole feed dead, and do not keep waiting for the A side.
Moscow Exchange, 2015-06-29: the exchange switched in 15 seconds, clients took 30 seconds to 4 minutes
| Item | Details |
|---|---|
| Time | 2015-06-29, 12:28–12:32 MSK |
| Root cause | A network infrastructure component, the load balancer, malfunctioned |
| Exchange side | Switched to the backup infrastructure within 15 seconds |
| Participant side | No market data until they switched to the backup system, which took 30 seconds to 4 minutes depending on how they connected |
| Source | https://www.moex.com/n9836 |
Lesson: however good the exchange’s redundancy is, how long you are down depends on your own failover design. Do you subscribe to primary and backup at the same time? Does it switch automatically, or does a person have to step in?
Nasdaq SIP, 2013-08-22: market data distribution is a single point for the whole market
| Item | Details |
|---|---|
| Nature | A SIP capacity and software problem, not a multicast configuration fault |
| Nasdaq’s account | That morning Arca disconnected and reconnected to the SIP more than 20 times, each time using significant resources. It also sent a stream of invalid stock symbols, which caused many reject messages. Arca’s traffic was more than double the capacity of 10,000 messages per second per data port. A latent software flaw kept the system from failing over properly |
| Duration | 30 minutes to fix the technical problem, then nearly 3 hours of testing before trading resumed |
| Source 1 | https://www.businessinsurance.com/nasdaq-says-software-bug-caused-trading-outage/ |
| Source 2 | https://www.cnbc.com/2013/08/29/nasdaq-takes-some-responsibility-for-flash-freeze.html (WebFetch gets 403; curl with a browser user agent works) |
Where the source material differs:
- It said NYSE disputed the attribution. The CNBC article does not report any NYSE response. It says Nasdaq accepted part of the responsibility, and it cites an independent analysis by Nanex (Eric Scott Hunsader): the quote burst “had to originate with the SIP itself”, and neither Arca nor anything else outside the SIP could have caused it. So the accurate version is that an independent analysis disagreed with Nasdaq blaming Arca.
- It said trading halted market-wide. As usually reported, the halt covered Nasdaq-listed stocks on all exchanges, while NYSE-listed stocks kept trading. Unverified: general knowledge, not checked against the two sources above.
Lesson: the market data path is a single point for the whole market. Plan capacity for the extreme case (a reconnect storm on top of a flood of bad messages), and test failover for real.