Application scorecards at onboarding

How to study this topic

Application scorecards at onboarding help a bank assess new credit applicants using application data, identity evidence, affordability, bureau information, policy rules and risk indicators before granting credit. The phrase may sound technical, but the banking meaning is practical. A bank uses this concept to decide how much risk it is taking, how much loss it may face, how to price or limit exposure, when to refer a case, how to monitor portfolios and how to explain credit decisions.

Keep the scope banking-first. This chapter is about lending, borrowers, counterparties, credit obligations, portfolios, limits, collateral, repayment, arrears, provisions, capital, governance and customer treatment. It is not a payments chapter. Transaction behaviour may appear only as account conduct evidence where it genuinely supports credit risk.

A learner should finish this topic able to explain it to a credit analyst, business analyst, data engineer, model validator, underwriter, collections manager and auditor. Plain language matters because credit-risk models are not useful if only modellers understand the answer.

The plain language meaning

An application scorecard answers the question: based on what the bank knows at onboarding, should this applicant be approved, rejected, referred, priced differently, given a lower limit, or asked for more evidence? It is a structured way of combining credit policy, application data and risk indicators.

The concept must always be tied to purpose. A number without purpose is dangerous. A PD used for application decisioning may differ from a PD used for IFRS 9, capital or portfolio monitoring. An LGD used for pricing may differ from a downturn LGD view. An EAD for stress testing may differ from day-to-day exposure monitoring. Scorecards also differ by product, portfolio and decision point.

Plain language does not mean weak explanation. It means the explanation should remain accurate without hiding behind formulas.

Source systems and evidence

Useful source areas include application form, identity verification, KYC data, income evidence, employment data, bureau score, existing obligations, deposit account conduct, fraud checks, affordability rules, product policy, and manual underwriter notes. A credit-risk chapter depends on controlled data because every input can change the risk view. Income evidence, arrears data, utilisation, collateral value, limit data, customer identity, bureau information and case outcomes all need clear source ownership and timing.

The bank must know which source is authoritative. A front-end application may show what the customer declared. A document-verification platform may show what was evidenced. A core loan system may show what was booked. A collections system may show what happened after stress started. A risk engine may show the rating and score. Finance may show impairment treatment. These views must be mapped, not casually mixed.

The source question becomes sharper when AI and ML are used. If a model learns from a field, the bank must know whether that field is complete, stable, corrected, overridden, refreshed and legally usable for the purpose.

Key inputs and calculations

Key inputs include application form, identity verification, KYC data, income evidence, employment data, bureau score, existing obligations, and deposit account conduct. The calculation must define the time horizon, observation period, product scope, customer population, exclusion rules and treatment of missing values. Without these, the same concept can be calculated in several different ways and produce conflicting results.

For application scorecards, the bank needs application data, identity evidence, income and affordability data, bureau attributes, existing commitments, fraud checks, policy rules and product eligibility. The model must not treat incomplete onboarding evidence as if it were reliable truth.

The formula is only one part. Banking interpretation, data quality and governance decide whether the output is safe to use.

Controls before use

Controls should include data capture validation, applicant identity match, income verification, bureau data freshness, policy rule alignment, and reject inference review. These controls must run before the concept feeds a model, decision engine, risk report, provisioning process or strategy review. Technical checks are not enough. The bank must check whether the value makes sense in credit terms.

Important checks include population coverage, source reconciliation, date alignment, treatment of overrides, treatment of outliers, missingness analysis, validation against realised outcomes and monitoring of drift. Credit-risk models can fail slowly. They may not throw a system error. They may simply become less aligned with borrower behaviour or economic conditions.

The bank should also define who can override the model, how overrides are recorded, and how override performance is reviewed. Human judgement can improve credit decisions, but undocumented override culture can damage validation.

How it supports bank decisions

