What credit risk means in a bank

How to study this topic

Credit risk in a bank is the possibility that a borrower or counterparty fails to meet agreed obligations, creating loss, capital pressure, provisioning impact, customer management decisions, and portfolio risk. Read this chapter as a banking operating lesson, not as an isolated data science definition. The purpose is to understand how a bank turns source evidence into controlled insight and then uses that insight in decisions, reporting, validation, monitoring or human review.

The scope is banking-wide. It includes retail loans, mortgages, credit cards, overdrafts, SME lending, corporate lending, trade finance, and treasury counterparties. Payments are not the centre of this chapter. Where transaction data appears, it appears only as one type of banking behaviour or exposure evidence. The main focus is the bank's risk, customer, finance, compliance, operations and governance reality.

A good learner should finish this chapter able to explain the concept to a business analyst, architect, data engineer, model validator, credit manager, risk officer and auditor without changing the meaning. If the explanation works only for a model developer, it is not yet strong enough for banking use.

The banking meaning

credit risk in a bank matters because banks do not use AI on abstract data. They use it on customers, products, accounts, obligations, exposures, cases, ledgers, risk ratings, decisions and reports. Every feature, score or risk view carries a meaning that can affect money, customers, staff workload, capital, provisions, compliance or reputation.

For credit risk, the basic idea is simple but serious: the bank has given value, committed funds, taken exposure or accepted counterparty risk, and may not receive full repayment according to agreed terms. That risk exists in a single borrower, but it also exists across products, sectors, geographies, collateral types, ratings, industries and economic conditions.

The banking meaning must therefore be documented in plain language. What does the signal represent? Which source created it? Which date matters? Which exclusions apply? Who owns it? Which decisions may use it? What are the limitations? These questions are practical, not theoretical.

Source systems and business evidence

Source areas include retail loans, mortgages, credit cards, overdrafts, SME lending, corporate lending, trade finance, treasury counterparties, guarantees, collateral, limits, and undrawn commitments. Some sources show customer intent. Some show final ledger facts. Some show case outcomes. Some show risk classification. Some show finance view. Some show regulatory view. A serious bank does not treat all of them as equal just because they can be joined in a table.

The first design question is authority. If two systems disagree, which one wins for this purpose? The second is timing. Was the value available at the time of the model score or only later? The third is purpose. Was the data collected and approved for this use? The fourth is lineage. Can the bank trace the value later, including transformation and quality checks?

Without this evidence, AI creates fragile confidence. A score may look precise, a dashboard may look clean, and a report may look official, but the bank may be unable to explain why the number is trustworthy.

Definitions and boundaries

Definitions must be explicit. For this chapter, words such as credit, risk, borrower, default, exposure, and portfolio cannot be left to habit. In a bank, the same word can carry different meanings in risk, finance, operations, reporting, model development and customer treatment. The definition should say exactly what is included, excluded and controlled.

Boundaries are equally important. A definition approved for one purpose may not be approved for another. A risk feature may support portfolio monitoring but not direct customer decisioning. A finance view may be reconciled for reporting but too late for intraday scoring. A model label may be useful for training but not identical to a regulatory reporting category.

The bank should avoid false simplicity. Shared definitions do not mean every team uses only one view forever. They mean every view is named, owned, mapped and reconciled. That is how different business purposes can coexist without creating confusion.

Controls before model use

Controls should include credit policy, risk appetite, underwriting standards, affordability assessment, collateral valuation, and portfolio limits. These controls must check technical shape and banking meaning. Technical shape tells the bank whether the data can be processed. Banking meaning tells the bank whether the processed value can be trusted for the intended decision.

A control should not only fail or pass. It should explain impact. Which records are affected? Which models consume them? Which reports consume them? Is the issue material? Should scoring stop? Should a fallback rule apply? Should the issue be visible as a limitation? Who owns correction?

This is where many banking AI efforts become either strong or weak. Strong teams make controls part of the design. Weak teams add controls after the model already depends on the feature. Retrofitting evidence is always harder than designing evidence from the start.

