Finance au Japon : cyberincidents de 2026 et cadre FSA face à DORA

Votre groupe a une succursale bancaire à Tokyo, une filiale d’assurance ou une société de gestion au Japon ? Les incidents publiés en 2026 dans la finance japonaise ont un point commun : dans la plupart des cas, l’attaquant n’a pas « cassé » un système. Il est entré par une porte légitime : identifiants volés par hameçonnage, requêtes au format d’un usage normal, environnement de test oublié, prestataire chargé de la relation client.

Dans le même temps, l’Agence des services financiers (Financial Services Agency, FSA), qui supervise banques, assureurs et intermédiaires au Japon, a resserré ses attentes. L’authentification résistante au hameçonnage est désormais attendue dans tous les grands secteurs. Depuis le 1er octobre 2026, les déclarations d’incidents passent par des formulaires communs à l’administration. Le 9 octobre 2026, la FSA a demandé aux établissements de revoir leur gestion des risques liés aux tiers et leur dispositif de réponse aux incidents.

Cet article s’adresse aux RSSI, DSI et responsables de la conformité des groupes français. Il résume les incidents de 2026 à partir des communiqués officiels, compare le cadre japonais avec DORA et la supervision de l’ACPR et de l’AMF, puis liste ce qu’il faut vérifier dans votre entité japonaise. Les faits sont arrêtés au 19 octobre 2026 ; plusieurs enquêtes sont en cours.

L’essentiel en trois points

• La menace : prise de contrôle de comptes-titres (19 252 accès frauduleux et 10 642 transactions frauduleuses entre janvier 2025 et septembre 2026, chiffres provisoires de la FSA), fuite massive chez un assureur (environ 4,4 millions de clients chez Aflac Life Insurance Japan) et fuites chez des prestataires.
• Le cadre : pas de règlement unique comme DORA, mais une ligne directrice cybersécurité de la FSA (2024) et des lignes directrices de supervision par secteur. Celles-ci imposent la déclaration « immédiate » des incidents et, depuis 2025-2026, une authentification résistante au hameçonnage pour les opérations en ligne sensibles.
• Pour un groupe français : un même incident au Japon peut déclencher une déclaration à la FSA, une notification au titre de la loi japonaise sur les données personnelles et une déclaration DORA à l’ACPR ou à l’AMF. Les délais, les formulaires et les langues diffèrent : la procédure doit être prête avant l’incident.

2026 en chiffres : l’usurpation plutôt que l’intrusion

Les comptes-titres en ligne

La vague a commencé au printemps 2025. Des sites imitant les courtiers en ligne ont permis de voler identifiants et mots de passe. Les fraudeurs se sont ensuite connectés aux comptes des victimes, ont vendu leurs titres et acheté avec le produit de petites capitalisations japonaises ou étrangères. Selon le rapport annuel de l’Agence nationale de police (National Police Agency, NPA), l’année 2025 a compté 17 668 accès frauduleux et 9 824 transactions frauduleuses, pour environ 740,8 milliards de yens de ventes et d’achats frauduleux. La NPA recense aussi 316 414 signalements de courriels d’hameçonnage se faisant passer pour des sociétés de bourse. En novembre 2025, la police a procédé à des arrestations pour manipulation de cours et accès frauduleux.

La FSA publie un tableau mensuel, mis à jour pour la dernière fois le 9 octobre 2026. Le pic date d’avril 2025, avec 5 490 accès frauduleux et 3 033 transactions frauduleuses. Sur les neuf premiers mois de 2026, le total tombe à 1 535 accès et 781 transactions : 18 accès en juillet, 43 en août, 37 en septembre. La FSA précise que ces chiffres sont provisoires, que des cas restent peut-être à découvrir et que les montants de transactions ne correspondent pas aux pertes des clients.

La banque en ligne et les rançongiciels

En 2025, les virements frauduleux en banque en ligne ont atteint 4 747 cas et environ 10,4 milliards de yens ; l’hameçonnage explique environ 90 % des cas. Au premier semestre 2026, la NPA compte 253 cas pour environ 2,07 milliards de yens, soit une baisse de 51 % sur un an.

