Monex pauses account services as IwaiCosmo discloses unauthorised orders

Monex has interrupted customer-facing services while investigating access to outsourced systems. Separately, IwaiCosmo has disclosed that an attack generated unwanted orders in seven accounts. The notices identify different operational exposures; they do not establish a common attacker or a shared cause.[1][2]

Monex separates account opening from existing accounts

In a notice updated at 17:00 Japan time on 21 October, Monex said it had paused new comprehensive securities-account applications through the affected routes from 19 October. These include its website, app and some partners. The trigger was evidence of attempted third-party access to a contractor-managed onboarding system.[1]

A separate 19:00 update said unauthorised access had been confirmed at a supplier supporting its Japanese-equity Stock Scouter. Monex suspended its Japanese, US and Chinese-equity Scouter services that day; Scouter Light remained available. It said no customer-information leakage had been confirmed. Both notices distinguish the affected systems from those managing existing account information, balances and trades. Reopening depends on safety checks, with no date given.[1]

For a prospective customer, an unavailable application route delays entry to the broker. For an existing customer using research tools, the interruption removes information used in making decisions. Neither situation can be described accurately by the blanket phrase “trading is down”. The service boundary is part of the news, because it determines whose activity is actually interrupted.

IwaiCosmo’s update adds an order-management failure

IwaiCosmo’s first notice, issued on 16 October, identified TradeWorks as the contractor operating and maintaining its internet-trading system. It said an intrusion was detected on 14 October, prompting emergency access restrictions. The initially disclosed information leakage affected 4,611 customers and included names and email addresses. The broker contacted those customers individually and warned about impersonation by telephone or email.[3]

The broker said the unauthorised orders did not use the leaked personal information. Trading PINs were not among the leaked data. It also explained that it had delayed disclosing the order attack while countermeasures were being introduced, and apologised for that delay. These distinctions keep two consequences of the incident separate: disclosure of customer information and misuse of trading infrastructure.[2]

The administration path matters as much as customer login

TradeWorks’ own 16 October filing provides the clearest technical explanation. It said multifactor authentication and passkeys had protected normal customer-login routes, but an improperly configured administration function was exploited. The supplier acknowledged shortcomings in its management. It had not confirmed that customer passwords were obtained through the affected function.[4]

The supplier said it disabled the abused function, invalidated unauthorised connections and blocked attack traffic. Its statement also described checks at other financial institutions using its systems, with no similar incident confirmed at that point. It said further review would include an external specialist.[4]

TradeWorks said it intended to bear the resulting losses and response costs, with the amount under examination and cyber-insurance coverage expected. An expected insurance recovery is not a confirmed payment. For brokers relying on external trading technology, the case illustrates why incident responsibility includes the administrative controls behind the customer screen, the restoration of affected orders and the allocation of remediation costs.[4]

Report an error or submit an update