The credit analyst spent forty minutes cleaning the output. She had used an AI assistant to analyze a self-employed borrower's two-year income history, and the model had produced a thorough, well-reasoned narrative: it described the trend in Schedule C net profit, noted the depreciation add-backs, identified the year-over-year revenue growth, and arrived at a qualifying income figure with a clear explanation of the calculation. The analysis was exactly what the analyst needed intellectually. It was also entirely unusable by the loan origination system (LOS, the software platform that receives, stores, and routes every field from application to close). The LOS expected a specific JSON record with named fields, typed values, and no prose. What the AI produced was a professional memo. What the LOS needed was a structured data record. The analyst spent those forty minutes manually translating the AI's narrative back into the discrete field values the LOS would accept, which was exactly the problem AI-assisted processing was supposed to solve. Getting structured output from AI is not a nice-to-have feature in a lending workflow. It is the difference between a productivity tool and a productivity obstacle.

What the LOS Needs and Why Prose Fails It

A loan origination system stores credit information as discrete, typed fields: a borrower's monthly income is a number in a currency field, not a sentence saying "the borrower earns approximately $7,200 per month based on the prior two years of Schedule C activity." The number $7,200.00 flows directly into the debt-to-income (DTI) ratio calculation, the automated underwriting system (AUS) submission, and the closing disclosure. The sentence does not. Before the sentence can produce the same downstream effects, a human must extract the number from the sentence, decide how to handle the word "approximately," and manually enter $7,200.00 into the correct field. That translation step is the bottleneck that structured output eliminates.

Structured output means AI that produces machine-readable records in a format the receiving system can parse without human translation. The two most common formats in lending-system integrations are JSON (JavaScript Object Notation, a text format that organizes data as named key-value pairs) and XML (Extensible Markup Language, a tag-based format used by older core banking systems and some LOS vendors). Most modern LOS platforms, and most point-of-sale and document management systems that feed into them, accept JSON natively. Some legacy systems require XML or a flat-file format like CSV (Comma-Separated Values). The format itself is less important than the principle: the AI output is organized as discrete, labeled, typed values that a system can read without a human intermediary.

The compliance dimension of structured output is equally important. When an AI extraction or analysis produces a prose summary, the traceability between the source document and the LOS field runs through a human translation step that may not be logged, may not be reproducible, and may introduce its own errors. When structured output flows directly from the AI into the LOS with a verification log, the traceability is maintained end-to-end. An examiner reviewing a denied application can follow the path: source document, AI extraction output (with source labels), verifier sign-off, LOS field value, underwriting decision. That chain of custody is what OCC Bulletin 2026-13 (the April 2026 interagency guidance bringing AI and generative AI tools under model-risk, fair-lending, third-party, and board-governance expectations) expects for AI-assisted credit processes.

Prompting for Structured Output: The Format Specification

Getting an AI model to produce structured output requires telling it explicitly what format to use, what fields to include, what types to use for each field, and what to do when a value is absent or uncertain. A prompt that does not specify format will usually produce narrative prose, because prose is the default output pattern that large language models learned from their training data. Imposing structure requires an explicit format specification in the prompt.

Here is a complete prompt for extracting qualifying income data from a self-employed borrower's two-year 1040 file, designed to produce a JSON record the LOS can accept:

You are processing federal income tax returns for a mortgage application. The borrower is self-employed with Schedule C income. Extract the following fields from the 2024 and 2023 1040 returns and return them as a single JSON object with the structure defined below. Do not add narrative explanation. Do not round values. If a field is not present or not clearly visible, use null. Do not estimate missing values.

Required JSON structure:

{
  "borrower_last_name": "string",
  "tax_year_current": "integer",
  "tax_year_prior": "integer",
  "schedule_c_net_profit_current": "number",
  "schedule_c_net_profit_prior": "number",
  "schedule_c_gross_receipts_current": "number",
  "schedule_c_gross_receipts_prior": "number",
  "depreciation_line_13_current": "number",
  "depreciation_line_13_prior": "number",
  "business_use_of_home_line_30_current": "number",
  "business_use_of_home_line_30_prior": "number",
  "agi_current": "number",
  "agi_prior": "number",
  "filing_status_current": "string",
  "filing_status_prior": "string",
  "source_labels": {
    "schedule_c_net_profit_current": "string",
    "schedule_c_net_profit_prior": "string"
  }
}