La NPA signale cependant un nouveau mode opératoire depuis mai 2026. Le fraudeur appelle une entreprise, lui fait installer un logiciel de prise de main à distance, puis l’amène sur un faux site pour récupérer ses identifiants de banque en ligne. Le virement est ensuite effectué depuis le poste habituel de l’entreprise. Selon la NPA, le but est de contourner l’authentification du terminal et la surveillance des transactions par la banque.

Durant ce même semestre, 123 cas de rançongiciel ont été signalés à la police, un record pour un semestre depuis le début de la statistique en 2020. Selon les organisations touchées, environ la moitié des intrusions sont passées par un équipement VPN.

Les incidents marquants de 2026

Aflac Life Insurance Japan : un accès qui ressemblait à un usage normal

L’assureur a constaté le 25 juin 2026 que des informations de clients et d’agences avaient été consultées et exfiltrées via deux services en ligne : la consultation en ligne et le portail « Aflac Yorisou Net ». Il a coupé l’accès et arrêté les systèmes le jour même. L’enquête a établi que la première fuite datait du 10 juin. Le 30 juin, jour de la publication, la FSA lui a adressé un ordre de communication d’informations, fondé sur la loi sur l’activité d’assurance (Insurance Business Act) et sur la loi sur la protection des informations personnelles (APPI).

Les données concernées sont le nom, la date de naissance, l’adresse et le numéro de téléphone du souscripteur, le numéro de police, les garanties et, pour environ 220 000 clients, les coordonnées du compte bancaire de prélèvement. Le numéro d’identification individuel japonais, les données de carte et les adresses électroniques n’en font pas partie.

Le rapport du 31 juillet est instructif. Les systèmes disposaient d’une détection des accès frauduleux, mais l’accès avait « le même format qu’un usage normal » et n’a pas été détecté tout de suite. Il manquait aussi une fonction de surveillance et de blocage des consultations massives sur une courte période. Enfin, l’assureur indique qu’il réalisait déjà des revues de sécurité lors de la conception et des tests d’intrusion avant mise en production, mais que ces contrôles n’avaient pas envisagé la technique utilisée. Les mesures annoncées portent sur l’authentification et les autorisations lors des consultations, la surveillance des volumes, des revues et tests d’intrusion plus poussés, et le renforcement des équipes de sécurité.

La leçon pour un RSSI : la question n’est pas seulement « qui peut se connecter », mais « combien de données un compte peut consulter, et à quelle vitesse ».

Awa Bank : l’environnement de test qui aurait dû disparaître

Le 24 mars 2026, une société de sécurité externe a prévenu la banque qu’elle constatait une possible fuite de ses données. Le 25 mars au soir, la banque a confirmé qu’il s’agissait bien de ses données. L’accès visait l’environnement de test d’un système interne de partage d’informations, séparé des systèmes de transaction ; les opérations des clients n’ont pas été affectées.

Le rapport du 3 juin reconnaît trois défaillances de gestion. L’environnement aurait dû être supprimé à la fin du projet, mais il a continué à servir, notamment pour des travaux sur l’IA. Les données clients auraient dû être effacées après le développement, ce qui n’a pas été fait. Enfin, les protections contre les accès frauduleux ne fonctionnaient pas correctement. La cause directe : quelqu’un a utilisé illégitimement des identifiants pour s’y connecter depuis l’extérieur.

Daiwa Securities : le prestataire de la relation client

Daiwa Securities utilisait un service de Scala Communications pour gérer les demandes reçues de ses clients par Internet. Selon la maison mère du prestataire, Scala, un tiers s’est connecté frauduleusement à la console d’administration du système de FAQ « i-ask » dans la nuit du 2 au 3 octobre 2026. Il y a installé un programme malveillant, puis récupéré des données dans les bases des clients hébergés sur le même serveur, au nombre de cinq au maximum. L’alerte de surveillance de la base a déclenché l’enquête et l’accès a été coupé le 3 octobre vers 8 h.