Model and reporting impact

Typical uses include credit approval, limit setting, pricing, portfolio monitoring, capital calculation, IFRS 9 or CECL provisioning, collections strategy, and risk appetite reporting. These uses are not equal. A portfolio dashboard, a credit approval model, a fraud triage queue, a compliance case ranking, a provisioning calculation and a management report all carry different materiality. The same data issue can be minor in one use and serious in another.

In credit risk, model outputs can influence approval, referral, pricing, limit setting, collections, capital, expected credit loss and management oversight. A wrong risk view can create customer harm by approving unaffordable credit or rejecting good customers. It can also create bank harm by underestimating losses, overconcentrating exposure or reacting too late to deteriorating portfolios.

Model validation and monitoring should therefore review the feature or risk concept as well as model performance. If the input meaning is unstable, the model performance number is not enough.

Audit, challenge and explanation

A bank should be able to explain the path from source to outcome. That includes source fields, transformations, feature version, quality checks, model version, score output, reason codes where applicable, decision policy and human review. This is not only for regulators. It helps internal teams fix issues faster and explain outcomes more honestly.

Effective challenge should ask uncomfortable but useful questions. What if the source is wrong? What if the definition changed? What if a migration affected the field? What if late-arriving data changed historical values? What if one customer segment is less complete? What if the feature was reused outside its approved purpose?

BCBS 239 supports strong banking data governance because risk data needs accuracy, completeness, timeliness and adaptability. Model-risk guidance supports the need for input quality, data constraints, limitations, validation, monitoring, documentation and governance. These principles support a practical banking approach: data, model, decision and evidence must stay connected.

Customer and conduct perspective

Customer impact must stay visible. A model feature or credit-risk view may affect a customer's access to credit, service priority, fraud friction, collections treatment, complaint handling, product offer, relationship review or manual referral. Even when the customer does not see the model, the model may shape the customer's experience.

This is why fairness, transparency and human review matter. A feature can be statistically useful and still problematic if it acts as an unfair proxy, punishes missing data, reflects old policy bias, or treats temporary customer stress as permanent weakness. A bank needs both analytical discipline and conduct judgement.

The safest design is not to avoid AI. It is to use AI with clear purpose, controlled inputs, explainable limits, monitored outcomes and human accountability for high-impact actions.

Operational implementation

Operational implementation should include a runbook. The runbook should describe sources, schedules, event timing, quality controls, exception ownership, restart rules, replay rules, fallback behaviour, monitoring dashboards and escalation. A concept that has no operating model is not production-ready banking AI.

Change control is central. If a source field changes, a definition changes, a feature calculation changes, a model version changes or a decision policy changes, the bank should know what downstream consumers are affected. This is where lineage, versioning and inventory are practical controls, not academic documentation.

The bank should also maintain evidence for incidents. If a score, report or decision is challenged later, the team should reconstruct what happened without guessing. Reproducibility is a major part of trust.

Common mistakes

The first mistake is confusing a technical join with banking truth. The second is treating a feature name as a full definition. The third is using future information in historical testing. The fourth is assuming risk, finance and reporting use identical meanings because the same word appears in each area.

Another mistake is letting teams create local versions of the same signal without mapping them. This creates report mismatch, model inconsistency and audit confusion. Local flexibility is useful during exploration, but production use needs ownership, definition and reconciliation.

The final mistake is not deciding what happens when the data fails. A bank needs fallback before failure: stop scoring, use last good value, route to manual review, switch to a rule, or flag degraded use.

Practical banking example

Consider a bank reviewing an SME credit portfolio. The bank needs borrower financials, repayment behaviour, limit utilisation, collateral, sector exposure, arrears, covenant status, risk rating movement, account conduct and macro context. AI can help identify early warning patterns, but only if the bank understands which facts are final, which are provisional, which are manually adjusted and which are approved for credit use.

The practical question is not whether the model can calculate. It can. The question is whether the bank can explain and defend the calculation in context. If the bank cannot do that, the model is not ready for a material decision.

