Part 17. Payments and Risk Signals Mart

Payment data is dangerous because a technically simple aggregation can look like a risk decision. In the textbook mart_payment_risk_signals is not a scoring engine. It is an observation mart: which transactions are flagged with a risk flag and which amounts/channels require attention.

Grain

For an operation-level risk mart, the grain is:

one row per `transaction_id`

If the mart aggregates by client or by day, that is a different data product. You cannot silently change an operation-level mart to a client-level mart, even if the SQL becomes shorter.

What to verify

• transaction_id is not null and unique;
• the amount is not null;
• the risk flag is treated as a tutorial source signal;
• direct PII does not appear;
• transactions without a risk flag are not removed from the upstream layer without a specification;
• the reviewer can see where the threshold is a tutorial rule.

Bad approach

where risk_flag = true

Such a filter may be acceptable for a specific mart, but only if the specification says: "the mart contains only risk events." If the consumer expects all operations with a risk attribute, the filter breaks completeness.

Qwen query

Read stg_card_transactions, mart_payment_risk_signals, and specs.
Determine the grain, which transactions are included, which are excluded, and what verification
facts are needed for the risk mart. Do not modify the files.

Minimum output

Write a note about the risk mart:

Mart:
Granularity:
Source of the risk flag:
Included rows:
Excluded rows:
Verification facts:
Reviewer's manual questions:

Breakdown for the reader

The risk signals mart seems simple: take operations with risk_flag, add large amounts, and hand over the list. But this is exactly where the agent most often starts making up business. It may decide that risk is only the source flag. Or that risk is an amount above a threshold. Or that it needs to aggregate by client because that is more convenient for a report. All of these decisions are possible, but none of them should appear without a specification.

In the tutorial project, mart_payment_risk_signals is not a scoring model. This is fundamental. Scoring requires methodology, explainability, quality control, legal and risk procedures. Here, the mart is needed to teach SDD: to show how to separate the signal source from the decision, operation-level grain from client-level aggregation, observation from inference.

The large-amount threshold is also a tutorial rule, not a banking truth. If the threshold is written only in SQL, the reviewer will not understand whether it is a temporary simplification, a product requirement, or an agent's guess. Therefore, the threshold must appear in the specification, the verification note, and the reviewer's report. Then a future author will be able to replace it with a different methodology without hidden drift.

This chapter teaches an important question: "what row does the mart represent?" If the row is an operation, then transaction_id is the key, and the client may repeat. If the row is a client, different fields, different tests, and a different specification are needed. These options cannot be treated as interchangeable just because both help talk about risk.

Practice

Describe two variants of the risk mart: operation level and client level. For each, specify the grain, the consumer, and why the SQL of one variant cannot be silently replaced by the other.

Typical mistake

Turning the tutorial risk_flag into a real decision. In the banking domain, such a decision requires a separate model, explainability, management procedures, and legal review. In this volume, the risk flag is a signal for the SDD process, not a scoring product.

Review questions

1. Why can't operation-level and client-level risk marts be mixed?
2. When is a risk_flag = true filter a breaking change?
3. What manual fact should the reviewer verify?