Reading: Part 20. Russian Banking Context

Lesson 1 of 5 in module «Part 20. Russian Banking Context»

You are viewing the lesson without signing in. Sign in to save progress and take tests.

Source

Part 20. Russian Banking Context

This chapter does not provide legal instructions. It shows how publicly known constraints become SDD rules. Telling an agent to "comply with the law" is useless. It needs concrete constraints, verifiable facts, and human confirmation.

Constraints as Specifications

For a training bank, the following classes of constraints matter:

personal data and PII minimization;
payment operations and the risk of unauthorized actions;
consents for data access via Open API;
AML and risk flags;
reporting and reproducibility of calculations;
lineage to source and rule version.

How to Write in a Project

Don't write in AGENTS.md: "comply with the law." This is unverifiable. Write concretely:

marts do not contain direct PII fields;
the consents mart separates active and revoked consents;
the risk signals data mart does not delete operations without a reviewer's note;
the reporting data mart has verification facts and lineage;
changing grain or SLA requires confirmation.

Example of Translating a Constraint

Weak rule:

It is necessary to consider personal data.

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 must check new mart columns before release.

The second rule is not legal advice. It is an engineering safeguard that can be performed and verified.

Human Confirmation

Human confirmation is needed where an agent should not make the decision:

changing the PII policy;
changing grain;
breaking contract change;
new risk methodology;
new interpretation of consents;
changing freshness/SLA.

If a change looks small but falls into this list, it cannot be skipped as "just SQL."

Qwen Query

Read the specs and marts.
Find places where the banking context should be expressed as a verifiable
rule: PII, consents, risk, reporting lineage, approval gates.
Don't modify files.

Minimum Output

Write constraints as technical rules:

PII: marts do not contain direct PII fields.
Consents: active and revoked consents are counted separately.
Risk: risk operations are not aggregated without an operation-level mart.

Reporting: each reporting metric has lineage to the source model.
Confirmation: grain/SLA/contract fields do not change without human confirmation.

These rules can be transferred to AGENTS.md, a review checklist, or a reviewer's skill.

Breakdown for the Reader

The Russian banking context in this book is not a legal section. Its task is to show how external constraints become engineering rules. An agent cannot "comply with the law" in general terms. It can refrain from adding PII to a mart, require confirmation when grain changes, preserve lineage, and not redefine risk methodology without a specification. The more specific the rule, the better it works in SDD.

It is important not to copy regulatory texts into specifications as decoration. A long quote from the law rarely helps an agent make the right decision. It is better to record a link to the source and formulate an executable project rule alongside it. For example: direct identifiers are prohibited in marts; consent is considered active only by the described rule; a reporting metric has lineage to the source; changing an SLA requires human confirmation.

Human confirmation does not mean giving up automation. On the contrary, it

shows where automation should stop. An agent can find a problem, suggest a change, and list the consequences. But the decision about a new risk methodology, changing the PII policy, or a breaking contract change remains with a human. This is a boundary of responsibility, not a technical limitation.

For the reader, this chapter should become a habit of translation. Any big word from the domain — personal data, consent, reporting, risk, audit — needs to be translated into a verifiable engineering rule. If the translation doesn't work out, the rule isn't ready for the agent yet. Then it should be left as an open question, not hidden behind an authoritative formulation.

Practice

Take one legal or regulatory word from your domain and translate it into an engineering constraint: a list of prohibited fields, mandatory review, a lineage fact, or an approval gate.

Typical Mistake

Inserting long quotes from laws into specifications. An agent needs not a legal treatise but verifiable engineering rules. References to laws and regulatory documents are better kept as sources and constraints, not as executable instructions.