Common uses include credit approval, manual referral, risk-based pricing, limit setting, affordability assessment, customer onboarding, portfolio origination quality, and policy monitoring. Each use has a different control requirement. A model used for internal portfolio insight may need one level of governance. A model used for credit approval, regulatory capital, provisioning or customer treatment needs much stronger evidence, validation and monitoring.

Application scorecards help keep onboarding consistent. They support approval, referral, pricing and limit setting, but they must stay aligned to credit policy and affordability rules. They should support underwriters, not hide judgement behind a score.

The output should be explainable to the decision owner. If a credit manager cannot understand why the model changed a view, the bank has a governance problem even if the statistical result is strong.

Provisioning, capital and portfolio view

Credit-risk concepts matter beyond individual decisions. They feed portfolio monitoring, risk appetite, concentration review, stress testing, capital planning and expected credit loss. The same borrower-level evidence can roll up into management and regulatory views.

IFRS 9 expected credit loss uses credit-risk movement to decide whether a financial asset remains in a 12-month expected loss view or moves into lifetime expected loss because credit risk has increased significantly. That makes data timing, default definition and risk movement important. A poor risk signal can affect provisions and reported performance.

Capital frameworks also care about credit-risk parameters. PD, LGD and EAD are not classroom abbreviations. They are part of how banks understand expected and unexpected loss, risk-weighted assets, portfolio quality and risk-adjusted return.

Customer and conduct impact

Credit-risk models affect customers. They can approve credit, restrict credit, increase price, reduce limit, refer for manual review, trigger collections activity or identify customers needing support. A wrong model can harm a customer by granting unaffordable credit or by denying reasonable credit without a fair basis.

Fairness is not solved by removing obvious sensitive fields. Proxies can appear through income, geography, employment type, channel usage, account history, product access or missing data. The bank should review whether the model treats customer groups fairly and whether limitations are visible to decision-makers.

Human review is important where impact is high. A score can support judgement, but the bank remains accountable for the decision.

Validation and monitoring

Validation should review concept, data, methodology, calibration, discrimination, stability, limitations and use. It should not only ask whether the model predicts. It should ask whether the model is suitable for the bank's portfolio, product, policy, customer population and decision purpose.

Monitoring should compare predicted outcomes with actual outcomes. For PD, defaults should be compared with predicted default rates. For LGD, realised loss and recovery experience should be reviewed. For EAD, drawdown and exposure at default should be tested. For scorecards, approval quality, referral rates, override outcomes and portfolio performance should be monitored.

If performance deteriorates, the bank may need recalibration, redevelopment, policy adjustment, overlays, tighter controls or temporary restrictions. Model monitoring must have a response path.

Common mistakes

The first mistake is confusing the parameter with the whole credit decision. PD, LGD, EAD and scorecards are decision inputs, not the entire decision. The second mistake is using weak labels. The third mistake is ignoring data timing. The fourth mistake is assuming a score remains valid after products, policy or economic conditions change.

Another mistake is treating a model as neutral because it is quantitative. Credit models reflect historical data, policy decisions, source availability, customer access and economic cycles. The bank must challenge whether the model learned credit risk or learned old operating patterns.

The final mistake is failing to explain limitations to users. A model can be useful with limitations if users understand them. A model becomes dangerous when limitations are hidden.

Practical banking example

A new customer applies for a credit card. The application scorecard uses bureau data, income evidence, identity match, affordability, existing obligations and policy rules. If the score is borderline, the bank may refer to an underwriter rather than blindly approve or reject.

The practical point is that credit-risk models support judgement. They should make banking decisions more consistent and evidence-based, but they should not remove responsibility from the bank.

Bank-ready checklist

Before using this concept in production, ask: is the definition clear, is the population right, are sources authoritative, are time windows correct, are labels validated, are overrides governed, are missing values explained, are customer impacts reviewed, and can the result be reproduced later?

Then ask: is the model calibrated, independently reviewed, monitored, documented and approved for this exact purpose? Is it being used for approval, pricing, provisioning, capital, collections or internal insight? Has the bank matched controls to impact?

