The NEPSE ransomware outage forced Nepal Stock Exchange to suspend Monday’s regular trading session after systems used by 72 brokerage firms at DataHub became unavailable. Current reporting confirms the market closure and broker-system disruption, while the ransomware cause is attributed to YCO and DataHub information. There is no reviewed evidence confirming that investor data was stolen or that NEPSE’s core exchange system itself was encrypted.
Direct answer: NEPSE halted trading because broker infrastructure serving 72 firms remained disrupted and the exchange said continuing under those conditions could create further operational risk. YCO, citing DataHub, described the underlying incident as ransomware. No verified reopening time, confirmed investor-data breach, ransomware family or attacker attribution was established in the reviewed evidence.
NEPSE ransomware outage: what is confirmed now?
Several current Nepal reports agree on the central operational state: Monday’s trading session was suspended, 72 brokerage firms were affected by the DataHub disruption, and the problem began during the previous day. NEPSE acted after the Stock Brokers’ Association requested a market-wide suspension and the exchange cited risk to its trading system.
The strongest detailed reporting attributes the incident to ransomware through statements from YCO and information attributed to DataHub. That ransomware state should remain attributed because a directly retrievable DataHub incident bulletin or full technical report was not recovered during the completed research.
Was NEPSE itself hacked?
The available evidence does not establish that NEPSE’s core matching or exchange infrastructure was directly encrypted by ransomware. What is confirmed is that systems used by 72 brokers at DataHub were disrupted and that NEPSE suspended market operation because the shared outage created unacceptable operational risk.
This distinction matters. A ransomware incident at infrastructure used by broker systems can force a market-wide halt without proving that every connected system, depository service or exchange server was independently compromised.
Which systems were affected?
YCO said the incident affected or required isolation of broker Trading Management System infrastructure and interconnected services including CDSC-related systems, payment gateways and other linked services.
That wording should not be converted into a claim that CDSC, payment gateways or every downstream service was separately breached. An interconnected service can be unavailable, isolated or operationally dependent on an affected environment without being independently compromised.
Why were all trades halted if 72 brokers were affected?
NEPSE did not treat the event as a normal single-broker outage. The disruption affected a large shared broker-services environment, and the brokers’ association requested suspension. NEPSE said continuing trading under the circumstances could create further risk to market operations.
A market-wide pause also avoids allowing some participants to trade normally while a large group of brokers cannot access essential systems, although the detailed operational decision criteria used by NEPSE were not published in the reviewed evidence.
Was investor data stolen?
No confirmed investor-data theft was established in the reviewed evidence. Ransomware incidents can involve encryption, data theft or both, but those possibilities should not be treated as confirmed facts without forensic or incident-response findings from DataHub, YCO, NEPSE, SEBON or another authoritative source.
The same caution applies to credentials, order data, settlement information and other customer records. Their exposure remains unknown.
When did the DataHub incident begin?
Current NEPSE-related reporting places the initial DataHub problem at around 4am on Sunday, September 20. The impact persisted into Monday’s trading day, leading to the suspension of the regular NEPSE session.
Did disaster recovery fail?
Some market commentary has questioned why disaster-recovery infrastructure did not keep broker trading services available. The reviewed evidence does not establish the detailed architecture, recovery-point design, trigger conditions or technical state of the relevant disaster-recovery systems.
TPS therefore does not describe this as a confirmed disaster-recovery failure. That conclusion would require a technical incident report or authoritative operational disclosure.
When will NEPSE trading resume?
No verified reopening time was established in the completed research. Trading resumption depends on NEPSE being satisfied that the affected broker and supporting infrastructure is sufficiently restored and safe for market operations.
The next material update should therefore be an official trading-resumption notice, another closure notice, or a clear restoration statement from NEPSE, YCO, DataHub or the relevant regulator.
What investors and brokers should check now
- Confirm the latest NEPSE trading status before attempting to place orders.
- Check the broker’s own TMS or service-status communication because restoration may not be uniform across every brokerage.
- Do not assume an order, payment or settlement instruction is processing normally while related infrastructure remains disrupted.
- Do not treat social-media claims of stolen investor data, ransom payment or attacker identity as confirmed unless an authoritative source verifies them.
- Preserve any broker-side operational or security alerts relevant to failed access, account changes or unexpected activity.
- Watch for NEPSE, YCO, DataHub or SEBON guidance on restoration, data exposure and any required user action.
What is the difference between the DataHub incident and the NEPSE closure?
The DataHub event is the underlying infrastructure incident. Broker systems hosted or dependent on that environment became unavailable or were isolated. NEPSE’s market closure was the operational response to the resulting trading risk.
Those are related but different states: a cybersecurity incident disrupted shared broker infrastructure, and the exchange then suspended trading to reduce further market-operational risk.
What remains unknown?
The reviewed evidence does not establish whether investor or customer data was exfiltrated, whether NEPSE’s own core systems were directly compromised, the ransomware family, the attacker identity, the initial-access vector, the precise technical scope inside DataHub or the exact recovery completion time.
It is also not yet clear whether every CDSC- or payment-related component mentioned in current reporting was directly affected, deliberately isolated, or simply unavailable because of a dependency on the disrupted environment.
What happens next?
The most important next states are a NEPSE trading-resumption notice, a further closure notice, restoration of broker TMS services, DataHub or YCO incident findings, SEBON guidance, confirmation or exclusion of data theft, and any verified ransomware attribution.
Those developments should update this same URL while the core reader task remains understanding the current NEPSE outage state, what infrastructure is affected and whether investors need to take any additional action.
Verification note
TPS reviewed current Nepal reporting that quotes or references NEPSE, YCO, DataHub and the Stock Brokers’ Association, and reconciled the consistent facts around the Monday trading suspension and 72-broker disruption. A directly retrievable DataHub forensic notice, confirmed breach report and verified reopening time were not available in the completed research.