A strong implementation keeps the learning human: source fact, business meaning, controlled feature, model output, bank decision, evidence. That path should be visible.

Bank-ready checklist

Before marking this topic complete for production use, ask: is the definition documented, is the source authoritative, is the time logic correct, is lineage complete, are exclusions documented, are quality checks monitored, are versions stored, and is permitted use clear?

For credit risk specifically, ask whether the bank understands borrower capacity, willingness to repay, exposure size, collateral support, portfolio concentration, early warning indicators, provisioning impact and capital impact. Credit risk is not only a borrower score. It is a bank-wide risk discipline.

If the answer is yes, the bank has a solid foundation. If the answer is no, the content may look complete but the control is still weak.

The event, the exposure and the decision

Credit risk is the possibility that a borrower or counterparty will not meet an obligation as agreed, causing a loss or other adverse result for the bank. In an AI and ML course, the useful question is what the model predicts and which decision uses it. A loan-application model might estimate the probability of a defined default within twelve months. A portfolio model might flag existing borrowers for review. A recovery model might estimate loss severity after default. These are different targets with different populations, timelines and consequences. A credit score alone cannot establish affordability, legal eligibility, accounting loss or capital adequacy.

The bank also has exposures of different forms. A fully drawn term loan, revolving line, guarantee and derivative counterparty position do not have identical cash flows or future exposure. For a retail lending example, focus on the contractual loan and its borrower. Define the observation date, amount at risk, repayment schedule and default event. Then identify what the model can know at the decision time. The practical risk process links evidence and estimate to an approved policy, a human review path and ongoing monitoring.

Three component questions

Probability of default asks how likely a specified default event is over a specified horizon. Loss given default asks how much of the exposure would be lost after recovery, conditional on default, under a defined convention. Exposure at default asks how much would be outstanding at the event, including relevant future drawings or changes. These concepts support expected-loss thinking, but the bank's actual accounting, pricing and prudential methods apply their own rules and approval. Do not multiply generic numbers and call the result a regulatory capital requirement.

A lending model's PD can rank applicants but may be poorly calibrated for expected loss. A long-running recovery case may not have a final LGD outcome. A revolving facility's balance can grow before default, making current balance a poor substitute for EAD. Each model needs an appropriate dataset and validation. A single feature such as days past due might inform several models while being interpreted differently. The analyst documents allowed uses and prevents a familiar metric from migrating into an unvalidated decision.

Define the borrower and the obligation

The risk unit might be an individual, a joint borrower, a legal entity, a corporate group or a facility. A customer can have several loans, a joint account and an authorized user. A corporate structure can change. Identity mapping must retain relationship type and effective time. An application score for one person cannot automatically attribute every joint account event to that person. A portfolio default label at obligor level may differ from a facility-level arrears flag. Model developers and business owners agree on the unit before assembling features and outcomes.

The obligation comes from terms and schedules, not simply a balance column. Payment due dates, grace periods, interest rates, holidays and restructures affect whether a payment is late. A ledger entry can be reversed or applied to a different facility. A model estimating credit deterioration should use the schedule and servicing records known at the score time and preserve later corrections separately. If the bank migrates loans between systems, link old and new IDs rather than treating long-standing borrowers as new.

Sources and their limits

Application data may include identity, verified income, declared expenses, internal account history, permitted bureau information and product terms. Each source has a different time and reliability. A recurring incoming transfer is not necessarily income; a bureau response may be stale or fail; a customer with no internal history is not known to have perfect repayment. A feature contract identifies source, definition, ownership, coverage, age and missingness reason. A model should not silently turn missing into a favorable or unfavorable value without validation and policy approval.

External market and macro data can support scenario or portfolio models, but their publication dates and revisions matter. A historic back-test using the final revised unemployment series can overstate predictive performance if the live bank had an earlier vintage. For an individual decision, use only data available and permitted for that purpose. The feature pipeline preserves decision cutoff, ingestion time and source version. A later correction helps investigate the earlier decision; it does not change what the model knew then.

