Topic: Part 20. Russian Banking Context
Difficulty level: Medium
Estimated study time: 2–3 hours of active work, including practical exercises
Prerequisites: Basic understanding of data warehouse architecture (staging, marts, datamarts)
Familiarity with the principles of SDD (Specification-Driven Development)
Understanding the role of the AGENTS.md file in agent operations
General understanding of banking processes (KYC, AML, payments, consents)
Basic skills in SQL and dbt-like tools
Learning objectives: Explain why abstract formulations from the subject domain ('comply with Federal Law 152-FZ', 'take personal data into account') are unsuitable as SDD rules for an agent.
List the key classes of constraints in the Russian banking context: PII, consents, risk flags, reporting lineage, human confirmation gateways.
Formulate a verifiable engineering rule (with prohibited fields, schema tests, review checklists) based on a vague regulatory norm.
Distinguish between zones where automation is acceptable and zones that require mandatory human confirmation (changes to grain, PII policies, risk methodology).
Apply the principle of minimal output: translate any 'big word' of the domain (personal data, consent, reporting) into a specific technical constraint.
Overview: The 'Russian Banking Context' chapter is not a legal reference. Its purpose is to show how publicly known banking constraints (Federal Law 152-FZ, 115-FZ, Bank of Russia requirements for reporting and risks) are transformed into verifiable engineering rules suitable for SDD specifications and agent operation. The book systematically introduces six classes of constraints: personal data and PII minimization, payment operations and the risk of unauthorized actions, consents for data access through Open API, AML and risk flags, reporting and reproducibility of calculations, lineage back to the source and rule versioning. For each class, it shows how to move from a weak formulation ('personal data must be taken into account') to a working rule ('direct PII fields pii_email, phone, passport_number may appear only in staging; marts must pass a schema test against the list of prohibited direct PII; a reviewer is required to check new mart columns before release'). The mechanism of human confirmation is examined separately: it does not cancel automation but marks its boundary. The chapter reinforces the translation habit: any 'big word' of the domain must be turned into a verifiable engineering rule, otherwise it remains an open question rather than an executable instruction.
Key concepts: Constraints as specifications: In SDD, a domain constraint is not a reference to a law but a technically verifiable rule. The rule must take a form that allows the agent to unambiguously understand whether it has been fulfilled or not: a list of prohibited fields, a schema test, a review checklist, a lineage fact, an approval gateway. If a rule cannot be fulfilled and verified, it remains a declaration, not a specification.
PII and minimization: Personal data is divided into direct identifiers (email, phone, passport number) and indirect ones (gender, age, region). In the Russian banking context, direct PII is allowed only in the staging layer and in protected PII sandboxes. At the mart level it is prohibited, and this is enforced by a schema test against a list of prohibited columns. Any new column in a mart must undergo review to check for the appearance of direct identifiers.
Marts vs staging: Staging is a technical layer with raw or lightly cleaned data, where PII storage is permitted under access control. Marts are a layer from which product teams, analysts, ML models, and external partners read. The boundary 'marts do not contain direct PII fields' is a key engineering rule that formalizes the principle of data minimization (Article 5 of Federal Law 152-FZ).
Consents: A client's consent to data processing is not a Boolean variable but a state with history. Consent can be active, revoked, expired, or awaiting confirmation. A consent mart must separate active and revoked consents, preserve the issue date, the revocation date, and the basis. Any datamart using client data must reference an active consent of the appropriate type.
Open API and access consents: The Open APIs of the Bank of Russia and commercial banks are required to transmit only the data to which the client has given consent. In SDD this is expressed as a rule: 'the Open API datamart returns only clients with an active consent of the corresponding type on the request date'. Without such a rule, the agent cannot safely generate a filter.
AML and risk flags: Anti-money-laundering rules (115-FZ, Bank of Russia requirements) and internal risk models generate flags for suspicious operations. These flags cannot be aggregated above the operation level without losing reproducibility. Rule: 'risk operations are not aggregated without an operation-level mart; the risk-signals mart does not delete operations without a reviewer note'.
Reporting and reproducibility: Regulatory reporting must be reproducible: the same metric on the same date must yield the same value on recalculation. This requires model versioning, snapshot fixing, and verification facts (test expectations) for every reported indicator.
Lineage to source: Every reported metric must have lineage back to the source model: which sources, which transformations, which code version. Without lineage, neither incident investigation nor confirmation of correctness to the regulator is possible. In SDD this is expressed as a mandatory lineage_id attribute or an equivalent dbt-graph mechanism.
Grain: Grain is the level of detail at which a table or datamart is defined (for example, 'one row = one client', 'one row = one operation'). Changing grain breaks all consumers of the datamart, so such a change cannot be made as part of an ordinary task — only through a human confirmation gateway.
SDD rule: A good SDD rule: 1) is unambiguously understood by the agent; 2) is verifiable (there is a test, checklist, or review step); 3) refers to a specific layer/table/field; 4) has an owner (who confirms the change). The formulation 'comply with the law' fails on every point.
Human-in-the-loop: A list of events that the agent has no right to perform autonomously: changing the PII policy, changing the grain, a breaking contract change, a new risk methodology, a new interpretation of consents, changing freshness/SLA. This is a boundary of responsibility, not a refusal of automation. The agent can find the problem, propose a change, enumerate consequences — but a human makes the decision.
Schema test: An automated test that verifies that a table does not contain columns from a prohibited list (for example, direct PII). In dbt this is implemented through custom tests or dbt-utils; in other frameworks, through macros. A schema test turns a vague rule into an executable constraint in CI.
Minimal output: The principle according to which only those rules that are executed and verified are included in AGENTS.md and the specification. Long quotations from laws and general declarations are not included, to avoid creating an illusion of coverage for the agent. If a rule is not ready as a verifiable one, it remains an open question with a reference to the source.
Important dates: 2001-08-07 — 115-FZ: Federal Law 'On Countering the Legalization (Laundering) of Criminally Obtained Incomes and the Financing of Terrorism'. The foundation of AML requirements in Russia; it sets the bank's obligations for transaction monitoring, client identification, and reporting to Rosfinmonitoring.
2006-07-27 — 152-FZ: Federal Law 'On Personal Data'. Establishes the principles of PD processing, including minimization, consent, and localization. For SDD it is important as the source of the rule 'marts do not contain direct PII fields'.
2014-07-21 — 242-FZ: Amendments to 152-FZ introducing the requirement to store and process the personal data of Russian Federation citizens on servers located on the territory of Russia. Affects the architecture of staging layers and cross-border exchange.
2018-05-25 — GDPR (EU): The EU General Data Protection Regulation. Relevant for Russian banks working with EU residents' data and as an example of the structure 'legal basis → engineering rule'.
2019-2024 — Bank of Russia Open API standards: A series of Central Bank standards on Open API that define the composition of transmitted data and consent obligations. For SDD — a direct source of filtering rules at the level of Open API datamarts.
Regularly — Bank of Russia directives and regulations (e.g., 590-P, 611-P): Normative documents that set requirements for risk management, capital adequacy, and reporting. Used as sources referenced by SDD rules, but not quoted in full in specifications.
Practice exercises: Name: Translating a vague formulation into a verifiable rule
Problem: You are given a customer datamart specification that says: 'It is necessary to ensure the protection of clients' personal data in accordance with 152-FZ'. Transform this sentence into a verifiable SDD rule suitable for AGENTS.md. The rule must contain: (a) a list of specific prohibited direct PII fields, (b) the layer/table where the constraint applies, (c) a verification method (test, review step).
Solution: Step 1. Identify the 'big words': 'protection of personal data', '152-FZ'. Step 2. Translate them into technical categories: direct PII fields (email, phone, passport_number, inn, snils), indirect PII (gender, age, region). Step 3. Formulate a verifiable rule. Example of a final rule for AGENTS.md:
PII: marts do not contain direct PII fields.
Prohibited direct PII fields: pii_email, phone, passport_number, inn, snils,
date_of_birth, full_name_unmasked.
Permitted layers for direct PII: only staging.* and protected pii_sandbox.*.
Verification: every mart passes a schema test against the list of prohibited
columns at the CI stage. A new column in a mart requires review by the
domain owner.Step 4. Make sure the rule can be executed (do not add direct PII to a mart) and verified (the schema test fails on violation).
Complexity: beginner
Name: Identifying direct PII in a fictional datamart
Problem: You are given the list of fields of the dm.customer_360 datamart: customer_id, full_name, email, phone, gender, age, region, registration_date, last_transaction_amount, device_id, ip_address, hashed_email. Identify which fields are direct PII and must be prohibited in the mart. Explain the difference between direct and indirect identifiers. Formulate exceptions (if any).
Solution: Direct PII (subject to removal/masking from the mart): full_name, email, phone, ip_address, device_id (in combination with other data). The hashed_email and customer_id fields are either pseudonyms or technical keys, but their classification as PII requires analysis: hashed_email is a pseudonym, but if the hash is compromised it becomes an indirect identifier. Indirect PII (allowed when aggregated): gender, age, region. Technical fields: customer_id, registration_date, last_transaction_amount. Final rule for this datamart: 'remove full_name, email, phone, ip_address, and device_id from dm.customer_360; keep hashed_email as a join key; keep gender, age, region as indirect identifiers'. Verification: schema test against the list of prohibited columns.
Complexity: beginner
Name: Designing a consent mart
Problem: Design a consent mart for a bank. The datamart must answer the questions: (1) Which consents does the client have active on date X? (2) Which consents have been revoked and when? (3) What types of consents exist (for PD processing, for transfer to Open API, for marketing, for scoring)? Describe: grain, key fields, separation of active and revoked consents, what is moved into separate columns. Formulate an SDD rule.
Solution: Grain: one row = one consent event (issuance, revocation, change). Recommended structure:
dm.consent_event
- client_id
- consent_type -- 'pd_processing', 'open_api_share', 'marketing', 'scoring'
- consent_state -- 'active', 'revoked', 'expired', 'pending'
- valid_from
- valid_to
- issued_at
- revoked_at
- source_system
- evidence_id -- link to the consent documentA parallel datamart for product use:
dm.consent_current
- client_id
- consent_type
- is_active -- true if there is an active record on the request date
- last_updatedSDD rule: 'Consents: dm.consent_event and dm.consent_current separate active and revoked consents. Any datamart using client data must join dm.consent_current and filter by is_active=true. Changing the logic for determining an active consent goes through a human confirmation gateway.'
Complexity: intermediate
Name: Lineage for a reported metric
Problem: You need to describe the lineage for the reported metric 'share of non-performing loans on the 1st of the month' (NPL ratio). Describe: which sources are involved, which transformations, which versions of models are recorded, which lineage_id attribute you will add, how you will ensure reproducibility. Formulate an SDD rule.
Solution: Sources: core.loan_agreement (contracts), core.payment_schedule (payment schedule), core.loan_status_history (statuses). Transformations: stg.loan_agreement → int.loan_with_status → dm.loan_snapshot (snapshot on the 1st of each month) → rep.npl_ratio. Version fixing: the dbt model snapshot is marked with dbt_snapshot_id; code version — git_sha; methodology version — methodology_version (for example, 'v2.1-2024-CBR'). The lineage_id attribute is formed as hash(source_system + source_table + load_date + methodology_version). Verification: every report row has a non-empty lineage_id; in CI — a test that the share of rows with lineage_id < 100%. SDD rule: 'Reporting: every reported metric has a lineage_id back to the source model; the methodology version is fixed in the methodology_version column; reproducibility is guaranteed by the snapshot on the calculation date. A change of methodology goes through a human confirmation gateway.'
Complexity: intermediate
Name: Determining the boundaries of automation and human confirmation
Problem: The agent proposes the following changes to the specification: (1) add the email_md5 column to the dm.customer_360 mart to simplify joins; (2) redefine the grain of dm.transactions from the operation level to the day level; (3) add a filter by is_active=true from dm.consent_current to dm.marketing_audience; (4) update the NPL ratio calculation methodology from v2.1 to v2.2; (5) change the datamart SLA from 24 to 12 hours; (6) fix a typo in the column name dt instead of date. Which of these changes require human confirmation, and which can be performed autonomously?
Solution: Require human confirmation (per the chapter's list): (2) changing the grain of dm.transactions — a breaking contract change; (4) updating the NPL calculation methodology — a new risk methodology; (5) changing the SLA from 24 to 12 hours — a freshness/SLA change. Conditionally require confirmation: (1) adding email_md5 — a new column in the mart, does not violate the list of prohibited PII, but requires review by the domain owner for the appearance of identifiers (even as indirect ones). Can be performed autonomously: (3) adding a filter by dm.consent_current.is_active=true — this is the application of an already existing rule 'the datamart must filter by active consents'; (6) fixing a typo — a cosmetic change that does not alter semantics. Result: 3 changes go through the gateway, 1 through review, 2 autonomously. The purpose of the exercise is to reinforce that a 'small' change (e.g., a new column) can be dangerous, while a 'large' SQL change (a filter on consents) is safe if it follows an already adopted rule.
Complexity: advanced
Name: Translating a real regulatory requirement into an SDD rule
Problem: Take one real requirement from your banking context (for example, Article 9 of 152-FZ on the subject's consent, or the requirement of 115-FZ on client identification, or a requirement of the Open API standard). Transform it into an SDD rule according to the chapter's schema: (1) the 'big word' of the domain, (2) the technical category, (3) the verifiable rule, (4) the verification method, (5) what requires human confirmation. Format the result as a block for AGENTS.md.
Solution: Example for Article 9 of 152-FZ (subject's consent). (1) Big word: 'subject's consent to PD processing'. (2) Technical category: a consent fact with history (issuance, revocation, validity period). (3) Verifiable rule: 'Any datamart using the client's PD joins dm.consent_current and filters by is_active=true and consent_type in (the required types). Consent is considered active only if there is a record in dm.consent_event with the active status for which valid_from <= now() < valid_to.' (4) Verification method: a dbt test that the share of clients without a joined record in dm.consent_current in the target datamart equals zero; review of new datamarts for the presence of a filter. (5) Human confirmation is required for: changing consent types, changing the logic for determining active consent, adding new consent collection channels. Ready block for AGENTS.md:
Consents: dm.consent_event stores all consent facts (issuance, revocation, expiration).
dm.consent_current is a snapshot of active consents on the current date.
Any datamart using the client's PD must join dm.consent_current
and filter by is_active=true.
Changing consent types, activity logic, or consent sources
goes through a human confirmation gateway.Complexity: advanced
Case studies: Name: Customer 360 datamart: transition from declaration to schema test
Scenario: An analytics team at a large retail bank built the dm.customer_360 datamart, which included the email, phone, and date of birth fields of clients. The datamart specification stated: 'The datamart ensures the protection of personal data in accordance with the requirements of 152-FZ'. The specification passed the architect's review, but direct PII continued to appear in the mart. A request from the product team to use the datamart for enriching marketing campaigns raised the question: can this data be transferred to a partner?
Challenge: The main problem was that the formulation about 'protection in accordance with 152-FZ' turned out to be unverifiable. The architect had no objective criterion by which to reject a merge request. There was no schema test for prohibited columns. The client's consent to partner transfer was not checked. The risk is leakage of direct identifiers and violation of data minimization (Article 5 of 152-FZ), as well as potential fines and reputational damage.
Solution: The team translated the abstract requirement into three verifiable rules. First: a list of prohibited direct PII (email, phone, passport_number, date_of_birth, full_name_unmasked) was explicitly fixed, and a schema test was introduced that fails in CI when these columns appear in any mart. Second: the dm.consent_current datamart was introduced, and any mart using client data is required to join it and filter by is_active=true; a test was introduced that checks that the share of clients without active consent in the mart equals zero. Third: for partner transfer, a separate pii_partner_safe layer was added with aggregates (only gender, age group, region) and a contract that fixes the absence of direct identifiers. The specification in AGENTS.md began to contain concrete rules rather than general declarations. Changing the list of prohibited columns or consent logic was moved to a confirmation gateway by the domain owner and DPO.
Result: A month after the schema test was introduced, three attempts to add 'convenient' fields to the mart (card number for a join, email for communications) were automatically rejected in CI. Review became objective: the reviewer checks against the list of prohibited columns and the test result, rather than interpreting 'compliance with the law'. The product team received a safe aggregate for partner campaigns. The regulatory audit passed without remarks on the data minimization section. The team established a habit: any 'big word' from 152-FZ (consent, minimization, localization) is translated into a verifiable rule with an owner and a test.
Lessons learned: The formulation 'complies with 152-FZ' has no operational meaning without a list of prohibited fields and automated verification.
A schema test turns an architectural rule into an objective acceptance criterion — this relieves the reviewer's load and speeds up CI.
Consent is not a Boolean variable but a state with history; a consent datamart must separate active and revoked consents.
Even a 'small' addition of a column to a mart can violate the PII policy and must undergo review.
Related concepts: PII and minimization
Marts vs Staging
Consents
Schema test
SDD rule
Name: Open API and consents: how to avoid data leakage into the partner channel
Scenario: A bank is launching an Open API for partners — insurance companies and marketplaces. Partners request a client profile (full name, contacts, transaction history) to calculate personalized offers. The internal development team prepared a datamart that returns 'everything there is about the client, with a filter for the presence of a record in the database'. The security team raised the alarm: partner requests do not take into account either the type of consent or the fact of revocation.
Challenge: Without formalizing filtering rules, an agent (or a junior developer) generating an Open API endpoint could easily hand over the data of a client who revoked consent for partner transfer. In addition, different partners require different sets of data: the insurer needs transaction history, the marketplace is satisfied with aggregates. The general rule 'give only what there is consent for' is too vague: what type of consent, what reference date, what to do with indirect identifiers?
Solution: The team introduced a hierarchy of datamarts. At the lower level — dm.consent_event (all consent facts) and dm.consent_current (active consents). Above them — dm.open_api_profile, which collects only those clients who have consent_type='open_api_share' and is_active=true at the time of the request, and only those fields that are allowed for the corresponding partner_scope (insurance, marketplace, scoring). For each partner_scope, the list of allowed fields is fixed as a separate configuration table. The following rule is recorded in AGENTS.md: 'Open API: dm.open_api_profile returns only clients with an active consent_type=open_api_share. The list of fields is determined by the config.partner_scope_allowlist table. Changing the field lists and consent types goes through a human confirmation gateway (product owner + DPO).' In dbt, a test was added: the share of rows in dm.open_api_profile without an active consent_type=open_api_share must equal zero. Additionally, a test was introduced for compliance of allowed fields with partner_scope_allowlist.
Result: The Open API launch passed without incidents. An attempt by one of the partners to expand the scope (obtain full name and email) was automatically rejected at the endpoint level. When a client revoked consent through the mobile application, they disappeared from dm.open_api_profile within an hour, and the partner channel stopped receiving their data — without manual intervention. The Bank of Russia auditor noted the presence of formalized lineage from the partner request to the consent fact.
Lessons learned: Consent must have types and temporal validity; a single 'agreed' mark is not enough.
A datamart for external consumers is not 'everything there is', but a projection filtered by consent type and scope.
The configuration of allowed fields by partner_scope must be a separate table with an owner, not hardcoded.
Lineage from an API request to a consent fact is a mandatory condition for regulatory audit.
Related concepts: Consents
Open API and access consents
Lineage to source
Human-in-the-loop
Name: Anti-pattern: quotations from laws instead of rules
Scenario: A team was implementing SDD in the risk management division. An expert analyst responsible for specifications inserted the full texts of Articles 6, 9, and 11 of 152-FZ into AGENTS.md, as well as excerpts from Regulation 590-P. His argument: 'The agent must know the law in order to make decisions correctly'. As a result, AGENTS.md grew to 40 pages, and when asked to generate SQL, the agent began returning formulations quoting the law but not addressing the task.
Challenge: The main problem is that long legal text is not an executable instruction. An agent does not know how to 'apply' an article of law; it knows how to execute a specific rule or not. The specification turned into noise: the reviewer could not find verifiable constraints in it, the developer did not understand which fields were prohibited, the analyst could not formulate which marts require confirmation.
Solution: The team refactored the specification. All long quotations were removed from AGENTS.md. In their place — short references to the source ('see Article 9 of 152-FZ') and next to it a verifiable rule. For example, instead of the full text of Article 9, the following appeared: 'Consent: dm.consent_event stores consent facts; datamarts using PD filter by is_active=true in dm.consent_current. Source of the rule: Article 9 of 152-FZ. Changing consent types goes through a human confirmation gateway.' Instead of excerpts from 590-P — specific rules for the risk metrics mart: methodology version, lineage_id, prohibition on aggregating risk operations above the operation level. Sources (links to normative documents) were moved to a separate references.md file, which is not loaded into the agent's context when generating SQL.
Result: The volume of AGENTS.md decreased from 40 to 8 pages. The specification review time decreased by about half. The agent began to give concrete, executable proposals instead of legal formulations. The reviewer received objective criteria (schema test, test for the share of clients with active consent, test for lineage_id) rather than interpretation of the law. During the audit, the team showed both AGENTS.md (executable rules) and references.md (sources), which satisfied both the regulator and the developers.
Lessons learned: A long quotation of a law in a specification is decoration, not an engineering constraint; it does not help the agent.
A reference to the source and next to it a verifiable rule is the optimal structure: both legal traceability and executability.
AGENTS.md must be loaded into the agent's context when solving tasks; therefore, it must be compact and verifiable.
The legal department is the owner of references.md, the engineering team is the owner of AGENTS.md; these are different artifacts with different responsibility.
Related concepts: Minimal output
SDD rule
Human-in-the-loop
Lineage to source
Name: Changing grain as a point of no return: a lesson from an incident
Scenario: The transactions datamart team decided to optimize performance and proposed moving from the grain 'one row = one operation' to 'one row = one day per account'. The change was formalized as an ordinary merge request with the note 'performance optimization'. After release, four product teams discovered that their joins and ML models were broken: operation details disappeared, sums changed, duplicates appeared. Rollback took a week.
Challenge: Changing grain is one of the events that the chapter assigns to the human confirmation gateway. In this case it was carried out as an 'ordinary SQL refactoring', and no one noticed that it was breaking the contract. The specification did not contain an explicit rule stating that changing grain is prohibited without confirmation from the product owner and consumer teams.
Solution: After the incident, the team added an explicit rule to AGENTS.md and to the review checklist: 'Grain: dm.transactions has grain = one row = one operation. Changing grain (in any direction) goes through a human confirmation gateway with notification of all consumers 5 business days in advance. A PR with a grain change must contain an Affected downstream section listing all affected datamarts and ML models.' Additionally, the dbt test fixes the expectation: count(distinct operation_id) = count(*) in dm.transactions (grain uniqueness test). When trying to aggregate the datamart above the operation level (for example, summing in the int layer), the lineage and grain test will remind the agent of the boundary.
Result: The next optimization attempt (through indexing, partitioning, and materialized views) passed without changing the grain. Performance increased by 40% without breaking the contract. The consumer team confirmed that the data remained compatible. The lineage audit showed that all downstream datamarts continue to reference the correct grain. The lesson was recorded in onboarding for new engineers.
Lessons learned: Changing grain is a breaking contract change, even if it is framed as an 'optimization'.
A grain uniqueness test is a simple and reliable way to automatically catch a violation.
A PR with a grain change must contain an Affected downstream section; without it, the change should not pass review.
A confirmation gateway is not bureaucracy, but protection against costly rollbacks.
Related concepts: Grain
Human-in-the-loop
Lineage to source
SDD rule
Study tips: Always ask yourself: 'Can I write a test that will verify this rule?' If the answer is 'no' — the rule is not ready yet, leave it as an open question.
Keep in AGENTS.md only what is executed and verified. Move long quotations from laws to a separate references.md referenced by the rule.
Translate every 'big word' of the domain (personal data, consent, risk, reporting, audit) into a specific technical category: prohibited field, test, review step, gateway.
Keep the list of confirmation gateways (PII policy, grain, contract, risk methodology, consents, SLA) in one place — for example, in the review checklist and at the beginning of AGENTS.md. This reduces the number of accidental violations.
For every reported metric, require lineage_id and methodology_version. Without them, reproducibility is not guaranteed, and regulatory audit becomes impossible.
A schema test against the list of prohibited columns is a minimal and mandatory tool. Introduce it first, before building complex policies.
Model consent as a state with history, not as a Boolean variable. This immediately reveals the requirements for the consent datamart and consumer filtering.
Practice translation: take one real requirement from your bank and format it as an AGENTS.md block. This is faster than reading the chapter and immediately reveals gaps in understanding.
Do not confuse a 'small' change with a 'safe' one. Adding one column to a mart can violate the PII policy, while a filter under an existing rule is safe.
Remember: human confirmation is a boundary of responsibility, not a refusal of automation. The agent can find the problem and propose a solution, but a human makes the decision.
Additional resources: Federal Law 152-FZ 'On Personal Data': The main Russian law on PD. Use as a source of references in references.md, not as text for AGENTS.md.
Federal Law 115-FZ 'On Countering the Legalization of Incomes': The foundation of AML requirements. Useful when formulating rules for the risk-signals and operations marts.
Bank of Russia Regulations and Directives (590-P, 611-P, etc.): Regulatory documents on risk management and capital adequacy. A source for methodology_version and lineage rules.
Bank of Russia Open API Standards: A source for filtering rules of Open API datamarts and working with consent types.
Dbt-utils (custom schema tests): A tool for implementing schema tests against the list of prohibited columns and other verifiable constraints.
Dbt-snapshot: A mechanism for fixing model versions to ensure reproducibility of reported metrics.
Internal bank policies on PII and risks: Each bank has its own policies for PD processing, risk models, and approval regulations. They are the main source of specific rules for your project.
GDPR (EU Regulation 2016/679): Useful as an example of the structure 'legal basis → engineering rule' and as a source of ideas for data minimization.
Open source: great expectations, soda core: Tools for describing and auto