The chief credit officer set the printed scorecard on the conference table and looked at the model-risk committee. The institution had spent eighteen months and $2.1 million building a custom gradient-boosted credit scoring model for auto lending. It performed well on backtests, achieved Gini coefficients in the 0.71 range, and the validation team had signed off on the documentation. Now the fair-lending officer was raising a question the committee had not fully anticipated: when the next examiner asks how this model reached a specific adverse credit decision for a specific applicant, who can explain it -- and in how much detail? The institution's model-risk team had focused on accuracy, stability, and validation. The question of individual-decision explanation had been treated as a feature to add later. As the committee worked through the implications, the chief credit officer realized the build-versus-buy analysis the institution had done two years earlier had compared vendors on accuracy, cost, and implementation timeline. Explainability had not appeared as a scored criterion. That gap, it turned out, was the governance gap that now sat at the center of the table. The lesson that follows provides the framework for making the build-versus-buy decision for credit models with explainability as a first-order requirement, not an afterthought. (The scenario above is a composite illustration reflecting patterns common in the industry; it does not describe a specific institution.)

Why Explainability Is Not Optional in Credit Decisioning

The Equal Credit Opportunity Act (ECOA), codified at 15 U.S.C. 1691 et seq., and its implementing regulation, Regulation B (12 CFR Part 1002), impose a specific obligation on creditors that shapes every credit model procurement or construction decision: when an institution takes adverse action on a credit application, it must provide the applicant with the specific reasons for the denial. The obligation is not satisfied by a generic statement that the application did not meet the institution's credit standards. Regulation B requires the principal reasons for the adverse action, typically expressed as the top three to four factors most significantly contributing to the credit decision.

This adverse-action explanation requirement creates a direct chain between the model's internal logic and the institution's legal exposure. If the model's decision logic cannot be translated into specific, accurate, applicant-level factors, the institution cannot satisfy Regulation B. If the institution provides explanations that are inaccurate representations of how the model actually made the decision, it has provided misleading adverse-action notices, which is a separate violation. And if a fair-lending examination discovers that the model's actual decision logic differs materially from the explanations the institution provided, the examination finding is compounded.

OCC Bulletin 2026-13, issued in April 2026 jointly by the Office of the Comptroller of the Currency (OCC), the Federal Reserve, and the Federal Deposit Insurance Corporation (FDIC), extends model-risk governance requirements explicitly to artificial intelligence (AI) and machine-learning credit models. The bulletin requires independent validation, ongoing monitoring, fair-lending testing, and model documentation. None of these requirements can be fully satisfied for a model whose internal decision logic cannot be examined and documented by the institution's own model-risk team. The bulletin does not require a particular type of explainability, but it does require that the institution understand how the model makes decisions and be able to document that understanding to the satisfaction of an examiner.

The build-versus-buy decision for credit models, therefore, is fundamentally a decision about who controls the explanation chain. In a built model, the institution controls the architecture and can design explainability into the model from the start. In a bought model, the institution depends on the vendor's architecture and the explanation methodology the vendor provides. Neither path automatically satisfies OCC 2026-13 and Regulation B, but each path creates different governance challenges that must be addressed before the model goes into production.

Approximately 38 percent of mortgage lenders had adopted AI or machine-learning credit models as of 2024, and adoption has accelerated since. The institutions furthest along in this adoption are now confronting the governance challenges that early adopters did not fully anticipate when they made their build-versus-buy decisions. The following sections develop the analytical framework for making that decision with explainability as a first-order criterion.

The Explainability Spectrum: Build vs. Buy Implications

Credit model explainability exists on a spectrum from intrinsically interpretable models, which produce explanations as a natural output of their decision logic, to post-hoc explanation systems, which apply a secondary algorithm to an opaque model's outputs to approximate the model's decision reasoning. The position of a credit model on this spectrum has fundamentally different implications for build-versus-buy decisions.