Application and behavior models

An application model scores a prospective loan using information available before approval. Its development outcomes generally come from applicants the bank previously approved; rejects do not have observed repayments on the bank's loan. This selection limit matters when proposing a broader approval policy. A behavioral model scores existing borrowers using servicing history and account activity. It may identify an emerging risk for a supportive intervention or portfolio review. The two models have different populations and observation windows. A strong behavioral feature may not exist at origination.

The action boundary matters. The model may return a score and uncertainty status, while policy separately checks eligibility, affordability, fraud and exposure limits. A low application score might refer for human review; a high score cannot override a failed mandatory control. For existing borrowers, a rising risk score should not automatically trigger punitive collections. The bank defines proportionate actions and records the human assessment. Evaluate customer outcomes as well as model accuracy.

Loss and recovery process

Default is not always the end of the exposure. Collections, restructuring, collateral realization, guarantees and recovery payments influence ultimate loss. A recovery model needs cash-flow dates, workout costs, discounting, collateral status and unresolved-case treatment. Training only on closed cases can bias estimates because difficult cases remain open longer. A model should state whether it predicts realized loss under the current recovery process, and the bank should examine how changes in collections strategy affect outcomes.

The risk process also includes concentrations and correlated shocks. A portfolio of individually low-PD loans can have material aggregate risk if borrowers share an economic driver. A downturn can raise defaults while reducing collateral values. ML correlations from a benign period may not describe stress. Risk teams use scenario analysis and limits alongside estimates. Portfolio monitoring checks product, geography and sector concentrations under the bank's approved categories without assuming an individual score captures every systemic effect.

A worked loan example

Consider a fictional applicant seeking a three-year unsecured instalment loan. The bank verifies identity, income and existing commitments, receives a dated bureau response and calculates affordability. A credit model uses permitted application features to estimate a defined twelve-month default probability for a similar applicant population. The policy may approve, refer or decline based on the score plus other controls. The example has no universal cutoff or calibrated PD. The decision record stores source snapshots, feature versions, model artifact, score, policy version, final action and any override.

After origination, the loan has a schedule and ledger. A monthly behavioral model observes repayments and potentially offers a review if risk rises. If a payment posts late because of a feed delay, the feature service should expose the uncertainty. If the borrower later restructures, the effective schedule changes. For validation, the bank joins dated scores to mature outcomes under a stable default definition, with treatment of early closure. The same borrower may move through application, servicing, support and recovery stages; each model sees a different information set.

What validation needs to establish

A model owner defines the intended population, target horizon, action and limitations. Development checks leakage, missingness, representativeness and feature provenance. Independent validation challenges conceptual soundness, implementation and outcomes. Discrimination asks whether riskier cases tend to rank higher; calibration asks whether estimated probabilities align with observed rates for mature cohorts. Stability checks whether the relationship holds over products, channels, time and relevant groups. A high discrimination statistic cannot repair a wrong default label or a data join that assigns another person's arrears.

Because repayment outcomes take time, monitoring uses several clocks. Source freshness, score distribution, referrals and overrides are visible quickly; default and recoveries mature later. A recent cohort must not be treated as non-default simply because its horizon has not ended. A change in approval policy can change who enters the future outcome sample. Compare with a simpler baseline and examine errors by segment. If a model is outside its validated population, refer or restrict use instead of reporting a confident score.

Fairness and explanation

A credit decision affects access to funds and can affect a customer's future opportunities. Variables can act as proxies for protected characteristics even without naming them. Review performance, referral and adverse outcomes across relevant groups where law and data permit, investigate disparities and consider better evidence or alternative designs. Thin-file customers may need a fair path to supply documents. An explanation should identify the actual factors and policy rules behind a covered decision under applicable law. A generic model score or an after-the-fact feature importance chart may not describe the principal reasons.

