On August 21, 2026, Japan's Fair Trade Commission said it would examine whether Apple or Google used commercially sensitive information obtained through interoperability requests to gain a competitive advantage, according to MLex's report. The statement followed complaints from companies seeking access to mobile operating system functions. The JFTC is also preparing a statutory review of the Mobile Software Competition Act (MSCA). The Coalition for App Fairness and Japanese competition scholars have criticized the companies' July compliance reports. The statement is small, but it exposes the central design problem in Japan's approach.
The case for the regulator's concern
The strongest argument for scrutiny is structural. Under the MSCA, a rival developer that wants access to an OS function must tell the platform owner what it intends to build. That request reveals a product roadmap to a company that may compete with it. If the owner can see the request and also ship a competing feature, the interoperability mandate becomes a tool for gathering intelligence on rivals.
This is not a hypothetical worry invented by lobbyists. The JFTC's own guidelines, summarized by Wolters Kluwer, define covered data to include user attributes, device identifiers and payment information. They bar designated providers from using it to benefit their own services. A regulator that investigates complaints about this is doing what the statute asks.
What the Act does, and when
The MSCA was passed on June 12, 2024. It covers mobile operating systems, app stores, browsers and search engines. According to the JFTC's digital policy page, provider designation provisions took effect on December 19, 2024, and the Act came into full effect on December 18, 2025. The JFTC finalized its guidelines on July 29, 2025, after receiving 105 comments in a consultation that ran from May 15 to June 13, 2025, as its press release records.
The guidelines require designated providers to give third parties access to OS functions with equivalent performance, though not necessarily through identical technical means. They allow a closed list of exceptions: cybersecurity, user privacy, protection of minors, hardware safety and prevention of crime. Each exception must pass necessity and proportionality tests, meaning the provider must show that no less restrictive alternative exists. Article 13 also requires annual compliance reports to the JFTC.
The verification gap
The guidelines contain an admission that matters here. As summarized by Wolters Kluwer, the JFTC states that it is difficult to externally verify whether data subject to the Article 5 prohibition has been used. The Act therefore relies on internal compliance systems, which providers build and describe themselves.
That is a weak foundation for either side. If misuse cannot be verified, complainants can allege it without proof, and the platforms cannot clear their names. A rule that is hard to audit tends to produce suspicion and litigation instead of compliance. It also gives companies a reason to be cautious about interoperability, which is the opposite of what the law intends.
Critics of the July compliance reports say the platforms have not shown enough. Whatever the merits of those complaints, an annual self-reported document is poorly suited to settling a question about internal data flows. The reports can describe a firewall. They cannot demonstrate that engineers on a competing product team never saw a request.
A proportionate path for the statutory review
The coming review gives the JFTC a chance to fix this without widening the Act's reach. Three changes would do more than additional prohibitions:
- Specify the evidence. The guidelines should say what a credible data-segregation record looks like: access logs, team separation and retention limits for request data. Providers could then show compliance, and the JFTC could test it against a known standard.
- Use third-party audits. Independent technical audits of how request data is handled would give the JFTC something checkable, and they impose less cost than blanket rules on product design.
- Publish aggregate outcomes. Statistics on requests received, granted, denied and the grounds for denial would let developers, scholars and the platforms themselves see whether interoperability is working. Today the debate runs on anecdote.
These steps also protect the legitimate security exceptions. Equivalent-performance access to OS functions carries real risks, and the Act's necessity and proportionality tests were written to handle them. The risk is that vague enforcement pushes platforms toward blanket refusals dressed up as security, or pushes regulators toward blunt orders that weaken protections users value.
Why this matters beyond Japan
Other jurisdictions are watching how ex ante regimes work in practice. Japan chose a narrower, more guideline-driven design than some peers, and it has so far preferred consultation to penalties. That restraint is a strength, and the JFTC's decision to examine a specific allegation instead of issuing a general warning is consistent with it.
The test now is whether the review turns that restraint into clear, auditable rules. A competition law that cannot tell a compliant platform from a violating one will frustrate challengers and incumbents alike. Japan has the chance to show that interoperability mandates can be enforced through evidence instead of mutual accusation.