Intrinsically interpretable models. Logistic regression, linear discriminant analysis, and scorecard models are intrinsically interpretable: the model's coefficients directly express the weight each input variable contributes to the output score. An examiner who asks why a model produced a specific score can be shown the scorecard, the applicant's values on each input variable, and the arithmetic that produced the total. The explanation is exact, not approximate. Fair-lending analysis can be conducted directly on the model's feature weights, identifying which variables contribute most to disparate impact and whether removing or modifying a variable would reduce disparity while maintaining performance. This is what the Consumer Financial Protection Bureau (CFPB) and OCC examiners can assess with the most confidence.

For institutions that build intrinsically interpretable models, the explainability challenge is primarily a design challenge: ensuring the scorecard's feature weights are documented, that the adverse-action reason codes derived from the scorecard are accurate, and that the documentation demonstrates the linkage between the model's logic and the explanations provided to applicants. For institutions that buy scorecard-based models from vendors, the challenge is different: obtaining sufficient documentation of the vendor's scorecard to validate the adverse-action reason code derivation methodology independently, and verifying that the vendor's pre-built reason codes accurately reflect the model's actual logic rather than a generic approximation.

SHAP-explained ensemble models. Gradient-boosted decision trees (GBDT) and random forest models achieve materially higher predictive accuracy than logistic regression for most credit applications, but they are not intrinsically interpretable. Their decision logic involves hundreds or thousands of individual decision trees whose combined output cannot be traced to a single readable formula. SHAP (SHapley Additive exPlanations) is a post-hoc explanation method that assigns each input variable a contribution value for a specific prediction by computing the average marginal contribution of that variable across all possible orderings of the feature set. SHAP values are theoretically grounded in cooperative game theory and satisfy desirable properties: consistency (a feature that contributes more always gets a higher SHAP value), local accuracy (SHAP values sum to the prediction), and efficiency. For a specific applicant's credit decision, SHAP values indicate which variables contributed most positively and most negatively to the score. These formal properties make SHAP internally consistent, but SHAP values remain a post-hoc approximation of feature contributions, not an exact causal record of the model's decision logic; the institution must validate SHAP-based explanations against actual model behavior rather than treating the mathematical properties as a guarantee of explanation accuracy.

SHAP-explained ensemble models create a more complex governance profile than intrinsically interpretable models, with different implications for build versus buy:

• Built SHAP-explained models. When an institution builds its own GBDT and applies SHAP post-hoc, it controls the implementation of both the model and the explanation system. It can validate that the SHAP values are computed correctly, that the adverse-action reason codes derived from SHAP rankings accurately reflect the model's decision reasoning for the validation test population, and that the SHAP explanation system performs consistently across demographic subgroups. The institution can also conduct a less-discriminatory alternative (LDA) search by retraining the model with candidate feature modifications and comparing disparity and accuracy outcomes directly. The governance burden is higher than for a scorecard, but the institution has full access to both the model's internals and the explanation system.
• Vendor SHAP-explained models. When a vendor provides a GBDT model with SHAP-based adverse-action explanations, the institution must validate the explanation system as well as the model. This requires the vendor to provide sufficient access to the SHAP implementation for the institution's independent validator to confirm that the SHAP values are computed correctly and that the adverse-action reason codes derived from SHAP rankings are accurate. Many vendor contracts do not include this level of transparency by default, and some vendors characterize the SHAP implementation as proprietary. The institution that buys a SHAP-explained vendor model without contractual access to validate the explanation system has a compliance gap: it cannot confirm that its adverse-action notices accurately reflect the model's actual decision logic.