Human review is meaningful when the reviewer can inspect source evidence, correct errors and record a reasoned outcome. Monitor overrides and complaints as possible signals of model or data failure. A model that refers too many cases can overwhelm staff, delaying customers and turning a nominal human check into a rubber stamp. Test capacity before thresholds change. A bank should also examine overextension: an optimistic score must not replace an affordability assessment and lead to harmful lending.

Accounting and capital boundaries

An impairment allowance estimates expected credit losses under the applicable accounting framework and reporting date. Prudential capital follows applicable regulatory rules and approvals. A lending PD or customer referral score may feed a component only after validation for that use. IFRS 9's staging and U.S. CECL's measurement differ; they are not interchangeable labels for one model output. A risk analyst can share source evidence across processes while keeping methodologies, horizons and sign-off distinct. Reconcile exposure counts and balances to the finance book before comparing model-derived portfolio metrics with reported figures.

Suppose a model change raises PD for a concentrated segment. An application policy may refer more customers, while a capital or allowance process might use a different calibrated parameter, horizon and constraint. The owner evaluates each use separately on a fixed dated portfolio. A score change does not automatically authorize a customer policy change or a reporting adjustment. A dependency map identifies which model versions feed which downstream calculations and enables controlled impact analysis.

Incident and fallback

Imagine a customer-master merge combines two borrowers' repayment histories. Scores become plausibly higher for some applications. The incident owner identifies affected relationship versions, time range and model decisions, contains automated use under approved fallback, and preserves original vectors and actions. Corrected replay shows which customers may have received different outcomes. Product and control owners determine remediation and communication under policy. A code fix alone cannot undo an adverse decision or restore trust in reported metrics.

Planned changes receive a similar, preventive review. Compare old and candidate features on a dated cohort, test source edge cases, check model scores and policy actions, obtain validation and document rollback. A service outage should return an explicit status; a missing bureau feed must not become a fabricated low-risk value. Monitor both service health and semantic health such as stale data, duplicate events and unexpected zeros. A reliable risk model depends on an equally reliable chain of data and human decisions.

Pricing is another controlled use

A bank may use credit-risk estimates in pricing, but a price includes funding costs, operating costs, capital, expected loss, product strategy and applicable legal or conduct constraints. A PD score is not a customer interest rate. If a pricing model is proposed, its owner should state the approved population, target, sensitivity to economic conditions and policy boundaries. Test whether a change in a feature or score alters offers for relevant customer groups and whether explanations remain supportable. A model that increases revenue in a historical simulation may also deter suitable borrowers or increase risk by changing who accepts an offer.

For example, two applicants can have the same estimated default probability but different loan terms and collateral. Their expected loss and capital treatment may differ. A deterministic fee or affordability rule may also constrain an offer. A pricing experiment should track applications, acceptance, repayment and complaints over a mature period, rather than declare success from booked-margin estimates alone. The bank must distinguish model prediction from the commercial and legal decision that uses it.

Counterparty risk is related but distinct

Credit risk also arises when a bank faces a trading counterparty. Exposure can vary with market values and collateral arrangements, so a simple loan balance is not an adequate EAD concept. An ML model used to forecast exposure needs contract, netting, margin and market data appropriate to the product and approved methodology. A wrong counterparty identity or stale collateral record can distort a portfolio estimate even if the model's statistical fit appears sound. Specialized controls and prudential rules apply; a retail loan example should not be generalized to derivatives without a separate definition and validation.

This distinction helps the learner ask the right question: who owes what, under which agreement, at what future point, and how might loss arise? For an instalment loan, scheduled payments and borrower default dominate the example. For a revolving facility, future draws matter. For a counterparty position, exposure can move with markets before default. Each use may share risk vocabulary while requiring different sources, models and oversight.

Limits of a score in economic change

Credit models learn from observed decisions and outcomes. When inflation, rates or employment conditions change, a historical relationship between features and default may weaken. Monitor calibration by origination vintage and product as outcomes mature, and investigate shifts in applicant mix, underwriting policy and source data. Scenario analysis can explore sensitivity to plausible conditions, but cannot prove exactly who will default. A model owner should document uncertainty and restrictions on use during a disruption. A prudent fallback might refer cases for review or reduce automated decisions while evidence is reassessed.