Scala chiffre la fuite possible à 713 126 demandes au maximum, sans nommer ses clients. Daiwa Securities indique que ses propres systèmes n’ont pas été touchés et que ces informations ne permettent ni d’accéder aux comptes ni de passer des ordres. La société a lancé un contrôle de ses autres prestataires et annonce un réexamen de sa gestion des sous-traitants. Pour un groupe français, le cas illustre un risque classique de tiers : un service SaaS mutualisé, rarement classé comme critique, qui détient pourtant des données clients.

Dai-ichi Life : les annuaires internes comme matière première

Le système RH partagé par Dai-ichi Life Group et Dai-ichi Life Insurance contenait des numéros d’employé, noms, adresses, téléphones, services, fonctions et noms des supérieurs hiérarchiques. Environ 120 000 personnes sont concernées. Aucun accès aux données clients n’a été constaté et le point d’entrée n’a pas été publié. Ce type de fichier sert pourtant à crédibiliser des courriels ou des appels frauduleux qui se font passer pour un collègue ou un responsable.

Le cadre japonais : ce que la FSA attend

Une ligne directrice transversale, appliquée selon les risques

La FSA a publié en octobre 2024 sa ligne directrice sur la cybersécurité du secteur financier (Guidelines on Cybersecurity for the Financial Sector). La dernière révision, en juillet 2025, est technique : elle tient compte de la transformation de l’ancien centre national NISC en Bureau national de cybersécurité (National Cybersecurity Office). C’est la version en vigueur en octobre 2026. La FSA en publie une traduction anglaise provisoire.

Le texte couvre la gouvernance, l’identification, la protection, la détection, la réponse et la reprise, ainsi que la gestion du risque de tiers. Il distingue des « mesures de base », attendues de tous, et des « mesures recommandées » pour les grands établissements. Il ne s’agit pas d’une obligation uniforme : chaque établissement applique une approche fondée sur les risques, et la FSA la vérifie lors de ses contrôles. Le texte s’applique notamment aux banques, assureurs, sociétés d’instruments financiers et prestataires de paiement.

Deux points intéressent directement une entité étrangère :

• Les tests : audits de vulnérabilités et tests d’intrusion réguliers, y compris avant mise en production, sont des mesures de base. Le test d’intrusion fondé sur la menace (TLPT) est une mesure recommandée.
• Les tiers : la ligne directrice demande un registre des prestataires (services, niveau d’accès, type, sensibilité et localisation des données), une évaluation des risques et des clauses contractuelles précises : responsabilités, droit d’audit, sous-traitance, déclaration des incidents, localisation et destruction des données. La logique est très proche de DORA.

Pour les succursales de banques étrangères, la ligne directrice de supervision des grandes banques (Comprehensive Guidelines for Supervision of Major Banks) contient un chapitre dédié. La FSA y attend que le siège ou la direction régionale supervise la gestion du risque opérationnel de la succursale, risque informatique compris. Elle attend aussi qu’en cas de fuite de données clients, la succursale et le siège puissent répondre vite et s’expliquer auprès des clients et des autorités.

L’authentification résistante au hameçonnage, secteur par secteur

Après la vague de 2025, la FSA a révisé ses lignes directrices de supervision en trois temps : les sociétés d’instruments financiers le 15 octobre 2025, puis les banques, coopératives et plateformes de crypto-actifs le 27 février 2026, et enfin les assureurs, prêteurs, prestataires de transfert de fonds et autres le 17 juillet 2026. Chaque révision s’applique dès sa publication.

Le texte pour les assureurs illustre le niveau attendu. Pour les opérations sensibles (connexion, retrait, désignation ou modification du compte de versement), l’établissement doit mettre en place une authentification multifacteur résistante au hameçonnage, par exemple une passkey ou une méthode fondée sur une PKI, et l’activer par défaut. En attendant, il doit proposer une autre méthode multifacteur, publier son calendrier et renforcer la détection : analyse comportementale à la connexion, notifications aux clients, verrouillage après plusieurs échecs.

La DSP2 impose déjà l’authentification forte en Europe, mais pour les comptes de paiement. Le texte japonais nomme les méthodes attendues et vise aussi les comptes-titres et les espaces clients des assureurs.

La déclaration des incidents depuis le 1er octobre 2026