If the answers are strong, the concept is bank-ready. If not, the model may still produce numbers, but the bank should not treat those numbers as trusted credit-risk evidence.

An application score has a narrow job

An application scorecard converts information available at the start of a credit relationship into a consistent estimate or ranking for a defined lending decision. It can be a transparent points table or a statistical model expressed as points. The bank must state the applicant population, product, target outcome, observation date, performance horizon and action. A points total does not verify affordability, identity or legal eligibility. The final policy can approve, refer or decline after combining the score with separate controls. A scorecard designed for unsecured personal loans should not silently score a business facility just because the API fields fit.

Development begins with historic applications whose input snapshots and later outcomes are available. The observation cutoff is the time of the original application decision. A bureau balance updated next week, a collections action next year or an account closure reason known later cannot be inserted into that earlier feature vector. Store the source response and receipt time, field definitions, missingness and account relationships known then. If training uses today's corrected warehouse data, a scorecard may appear more predictive than it will be online.

Define the target and cohort

The scorecard may predict a stated delinquency or default event over a specified horizon. Define the event under the bank's approved rule, the unit of observation and how early closures, refinances and immature accounts are handled. A loan originated three months ago cannot yet be labeled non-default over a twelve-month performance window. One borrower with multiple applications can put related observations on both sides of a random test split and inflate validation. Separate development and later time-based cohorts with appropriate relationship controls.

Only borrowers approved under past policies generate repayment outcomes with the bank. Rejected applicants do not have a known outcome for the loan the bank never granted. This selection bias limits claims about expanding approval to applicants unlike the old book. Reject inference techniques require explicit assumptions and sensitivity testing; a fabricated label is not observed evidence. A controlled, approved pilot can collect some outcomes at a defined policy boundary, but it cannot reveal every rejected person's counterfactual. Report what the dataset supports.

Inputs at onboarding

Candidate inputs may include verified income, existing debt obligations, repayment history, account tenure and permitted bureau attributes. Each needs a precise definition and a reason it is relevant. A regular incoming transfer may be a refund or transfer between owned accounts rather than salary. A bureau no-match response is not the same as a low balance. A new-to-bank applicant has no internal history, not necessarily zero missed payments. Encode missingness and source age explicitly, then test whether a referral path is better than an automatic score when key evidence is absent.

Source rights and fairness need review. A variable can proxy for protected or vulnerable characteristics even without directly naming them. Assess performance, error and action rates by relevant groups where law and data permit. A feature that improves aggregate discrimination may be unsuitable if it relies on unstable access to digital channels or causes disproportionate false declines. Compare alternatives such as verified external evidence or human review. Document the lawful basis and product purpose for each source.

From variables to points

A traditional scorecard groups variables into bands and assigns points based on an approved statistical and business process. Analysts should inspect enough observations in each band, monotonicity where expected, missing categories and stability through time. A points table is understandable, but the meaning of its total depends on calibration. One hundred points is not a universal default probability. Keep the fitted model, band edges, scaling and score-to-risk mapping versioned. Test a value exactly on each boundary and a missing value.

For an illustrative exercise, a customer receives 30 points for a defined repayment-history band, 20 for a verified-income band and 10 for a moderate debt-burden band. A score of 60 is not an approval without the bank's calibrated mapping and policy. The same borrower might fail a separate affordability calculation. A reviewer traces each point to source evidence and the exact table version, then to the score and final action. The example values are teaching numbers, not a recommended lending rule.

Affordability and policy

The score estimates a defined risk outcome, while affordability assesses the applicant's capacity to meet the proposed obligation under applicable law and bank policy. An applicant with a favorable score can have too little residual income after commitments. Another with sparse scorecard data may demonstrate repayment capacity through verifiable evidence but need referral. Keep policy rules visible and order them explicitly. An identity failure, product exclusion or mandatory restriction should not be bypassed by a high score. Record which rule determined the final outcome.

