Credit decision records with adverse action reasons for lending models

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

What a complete credit decision record contains

A complete record links one application to its decision, its stated reasons and, if booked, its performance. Most failures in purchased credit data come from a missing link in that chain rather than from missing columns. Ask for each layer explicitly, because loan origination systems (LOS), decision engines and servicing platforms usually store them in separate tables keyed by different IDs.

The layers that matter:

• Application snapshot. Product, channel, requested amount and term, stated income, employment tenure, debt-to-income as calculated at decision time, collateral fields for secured products, and a decision-time timestamp. "As of decision" matters: refreshed values from servicing leak the future into training.
• Decision record. Approve, counteroffer, decline, withdrawn or incomplete; the policy or model version; the score band; manual override flags and underwriter notes where present.
• Adverse action reasons. The ranked principal reasons actually sent to the applicant, with the internal reason code, the notice text, the notice date and the method (letter, electronic).
• Performance outcomes. For booked loans, vintage (origination month), days-past-due history, and flags such as ever 60+ DPD within 12 or 24 months, charge-off and prepayment.

Decision records with rationale are a broader pattern across business workflows; see decision records with rationale for agent builders for how the same structure applies outside lending.

Why adverse action reasons are the scarce field

Adverse action reasons are scarce because they exist only inside the lender's notice workflow, and public baselines either omit them or reduce them to a few coarse categories. Under Regulation B, a creditor must notify an applicant of action taken, generally within 30 days of receiving a completed application, and a notice of adverse action must give the specific principal reasons or disclose the applicant's right to request them [1]. The appendix of sample forms lists example reasons such as insufficient credit references, excessive obligations relative to income and length of employment [2].

For reason-code generation, explanation and evaluation work, those notices are ground truth for what a lender told a consumer, not necessarily for why the model scored them low. That gap is the whole point of the data. Regulation B does not carve out complex or machine-learning models, so a lender using one still has to produce specific principal reasons and should be able to show how its reason-selection method maps to the model [1].

CFPB guidance on adverse action notices for algorithmic credit decisions has shifted in recent years. As of October 2026, confirm with counsel which agency statements remain current; the regulation text in 12 CFR 1002.9 is the fixed reference [1].

Failure modes to check in a sample:

• Reason codes mapped to a later code table than the one in force at decision time.
• Only the first reason retained when notices listed up to four.
• Counteroffers recorded as approvals, which drops their reasons entirely.
• Notices sent by a third-party letter vendor whose records were never joined back to the LOS.

How FCRA, GLBA and bureau contracts limit what can be licensed

Consumer report data is the field family most likely to be excluded, because the lender obtained it for a credit decision and may not be able to pass it on for model building. FCRA section 604 (15 U.S.C. 1681b) limits who may receive a consumer report to a list of permissible purposes, and a credit application is the purpose lenders typically rely on, not resale for model building. Bureau subscriber agreements typically add their own restrictions on resale and redisclosure, so ask the supplier to check its contracts rather than assume.

Separately, application files are nonpublic personal information under GLBA. The FTC explains that a recipient of such information "steps into the shoes" of the originating institution and is bound by the same reuse and redisclosure limits, whether or not the recipient is itself a financial institution [3]. Under Regulation P, information received under an exception may be used only in the ordinary course of business to carry out the purpose for which it was received [4].

Practical consequences for scoping:

• Raw tradelines, bureau scores and bureau attribute files are frequently excluded; derived lender attributes (for example, DTI bands) are more often licensable once the supplier's counsel signs off.
• Removing direct identifiers does not settle the GLBA question by itself; the supplier's counsel decides whether the release is permitted at all.
• If you are a lender building a model on your own customers, your own data is governed differently from data licensed in; do not merge the two without a documented basis.

Commercial and small-business credit carries different rules; commercial credit memos and approval decisions covers that side.

Public baselines and their gaps

Public datasets are useful for prototyping but miss the joins that production lending models need. HMDA loan application register data covers mortgage applications at scale and includes action taken and denial reason fields, but it has no performance outcomes and no non-mortgage products. Historical peer-lending loan books include repayment status but only for booked loans and one platform's credit box.