Les lignes directrices de supervision demandent de signaler l’incident à la FSA dès qu’il est connu, puis d’envoyer un rapport écrit sur les causes, les dommages, la réponse et les mesures correctives. Il faut faire un nouveau rapport au rétablissement et à l’identification de la cause. Si ni l’un ni l’autre n’est acquis, un point de situation est dû dans un délai d’un mois. Une cyberattaque détectée ou annoncée doit aussi être déclarée, même sans panne, si elle est fortement susceptible d’affecter les clients ou l’activité.

La révision publiée le 18 septembre 2026 a changé les formulaires à partir du 1er octobre 2026. Les établissements utilisent désormais les formulaires communs définis par un accord entre ministères : un pour les attaques DDoS, un pour les rançongiciels et, depuis le 15 septembre 2026, un pour les autres cyberattaques. Pour un rançongiciel ou une autre cyberattaque, le formulaire commun peut aussi servir de notification de fuite de données personnelles. Jusqu’à fin mars 2027, l’ancien formulaire de la FSA reste accepté pour les établissements qui ne sont pas désignés comme opérateurs d’infrastructures essentielles au titre de la loi sur la sécurité économique.

La fuite de données personnelles suit en plus les règles de l’APPI : un rapport préliminaire rapide (3 à 5 jours après la découverte, selon la Commission de protection des informations personnelles, PPC), puis un rapport définitif dans les 30 jours, ou 60 jours si elle a pu être commise dans un but malveillant. Pour les établissements financiers, ce rapport va en principe à la FSA, à qui la PPC a délégué ce pouvoir. Une loi de réforme de l’APPI a été promulguée le 17 juillet 2026 et entrera en vigueur, en principe, dans les deux ans. Elle prévoit notamment d’assouplir l’information des personnes lorsque le risque est faible. Nous détaillons ces règles dans notre article sur la notification des fuites selon l’APPI et le RGPD.

Ce dispositif est effectivement utilisé : la FSA indique avoir reçu environ 1 600 déclarations de pannes informatiques au cours de l’exercice 2025. Son rapport de juillet 2026 sur la résilience informatique demande aussi de revoir la criticité des prestations confiées selon les données transmises, de contrôler aussi les sous-traitants des prestataires et d’inscrire dans les contrats l’obligation de déclarer les incidents.

FSA et DORA : la comparaison

En pratique, l’écart tient moins au fond qu’à la forme. DORA fixe des délais en heures et des critères de classification. La FSA demande une déclaration « immédiate », sans délai chiffré, et elle utilise largement les ordres de communication d’informations après coup, comme pour Aflac. Une équipe de Tokyo habituée au cadre japonais ne pensera pas forcément à l’horloge DORA, et une équipe parisienne ne connaîtra pas forcément les formulaires japonais.

Ce que le RSSI du groupe doit vérifier dans l’entité japonaise

1. Le régime applicable

Établissez par écrit de quelle ligne directrice relève votre entité : succursale bancaire (grandes banques, chapitre des succursales étrangères), filiale d’assurance (assureurs) ou société de gestion (sociétés d’instruments financiers). Vérifiez aussi si elle est désignée comme opérateur d’infrastructure essentielle, ce qui change les règles de transition jusqu’en mars 2027. Côté européen, faites confirmer par votre conformité comment l’entité japonaise entre dans le dispositif DORA du groupe. Une succursale n’a pas de personnalité juridique distincte de l’établissement français ; une filiale japonaise, si.

2. Une procédure unique pour plusieurs déclarations

• Qui, à Tokyo, appelle la FSA, et en japonais ? Qui, à Paris, classe l’incident au regard de DORA et déclare à l’ACPR ou à l’AMF ?
• Les formulaires communs japonais sont-ils prêts, pré-remplis pour ce qui peut l’être ?
• Le décalage horaire (7 à 8 heures entre Tokyo et Paris) est-il prévu dans la chaîne d’escalade, en particulier pour la notification DORA de 4 heures ?
• La notification APPI, et le cas échéant RGPD, est-elle intégrée à la même procédure ?

3. L’authentification des clients japonais

Si l’entité propose des services en ligne aux clients au Japon (espace assuré, compte-titres, banque en ligne pour les entreprises), vérifiez que la connexion, les retraits et la modification du compte de versement exigent par défaut une méthode résistante au hameçonnage. Étendez la même exigence aux comptes d’administration du personnel et des prestataires.