At onboarding, an applicant may update declared income or provide documents during review. The original automated score and later human decision may use different information sets. Preserve both, with timestamps and reasons. A reviewer should not overwrite the earlier score with a recomputation using later evidence. Monitor how often referrals lead to corrected data and whether particular segments rely heavily on manual paths. If a scorecard creates unmanageable referral volume, human review may become superficial; capacity is part of safe model use.

Validation on a later cohort

Separate discrimination from calibration. A model can rank applicants correctly but understate absolute default rates. Examine performance on a later period with mature outcomes, by product, channel, thin-file status and relevant customer groups. Compare with a simpler baseline and the incumbent policy. Inspect sample counts and uncertainty rather than treating every small segment statistic as precise. Check changes in data capture and population before attributing a performance movement to the model.

Validate implementation as well as concept. On a frozen application set, compare source fields, bands, point totals, score-to-risk mapping and final policy actions with independent expected values. Test a bureau outage, stale balance, joint account, migrated customer and duplicate application. An API may return a plausible score while the income field is in gross rather than net units. A model validation report without production mapping tests cannot establish that the live service implements the approved scorecard.

Explanations and customer correction

When a covered credit decision requires an adverse-action explanation, the bank should identify the actual principal reasons under applicable law and policy. A generic statement that the score was low does not explain whether the decision came from high commitments, insufficient verified income or a separate eligibility rule. Reason codes should correspond to the factors and rules actually used. Test combinations: a favorable score plus an affordability failure, a missing bureau response plus referral, and a human override after new documents. Keep the original and final decisions distinct.

Applicants need a route to correct inaccurate records and supply permissible evidence. A reviewer should be able to inspect source information and its age, not just the score. Monitor disputes, overrides and complaints for systemic patterns. If a bureau mapping error affects many applicants, reverse lineage should identify the scorecards and decisions using it. Corrected replay supports impact assessment, while the original snapshot shows what the bank actually knew and did.

Deployment and monitoring

The release pack pins variable definitions, source contracts, points table or model artifact, score mapping, policy version, eligible population and fallback. Test controlled requests before activation. A feature service timeout should return an explicit error; it should not fill a missing income value with zero or a favorable default. Operations knows which cases to refer when a source is unavailable. Rollback restores a compatible feature and policy combination, not merely an older scorecard file.

Near-term monitoring tracks source coverage, missingness, score distribution, approvals, referrals, overrides and failures. Default outcomes take months to mature; do not count recent approvals as successful non-defaults yet. A policy change affects who receives loans, which later changes the labeled population. Examine vintage cohorts, product and channel mix, and customer complaints. A sudden drop in scores after a bureau feed change requires source investigation before retraining.

A worked application

A fictional applicant requests a loan. The bank captures consent or authority for a permitted external check, receives a bureau response, verifies income from identified evidence and calculates existing commitments. The scorecard uses the approved snapshot and returns a score and reason inputs. The policy checks identity, eligibility and affordability separately. Suppose the score is within a referral band because the bureau history is short, while affordability appears adequate. A trained reviewer requests further evidence and records the final action. The decision log shows the scorecard and policy versions and what evidence arrived after the initial score.

The analyst then tests a second applicant with the same income but a high committed debt burden. The scorecard may still rank the customer acceptably on past repayment, but the affordability rule refers or declines under policy. An adverse explanation should not claim unstable income if that was not the reason. A third applicant has a bureau timeout. The system must distinguish unavailable data from a verified empty file. These examples show how a scorecard assists a decision without becoming the entire decision.

Change and incident example

Suppose a bureau provider changes a field from monthly repayment amount to outstanding balance without a compatible schema change. Scores move because debt-burden bands now receive much larger numbers. Monitoring detects an unusual distribution, and the bank restricts automated decisions under its contingency. The incident owner identifies affected requests, preserves original values and final actions, corrects mapping, and compares decisions with a proper replay. Product and control owners assess customer remediation. A unit test that checked only numeric type would not have caught the semantic break.