Include source_labels for the two net profit fields, stating the exact line number and page number of the source document where each value was found. Extract directly from the documents. Do not calculate qualifying income.

This prompt does several specific things that matter for LOS integration. It defines the exact JSON key names, which must match the LOS field mapping exactly or the integration will fail. It specifies value types (string, integer, number), which prevents the model from returning "87,340" as a string with comma formatting when the LOS expects a float. It instructs the model to use null rather than zero or an estimate for missing fields, which allows the receiving system to distinguish between a documented zero and an absent value. And it includes a source_labels subobject for the two highest-stakes fields, preserving the traceability link that the verification step needs.

The output from this prompt, when the model executes it correctly against a clean document set, looks like this:

{
  "borrower_last_name": "Johnson",
  "tax_year_current": 2024,
  "tax_year_prior": 2023,
  "schedule_c_net_profit_current": 87340.00,
  "schedule_c_net_profit_prior": 81200.00,
  "schedule_c_gross_receipts_current": 127500.00,
  "schedule_c_gross_receipts_prior": 118400.00,
  "depreciation_line_13_current": 4200.00,
  "depreciation_line_13_prior": 4200.00,
  "business_use_of_home_line_30_current": null,
  "business_use_of_home_line_30_prior": null,
  "agi_current": 87340.00,
  "agi_prior": 81200.00,
  "filing_status_current": "Single",
  "filing_status_prior": "Single",
  "source_labels": {
    "schedule_c_net_profit_current": "Schedule C, Line 31, Page 3 of 2024 return",
    "schedule_c_net_profit_prior": "Schedule C, Line 31, Page 3 of 2023 return"
  }
}

This output is immediately usable by a system that accepts JSON. The depreciation fields have values (not null), so the underwriter knows to consider the add-back. The business-use-of-home fields are null, which tells the receiving system the deduction was not claimed, rather than zero, which the system might misread as a confirmed zero deduction. The source labels for the net profit fields are present, so the verifier can locate those specific lines without searching the whole document.

Field Mapping: Connecting AI Output to LOS Fields

Structured output from an AI is only half the integration problem. The other half is making sure the AI's field names and value formats match what the LOS expects. This mapping layer, the translation between AI output keys and LOS field identifiers, is a one-time configuration task that determines whether the integration is seamless or requires manual intervention on every file.

The most common field mapping mismatches in lending LOS integrations fall into four categories.

Key name mismatches. The AI output uses "schedule_c_net_profit_current" but the LOS expects "sched_c_net_profit_yr1." These look similar but do not match, so the LOS rejects the field or maps it to the wrong record. The solution is to define the JSON key names in the prompt to exactly match the LOS field identifiers, which requires a one-time coordination with the LOS administrator to obtain the complete field name dictionary.

Type mismatches. The AI returns "87,340" (a string with comma formatting) when the LOS expects 87340.00 (a numeric float). JSON does not enforce types unless the receiving system validates them, so a poorly specified prompt can produce strings where numbers are expected, leading to calculation failures downstream. The solution is to include explicit type annotations in the prompt ("return as a number with two decimal places, no comma separators, no currency symbols") and to validate the output against the LOS type specification before submission.

Date format mismatches. The AI returns "10/15/2025" but the LOS expects "2025-10-15" (ISO 8601 format). Date format mismatches are among the most common integration failures because date representation is not standardized across systems and AI models default to the format most common in their training data. Specify the exact date format in the prompt and validate it before LOS submission.

Null versus empty string mismatches. The AI returns null for a missing field, but the LOS expects an empty string ("") or a zero. Or the AI returns an empty string but the LOS interprets an empty string as a data error and expects null. The distinction matters for fields like "business_use_of_home" where null (not claimed) and zero (claimed, deduction was zero) have different underwriting implications. Define the null convention explicitly in the prompt and confirm it against the LOS field specification.

The practical solution to field mapping mismatches is to build and maintain a field mapping table that documents: the LOS field identifier; the expected type and format; the null convention; and the AI prompt key name. This table is the specification that governs every extraction prompt for that document type, and it is updated whenever the LOS is reconfigured or upgraded. An institution that treats field mapping as a one-time setup task and does not maintain the mapping table will discover silent mapping errors when the LOS is updated and previously correct integrations begin failing without an obvious cause.