4. Les autorisations et les volumes de consultation

Pour chaque application ou API qui donne accès aux données clients, demandez quelles données un compte peut consulter et s’il existe une limite de volume, une alerte et un blocage automatique. C’est exactement ce qui manquait chez Aflac. Un test d’intrusion qui ne cherche que des vulnérabilités techniques ne couvre pas ce point.

5. Les environnements hors production

Demandez la liste des environnements de test, de développement et de validation, ceux qui contiennent des données réelles et ceux qui sont accessibles depuis Internet. Fixez une règle de suppression en fin de projet et de masquage des données. Le cas d’Awa Bank montre qu’un environnement « temporaire » peut durer des années.

6. Les prestataires locaux

Les prestataires choisis localement (SaaS de relation client, centres d’appels, agences, éditeurs japonais) échappent souvent au registre du groupe. Rapprochez la liste de l’entité japonaise de votre registre d’informations DORA. Pour chaque prestataire, vérifiez la localisation des données, l’hébergement mutualisé, le délai de notification d’incident et le droit d’audit. Le cas Scala montre qu’un seul serveur peut héberger les données de plusieurs clients. Nous traitons ce sujet dans notre article sur les attaques par la chaîne d’approvisionnement.

7. Les tests

Vérifiez que les systèmes exposés de l’entité japonaise sont testés régulièrement et avant chaque mise en production, et que les résultats importants remontent à la direction, comme l’attend la FSA. Si votre groupe mène des TLPT au titre de DORA, demandez-vous si un scénario doit inclure l’entité japonaise. Les exigences japonaises sur le TLPT sont présentées dans notre guide du TLPT pour les établissements financiers.

8. Le personnel et les clients entreprises

Après les cas Dai-ichi Life et les appels frauduleux avec prise de main à distance décrits par la NPA, sensibilisez le personnel et les entreprises clientes de la banque en ligne : un appel « du support » qui demande d’installer un logiciel est un signal d’alerte. Vérifiez aussi si votre entité participe à l’exercice de crise sectoriel de la FSA, Delta Wall, organisé du 6 au 22 octobre 2026 avec 181 établissements participants prévus.

Questions fréquentes

Q1. Notre succursale à Tokyo relève-t-elle de DORA ou de la FSA ?

En pratique, des deux. Au Japon, la FSA supervise les succursales de banques étrangères dans le cadre de sa ligne directrice pour les grandes banques et leur applique sa ligne directrice cybersécurité. En Europe, la succursale fait partie de l’établissement français soumis à DORA. Le périmètre exact, en particulier pour la classification des incidents et le registre d’informations, est à valider avec votre conformité.

Q2. La FSA fixe-t-elle un délai en heures comme DORA ?

Non. Elle demande un signalement dès que l’incident est connu, puis des rapports au rétablissement et à l’identification de la cause, avec un point de situation sous un mois au plus tard. Les délais APPI s’ajoutent en cas de fuite de données personnelles. Le délai japonais n’est pas chiffré, mais « immédiatement » ne laisse pas de marge.

Q3. La ligne directrice cybersécurité de la FSA est-elle contraignante ?

Ce n’est pas une loi, et elle s’applique selon une approche fondée sur les risques. Mais la FSA l’utilise lors de ses contrôles et peut exiger des informations ou ordonner des mesures sur le fondement des lois sectorielles : Aflac a reçu un ordre de communication d’informations le jour même de la publication de son incident.

Q4. L’authentification résistante au hameçonnage concerne-t-elle une société de gestion ?

Elle concerne les services de transaction en ligne proposés aux clients. Une société de gestion sans espace client transactionnel est moins exposée à cette exigence précise. Elle reste soumise aux autres attentes de la FSA, et la même logique vaut pour les accès de son personnel et de ses prestataires.

Q5. Un incident chez un prestataire japonais doit-il être déclaré à l’ACPR ?

Oui, s’il constitue un incident majeur pour l’entité européenne selon les critères de classification de DORA. La déclaration incombe à l’entité financière, même si la cause se trouve chez le prestataire. D’où l’importance d’une clause qui oblige le prestataire japonais à vous prévenir rapidement.

