Credit risk is often associated with ratings, default probabilities and loss estimates. Before those results come individual data items and decisions about their meaning. Is a payment genuinely overdue, or has it been linked to the wrong contract? Is the income figure current? Do two companies belong to the same group? My existing experience concerns data analysis, integration and statistical information systems, and output validation. Credit risk is an area I want to develop in. This article therefore sets out a proposed analytical approach rather than claiming that I have worked as a credit risk specialist.
A documented case: data quality at Citigroup
On 10 July 2024 the US Federal Reserve announced a $60.6 million penalty against Citigroup for insufficient progress on data quality remediation and compensating controls under its 2020 action. The official announcement does not establish a particular credit-model error or the bank’s present condition. I use this historical case to distinguish a remediation programme from demonstrated control effectiveness, not to extend the regulator’s findings.
My own analysis would separate the permanent correction from management of the risk that remains meanwhile. Reports continue to be produced while a replacement system is being built. The team needs to know which information is reliable, which carries limitations, and how those limitations affect decisions. An interim control should have an owner, a defined scope and evidence that it actually operated. Its appearance on a programme slide is insufficient. This is a proposed lesson for analysis, rather than an additional claim about what happened at Citi.
Establish what each data item means
I would ask about definition, reference date and source before comparing numbers. Loan amount might mean the original agreement, current drawings or the total commitment. Confusing those concepts can create a discrepancy without an arithmetic error. Outstanding balance, available limit and secured amount need separate treatment. A data dictionary should therefore explain business meaning and exception handling as well as field name and type. A short worked calculation can expose differences in understanding that remain invisible in apparently identical labels across two systems.
Missing values need similar care. A blank may mean unknown information, an inapplicable measure, a transfer defect or an item awaiting verification. Zero is a specific value. If an import replaces all these conditions with zero, the table becomes technically complete while uncertainty disappears. I would not consider a ban on empty cells sufficient evidence of quality. I would ask whether the process distinguishes the reasons and whether a decision-maker can see the limitations that matter. A documented exception can be more informative than an invented default value.
A hypothetical portfolio example
Imagine 1,000 corporate loans. The date of the latest financial statements has been verified for 900, copied without verification for seventy and omitted for thirty. The average rating might appear unchanged. Before interpreting it, I would segment the portfolio by evidence quality. If twenty of the thirty missing items belong to one industry, a headline missing-data rate of three per cent hides an important concentration. I would investigate whether the affected group changes the conclusion and how much exposure it represents, rather than merely report a record count.
Suppose total exposure is CZK 2 billion. The thirty incomplete records might represent CZK 60 million or CZK 600 million. Both datasets have the same number of exceptions but different significance for a decision. I would present record count, value and concentration together. I would not automatically give every missing item the worst possible rating: the relevant methodology owner should decide the appropriate treatment. My contribution would be to make the uncertainty and result sensitivity visible, so the decision does not rely on an undocumented assumption about the missing records.
Connecting business meaning and technical processing
I would trace a small set of records from original documents through processing to the report. At each transition I would capture the identifier, timestamp and applied rule. If report and document disagree, I want the first point of divergence. It could be classification mapping, a delayed update or legitimate use of another reporting period. IT would explain technical processing and the business function the meaning of the rule. The analytical description should let both discuss the same record instead of exchanging general statements that the data does not reconcile.
I would also test the controls themselves. A non-empty rating is not necessarily a current rating. A value within the permitted range may still belong to another customer. Negative tests could therefore include swapped identifiers, stale evidence, duplicated contracts and changes in group membership. For each, I would define the expected response before execution. The aim is not the largest possible number of alerts. It is evidence that the control detects the situation it is designed to prevent and handles legitimate exceptions without obscuring the reason for acceptance.
Correcting a field and correcting a process
A one-off correction should be followed by a question about recurrence. Who should notice an outdated document, and when? What happens if an update never arrives? How does a failed transfer become visible to the user? For recurring checks I would track exception age, repetition and ownership as well as totals. If the same field is repaired manually every month, the final report can be correct while its production remains fragile. I would describe that separately, distinguishing the quality of an individual result from the reliability of the process.
A useful finding should state the differing data, affected population, comparison evidence and remaining uncertainty. I would avoid overstating impact: a bad input does not automatically change a lending decision. Another control may intercept it, or the relevant model may use a different source. I would therefore identify the data’s real recipient and verify its downstream use. A finding that explains the limits of its conclusion is more credible than a strong claim made without understanding the data journey or the decision it ultimately supports.
Summary and recommendations
Data quality supports credit-risk interpretation but does not replace specialist assessment. I would start with definitions and reference dates, validate relationships and freshness, and assess exceptions by both count and value. Material exceptions need a traceable resolution process and a check of actual downstream effects. My proposed contribution is careful validation of the evidence and clear communication between technical and business specialists. That provides a sound foundation on which credit-risk expertise and the institution’s approved methodologies can build, without confusing an analytical observation with an unsupported risk conclusion.