AI security for fintech organizations
Written by
Updated at October 20, 2026
The appendix contains a reference matrix mapping the requirements of this Standard to external recommendations for ensuring the information security of artificial intelligence systems.
External recommendation source
Methodological Recommendations of the Bank of Russia No. 3-MR dated 16/06/2026 on ensuring information security when developing and applying artificial intelligence in the financial market.
Application status
The application is for reference only and introduces no regulatory requirements on its own. Actions listed under User actions are recommended deficit elimination measures. They become mandatory only if approved by the organization's internal regulatory document. The compliance matrix does not replace the requirements of this Standard.
The application is used to design, develop, deploy, and operate AI solutions, including:
- Applications based on external and internal AI APIs.
- RAG systems, knowledge bases, vector stores, and data ingestion processes.
- AI agents, MCP servers, MCP Gateway, and connected tools.
- ML models, datasets, training, testing, fine-tuning, and deployment processes.
- Cloud infrastructure used for AI solutions.
Compliance statuses
| Status | Value |
|---|---|
| Fulfilled | The requirement is fully covered by the mandatory provisions of the Standard; it is sufficient to meet the associated AI-* requirements and retain evidence of compliance. |
| Partially | The Standard includes related measures, but they are not sufficient to fully comply with the external recommendation; the additional actions listed in the row are a recommended compensating measure, which the organization approves via an internal document of its own. |
| Not fulfilled | The Standard does not contain an equivalent requirement; implementation of the specified measure is recommended via project documentation, an internal regulatory document, or an action plan prior to putting the solution into operation. |
| Not applicable | The requirement does not apply to a specific AI solution; the decision regarding non-applicability should be documented by the AI solution owner and harmonized with the information security function. |
Responsibility matrix
The matrix uses the following roles:
| Role | Responsibility |
|---|---|
| User | The organization leveraging Yandex Cloud services and using an AI solution is responsible for the solution architecture, service settings, data, accesses, processes, and compliance with this Standard. |
| Yandex Cloud | The cloud infrastructure and managed services provider is responsible for the cloud platform's security under the shared responsibility model and terms for providing the relevant service. |
| Shared responsibility | Yandex Cloud fulfills the requirement at the platform level, while the user fulfills it by using a specific service setting, restricting access, enabling logging, applying encryption keys, and taking other measures offered by the relevant service. |
If the User actions column specifies that Yandex Cloud is responsible for fulfilling the requirement, this applies solely to protecting the platform component of the relevant managed service. The user remains responsible for the service configuration, accounts, access permissions, data, integrations, application code, and compliance with the requirements for their AI solution.
Compliance matrix
AI risk management
| External requirement | Status | Covered / lacking in the Standard | Relevant AI-* requirements | User actions | Responsibility |
|---|---|---|---|---|---|
| Consider information security risks of AI when selecting a scenario, technology, architecture, and protection measures. | Partially | The Standard imposes technical measures for AI API, RAG, MCP, data, and cloud infrastructure, but the unified process of admissibility evaluation for scenarios and information security risks of the AI solution requires formalization. | AI-SDLC1 |
Before you start development, register the scenario in the AI solution registry; evaluate information security risks, process criticality, admissible automation level, and the need for human-in-the-loop; get the results approved by the business owner or information security officer. | User |
| Evaluate the consequences in terms of subject permissions, operations, costs, reputation, supply chain, and organization stability. | Not fulfilled | The Standard provides for confidentiality and compliance controls but has no formal procedure for evaluation of consequences for the specified categories. | AI-SDLC1, AI-COMPLY1 |
Perform and document the evaluation of consequences before commissioning the AI solution; determine unacceptable scenarios, limitations on automation, and conditions for escalation to a human. | User |
| Use human-in-the-loop for high-risk automatic operations. | Partially | The Standard provides for confirmation of individual actions via MCP Gateway but does not set the general rule for manual validation of AI results in critical processes. | AI-AGENT-HITL1 |
List critical operations; prohibit autonomous execution of such operations; provide the possibility to check, reject, and update the result by a human; log record the decision and responsible person. | User |
| Develop a threat model for the AI system. | Partially | The Standard describes the boundaries of Ingres, Identity, Application, Model, Data/RAG, Egress, and Logging/Monitoring contours; however, the duty to develop the threat model and keep it up-to-date must be formalized explicitly. | AI-SDLC1 |
Develop a threat model for each AI solution; include assets, interfaces, external and internal intruders, AI-specific threats, attack scenarios, and related controls; review the threat model in case of significant changes. | User |
| Make sure the measures are adequate to risk level and consequences. | Not fulfilled | The Standard lists protection measures, but there is no rule for how to select and justify measures depending on risk. | AI-SDLC1 |
Define a risk level for each AI solution; select the minimum set of required controls depending on risk level; document justification of exclusions and mitigation measures. | User |
Data and privacy
| External requirement | Status | Standard provisions and gaps | Reated AI-* requirements | User actions | Responsibility |
|---|---|---|---|---|---|
| Control the origin, quality, structure, format, consistency, and labels of training and test data. | Partially | The standard provisions controlled RAG data ingestion, DSPM, data classification and protection; quality checkpoints for training and test ML datasets require more explicit detail. | AI-DATA1, AI-DATA5, AI-DATA-CHECK1 |
Maintain a passport for each dataset; record the source, owner, lawful basis for processing, version, format, classification, quality, and check results; never use datasets that fail the established checks. | User |
| Clean out anomalies in training and test data and repeat data checks post-cleansing. | Partially | Input data and RAG source controls are defined; however, there is no separate mandatory process for training and test datasets. | AI-DATA-CHECK1, AI-DATA3 |
Establish a procedure for anomaly detection, cleansing, and re-checking; save the check results and dataset admissibility decision. | User |
| Encrypt data in transit and outside the controlled zone. | Fulfilled | The standard enforces TLS, VPC, KMS, and other data protection mechanisms for cloud environments. | AI-CRYPT1, AI-NET2 |
Use TLS for all external and internal connections; use network segmentation and private endpoints wherever officially documented for the service; enable encryption and key management for supported services. | Shared responsibility: Yandex Cloud provides the platform-level service security mechanisms, while the user must correctly enable and configure the available mechanisms. |
| Ensure dataset integrity and authenticity. | Partially | Object locks, access control, audits, and logging reduce the risk of unauthorized modification; however, there is no mandatory integrity check for each dataset. | AI-DATA6 |
Use checksums, digital signatures, or other approved integrity controls; restrict dataset modifications; check integrity before training, testing, and RAG ingestion. | User |
| Enforce dataset versioning and change tracking. | Partially | The standard enforces inventory and elements of data lineage; however, it does not establish a fully reproducible versioning framework. | AI-DATA6, AI-REL1 |
Track dataset versions and change logs; ensure this mapping: source — dataset version — model version — test results — deployment version. | User |
| De-identify personal data and mask restricted information. | Fulfilled | The standard mandates identification and protective transformation of personal data before it leaves a trust boundary, transformation control, and audit. DSPM only identifies data, while KMS and Lockbox protect keys and mapping tables, but they do not mask data. | AI-COMPLY-PII1, AI-COMPLY-PII3, AI-COMPLY-PII4, AI-DATA4 |
Classify data before providing it to an AI system; delete, de-identify, or mask personal data or any other sensitive information if its processing is prohibited or not required; control RAG sources and prompts. | User |
| Ensure destruction of data after processing or upon expiration. | Partially | The standard governs the lifecycle of data and cloud resources; however, the explicit requirement for secure data destruction needs clarification. | AI-DECOM1 |
Establish retention periods; implement deletion of data, backups, indexes, and temporary artifacts; log deletion confirmations. | Shared responsibility: Yandex Cloud handles data deletion at the platform level based on the service features; the user must initiate resource and data deletion, set retention periods, and make sure there are no application-layer copies. |
| Transfer only cleansed, synthetic, de-identified, or specifically prepared data to external providers. | Partially | The standard mandates personal data masking and transfer limits but does not specify an explicit rule for external training or external AI APIs. | AI-COMPLY3, AI-DATA4, AI-NET3 |
Before sending data to an external provider, conduct admissibility assessment; use synthetic, de-identified, and cleansed data by default; prohibit transfer of secrets, personal data, or any other sensitive information without documented reasoning and approval. | User |
Model, development, and supply
| External requirement | Status | Covered / lacking in the Standard | Relevant AI-* requirements | User actions | Responsibility |
|---|---|---|---|---|---|
| Analyze model, code, and component vulnerabilities throughout their lifecycle. | Partially | The Standard provides for SBOM, Container Registry, and protection measures for the supply chain; however, the frequency and minimum scope of checks require explicit formalization. | AI-SUPPLY4, AI-SUPPLY5 |
Enable SAST, DAST, SCA, and image vulnerability check in CI/CD; maintain SBOM; define sources of information about vulnerabilities, elimination timeline, and release blocking criteria. | User |
| Check cryptographic integrity and authenticity of the model, code, and containers. | Partially | A digest, registry and KMS are used, but there is no the direct requirement to confirm a trusted version before applying. | AI-MODEL1, AI-SUPPLY2, AI-SUPPLY3 |
Sign or otherwise confirm trusted versions of artifacts; allow deployment only from a trusted registry; check the digest, signature, or another integrity ID prior to deployment. | Shared responsibility: Yandex Cloud provides the registry, IAM, KMS, and logging mechanisms; the user must organize a trusted build and test chain. |
| Track changes in code, model, and documentation. | Partially | The Standard provides for deployments and rollbacks, Audit Trails and inventory, but the full reproducible change tracing must be strengthened. | AI-REL1, AI-CORE5, AI-AUDIT1 |
Keep an immutable change log for code, configurations, prompts, datasets, and model docs; map each change to its author, approval, tests, and deployment version. | User |
| Apply a secure AI development lifecycle. | Partially | The Standard is based on ML DevSecOps, but a full secure SDLC for an AI model needs to be formalized. | AI-SDLC1, AI-REL1, AI-REL2 |
Introduce AI SDLC: requirements, risk assessment, threat model, data preparation, development, testing, approval, deployment, monitoring, retraining, and decommissioning. | User |
| Prevent model substitution. | Partially | A registry, digest, audit, and controlled deployment reduce the risk, but a separate model substitution control is not formalized. | AI-MODEL1, AI-REL2 |
Allow using only approved model versions; limit the publishing and deployment permissions; check model origin and ID before you run it; provide rollback to a previous trusted version. | User |
| Use digital labels on models, data, or outputs where required due to a risk or regulation. | Not fulfilled | There is no explicit requirement for watermarks or other similar digital labels. | — | Assess the need for digital labels for authorship protection, origin tracing, and substitution detection; if needed, select a technology, define the scope of use and the inspection procedure. | User |
Testing and resilience
| External requirement | Status | Covered / lacking in the Standard | Relevant AI-* requirements | User actions | Responsibility |
|---|---|---|---|---|---|
| Test the model for data poisoning after training | Not fulfilled | RAG data ingestion and data protection controls are in place, but no post-training poisoning test is provided. | AI-DATA-CHECK1 |
Include testing for data poisoning in the model acceptance and periodic review program, and define the scenarios, acceptance criteria, and response procedures for detected signs of poisoning | User |
| Keep training and test datasets separate, including their storage and access | Partially | IAM, VPC, ACLs, KMS, and secrets provide the basis for segregation, but the test dataset must be kept independent of the training dataset. | AI-DATA3, AI-DATA5, AI-TRAIN1 |
Use separate datasets, accounts, or storages for training and test data; prevent unauthorized changes to the test dataset; grant access based on the principle of least privilege | User |
| Test resilience to adversarial attacks | Not fulfilled | The Standard considers prompt injection and input filtering but establishes no methods for improving ML model’s resilience to adversarial attacks. | — | Run adversarial testing for applicable models; apply adversarial training, defensive distillation, ensemble methods, or other security measures as needed; document model results and limitations | User |
| Perform model penetration tests using AI-specific scenarios | Partially | The Standard provides for the API protection, WAF, guardrails, RAG, and MCP, but the regular test of the model itself is not formally defined. | AI-APP-WAF1, AI-APP-INJECT1, AI-CONTENT2 |
Perform acceptance and periodic tests that cover guardrails bypass, prompt injection, indirect prompt injection through RAG, fuzzing, extraction, inversion, poisoning, DoS, and resource exhaustion; remediate all critical findings before production deployment | User |
| Monitor data drift, model drift, and model degradation | Partially | The Standard provides for logging and monitoring, but AI-specific SLIs/SLOs, thresholds, and managed retraining process must be defined. | AI-MON-ANOMALY2, AI-DATA5 |
Define quality, security, data drift, and output data drift metrics; establish thresholds, owners, and response procedures; tune and revalidate the model only on verified data | User |
Operation and monitoring
| External requirement | Status | Covered / lacking in the Standard | Relevant AI-* requirements | User actions | Responsibility |
|---|---|---|---|---|---|
| Control and clean up anomalies in input and output data. | Fulfilled | The Standard provides for guardrails, content filtering, protection against injections, API checks, and RAG pipeline protection measures. | AI-CONTENT1, AI-CONTENT2, AI-APP-WAF1 |
Set up and enable applicable guardrails, content filters, and input/output checks; define rules for blocking, masking, escalation, and trigger logging. | Shared responsibility: Yandex Cloud provides supported service mechanisms; the user must activate them, set up policies, and trigger processing. |
| Get protected from direct and indirect prompt injections. | Fulfilled | The Standard comprises AI-APP-INJECT1 requirements, context limitations, guardrails, controlled RAG sources, and API/MCP protection. | AI-APP-INJECT1, AI-APP-INJECT2 |
Implement filtering and validation of input data; limit agent tools and privileges; use a list of permitted RAG sources; run tests for direct and indirect prompt injection. | User |
| Register model, user, and request events. | Fulfilled | The Standard provides for Cloud Logging, Audit Trails, and logging of operations pertaining to AI Studio, API, MCP Gateway, Kubernetes, and related services; the platform logs do not provide full end-to-end tracing; application-level model request tracing is implemented separately. | AI-AUDIT1, AI-MON-TRACE1 |
Enable logging for services that are in use; implement application-based end-to-end tracing of requests; deliver logs to Yandex SIEM if required; store logs as per the storage policy protect them against unauthorized modification. | Shared responsibility: Yandex Cloud provides service logs to the extent of the service's capabilities; the user must enable logging and configure export, storage, and monitoring. |
| Limit the number, frequency, size, and parameters of requests. | Partially | WAF, API Gateway, and Smart Web Security support frequency limiting, but limits for tokens, complexity, and AI resource consumption must be set separately. | AI-NET7, AI-APP-WAF1, AI-AGENT2 |
Implement quotas and limits, maximum request size, token limits, timeouts, and resource budget; apply limits at the API Gateway, WAF, application, and model levels. | Shared responsibility: Yandex Cloud provides traffic limiting mechanisms for supported services; the user must set the limit values and control their sufficiency. |
| Control the model's routine operation, quality, and behavior. | Partially | The Standard provides for observability and logging, but AI-specific SLIs/SLOs and degradation thresholds are not formalized. | AI-MON-ANOMALY2 |
Define SLIs/SLOs for availability, delays, errors, quality, security, cost, data drift, and output data; configure notifications, escalation, and regular deviation analysis. | User |
| Prevent denial of service and resource exhaustion. | Partially | API Gateway, WAF, and network limitations cover the basic DoS circuit, but special measures against resource exhaustion require a more detailed definition. | AI-NET7, AI-AGENT2 |
Set quotas and limits, token limits, limits on parallel processing of requests, timeouts, and protection against abnormally expensive requests; test resource exhaustion scenarios prior to commissioning. | Shared responsibility |
| Provide a plan for recovery and AI emergency stop. | Partially | The Standard provides for rollbacks and managed infrastructure, but the AI system emergency stop mechanism and recovery roles and scenarios need to be formalized. | AI-REL2, AI-AGENT2 |
Develop an AI incident response plan; define trigger criteria for the AI emergency stop mechanism, roles, procedure for model or RAG source isolation, rollback, artifact saving, notifications, and recovery. | User |
Suppliers and open-source software (OSS) management
| External requirement | Status | Covered / lacking in the Standard | Relevant AI-* requirements | User actions | Responsibility |
|---|---|---|---|---|---|
| Approve an internal information security policy for the development and use of AI | Partially | The Standard sets out technical and organizational requirements but does not replace the organization’s internal policies. | AI-SDLC1 |
Approve an AI information security policy defining its scope, roles, scenario classification, exception handling procedures, compliance monitoring, and accountability for violations | User |
| Appoint a manager responsible for AI information security | Not fulfilled | Technical roles and IAM are described, but the AI information security policy owner is not defined. | — | Appoint a responsible officer and give them authority to approve the policy, manage risks, escalate significant incidents, and report to management | User |
| Audit policy compliance and report violations to management | Partially | Audit Trails, Cloud Logging, and Yandex SIEM support evidence collection, but auditing and reporting must be defined through established processes. | AI-AUDIT1 |
Define the frequency of internal audits; prepare reports on compliance, exceptions, incidents, and risks; report the results to management in accordance with the established procedures | User |
| Train employees in secure AI development and use | Not fulfilled | There is no separate training requirement for developers, MLOps, information security personnel, product owners, or users. | — | Introduce a training program covering AI threats, sensitive data handling, prompt injection, RAG, MCP, secure development, and incident response procedures. | User |
| Provide the minimum required access permissions | Fulfilled | The Standard describes IAM, RBAC, service accounts, AI Studio roles, Kubernetes RBAC, and CIEM in detail. | AI-IAM-LEASTPRIV1, AI-IAM5 |
Use separate service accounts; follow the principle of least privilege when granting permissions; regularly review access permissions; prohibit account sharing | Shared responsibility: Yandex Cloud provides IAM and service roles; the user assigns and reviews access permissions and disables access that is no longer required. |
| Set rules for the secure use of public AI services | Partially | For external AI APIs and SaaS, the Standard enforces allowed recipient lists, TLS, and compliance considerations, but a unified user policy must be approved separately; a private network path to an external provider is only claimed when supported by the provider’s official documentation. | AI-NET3, AI-COMPLY3, AI-COMPLY4 |
Approve a list of allowed public AI services; define data classes that must not be shared; establish procedures for exception approval and usage monitoring | User |
| Consider the risks associated with open-source models, components, agents, plugins, and tools | Partially | SBOMs, Container Registry, and supply chain controls are provided for, but the OSS component registry and risk assessment must be formally defined. | AI-SUPPLY1, AI-SUPPLY4, AI-SUPPLY5 |
Maintain a registry of OSS models, libraries, agents, plugins, MCP servers, and tools; keep the SBOM up to date; assess licenses, provenance, vulnerabilities, and trust level before use | User |
| Evaluate the trust level of the provider, its data, models, and components | Partially | Technical controls for the cloud environment are well defined, but an internal provider assessment methodology is missing. | AI-SUPPLY6 |
Assess the provider before signing the agreement and periodically thereafter, with a focus on the threat model, secure software development lifecycle practices, audits, licenses, SBOM, vulnerability disclosure, penetration testing results, SLA, and data processing terms | User |
| Obtain provider reports on security audits, licensing, vulnerabilities, and penetration testing | Not fulfilled | Contractual and process requirement is missing. | AI-SUPPLY6 |
Add a contractual or procurement requirement for the provider to deliver security evidence and notifications about any changes, vulnerabilities, or incidents | User |
| Hold the provider contractually accountable for information security and incident notification | Not fulfilled | The Standard does not replace contractual terms and does not require their inclusion in the agreement. | AI-SUPPLY6 |
Include information security requirements, vulnerability and incident notification timelines, investigation procedures, data return or deletion requirements, and the parties’ liability in the agreement. | User |