Model Risk Management for Third-Party Training Data in Banking

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Which supervisory documents govern external training data

Two families of guidance apply at once: model risk management for the model built on the data, and third-party risk management for the relationship that supplies it. They answer different questions, and validators and vendor-management teams will each ask for their own evidence.

SR 11-7, issued in April 2011 by the Federal Reserve with the OCC's companion Bulletin 2011-12, calls for a rigorous assessment of data quality and relevance with appropriate documentation, and flags this as particularly important for external data from a vendor or outside party [1]. It also expects vendor and third-party models to fall within the framework rather than being treated as pre-validated [1]. As of October 2026, the Federal Reserve's SR 26-2, dated April 17, 2026, states that it supersedes and replaces SR 11-7 and emphasizes a risk-based approach [2]. Check with your primary regulator whether its own companion issuance has changed, and map your internal policy to the current text rather than to quotations of the 2011 letter.

The June 2023 final interagency guidance from the Federal Reserve, FDIC and OCC replaced each agency's earlier third-party guidance with one framework [3]. The agencies' community bank guide organizes it as a life cycle: planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination [4]. A data supplier whose records feed a credit, fraud, complaints or AML model is a third party under that framework, even when the purchase is a one-time license.

Broader AI frameworks sit on top. NIST AI RMF 1.0 (still the released version as of October 2026, with a revision underway) organizes controls under GOVERN, MAP, MEASURE and MANAGE [6], and our NIST AI RMF guide for acquired training data maps those functions to supplier records. For the full compliance landscape, start at the AI training data compliance hub.

What validators expect to see about training data

Validators want evidence that the data is fit for the model's intended use, not only that it is clean. Under model risk guidance, data that is accurate but unrepresentative of your portfolio is still a weakness, and any data proxies should be identified, justified and documented [1].

For a fine-tuned complaint classifier or a dispute-handling agent, that typically means five questions. Where did each record come from, and under what authority was it released? Does the source population resemble your customers, products and channels? What was removed, masked or relabeled, and how? Which fields could act as proxies for protected characteristics? And what does the license allow if the model is retrained or repurposed?

ISO/IEC 5259-3 gives a vocabulary for the quality management side: requirements and guidelines for running a data quality management process for ML data, without prescribing specific metrics [7]. Using it lets you translate a supplier's preparation notes into the dimensions your validation team already scores, such as completeness, consistency and timeliness. Before a purchase order, the pre-acquisition risk scoring method converts the same questions into a gating score.

The validator evidence pack for a third-party dataset

The most efficient practice is to request one evidence pack per dataset and file it in both the model inventory and the vendor management system. That avoids two teams chasing the same supplier for overlapping answers.

Illustrative example: invented to show structure; it does not describe an available dataset.

The license-summary row deserves attention. An audit of more than 1,800 public text datasets found license information omitted in over 70% of cases and wrong in over 50% on popular hosting sites [8], so "publicly available" is a weak provenance statement on its own. Retention and deletion interplay is covered in how long to keep training data and its records.

Running a data supplier through the third-party life cycle

Treat the data supplier like any other critical vendor, scaled to the model's risk tier. The interagency guidance expects risk management to be proportionate to the criticality of the activity the third party supports [3].

Planning. Record the intended model use, risk tier and whether the output touches credit decisions, BSA/AML alerts or customer communications. This sets the depth of everything that follows.

Due diligence. Ask the supplier how the data was collected, who approved its release, what consents or notices covered the original customers, and how personal information was handled [4]. For narrative-heavy sources such as KYC and CDD case review files, ask specifically how free-text fields were scrubbed.

Contract negotiation. Write permitted uses, retraining rights, audit or information rights, notification of data incidents, and termination handling into the license itself [4]. Vague "AI training" grants rarely satisfy a validator who must confirm the model can be redeveloped later.

Ongoing monitoring. For recurring deliveries, compare each refresh's population profile against the baseline and re-run the proxy screen. Log schema changes as model changes.

Termination. Define what happens to delivered files, derived features and trained weights. Keep the evidence pack after exit, because validators may revisit the model long after the license ends.

Fair lending and adverse action exposure from training data

Training data can carry fair-lending risk into any model that influences a credit outcome, even indirectly. Historical servicing or collections decisions embed past policy, and a model trained on them can reproduce disparities through proxies.

Regulation B requires creditors taking adverse action to provide a statement of specific reasons [5]. If an AI component trained on third-party data contributes to that decision, your team must be able to explain which inputs drove it, which is harder when feature definitions came from a supplier. Require field-level dictionaries and label definitions in the evidence pack so reason codes stay traceable.

Practical controls: exclude or justify geographic and name-derived fields, test outcome rates across available or estimated demographic groups before and after fine-tuning, and document why any retained proxy is necessary. Route the results to the fair-lending function, not only to model validation. Our banking data licensing rules for banks and credit unions covers the licensing side in more depth.

De-identification evidence for customer narratives

Customer-derived training data should arrive with a written de-identification method, not only an assurance. Complaint text, dispute notes and SAR-adjacent case narratives routinely contain account numbers, card PANs, phone numbers and names in free text where field-level masking misses them.

NIST SP 800-188 describes de-identification techniques and governance and cautions that traditional de-identification has inherent limits compared with formal privacy methods [9]. Ask suppliers which identifiers were removed or replaced, whether pseudonyms are consistent across records (needed for conversation-level training), how a sample was checked, and what residual risk remains. The privacy hub for de-identified training data explains the trade-offs between redaction, consistent replacement and synthetic substitution.

How SourceX supports bank AI teams

SourceX sources operational datasets from US companies and manages the commercial process, including licensing agreements and ongoing purchases. Relevant categories include support and sales histories, documents, and finance and legal workflows, sourced on request rather than held in stock, so a request does not guarantee a match. Every dataset is rights-reviewed for ownership and consents and delivered under a license defining records, uses, term and delivery, with diligence materials on source, rights, preparation and allowed use prepared per dataset.

Personal details such as names, emails, phones and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Delivery runs through private, access-controlled workflows only after an executed agreement and supplier approval. Finance teams can see how this maps to their sector on the finance buyers page, or describe the banking data your validators need.

Sourcing banking training data for validator review

SourceX looks for US businesses that hold the data you describe, assesses data and licensing permissions, and agrees pricing and allowed uses in a license; nothing is contracted until a supplier agrees. Describe the records your model needs at SourceX for buyers.