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
Russian Cybersecurity Market Set to Hit 455 Billion Rubles by 2026 as Talent Shortage Persists
MWS Cloud forecasts that the Russian information security market will grow 20.8 percent to reach 455.4 billion rubles in 2026. The largest segment will be software at 216.5 billion rubles, followed by services at 167 billion and hardware at 71.9 billion rubles. Demand is increasingly driven by sophisticated attacks, regulatory requirements and fines rather than import substitution alone. BI.ZONE offers a more conservative estimate of 10-15 percent annual growth. Managed security services such as monitoring, incident response and vulnerability management are leading the services segment because few organizations can maintain 24/7 in-house teams. Director Artem Gribkov of Angara MTDR estimates the personnel deficit at approximately 40 percent, especially at middle and senior levels.
Russian Internet Users Report Growing Access Restrictions as Certificate Revocations Affect 39 Percent of Respondents
A recent telephone survey conducted by Russian Field between September 23 and 30, 2026, among 1,600 participants representative by gender, age, federal districts, and settlement types shows that 39 percent of Russian internet users have noticed restrictions or complications when trying to access websites. When sites fail to open due to certificate problems, 26 percent of respondents said they would simply stop visiting the resource. The findings, published by Kod.ru, also indicate that 57 percent of users are aware that Russian websites may not load in certain browsers because of revoked foreign certificates. In response to certificate errors, 55 percent would switch browsers, 22 percent would install the required certificates, and 21 percent would try accessing the site from a mobile device. Younger users are more inclined to use VPNs or proxies, while older respondents more often choose to abandon the site. Overall, 77 percent of those surveyed expect further changes to the Russian internet segment, with only 9 percent believing it will remain unchanged.
CISA and NSA Urge Shift to Memory-Safe Languages Like Rust to Eliminate Memory Vulnerabilities
Official reports from CISA, NSA, FBI and partners highlight that decades of safe coding practices and code analysis tools have failed to resolve memory safety issues in languages such as C and C++. Government documents cite statistics showing that 70-75% of exploited vulnerabilities and zero-days stem from memory errors, including data from Microsoft, Google Chromium, Mozilla and Project Zero. Google reports that Rust adoption in Android reduced memory-related vulnerabilities below 20% in 2025, with a 1000-fold lower vulnerability density compared to C++. The analysis details Rust's ownership, borrowing and move semantics that provide compile-time guarantees unavailable in C++, enabling stronger compiler optimizations. Reports also acknowledge migration challenges including learning curves, interop issues and ecosystem gaps, while noting ongoing C++ safety improvements targeted for C++26 and C++29. Major organizations including Microsoft, Amazon and Google are already committing to Rust for critical new code.
Russian CA TCI Integrates ACME Protocol to Automate TLS Certificate Issuance
The Technical Center Internet (TCI), part of RTK-COD, has deployed a production ACME server compatible with standard clients such as acme.sh, Certbot and lego. The implementation aligns the ACME state machine with the existing isolated signing infrastructure, Domain Control Validation mechanisms and mandatory Certificate Transparency logging to Yandex and VK CT logs. Certificate lifetimes are shortening industry-wide, with Web PKI limits dropping to 47 days by 2029, making manual issuance unsustainable. The service supports HTTP-01 and DNS-01 challenges, ECDSA P-256 keys and certificate revocation, while preserving the requirement for Subject/CN in CSRs and mandatory revocation reasons. A separate staging environment uses an internal CT log simulator for safe testing. Future plans include full multi-SAN support, ARI (RFC 9773) and removal of the Subject/CN restriction.