Structured Output for the Adverse-Action Package

Income and asset extraction are the most common structured output use cases in document processing, but the Equal Credit Opportunity Act (ECOA, the federal statute prohibiting credit discrimination) and Regulation B (Reg B, 12 CFR Part 1002) create a specific structured output requirement for adverse-action notices that deserves separate treatment. A denial notice in a lending workflow is not just a document; it is a set of structured fields (reason codes, applicant identifiers, dates, disclosure language) that must be populated accurately and specifically, documented in the LOS, and retained for regulatory examination.

AI-assisted adverse-action drafting benefits from structured output in the same way income extraction does: the AI produces the initial reason-code selection and supporting rationale, but the output must be structured so that each reason code is a discrete, labeled, verifiable element rather than a sentence in a paragraph. Here is an example of structured output for an adverse-action reason package:

{
  "application_id": "string",
  "decision_date": "YYYY-MM-DD",
  "action_type": "denial",
  "reason_codes": [
    {
      "code": "string",
      "code_description": "string",
      "file_basis": "string",
      "source_document": "string",
      "source_location": "string"
    }
  ],
  "fcra_disclosure_required": true,
  "credit_bureau_name": "string",
  "reviewer_id": "string",
  "reviewer_verified_date": "YYYY-MM-DD"
}

The "file_basis" field is the most important element in this structure. It records, for each reason code, the specific data point from the borrower's file that supports the reason. For a reason code of "Excessive obligations in relation to income," the file_basis might read: "DTI ratio of 48.6%, calculated from verified income of $5,840/month and obligations of $2,836/month per application." The file_basis is what makes the adverse-action reason specific and accurate under Reg B, and it is what the human reviewer verifies before the notice is finalized. A structured output that includes file_basis for each reason code makes the verification step faster (the reviewer sees the rationale alongside the code rather than having to reconstruct it from the file) and the documentation more complete (the rationale is preserved in the LOS record, not just in the notice text).

The FCRA (Fair Credit Reporting Act, 15 U.S.C. Section 1681 et seq.) disclosure fields are also structured here: "fcra_disclosure_required" is a boolean that flags whether a consumer report was used in the decision, and "credit_bureau_name" provides the disclosure required by FCRA. Making these structured fields in the LOS rather than free-text fields in a notice template reduces the risk that the FCRA disclosure is omitted when the template is updated or when a note is added manually.

Validation Before Submission: The Pre-LOS Check

Structured output does not guarantee correct output. Before a structured record is submitted to the LOS, a validation step confirms that the record is well-formed (all required fields are present, all values have the expected types and formats) and that the field values have been verified against the source documents. The validation step is the bridge between AI-assisted processing and LOS-accepted data.

The validation check for a structured income record has three components.

Schema validation. Confirm that the JSON record contains all required keys, that all non-null values have the expected types, and that no extra keys are present that the LOS will reject. Schema validation can be automated: a simple validation script that checks the output against a defined schema specification will catch type mismatches and missing required fields before any human time is spent reviewing the content. Many LOS integrations already include a schema validation layer; institutions that are building new integrations should include schema validation as a pre-submission step, not as an error-handling step after rejection.

Value range validation. Confirm that numeric values fall within plausible ranges for the document type. A monthly income figure above $500,000 or below $100 should flag for review, not because the value is necessarily wrong, but because it is outside the range where automated acceptance is appropriate and human review adds value. Value range validation is a quality gate, not a replacement for source-line verification. It catches the gross transposition errors (the $9,140 that should be $914) before they reach the source-line verification step, saving verification time for the borderline cases.

Completeness review. For documents where multiple schedules or sections are expected (a 1040 with Schedule C, a bank statement with multiple months), confirm that the extraction output covers all expected sections before submission. A schedule C borrower whose extraction output contains no depreciation field and no business-use-of-home field has either a schedule with no entries in those lines (which should be confirmed by a null value, not an absent field) or an extraction that did not process all pages of the schedule. The completeness review surfaces this gap before the LOS receives an incomplete record.

The Unfair, Deceptive, or Abusive Acts or Practices (UDAAP, the broad consumer protection standard under the Dodd-Frank Act) risk in structured output workflows arises when the pre-LOS validation is applied inconsistently. If the value range validation flags certain income figures for extra review but not others, and the flagging pattern correlates with borrower demographics or geographies associated with protected classes under ECOA, the differential validation is a UDAAP exposure even if each individual review is handled correctly. Validation rules should be documented, consistently applied, and periodically reviewed for disparate application.

