Bank of Russia Publishes Methodological Recommendations No. 3-MR on AI Security for Financial Market Participants
The Bank of Russia has issued Methodological Recommendations No. 3-MR dated 16 June 2026 on ensuring information security when developing and applying artificial intelligence systems on the financial market. The document targets credit organizations, branches of foreign banks in Russia, non-credit financial institutions, professional market participants, and subjects of the national payment system.
Status and Relation to Existing Regulation
Although the recommendations carry a non-binding status, they represent a clear direction of regulatory travel. The document builds directly on the Code of Ethics in the sphere of AI development and application on the financial market (information letter of the Bank of Russia dated 9 July 2025 No. IN-016-13/91). It integrates seamlessly with the sector’s existing foundations in risk management, operational reliability, outsourcing controls, and personal data protection under 152-FZ, rather than creating a separate regulatory universe.
Key Innovations in Terminology and Risk Categories
The recommendations introduce official definitions for AI-specific concepts previously found mainly in expert literature and national standards, including AI hallucinations, data drift, direct and indirect prompt injection, and poisoned datasets. Terms such as AI system, explainability, predictability, reliability, and quality are drawn from GOST R 71476-2024 and GOST R 59898-2021. Risks are grouped into six categories: data management risks, confidentiality breaches, model malfunction including hallucinations and drift, insufficient explainability, supplier and open-source risks, and operational resilience threats. Potential consequences range from violations of citizens’ rights and financial losses to threats to the stability of the entire financial system.
Human Oversight and Threat Modeling
For critical automated processes such as payment operations and accounting systems assessed as high-risk, the document recommends human validation of AI outputs with the ability to override decisions. Threat modeling should follow the FSTEC Methodology for Assessing Information Security Threats dated 5 February 2021. The AI system lifecycle is divided into four stages: data preparation, development, training and testing, and operation. Specific threats include model evasion, poisoning of training data, model extraction, dataset theft, model modification, denial of service, and behavior manipulation, with attack techniques such as fuzzing, backdoors, data extraction, malicious injections, sponge attacks, and adversarial examples.
Supply Chain and Open Source Controls
Chapter 5 addresses practical realities of using external services and open-source components. Organizations should apply existing outsourcing rules from STO BR IBBS-1.4-2018 and build trust in external data and models according to GOST R 59276-2020. A dedicated methodology for assessing trust in third-party data, models, and open-source elements is recommended, covering factors such as Bug Bounty participation, software specifications including SBOM/MLBOM, vulnerability analysis reports, penetration testing results, secure development processes, data provenance tracking, and internal risk evaluation. Integrity of external components must be verified using tools certified by the FSTEC certification system. When a supplier trains a model, only cleaned, synthetic, or anonymized data should be transferred, and contracts must include liability provisions and incident notification obligations.
Practical Implementation Steps
The recommendations include a detailed policy template covering red-team testing, minimal use of personal data, output labeling, reduction of model information in public repositories, emergency shutdown plans, and periodic policy reviews. Practical steps for organizations begin with inventorying all AI components, followed by risk assessment across the six categories, construction of a threat model, implementation of controls at each lifecycle stage, placement of human oversight in critical processes, strengthening of supply-chain due diligence, and formalization of an AI security policy with assigned responsibility and continuous improvement cycles.
Related articles
Aladdin Obtains New FSB Certificate for CryptoFlash Encrypted USB Drive Valid Until 2029
Aladdin has received a new FSB Russia certificate for its Aladdin CryptoFlash hardware-encrypted USB drive. The certificate number СФ/124-5574 confirms compliance with cryptographic protection requirements for classes KS1 and KS2 and remains valid until 16 July 2029. The device now supports additional Russian Linux distributions including RED OS 7.3 and 8, Alt 8 SP Workstation, Alt Workstation 10, and the OS of the Moscow Electronic School. Read and write speeds have been increased to 11 MB/s while the graphical interface received improvements. The product uses the Magma encryption algorithm in hardware and operates as a clientless solution that requires no additional drivers or software. The previous certificate remains active until December 2028, allowing both versions of the device to be used in parallel for storing and transferring official and confidential information marked DSP.
Microsoft Tightens Corporate Windows Activation with TPM-Bound KMS Servers
Microsoft is strengthening its corporate Windows licensing controls by introducing new requirements for KMS servers used in volume activation. The changes will bind KMS hosts to TPM hardware attestation, preventing cloned or fake servers from issuing licenses to unlicensed devices. Warnings will begin appearing in Windows Server 2025 in August 2026, with mandatory enforcement planned for the next LTSC release. Existing KMS systems will continue operating normally until the new rules take effect. The update targets enterprise environments with on-premises KMS infrastructure and does not affect individual consumer devices or common non-KMS activation bypass methods. Administrators can already verify TPM support on physical servers using the Get-TpmSupportedFeature command.
Russia's Article 10.1 on Personal Data Dissemination: Apparent and Real Contradictions in Federal Law 152-FZ
Part II of the analysis examines how the rushed redrafting of Article 10.1 between the first and second readings created serious interpretive problems in Federal Law 152-FZ. The core issues include undefined terms such as 'disclosure', conflicting definitions of 'access', 'provision' and 'dissemination' between 152-FZ and 149-FZ, and the removal of the legal basis for processing publicly available data while retaining the consent mechanism that was meant to control it. Courts have consistently held that mere openness of data does not constitute a valid processing ground, forcing subsequent operators to find their own basis under Article 6. The article highlights that the mechanism for subjects to set conditions and prohibitions was preserved, yet the underlying legal foundation that would make those rules effective was eliminated. Two possible readings of the special consent are explored, with judicial practice leaning toward the narrower interpretation that leaves conditions and prohibitions as mere additional restrictions rather than a source of authorization.
Why Deep Packet Inspection Overestimates Its Reach in Encrypted Networks
Modern encryption has fundamentally limited the effectiveness of Deep Packet Inspection systems, leaving network monitors with only metadata and behavioral patterns rather than actual content. DPI tools can still classify traffic types and apply policies based on visible flow characteristics, but they cannot read messages, files, or credentials inside properly encrypted sessions without explicit TLS inspection. The article details how TLS 1.3, Encrypted Client Hello, and QUIC further reduce passive visibility while corporate inspection remains possible only when endpoint devices trust an organizational certificate. Russian regulatory requirements around TSPU systems are discussed separately from corporate DPI use, with emphasis on the need for technical confirmation rather than assumptions. The piece also clarifies distinctions between DPI, IDS, IPS, and DLP, and explains why machine learning cannot convert metadata into decrypted payloads. Overall, the analysis shows that DPI remains useful for traffic management and known-threat detection where visibility exists, but it cannot serve as a complete security foundation.