Parler à AEVUS

AEVUS est une entreprise de cybersécurité basée au Japon. Nous réalisons des tests d’intrusion sur les systèmes exposés et les services clients des établissements financiers, y compris les API de consultation de données et les tests avant mise en production. Nous auditons aussi la configuration des environnements cloud et réseau, environnements de test compris. Si vous voulez vérifier ce qu’un attaquant muni d’identifiants valides pourrait faire dans votre entité japonaise, ou préparer la réponse à incident côté japonais, contactez-nous.

En résumé

• En 2026, les incidents dans la finance japonaise sont surtout passés par des accès légitimes : identifiants volés, requêtes d’apparence normale, environnement de test oublié, prestataire.
• La prise de contrôle de comptes-titres a reculé fortement depuis le pic d’avril 2025, mais n’a pas disparu (37 accès frauduleux en septembre 2026).
• La FSA exige désormais, dans tous les secteurs, une authentification résistante au hameçonnage pour les opérations en ligne sensibles.
• Depuis le 1er octobre 2026, les incidents se déclarent à la FSA sur des formulaires communs, sans délai chiffré mais « immédiatement ».
• Pour un groupe français, l’enjeu est de coordonner FSA, APPI, DORA et RGPD dans une même procédure, et d’inscrire les prestataires japonais au registre du groupe.

Sources

• FSA, accès et transactions frauduleux sur les services de bourse en ligne, page mise à jour le 9 octobre 2026 (en japonais) et tableau mensuel (en japonais, PDF)
• NPA, état des menaces dans le cyberespace en 2025, mars 2026 (en japonais, PDF)
• NPA, état des menaces dans le cyberespace au premier semestre 2026, septembre 2026 (en japonais, PDF)
• FSA, révision de la ligne directrice sur la cybersécurité du secteur financier, 4 juillet 2025 (en japonais) et traduction anglaise provisoire (PDF)
• FSA, révision des lignes directrices pour les sociétés d’instruments financiers, 15 octobre 2025 (en japonais)
• FSA, révision des lignes directrices pour les banques et autres établissements, 27 février 2026 (en japonais)
• FSA, révision des lignes directrices pour les assureurs et autres établissements, 17 juillet 2026 (en japonais)
• FSA, passage aux formulaires communs de déclaration des incidents au 1er octobre 2026, 18 septembre 2026 (en japonais)
• FSA, ligne directrice de supervision des grandes banques, chapitre sur les succursales de banques étrangères (en japonais, PDF)
• FSA, Analytical Report on IT Resilience in the Financial Sector, 30 juillet 2026
• FSA, appel au renforcement de la cybersécurité, 9 octobre 2026 (en japonais)
• FSA, exercice sectoriel Delta Wall 2026, 5 octobre 2026 (en japonais)
• Aflac Life Insurance Japan, réception de l’ordre de la FSA, 1er juillet 2026 et résultats de l’enquête et mesures, 31 juillet 2026 (en japonais, PDF)
• Awa Bank, communiqué du 3 avril 2026 (en japonais) et suite du 3 juin 2026 (en japonais, PDF)
• Daiwa Securities, fuite possible chez un prestataire, 5 octobre 2026 (en japonais, PDF)
• Scala, accès frauduleux chez sa filiale Scala Communications, 6 octobre 2026 (en japonais, PDF)
• Dai-ichi Life Group et Dai-ichi Life Insurance, accès frauduleux au système RH, 2 octobre 2026 (en japonais, PDF)
• PPC, déclaration des fuites de données (en japonais) et réforme de l’APPI de 2026 (en japonais)
• Règlement (UE) 2022/2554 (DORA)
• Règlement délégué (UE) 2025/301 sur le contenu et les délais des notifications d’incidents majeurs
• ACPR, FAQ sur la directive et le règlement DORA
• AMF, dossier DORA

Articles connexes

• Les cyberattaques au Japon en 2026 : cas et enseignements
• Le TLPT pour les établissements financiers au Japon
• Tests d’intrusion pour les établissements financiers au Japon