Japan's FSA Publishes a Crypto-Asset Cybersecurity Research Paper: One Class of Outflow Was Not Key Theft but Tampering Before Signing

On July 23, 2026, Japan's Financial Services Agency (金融庁, the FSA) published a research paper on cybersecurity issues and countermeasures in crypto-asset-related businesses, on the innovation policy page of its website. The date printed on the paper's cover is June 30, 2026, and the author named on it is Deloitte Tohmatsu LLC (合同会社デロイトトーマツ). On the same day, on a separate announcement page, the FSA also added the English version of the cybersecurity policy approaches it had itself set out on April 3, 2026.

This article was fact-checked on September 17, 2026, against the Japanese version of that policy page, the English PDF of the research paper, the FSA's announcement page of April 3, and the English policy approaches filed as Annex 3 on that page. One thing has to be settled first: this paper is not the FSA's view. On the publication page the FSA states plainly 「※上記リサーチペーパーは、当庁の見解、意見等を示すものではありません。」 — the research paper above does not represent the views or opinions of the agency — and page 2 of the paper says its contents do not represent the official views of the Financial Services Agency and that any errors in it are the sole responsibility of the contractor. So this article writes “the report says” throughout for the paper, and “the FSA says” only for the policy approaches; we have tested nothing ourselves, and this is not investment or legal advice.

What was published on July 23: one commissioned research paper

The paper was published in the latest-information list on that policy page, as the first item under 2026, with three PDFs beneath it — the Japanese paper, the English paper and a Japanese summary — and the disclaimer line printed immediately below the links. On the day this article was checked the page was marked 「令和８年７月23日更新」, that is, updated July 23, 2026. That is the page's update date: update the page again and the date changes.

The paper's own disclaimer is worth reading too. Page 2 says any errors in the report are the sole responsibility of the contractor, and that its case studies were compiled for research purposes from information published about each case and do not indicate the attribution of responsibility or any legal assessment. The acknowledgments on the same page also record advice and comments from officials of the Financial Services Agency — which is exactly where the line between commissioned research and an official view sits. The document the FSA signs itself is the policy approaches, and it opens with the lines April 3, 2026 and Financial Services Agency.

Four dates, kept apart: draft, adoption, cover, publication

The policy approaches did not first appear on July 23. The FSA's announcement page of April 3, 2026 says the draft was put out for public comment from 令和８年２月10日 to 令和８年３月11日, that is from February 10 to March 11, 2026, and that 「計18件のコメント」, 18 comments in all, were received; the FSA then made the necessary additions and corrections in the light of those comments before settling the document.

The head of that same page carries 「令和８年４月３日」 and 「令和８年７月23日更新」, and after Annex 1 and Annex 2 it says 「令和８年７月23日、以下の英語版を公表しました。」 — on July 23, 2026 the following English versions were published — and then lists Annex 3 and Annex 4. So the policy approaches were set out on April 3, 2026, July 23, 2026 is the date the English version was published, and the June 30, 2026 on the paper's cover is the date of the paper itself.

How the report re-reads the asset outflows of recent years

The paper's summary of findings says attacks on crypto-asset-related businesses have continued and grown in scale in recent years, and that the routes taken have become more varied, more sophisticated and more organized year by year. Attackers, the report says, are increasingly targeting not only systems themselves but also operational infrastructure, and the examples it gives are signing keys, wallets, access controls, CI/CD, cloud IAM/KMS and signing services. A signing key is the secret key defined in note 1 of the policy approaches: the key used for proving that a transaction was conducted by a person with the legitimate authority.

The most important sentence comes straight after it. Having analyzed recent incidents, the report says, it confirmed attacks that did not involve the theft of signing keys themselves, but instead tampered with components, for example the user interface, APIs, CI/CD, unsigned transaction generation logic and production programs, causing fund outflows by abusing legitimate signing processes. The lessons it draws from the case studies go on to say that the starting point of these incidents is the compromise of developer privileges through social engineering or phishing, or the deployment of malware, and that tampering with UIs and APIs made it difficult for signers to notice that the transaction is fraudulent, and thus they proceeded with signing.

The report also makes a structural judgement: crypto-asset-related services in the real world do not operate in a purely decentralized model, so a risk assessment has to encompass not only on-chain code and protocols but also off-chain components, operational controls, external dependencies and governance. Its case studies are numbered (1) to (10); by the report's own account it analyzed recent cases of crypto-asset-related services including DeFi, focusing on major attack methods that resulted in large losses, and the examples it gives are third-party compromises, smart contract vulnerabilities, flash loan attacks and malware attacks. This article does not name the businesses or protocols in those cases, and the loss amounts and incident counts the report cites all come from outside organizations, so they are not written here either.

