Part 18. Credit Portfolio Mart
The credit portfolio shows how SDD Data works with aggregated reporting. Here the danger is not in PII, but in incorrect interpretation of stage, principal, delinquency, and portfolio quality. A small change in a rule can change the reporting.
Educational mart
mart_credit_portfolio_quality aggregates loans by stage. The minimal contract:
- stage not null;
- principal is aggregated reproducibly;
- delinquency is not lost;
- stage source is described;
- business interpretation is not invented by the agent.
What stage means
In a real bank, stage may be tied to IFRS 9, risk methodology, and regulatory reporting. In the educational example, stage is a synthetic feature. This needs to be stated explicitly so the agent does not start adding an "improved" methodology.
Bad specification:
Compute the credit portfolio quality.
Good specification:
Group synthetic loans by the source `stage`. Show
`loan_count` and `principal_rub`. Do not derive IFRS staging rules. Treat
`stage` as a source field.
Validation facts
stagenot null;
- principal amounts are not negative if this is set by source rules;
- number of rows matches the number of
stagevalues; - reviewer confirmed that stage is not redefined in SQL;
- note about contract impact records that the methodology has not changed.
Qwen query
Compare stg_loans and mart_credit_portfolio_quality.
Show which business assumptions SQL makes.
Separate source facts from derived rules. Do not modify files.
Minimal output
After the chapter create a review note about the credit mart:
Source stage:
Aggregation:
Metrics:
Assumptions:
Verification:
Confirmation required:
Breakdown for the reader
The credit mart shows a different type of risk: here the danger is not only PII leakage, but also false methodology. The words stage, delinquency, principal, portfolio quality look like elements of a serious banking model. The agent may try to "improve" the example with knowledge of IFRS 9, PD, LGD, or ECL. For a textbook this is an error if such decisions are not written into the specification and confirmed by a human.
Therefore stage in the example is treated as a source field. We do not claim that
it is calculated according to a proper methodology. We only aggregate the synthetic portfolio by this feature and check basic invariants: stage is not empty, amounts are non-negative, principal is aggregated reproducibly. Such honesty is more important than apparent completeness. The educational mart should clearly say where the example ends and real banking methodology begins.
In credit data it is especially useful to separate source fact from interpretation. days_past_due may be a number from the system. The decision of how it affects portfolio quality is already methodology. principal_rub may be a balance or the original amount. If this is not clarified, the aggregate looks convincing but may mean different things. The specification should either close the question or explicitly leave it open.
A good reviewer report on the credit mart does not try to become a credit committee. It checks boundaries: SQL did not redefine stage, amounts did not go negative, the mart does not claim more than it can prove. This is a modest role, but it prevents the main educational defect — confident text around unproven methodology.
Practice
Find in the credit mart one field that looks methodological.
Write down whether it is a source fact, an educational simplification, or requires a separate banking specification.
Typical mistake
Adding the "correct" banking methodology without a specification. The agent may know the words IFRS, PD, LGD, ECL, but in an educational project these are external concepts. They cannot be introduced without a separate product specification.
Control questions
- Why can't the source
stagebe silently redefined? - What checks are needed for an aggregated credit mart?
- Where does the boundary run between an educational mart and real methodology?