An analyst should not automatically retrain on the newest few months. Recent default labels may be immature, and the observed borrowers were selected by a changed policy. First verify data contracts and event timing, then examine mature cohort evidence. A challenger can be tested in shadow mode with the same permissible inputs. Governance decides whether to approve, restrict or retire the model based on actual performance, customer effects and the bank's risk appetite.

Analyst acceptance set

For a release, construct applicants with regular verified income, irregular income, a thin bureau file, joint accounts, a disputed record and an unavailable feed. For an existing loan, test a full payment on the grace boundary, a partial payment, a valid holiday, a restructure and a reversed posting. Write expected feature values and model eligibility before execution. Check the final policy action separately. A validator should trace sample decisions from source records to scores and customer outcomes, and use later corrections only in a marked impact review.

Credit risk becomes an ML problem only after the bank has named the event, population, time horizon and permitted action. Predictive models can improve ranking, forecasting and early support, but they must be checked against the actual contracts and people they affect. The bank's controlled decision process turns estimates into responsible use: clear source definitions, point-in-time evidence, independent challenge, explicit policy and a route to correct mistakes.

Banking practice note on business meaning

For credit risk in a bank, business meaning matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Observed facts come from areas such as retail loans, mortgages, credit cards, overdrafts, and SME lending. Derived signals apply a controlled definition and time window. The model interprets those signals within an approved purpose. The business action decides what happens to the customer, portfolio, report, control or case. When these layers are visible, the bank can challenge the result without guessing.

This is the difference between a banking-grade AI foundation and a simple analytics exercise. Banking-grade work preserves lineage, ownership, quality, version, reconciliation, permitted use, fallback and audit evidence. It is slower at the beginning, but it prevents expensive confusion later.

Banking practice note on timing

For credit risk in a bank, timing matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Banking practice note on lineage

For credit risk in a bank, lineage matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Banking practice note on definition ownership

For credit risk in a bank, definition ownership matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Banking practice note on model validation

For credit risk in a bank, model validation matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Banking practice note on reporting impact

For credit risk in a bank, reporting impact matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Banking practice note on customer outcome

For credit risk in a bank, customer outcome matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Banking practice note on audit evidence

For credit risk in a bank, audit evidence matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Banking practice note on operational fallback

For credit risk in a bank, operational fallback matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Banking practice note on change control

For credit risk in a bank, change control matters because banking AI is only as strong as the evidence chain behind it. A bank can build a technically good pipeline and still create a weak decision if the meaning, timing, definition or limitation is wrong. The practical discipline is to keep observed fact, derived signal, model interpretation and business action separate.

Risk belongs to a decision and horizon

Credit risk describes uncertainty that a borrower will meet an obligation and the loss if the obligation is not met. At application, the bank decides whether and on what terms to extend credit using evidence available then. After origination, it monitors a changing portfolio and may assess expected losses under a different process. A probability of default, loss given default and exposure at default are related components, but a single score is not the whole decision. Product policy, affordability, collateral, concentration and customer treatment remain separate controls.

Consider two loans with the same estimated default probability. One has a small secured balance; another has a large unsecured revolving limit. Their potential loss and exposure dynamics differ. Compare a dated assessment for each, showing contractual obligation, current balance, possible drawdown, recoveries and uncertainty. Do not multiply components from mismatched populations or horizons and label the result a precise forecast. State the event definition and observation period before interpreting any rate.

At monitoring time, a borrower may enter arrears, cure or restructure. Record event dates and source statuses; a later cure does not erase the earlier distress event. A model may flag a case for review but cannot independently change an account's legal terms. Track decisions, overrides, actual repayment and customer effects. A reviewer should be able to explain what was known at origination and how subsequent evidence changed the bank's assessment.

Primary sources for further study

• Basel Framework CRE32: IRB risk components
• IFRS Foundation: IFRS 9 Financial Instruments