LLM-based explanations. A newer category of vendor AI credit model uses large language models (LLMs) to generate narrative explanations of credit decisions. The LLM receives structured inputs (model score, SHAP values, applicant data fields) and generates a natural-language explanation targeted at the applicant's specific situation. This category creates the most complex governance profile. The LLM's explanation is not the same as the model's decision logic: the LLM is a separate system that generates plausible narrative, and the narrative it generates may or may not accurately represent the model's actual decision reasoning. Institutions that use LLM-based credit explanations must independently validate that the narrative explanations are accurate representations of the model's logic (not just plausible approximations), consistent across demographic subgroups (not systematically different in language, tone, or specificity for protected-class applicants versus non-protected-class applicants), and legally compliant with Regulation B's specificity requirements. For a bought LLM-explanation system, this validation requires vendor cooperation and contractual access that is significantly more complex to negotiate than for SHAP-explained models.

The Build Path: Governance Profile and Trade-Offs

Building a credit model internally places all architectural decisions, including all governance obligations, within the institution's control. This is both the primary advantage and the primary cost of the build path for explainability governance.

Explainability design authority. An institution that builds its own credit model can design the explanation system into the model architecture from the start, rather than retrofitting explanations to an existing opaque model. This means the institution can select a model architecture that produces the type of explanation most consistent with its regulatory obligations, decide how much predictive accuracy to trade for interpretability, define how adverse-action reason codes will be derived from the model's output and validate that derivation methodology, and conduct the LDA search within its own model architecture rather than asking a vendor to explore alternatives to its proprietary model.

Development cost and timeline. Building an internally governed credit model with a validated SHAP explanation system requires substantial investment. A typical build project for a regional bank includes: data preparation and feature engineering (often the largest cost item); model development (typically six to twelve months for a production-quality credit model); SHAP implementation and adverse-action reason code derivation and validation; documentation to the depth OCC 2026-13 requires for independent validation; initial independent validation (by a team or external firm independent of the model developers); and fair-lending testing using the institution's own applicant data. For a large regional bank, this total investment may range from roughly $800,000 to $2.5 million for an initial deployment (these figures are illustrative of the order of magnitude; actual costs vary significantly by institution size, data complexity, and validation scope). For community banks, the cost is proportionally lower but the capacity challenge is greater.

Ongoing governance obligations. Built models require ongoing model monitoring, annual or more frequent fair-lending testing, and a re-validation cycle when material changes occur. They also require model ownership with clear institutional accountability. The institution's model-risk team must maintain sufficient expertise to monitor the model's performance and interpret its outputs across product cycles. If key model development staff leave the institution, the built model can accumulate what practitioners call technical debt: the model continues operating but institutional understanding of its internals degrades over time, eventually approaching the opacity problem that vendor models present from the start.

Regulatory examination posture. Built models provide the strongest examination posture for intrinsically interpretable architectures and a strong examination posture for SHAP-explained architectures, because the institution can demonstrate comprehensive understanding of the model's decision logic to an examiner. For built models, the adverse-action notice accuracy question is answerable from the institution's own documentation. The LDA obligation (searching for less-discriminatory alternatives when fair-lending testing identifies a disparity) is most fully satisfiable with a built model, because the institution can run alternative specifications against its own data without vendor involvement.

When the build path is most appropriate. The build path is most appropriate for institutions that have the internal technical capacity to develop and maintain a complex credit model; that are deploying in a high-volume, high-stakes credit product where accuracy gains justify the development investment; that face a distinctive underwriting logic specific to their portfolio or market that off-the-shelf models do not capture; and that have a model-risk team with the capacity to provide ongoing governance throughout the model's lifecycle. The build path is less appropriate for institutions that lack the technical capacity to build, validate, and maintain a production credit model, because a poorly built model with inadequate governance creates worse regulatory exposure than a properly governed vendor model.

The Buy Path: Governance Profile and Trade-Offs

Buying a vendor AI credit model provides faster time-to-deployment, access to models trained on larger datasets than most individual institutions can assemble, and established explanation systems that have been deployed across multiple institutions. It also introduces the governance challenges that OCC 2026-13 and the previous lessons in this chapter have addressed at length.