Competition datasets usually anonymize features into opaque columns, which rules out reason-code work. None of these carries the actual adverse action notice text. That is why buyers comparing a "loan approval dataset alternative to Lending Club" are usually looking for declined applications with reasons, which only originators hold.

Performance windows and reject inference

Outcome labels are only comparable when every loan is observed over the same window from origination. Specify the window in the request: for example, ever 60+ DPD within 12 months for installment loans, with vintages whose window has fully matured by the extract date. Loans younger than the window must be flagged or excluded, or the default rate will look artificially low.

Declined applicants never get an outcome, so any model trained only on booked loans learns the old policy's credit box. Ask whether the supplier can include declines that were later booked elsewhere (rarely available) or at least full decline volumes so you can apply reject inference methods such as parceling or augmentation. Record which approach you used in model documentation.

Verifying the outcome fields themselves is its own task; verifying outcome labels in operational records and outcome-labeled evaluation data cover sampling and reconciliation methods.

Fair-lending testing without protected-class fields

Most non-mortgage credit records will not contain race, ethnicity or sex, because Regulation B generally restricts creditors from collecting that information outside specific cases such as mortgage monitoring. Fair-lending testing on consumer credit therefore relies on proxy methods such as Bayesian Improved Surname Geocoding (BISG), which needs surname and geography that de-identification will usually remove. Decide before the request whether the supplier runs proxy estimates internally and delivers only the estimated probabilities, or whether you test on HMDA-style mortgage data instead.

Historical approval decisions encode the old policy and its biases. Auditing those labels is covered in depth at historical decision bias in operational labels; this page stays with what can be sourced and licensed.

State rules also reach the documentation layer. Colorado SB26-189, signed May 14, 2026, replaces the 2024 Colorado AI Act and, starting January 1, 2027, requires developers of automated decision-making technology used in consequential decisions to give deployers technical documentation [5]. A lender deploying a third-party model should expect to ask what data trained it.

Request template for lender decision data

A precise request saves weeks of back-and-forth with supplier counsel. Describe the data, the use and the exclusions you already expect.

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

request: consumer_installment_decisions
products: [unsecured_personal_loan]
application_window: 2021-01 to 2024-06
decisions: [approve, counteroffer, decline, withdrawn]
fields_required:
  application: [channel, amount_requested, term, stated_income_band,
                dti_at_decision, employment_tenure_band, decision_ts]
  decision: [outcome, policy_version, model_version, score_band, manual_override]
  adverse_action: [reason_codes_ranked (up to 4), reason_code_table_version,
                   notice_date, notice_method]
  performance: [vintage, dpd_history_monthly, ever_60dpd_12m, charge_off_flag]
fields_excluded_expected: [bureau_tradelines, bureau_scores, ssn, name,
                           address_line, account_number]
geography: zip3 or state only
intended_use: reason-code generation and evaluation; internal credit model research
documentation_requested: [data dictionary, reason code tables by version,
                          de-identification method, extract logic, known gaps]

For model risk review, attach the supplier's data dictionary, extract SQL or logic description, code-table history and de-identification note to your third-party data file. Reviewers will ask how the data was selected, whether it represents your target population and what was removed.

How SourceX handles credit decision requests

SourceX sources operational datasets from US companies on request and manages the commercial process, including licensing agreements and ongoing purchases. Nothing is held in stock, and a request does not guarantee a match. Buyers describe the data, not the businesses; SourceX looks for US businesses that hold it, and every release is approved by the supplying company.

Each dataset is rights-reviewed for ownership and consents and delivered under a license defining records, uses, term and delivery. 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. Diligence materials covering source, rights, preparation and allowed use are prepared per dataset, which is what a model risk reviewer will ask for. You can start a buyer request, see the finance buyers page or the fintech software buyers page, or compare underwriting files for AI training. More industry topics sit under industry-specific operational data and the AI data hub.

Source lender decision data with reasons and outcomes

Describe the products, decision window, reason-code and performance fields you need, and the fields you expect to exclude. SourceX moves through Find, Assess, Agree, Transact and Manage, and nothing is contracted until a supplier agrees. Describe your credit decision data request.