For a planned band update, run old and candidate scorecards on the same dated cohort with identical features. Compare scores, approvals, referrals, expected risk and customer effects by segment. Check whether source availability in live channels matches development data. Obtain validation and policy approval, document rollback and monitor the release. A transparent scorecard is valuable when its features, points, calibration and final action can be traced for a person and challenged on evidence.

Development data and stability

Application data often spans product and channel changes. A field required in a branch form may be optional online. A bank acquisition can bring a different bureau mapping. Before modeling, profile each cohort by date, product and channel, with missingness, outliers and source definitions. A high predictive relationship can result from a historic policy that asked extra questions only of applicants already considered risky. The variable may encode the prior human referral rather than independent risk. A feature-selection review should examine when and why each field was collected.

Sampling choices also matter. If the training set oversamples defaults, a raw model output may not be calibrated to the portfolio event rate. Weighting or recalibration must be documented and tested on a representative later cohort. A model can discriminate in development and still produce poorly calibrated probabilities when origination mix changes. A score-to-PD mapping should identify its calibration population and date. If the business uses points only for policy bands, it should still know how the bands performed over mature vintages.

Scorecard points are not explanations by themselves

A points table reveals how a feature contributes within a model, but the final decision can include separate rules. Suppose a borrower loses twenty points for high utilization but remains above the score threshold; a debt-service rule then declines the application. Listing high utilization as the principal reason may misdescribe the actual action. The decision system should retain the model's point contributions and the policy rules separately and generate explanation candidates from factors actually used. Reviewers test notices against representative combinations and applicable legal requirements.

Correlated features can also complicate reason ordering. A customer with high balance and high utilization may be penalized twice by related variables. The model owner examines stability and whether the points design is justified. A technical explanation that a feature contributed negatively does not prove the source was accurate or the use fair. A customer challenge should allow the bank to check the underlying balance and limit as of the decision time. Later corrected data should produce a marked reassessment, not a silent replacement of the audit record.

Boundary between automation and judgment

A bank may automate clearly eligible cases while referring uncertain cases. It should define review bands, staff authority, evidence requirements and service-time expectations. An override can be appropriate when verified information arrives after the initial score, but routine undocumented overrides can undermine validation. Log original score, source snapshot, new evidence, reviewer, rationale and final action. Monitor override frequency by reason and segment. A spike in overrides for self-employed applicants may indicate the scorecard lacks an appropriate income feature or is being used outside its population.

Manual review is not a cure for every weak model. If reviewers are shown a confident score without source context, anchoring can make them repeat the model's error. Design the review view to show uncertainty and key evidence, and allow independent challenge. Test whether reviewers can recognize a stale bureau response, wrong account link and missing feed. A referral policy needs adequate staffing at peak application volume. Otherwise queue delays can cause customer harm even without an incorrect final credit decision.

A threshold decision with queue capacity

Imagine an illustrative lender that can review 100 referred applications per day. A proposed threshold change raises the expected queue to 180 on busy days. The model team may report a better default tradeoff, but the operational path cannot meet the promised review time. Compare candidate policies on the same dated applications: automated approvals, declines, referrals, expected mature outcomes, staff time and customer waiting. A bank might phase a change, improve evidence collection or adjust staffing rather than deploy the threshold at once. No universal score boundary follows from the example.

Model estimates and policy thresholds should be evaluated separately. A challenger model can score in shadow mode while the incumbent drives decisions. Once enough mature outcomes and coverage evidence exist, a policy experiment can be considered under governance. The bank records which applicants were eligible, which model and threshold were used, and how overrides were handled. Without that assignment record, later outcome comparison can conflate model quality with different applicant populations or reviewer behavior.

Source outages and fallback