The Audit Trail: Structured Output as Regulatory Documentation

One of the less-discussed benefits of structured output in lending workflows is that a well-designed structured record is also the audit trail an examiner needs. A JSON record that includes field values, source labels, verifier identifiers, and verification dates does not need a separate audit log, because the record is the audit log. The information the examiner needs to confirm that the income figure in the LOS was verified against the source document is embedded in the structured record that produced the LOS field.

Under OCC Bulletin 2026-13, institutions are expected to maintain documentation of how AI model outputs are reviewed before they influence credit decisions. For extraction tools, "documentation of review" means a record that links the AI output to the source document, confirms the match, and identifies the human who performed the confirmation. A structured output format that includes source labels and reviewer fields satisfies this requirement without any additional documentation step, because the review information is captured in the same record as the extraction output.

The Community Reinvestment Act (CRA, the statute requiring banks to meet the credit needs of the communities they serve, including low-and-moderate income neighborhoods) adds another dimension. CRA examiners evaluate whether an institution's lending serves the credit needs of its assessment area, including geographic patterns of application volume, approval rates, and product availability. If the institution's AI-assisted processing produces structured records that include geographic data (property address, borrower address), those records can feed directly into the CRA data analysis that prepares for an examination. An institution that has clean structured output from its AI processing has cleaner CRA data, which produces cleaner CRA analyses, which produces a cleaner exam.

The Bank Secrecy Act (BSA, the 1970 statute requiring financial institutions to assist government agencies in detecting and preventing money laundering) and Anti-Money Laundering (AML) programs at the institution are not directly served by income and asset extraction structured output, but the data quality principles established in a structured output workflow, particularly the discipline of typed fields, null conventions, and source traceability, are directly applicable to the structured outputs that Suspicious Activity Report (SAR, a mandatory report filed with the Financial Crimes Enforcement Network when a bank suspects money laundering or financial crime) drafting workflows produce. An institution whose lending team has internalized structured output discipline will find the same principles applied naturally when the BSA/AML team begins using AI-assisted SAR drafting.

Key Takeaways

• Prose output from an AI is not LOS-acceptable output. The loan origination system requires discrete, typed, named field values. Getting structured output requires an explicit format specification in the prompt: key names that match LOS field identifiers, value types with formatting rules, null conventions for missing fields, and source labels for verification-critical fields.
• The four most common field mapping mismatches that break LOS integrations are key name mismatches, type mismatches (string versus number), date format mismatches, and null-versus-empty-string mismatches. Each is a one-time configuration problem that a maintained field mapping table prevents. Build and maintain the mapping table; do not treat it as a setup artifact.
• Structured adverse-action output should include a "file_basis" field for each reason code, recording the specific data point from the borrower's file that supports the reason. The file_basis is what makes the reason specific and accurate under Regulation B, and it is what the human reviewer verifies before the notice is finalized. Without file_basis, the verification step requires the reviewer to reconstruct the rationale from the file, which takes more time and produces less consistent documentation.
• The pre-LOS validation check has three components: schema validation (required fields present, correct types), value range validation (numeric values within plausible bounds), and completeness review (all expected schedules and sections extracted). Schema validation should be automated. Value range validation and completeness review require human attention, but they are fast when the structured output makes the scope of the extraction explicit.
• A well-designed structured output record that includes source labels and reviewer identifiers is also the audit trail that OCC Bulletin 2026-13 expects for AI-assisted credit processes. The same record that the LOS ingests is the record the examiner reads. Building the audit trail into the output format eliminates a separate documentation step without reducing documentation quality.
• Separating extraction from calculation is a core structured output design principle. The extraction model produces verified field values from source documents. The income calculation, DTI calculation, or qualifying income formula is a separate step performed by the underwriter or by a dedicated calculation tool using the verified extracted values as inputs. This separation prevents a single AI extraction error from propagating silently through the entire income analysis.
• UDAAP risk in structured output workflows arises when validation rules are applied inconsistently in patterns that correlate with protected-class demographics or geographies. Document validation rules, apply them uniformly across all files, and periodically review the pattern of flagged files for disparate application. The validation rules are a quality control tool, not a creditworthiness screen, and they should not function as one.