Explainability dependency. When an institution buys a vendor credit model, it inherits the vendor's explanation architecture. The institution cannot redesign the explanation system without the vendor's cooperation, and it cannot conduct an LDA search on the vendor's model without vendor cooperation (since the model's feature set and architecture are typically proprietary). This creates a fundamental asymmetry: the institution bears the full Regulation B adverse-action explanation obligation and the full OCC 2026-13 fair-lending testing obligation, but it depends on the vendor's architecture and cooperation to satisfy those obligations.

The three categories of explainability discussed in the previous section create very different vendor dependency profiles:

• Vendor scorecard models. If the vendor provides a scorecard-based model with documented feature weights and reason code derivation logic, the institution can validate the explanation system independently using the scorecard documentation. This is the lowest-dependency buy scenario for explainability governance.
• Vendor SHAP-explained models. The institution must negotiate contractual access to sufficient SHAP implementation detail for independent validation. Vendors whose SHAP implementation is proprietary may resist providing this access, requiring the institution to either negotiate it as a contract condition or accept validation limitations that OCC 2026-13 may not accept.
• Vendor LLM-explanation models. The institution faces the most complex governance profile and the highest vendor dependency. Validating that LLM-generated narrative explanations are accurate representations of the model's decision logic requires access to both the underlying model's internals and the LLM explanation system, which most vendors treat as highly proprietary.

Speed to deployment and data access. Vendor models can typically be deployed in weeks to months versus the six to eighteen months typical for a built model. For institutions entering a new credit product category or responding to competitive pressure, this speed advantage is significant. Vendor models also benefit from training data that may span multiple institution portfolios, providing exposure to credit performance patterns that a single institution's data would not capture. However, this data breadth comes with a governance question: the institution cannot independently verify the training data's quality, recency, or geographic and demographic representation, and must rely on the vendor's documentation and its own validation testing to assess performance on the institution's specific applicant population.