A bureau timeout, account-data consent failure and internal feature-service outage are different conditions. A bureau no-match response is a valid observation, not a service failure. The scorecard should receive distinct statuses and apply a documented referral or alternative evidence path. It must not impute a favorable score simply because a high-risk field is absent. An applicant should receive an accurate application status rather than a fabricated decision. Monitor outages by provider and channel so systemic failures do not become hidden customer disparities.

An acceptance test can inject each failure after otherwise identical application data. Compare the logged feature vector, score status, policy action and customer-facing message. Retry behavior must not create duplicate applications or contradictory decisions. When service resumes, a later score is a new event with a timestamp and source version. The original failed request remains visible. This distinction lets the bank explain why a customer waited or why a human asked for documents.

Acceptance cases for a bank analyst

Write expected outcomes for an ordinary applicant, a thin-file applicant, a joint-account holder, irregular income, a stale bureau record, an exact band-boundary value and a verified data correction. Include separate model, policy and reviewer outcomes. Test an applicant outside the scorecard's population and a request with a missing critical field. Reconcile processed, referred and failed counts and sample decision traces. The scorecard is ready only when it can be reproduced from the information actually available at onboarding and when its approved use and customer correction route work in practice.

The release reviewer should sample a case where the applicant changed information during the journey. An initial income declaration, a later verified payroll record and a final approval may legitimately differ. The audit trail needs to show which score was used at each step, when the additional evidence arrived and which action was communicated. If the bank cannot distinguish the first automated referral from the later human approval, a performance study can assign the wrong model outcome and a customer explanation can cite the wrong reason. This final trace tests the full onboarding path.

Banking practice note on data definition

For application scorecards, data definition matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

The practical discipline is to keep source fact, credit-risk interpretation, model estimate and business action separate. Source facts come from areas such as application form, identity verification, KYC data, income evidence, and employment data. The credit-risk interpretation explains what those facts mean. The model estimate turns that interpretation into a score, probability, severity, exposure or ranking. The business action decides approval, referral, monitoring, support, pricing, limit or reporting treatment.

This separation helps the bank challenge the result properly. When a score changes, the bank can ask whether borrower behaviour changed, source data changed, policy changed, model calibration changed or economic conditions changed. That is the kind of clarity serious banking AI needs.

Banking practice note on model use

For application scorecards, model use matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on customer impact

For application scorecards, customer impact matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on portfolio control

For application scorecards, portfolio control matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on validation

For application scorecards, validation matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on monitoring

For application scorecards, monitoring matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on governance

For application scorecards, governance matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on audit evidence

For application scorecards, audit evidence matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on economic conditions

For application scorecards, economic conditions matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on human judgement

For application scorecards, human judgement matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

The first decision record

An application scorecard converts approved evidence into a risk ranking at onboarding. The lender should keep the application snapshot, feature transformation, scorecard version, policy threshold, affordability result and final decision together. A score may place an applicant in a referral band while an incomplete income document independently prevents approval. The human reviewer needs both facts; changing the score is not a substitute for resolving missing evidence.

Test a new applicant with limited credit history and a repeat applicant with established repayment data. Missing history should follow its validated scorecard treatment, not an invented average. A channel migration can alter the meaning of employment or income fields; compare distributions and decisions before and after. Monitor approval, referral and decline by relevant segments, as well as later matured default among booked loans. Historical declines have no repayment outcome for the proposed facility, which limits performance claims under a broader approval policy.

An independent reviewer should calculate a sample score from source evidence, reproduce band and policy action, and inspect an override. If a corrected application field arrives later, preserve the original decision and a separate review of customer impact. Release tests cover score arithmetic, mappings, reason evidence, missing inputs and fallback when the score service is unavailable.

Primary sources for further study

• U.S. CFPB Regulation B, § 1002.9: adverse-action notices
• U.S. Federal Reserve SR 26-2: revised model-risk guidance