The FSA's own policy approaches: cold wallets alone are not enough

Chapter 1 of the policy approaches says recent cases involving the outflow of cryptoassets are not necessarily caused by the theft of signing keys, and that various sophisticated methods have become prominent instead, including indirect attacks such as social engineering and intrusions into outsourcees, with cases where attackers spent time preparing in advance without the provider noticing. Against that background the document writes its key sentence: the safe management of cryptoassets cannot be ensured only by the use of cold wallets; rather, it is definitely necessary to strengthen the cybersecurity management systems of the entire supply chain, including outsourcees. The policy approaches also record that a case of an outflow of cryptoassets deposited by users had actually occurred in Japan, and in the passage on focused supervision they say that, in light of the large-scale outflow of cryptoassets in the past, the FSA has intensively monitored countermeasures against outflow risks and system risk management at individual providers.

The document divides its policy framework into self-help, mutual assistance and public assistance. On self-help, the FSA says that from Program Year 2026 onward it will request all cryptoasset exchange service providers (暗号資産交換業者) to conduct the cybersecurity self-assessment (CSSA) it has asked other types of financial institution to do, or otherwise hold dialogue with them as needed; note 10 explains that the CSSA is a self-assessment against questions consistent with the Guidelines on Cybersecurity for the Financial Sector, which lets a provider understand the position of its own organization within the industry and improve autonomously. The FSA also says it will endeavor to raise the levels of cybersecurity expected of these providers by revising the Guidelines for Supervision, and the directions it gives as examples are requirements for cybersecurity staffing, for external audits and for outsourcees. On public assistance, the FSA will keep requesting providers to take part in Delta Wall, the cross-industry exercise, aiming to achieve the participation of all service providers within three years, and within 2026 it will conduct threat-led penetration testing (TLPT) targeting several providers regarding their actual operational environments.

On mutual assistance, the body of the document says only “the self-regulatory organization”; JVCEA appears in note 11, which links to that association's organizational chart. The FSA also encourages providers to participate in information sharing organizations, such as JPCrypto-ISAC. None of this is a newly added statutory obligation, though: the policy approaches carry no penalty, on the Guidelines for Supervision they go no further than revising them and endeavoring to raise the levels, and they set out neither an amended provision nor an effective date; the participation of all providers within three years has no stated starting point; and the TLPT does not say which providers, only that the assessment results go to the targeted providers individually and the common issues extracted from them go back to the industry as a whole.

What this has to do with readers in Taiwan

The boundary first. The policy approaches are addressed to Japan's cryptoasset exchange service providers; neither document mentions Taiwan, and neither says Japan's rules apply to users or platforms in Taiwan. What a reader here can take away is the shape of the problem. The report says that where a provider's wallet system uses a third-party service, it remains important — even if signing keys are not entrusted to the third party — to confirm that the third party has appropriately established and operates controls such as cyberattack countermeasures, production-environment access management and program/change management. Separately, the report says a compromise at an outside service provider may spill over into the provider's own service or its users' assets.

The other layer is what people who hold their own wallets do every day. One page of the report is given to verifying transaction details at the time of signing and to blind signing: with a complex smart contract transaction a wallet may not be able to present the details in a human-readable format, and a hardware wallet is further constrained by screen size and UI design. So the report writes one sentence for the person doing the signing: when signing a complex transaction involving a smart contract, signers should understand not only the recipient address and transfer amount, but also what operation the transaction will perform, what privileges it will grant, and to whom.

The report records that on May 12, 2026 the Ethereum Foundation, together with wallet developers, security firms and other ecosystem participants, announced Clear Signing, and that ERC-7730, the core technology of Clear Signing, is a JSON-based descriptor standard. It warns in the same breath that the effect depends on whether the information displayed is correct, whether the descriptor is trustworthy and which model each wallet adopts; an error in a descriptor or a compromised distribution channel could produce a misleading display, so what it shows cannot be treated as unconditionally safe. One more boundary: this report is written for businesses and regulators, and the version checked for this article carries no self-protection checklist for ordinary users. The following is an example designed by the editors, not official advice: when a phone wallet raises an approval you cannot read, one question to start with is what this transaction is asking me to authorize, and to whom.

2026 Crypto News Roundup: Key Developments in Regulation, Technology and Industry

Taiwan's Virtual Asset Service Act Clears Third Reading: Seven Kinds of Provider, Stablecoin Licensing, No Commencement Date Yet

• Money & finance
• Crypto & blockchain