Total cost of ownership. The buy path typically involves lower initial investment than the build path but introduces ongoing licensing costs that the build path does not. A rigorous total-cost-of-ownership analysis for a vendor credit model must include: licensing fees across the expected deployment period; the cost of independent validation (which the institution must commission regardless of the vendor's own validation); the cost of the institution's ongoing fair-lending testing (which the vendor's testing does not replace); contract renegotiation costs when governance gaps are discovered; and the cost of vendor replacement if the vendor terminates, is acquired, or changes the model in ways that create governance problems. Institutions that benchmark vendor costs against internal development costs without including these governance costs systematically understate the buy path's total cost.

When the buy path is most appropriate. The buy path is most appropriate for institutions that lack the internal technical capacity to build and maintain a production credit model; that are deploying in a standard credit product category where off-the-shelf models have established performance records; that can negotiate the contractual access required for independent validation and explanation system verification; and that have a model-risk governance program capable of owning all eight obligation categories identified in OCC 2026-13 regardless of vendor involvement. The buy path is most problematic for institutions that choose it to avoid the governance obligations of the build path, because OCC 2026-13 explicitly denies that vendor deployment reduces institutional obligations.

The Governance Decision Matrix: Explainability Across Build and Buy

The decision matrix below organizes the key governance dimensions of the build-versus-buy choice across the three primary explainability architectures. This matrix does not produce a single recommendation; it produces an honest assessment of the governance work each combination requires.

Adverse-action explanation accuracy. For built intrinsically interpretable models, explanation accuracy is verifiable from the scorecard directly. For built SHAP-explained models, accuracy is verifiable from the institution's own SHAP implementation. For vendor scorecard models, accuracy requires documented feature weights and reason code methodology from the vendor. For vendor SHAP-explained models, accuracy requires contractual validation access to the SHAP implementation. For vendor LLM-explanation models, accuracy requires the most extensive validation work and vendor cooperation.

Fair-lending (disparate impact) testability. Disparate impact testing analyzes whether a neutral policy produces a statistically significant disparity in credit outcomes across protected classes under ECOA regardless of intent. For built models of any architecture, the institution controls the feature set and can conduct full controlled and uncontrolled disparity analysis on its own data. For vendor models, the institution must conduct disparity analysis using the model's outputs and its own applicant data, but the LDA search (identifying less-discriminatory feature specifications) requires vendor cooperation because the institution cannot modify the vendor's model architecture. This is the most significant governance asymmetry between build and buy: the institution bears the full LDA obligation under ECOA but can satisfy it most fully only with a built model or a vendor who contractually commits to LDA cooperation.

OCC 2026-13 independent validation. For built models, validation is conducted by a team or firm independent of the model developers and the business line using the model. The institution has full access to the model's internals for the validator. For vendor models, the validator must be independent of the vendor, and the validator's access to the model's internals depends on what the vendor contractually provides. The validation of a vendor model is necessarily more limited than the validation of a built model, and the institution must document the scope of access and the governance implications of any access limitations.

Change governance. Built models give the institution full control of the change process: any modification to the model's feature set, architecture, or training data is a decision made by the institution, triggering the institution's own change governance assessment. Vendor models create the silent-update risk addressed in the previous lesson: the vendor can retrain or modify the model without the institution's knowledge if the contract does not include adequate notification requirements. Change governance for vendor models depends on contractual protections that must be negotiated before deployment.

Audit trail. Built models allow the institution to maintain a complete audit trail of model development decisions, validation findings, fair-lending testing results, and change governance assessments within its own systems. Vendor models create the risk that governance documentation lives in vendor platforms from which the institution cannot independently retrieve it. The institution must contractually ensure retrieval rights for all governance documentation from vendor systems.

LDA (less-discriminatory alternative) search. When fair-lending testing identifies a material disparity in a built model, the institution can conduct the LDA search internally: modifying the feature set, retraining on the same data, and comparing accuracy and disparity outcomes across candidate specifications. For a vendor model, the LDA search requires the vendor's cooperation to explore alternative specifications, which may not be contractually available and which the vendor has no competitive incentive to facilitate. Institutions that deploy vendor AI credit models should negotiate a contractual LDA commitment requiring the vendor to explore alternative specifications if fair-lending testing identifies a material disparity.

Practical Guidance: Structuring the Decision and the Transition

Most institutions approaching the build-versus-buy decision for credit models benefit from a structured process that separates the business case from the governance analysis. The governance analysis must be completed before the business case closes, not as a post-hoc compliance review.

Step 1: Audit current explanation capability. Before evaluating vendors or build options, the institution should audit its current adverse-action explanation process: what explanation methodology is currently used, whether the explanations provided to applicants are accurate representations of the model's decision logic, whether any fair-lending testing has identified explanation accuracy gaps across demographic subgroups, and whether the current explanation methodology would withstand an examiner's scrutiny. This audit establishes the baseline against which build and buy options should be evaluated.

Step 2: Define the explanation requirement before evaluating options. The institution should specify, before evaluating any vendor or design option, what level of explainability it requires. The minimum requirement is Regulation B compliance: the model must be able to produce the specific reasons for an adverse action that accurately represent the model's actual decision reasoning. Beyond that minimum, the institution should specify whether it requires individual-decision SHAP explanations at the feature level, LDA search capability for fair-lending remediation, and board-level explainability for governance reporting. These requirements become evaluation criteria applied equally to build and buy options.

Step 3: Evaluate vendor explanation systems as governance artifacts, not product features. When evaluating vendor AI credit models, the institution should request and review: the vendor's adverse-action reason code derivation methodology and documentation; evidence that the explanation system has been independently validated for accuracy; fair-lending testing results showing that explanations are consistent in specificity and accuracy across demographic subgroups; the vendor's process for conducting an LDA search if fair-lending testing identifies a disparity; and the contractual terms under which the institution can independently validate the explanation system. Vendors who treat the explanation system as a product feature that can be demonstrated in a sales environment rather than a governance artifact that can be validated should be disqualified, as this framing indicates the vendor does not understand what OCC 2026-13 requires of the institution.

Step 4: Calculate total governance cost for each option. The total governance cost for both build and buy options includes development or licensing, independent validation, annual fair-lending testing, ongoing monitoring, model owner time, and expected model lifecycle governance costs over a three to five year deployment horizon. This calculation typically closes the apparent cost gap between build and buy that simplified comparisons overstate, and sometimes reverses the finding in favor of the build path for institutions with sufficient technical capacity.

Step 5: Assess LDA obligation satisfiability. Before finalizing either a build or buy decision, the institution should explicitly assess how it will satisfy the LDA obligation if fair-lending testing identifies a disparity. For built models, this assessment is part of the model development plan. For vendor models, this assessment requires a written vendor commitment to LDA cooperation or a documented plan for how the institution will manage a fair-lending disparity finding without vendor cooperation. Institutions that deploy vendor AI models without an LDA plan are assuming that fair-lending testing will produce clean results, which is a risk assumption that should be made explicitly rather than by default.

Step 6: Embed explainability in the model-risk governance cycle. Whether the institution builds or buys, the model's explanation system must be included in the independent validation scope, the ongoing monitoring program, and the change governance assessment process. An explanation system that was accurate at deployment may drift as the underlying model is updated. The model owner's responsibility includes monitoring explanation accuracy as well as model accuracy, and the monitoring program must include testing explanation system output against changes in the model's behavior.

A final note on the build-versus-buy decision timeline: the governance analysis described in these six steps typically takes four to eight weeks for a thorough assessment. Institutions that compress this timeline to meet business deadlines typically discover the governance gaps they skipped during the due diligence process when an examiner arrives or a fair-lending disparity emerges. The cost of a comprehensive pre-decision governance analysis is small relative to the cost of retrofitting governance onto a deployed model or managing a fair-lending finding in production.

Key Takeaways

• The build-versus-buy decision for credit models is fundamentally a decision about who controls the explanation chain; explainability is a governance requirement under ECOA (Regulation B adverse-action notices) and OCC 2026-13, not a product feature to be compared across vendor demos.
• Intrinsically interpretable models (scorecards, logistic regression) produce the strongest examination posture because explanations are exact and verifiable directly from the model's coefficients; SHAP-explained ensemble models achieve higher accuracy at the cost of requiring independent validation of the explanation system itself; LLM-based narrative explanations require the most extensive governance and vendor cooperation to validate for accuracy.
• The build path gives the institution full control of the explanation architecture, the LDA (less-discriminatory alternative) search, and the audit trail, but requires substantial internal technical capacity and investment; the buy path provides faster deployment but creates vendor dependency for explanation system validation and the LDA search that must be addressed contractually before deployment.
• OCC 2026-13 requires that the institution understand how the model makes decisions; this requirement is most fully satisfiable for built models and for vendor models where the institution has negotiated contractual access to validate the explanation system independently of the vendor.
• The LDA obligation under ECOA is most fully satisfiable with a built model; for vendor models, the institution must negotiate an LDA cooperation commitment before deployment and must have a documented plan for managing a fair-lending disparity finding that does not depend entirely on vendor cooperation.
• Total governance cost for both build and buy options must include independent validation, annual fair-lending testing, ongoing monitoring, model owner time, and change governance costs over the full deployment lifecycle; simplified build-versus-buy analyses that compare development cost to licensing cost systematically understate the buy path's total governance cost.
• Define the explanation requirement before evaluating any build or buy option; evaluate vendor explanation systems as governance artifacts subject to independent validation, not as product features demonstrated in sales environments; and embed explanation system accuracy in the model's ongoing monitoring program regardless of whether the model was built or bought.