Executive guidance on credit risk data governance in South African banking, covering IFRS 9 exposure data, ownership, collateral, staging, and lending lifecycle controls.
Many South African banks do not have a credit model problem. They have a credit risk data governance problem.
The symptoms are familiar: IFRS 9 provision numbers move late in the reporting cycle; credit, finance, and treasury disagree on exposure values; collateral data is incomplete or stale; restructures are not consistently flagged; staging outcomes require manual adjustment; and executives receive explanations that depend too heavily on spreadsheets prepared under pressure.
For a chief risk officer or CFO, this is not a technical inconvenience. It affects capital planning, audit confidence, earnings volatility, collections strategy, conduct risk, and board reporting. In a South African environment shaped by POPIA, SARB prudential expectations, FSCA conduct scrutiny, legacy lending platforms, and operational disruption from load-shedding, credit risk data governance banking South Africa cannot be treated as a back-office clean-up exercise.
It must be managed as part of the lending lifecycle.
IFRS 9 expected credit loss calculations rely on probability of default, loss given default, exposure at default, forward-looking assumptions, and staging rules. The model may be mathematically sound, but the result is only as reliable as the data it receives.
A retail bank may have a well-calibrated home loan impairment model, yet still produce weak outputs if property valuation dates are missing, arrears status is inconsistent between systems, or restructures are captured in free-text notes rather than controlled fields. A business banking portfolio may show stable risk metrics until auditors ask why overdraft utilisation, limit expiry, and covenant breach indicators are stored in separate systems with no clear reconciliation owner.
The risk is not only misstatement. Poor input data can mask deterioration until it becomes visible through arrears or write-offs. By then, the bank has lost valuable time to adjust pricing, collections, risk appetite, or capital allocation.
Credit risk data governance should therefore define which data elements are critical to IFRS 9, who owns them, how they are validated, and what happens when they fail quality checks. This is not the same as model validation. Model validation tests whether the model behaves appropriately. Data governance tests whether the model is being fed the right facts.
For more on banking data strategy in this context, see Zorinthia’s broader guidance on data strategy for banking.
Exposure data is often assumed to be obvious. In practice, it is one of the most contested areas in credit risk reporting.
A loan operations team may own contractual balances. Finance may own general ledger balances. Treasury may use behavioural assumptions for liquidity reporting. Credit risk may calculate exposure at default using utilisation patterns, limits, product type, and undrawn commitments. Each view can be valid for its purpose, but IFRS 9 requires disciplined agreement on which exposure measure is used, when, and why.
Consider a corporate client with a term loan, revolving facility, guarantee, and foreign currency exposure. The relationship manager understands the facility structure. Operations records drawdowns. Treasury monitors currency exposure. Credit risk evaluates default risk. Finance reports impairment. If no single governance structure defines the authoritative exposure fields, the impairment process becomes a negotiation at month-end.
Good governance assigns ownership at the data element level. For example:
Ownership does not mean one department controls the entire process. It means there is a named accountable function for definition, quality, correction, and approval of changes.
Without this clarity, executive committees are left asking why exposure numbers changed, rather than discussing what the movement means for risk.
Collateral is central to loss given default, but in many banks it is less governed than origination data.
Security may be captured when the loan is granted, then updated unevenly over time. Valuations may expire without escalation. Insurance confirmation may sit outside the core lending record. Legal enforceability may be assumed rather than evidenced. In secured lending, this creates a direct impairment risk.
A commercial property loan illustrates the issue. The bank approves a facility against a shopping centre. At origination, the valuation is current, the bond is registered, rental income is assessed, and insurance is confirmed. Three years later, the borrower’s sector has weakened, vacancies have increased, the last valuation is outdated, and updated lease schedules are not captured in a structured form. The collateral record still exists, but it no longer supports confident LGD assessment.
This is not solved by asking credit teams to “update collateral”. Governance must specify:
For South African banks, collateral governance also needs POPIA discipline. Property, identity, guarantor, and business ownership data can include personal information. Access should be limited to legitimate business users, retention periods should be defined, and manual extracts should be controlled. A spreadsheet of guarantor details emailed between teams is not a harmless workaround; it is a potential compliance and reputational exposure.
IFRS 9 staging is often discussed as a risk methodology issue: Stage 1 for performing exposures, Stage 2 for significant increase in credit risk, Stage 3 for credit-impaired assets. The governance challenge is that staging depends on events captured across the lending lifecycle.
Origination quality affects the baseline risk view. Payment behaviour affects arrears triggers. Limit changes affect exposure. Restructures affect credit deterioration assessment. Forbearance, covenant breaches, debt review, business rescue, collections actions, and write-offs may each influence staging. If these events are captured inconsistently, staging outcomes become unstable.
A vehicle finance book provides a practical example. Customers affected by income disruption may enter short-term payment arrangements. If one operations team records this as a payment holiday, another as a restructure, and a third as a collections note, the staging engine may treat similar customers differently. The bank then faces both financial reporting risk and fair treatment concerns.
The solution is a controlled event taxonomy. In plain terms, the bank needs agreed categories for credit events, clear definitions, system fields that enforce those categories, and governance over changes to those definitions.
This matters beyond accounting. FSCA conduct expectations and Treating Customers Fairly principles require banks to understand customer impact. A staging process that treats equivalent hardship arrangements inconsistently can create uneven outcomes, especially in collections or pricing decisions.
Many banks rely on heroic month-end reconciliation. Skilled finance and risk teams know where the data usually breaks, how to adjust it, and who to call. That institutional knowledge is valuable, but it is not a sustainable control environment.
Reconciliations should be designed into the reporting process. The bank should know, before close, which balances must tie to the general ledger, which exposure fields must reconcile to source systems, which records are excluded from IFRS 9 processing, and which exceptions require sign-off.
Load-shedding adds a South African operational reality. Even large banks have stronger resilience than most industries, but upstream clients, branches, third-party data providers, and batch processes can still be affected by downtime or delayed file transfers. If an overnight data feed fails near reporting cut-off, the bank needs a pre-agreed fallback rule. It should not depend on an analyst deciding under pressure whether to reuse yesterday’s file.
Effective reconciliation governance includes:
This reduces the risk that impairment numbers become dependent on undocumented interventions.
Boards and executive committees do not need every data quality metric. They need the few measures that indicate whether credit risk decisions can be trusted.
A chief risk officer should be able to show, by portfolio, the completeness and reliability of the data driving IFRS 9 and lending decisions. For example: percentage of exposures with valid collateral valuations, number of facilities with missing limit review dates, volume of accounts with unresolved staging exceptions, ageing of data quality issues, and value of exposures subject to manual override.
The point is not to create a dashboard for its own sake. The point is to connect data quality to financial and risk decisions.
If a bank’s SME book has a high percentage of missing financial statement dates, the executive question is not “why is the field blank?” The question is whether credit appetite, pricing, provisioning, and collections strategy are being set on incomplete borrower information. If the mortgage book has outdated valuations in a stressed region, the question is whether LGD assumptions remain defensible.
King IV reinforces this accountability. Information governance is not only an IT matter; it sits within board oversight of risk, assurance, and performance. For a bank, credit risk data is among the most consequential information assets it holds.
Credit risk data governance fails when it is assigned to one function without authority over the full data path.
Risk understands methodology and credit policy. Finance understands reporting, audit, and impairment disclosure. Operations understands capture and servicing processes. Technology understands systems, integrations, resilience, and access controls. Business units understand product behaviour and customer context. None of these teams can govern the whole environment alone.
A practical operating model normally includes:
This does not require a large bureaucracy. It requires disciplined accountability over the data that matters most.
The starting point should be narrow. Select the portfolios where data weakness creates the highest financial or regulatory exposure: for example, commercial property, SME lending, unsecured retail, vehicle finance, or restructured accounts. Prove governance there before expanding.
Across advisory work, the same patterns appear repeatedly.
The first is treating IFRS 9 data as a reporting layer problem. If the issue originates at loan origination or servicing, correcting it in the impairment engine is too late.
The second is confusing data ownership with system ownership. The team that maintains a platform is not automatically accountable for the business meaning of default status, collateral value, or exposure type.
The third is allowing manual spreadsheets to become permanent controls. Spreadsheets may be necessary during transition, but they must be governed with access control, versioning, review, and retirement plans.
The fourth is underestimating legacy complexity. Many South African banks have accumulated product systems through growth, mergers, and historical technology decisions. Governance must work with that reality. Waiting for a full platform replacement before improving data discipline is usually a costly delay.
The fifth is failing to preserve evidence. Auditors, regulators, and internal assurance teams need to see not only the final number, but how the bank arrived at it.
Zorinthia’s example on an IFRS 9 provision model data failure shows how data weaknesses can undermine a technically capable impairment process.
Credit risk data governance is not about making data tidy. It is about whether the bank can defend its lending decisions, impairment numbers, collateral assumptions, staging outcomes, and portfolio actions with confidence.
For the executive team, the next question is simple:
Which credit data elements, if wrong or missing, would materially affect our IFRS 9 provisions, lending decisions, capital view, or customer outcomes — and who is accountable for each one today?
If that question cannot be answered clearly, the bank does not yet have adequate credit risk data governance.