At 2:14 on a Wednesday afternoon, a processor at a regional bank tried to paste an AI-generated income summary into Encompass, the bank's loan origination system (LOS). The AI had done everything right, by the processor's reading: it extracted the borrower's W-2 income, calculated the two-year average, noted the self-employment adjustment from the Schedule C, and summarized everything in a clean paragraph. The LOS field expected a single number formatted to two decimal places. The paragraph went nowhere. The processor spent the next twenty minutes manually re-extracting the figure from the AI's narrative, re-checking the math, and entering it by hand. This is the structural problem with AI output in banking: the model produces prose and the bank runs on data. The core banking system, the LOS, the credit policy workflow, the audit trail, and the regulatory report all expect discrete, typed, formatted fields. When AI generates flowing text, someone must manually bridge the two worlds, and every manual bridge is a verification point that may or may not be staffed carefully enough to catch errors. Structured output from the AI is not a technical preference. In a regulated banking environment, it is a workflow requirement, an audit requirement, and in some contexts a fair-lending requirement.

Why Bank Systems Run on Data, Not Prose

Understanding the gap between AI prose output and bank system requirements starts with understanding what bank systems actually expect. The core banking system, the software platform at the center of a bank's operations that tracks accounts, balances, transactions, and customer records, expects structured records with defined field types, character limits, and validation rules. A field labeled "Monthly Income" expects a number. A field labeled "Loan Type" expects one of twelve enumerated values. A field labeled "Property Address" expects a street address in a specific format. None of these fields accepts a paragraph, a sentence, or an AI-drafted summary, however accurate.

The LOS operates the same way, and its data requirements are more granular. A modern LOS like Encompass, BytePro, or Calyx Point manages hundreds of data fields per application: borrower demographics, employment details, income amounts by category (base salary, overtime, commission, self-employment, rental), property details, loan terms, credit scores, and dozens of others. Each field has a data type (integer, decimal, string, date, Boolean), a character limit, and often an enumerated set of acceptable values. The LOS workflows route the file through stages (application, processing, underwriting, closing, post-closing) based on the values in specific fields, and the compliance engine checks for required disclosures and timing rules based on field states. When data enters these fields through manual re-entry from AI prose, every entry is a potential error, and every error propagates through all the downstream workflows that depend on that field.

The audit trail requirement adds another dimension. OCC Bulletin 2026-13 (the April 2026 interagency model-risk update that pulled AI and generative AI under model-risk and governance expectations) requires financial institutions to maintain documentation sufficient for an examiner to reconstruct how an AI-assisted credit decision was reached. If the AI's income analysis existed only as prose that was manually re-entered into the LOS, the reconstructed audit trail will show only the final LOS field values, with no documented connection to the AI's source analysis. The institution cannot demonstrate whether the re-entered value matched the AI's analysis, whether the human who entered it verified the figure before entering it, or whether the AI's analysis was the source of the entered figure at all. Structured output, by contrast, can be linked directly to the LOS field it populated, creating a traceable chain from AI analysis to LOS record to credit decision.

When AI generates prose, someone must bridge it to a data field by hand. Every manual bridge is a potential error and a break in the audit trail. Structured output is the bridge that holds.

JSON as the Lending Workflow Lingua Franca

The most practical format for structured AI output in banking workflows is JSON (JavaScript Object Notation), a lightweight data format that represents information as key-value pairs organized into nested objects and arrays. JSON is not new technology; it is the standard format for data exchange between software systems in nearly every industry, and most modern LOS platforms and core systems either accept JSON input directly via an application programming interface (API), or can consume JSON through a middleware integration layer. The reason JSON is the right choice for lending AI output is that it combines human readability (a person can look at a JSON object and understand what it contains) with machine readability (a software system can parse, validate, and ingest it without manual re-entry).

A JSON output from an AI income analysis looks like this:

{
  "borrower_id": "APP-2026-004417",
  "analysis_type": "income_verification",
  "analyst_tool": "AI_assisted",
  "income_sources": [
    {
      "source_type": "W2_employment",
      "employer_name": "Hartwell Manufacturing Inc.",
      "year_1": {
        "tax_year": 2024,
        "gross_wages": 89400.00,
        "source_document": "W-2, Box 1, Tax Year 2024"
      },
      "year_2": {
        "tax_year": 2023,
        "gross_wages": 84200.00,
        "source_document": "W-2, Box 1, Tax Year 2023"
      },
      "two_year_average_monthly": 7233.33,
      "calculation_note": "(89400 + 84200) / 2 / 12 = 7233.33"
    },
    {
      "source_type": "self_employment",
      "business_name": "Hartwell Consulting LLC",
      "year_1": {
        "tax_year": 2024,
        "net_profit_before_depreciation": 18600.00,
        "depreciation_addback": 2400.00,
        "adjusted_net_income": 21000.00,
        "source_document": "Schedule C, Lines 31, 13, Tax Year 2024"
      },
      "year_2": {
        "tax_year": 2023,
        "net_profit_before_depreciation": 14200.00,
        "depreciation_addback": 1800.00,
        "adjusted_net_income": 16000.00,
        "source_document": "Schedule C, Lines 31, 13, Tax Year 2023"
      },
      "two_year_average_monthly": 1541.67,
      "calculation_note": "(21000 + 16000) / 2 / 12 = 1541.67",
      "declining_income_flag": false
    }
  ],
  "total_qualifying_monthly_income": 8775.00,
  "verification_status": "PENDING_HUMAN_REVIEW",
  "unverified_flags": [],
  "human_reviewer_required": true,
  "notes": "Two income sources identified. Self-employment income shows growth; no declining income flag triggered. Reviewer should confirm Schedule C source documents are signed originals or IRS-certified transcripts."
}

Compare this to a prose equivalent: "Based on the tax returns provided, the borrower's qualifying income from W-2 employment averages approximately $7,233 per month over the past two years, and self-employment income from a consulting LLC averages approximately $1,542 per month, for a combined qualifying income of approximately $8,775 per month." The prose is accurate and readable. But it cannot be automatically validated against the bank's income field format, cannot be imported into the LOS without manual re-entry, cannot be checked by an automated rule for declining income without parsing natural language, and cannot be reliably linked in an audit trail to the specific LOS fields it populates.

The JSON version does all of those things. It can be validated before entry (does every field have a value? Do all the calculations check out? Are all source document citations present?). It can be mapped to specific LOS fields by field name. It can be checked by an automated rule for the declining income flag. And the entire object can be stored with the loan file as evidence that the AI analysis was the source of the income figures in the LOS.

Designing JSON Output Schemas for Lending Use Cases

A schema is the formal definition of a JSON structure: which fields must be present, what data type each field must have, what values are acceptable for enumerated fields, and which fields are required versus optional. In a lending AI workflow, the schema for AI output is the bridge between what the AI can produce and what the bank's systems will accept. Building that schema is a one-time design task that enables reliable, repeatable ingestion for every file the AI touches after.

The schema design process for a lending AI output has five steps.

Step one: inventory the LOS fields the AI output will populate. Start with the LOS and work backwards. Which fields in the LOS will be populated from the AI's analysis? For an income analysis workflow, these might include fields for base income, overtime income, commission income, self-employment income, rental income, total qualifying income, income verification method, and verification status. Each field has a name, a data type, a character limit, and acceptable values that are documented in the LOS vendor's field guide.

Step two: map AI output fields to LOS fields. For each LOS field that the AI output will populate, define the corresponding JSON field in the AI's output schema. The JSON field name does not need to match the LOS field name exactly, but the mapping must be documented so that the integration layer can route the correct JSON value to the correct LOS field. Undocumented mappings are where data ends up in the wrong field, which in a lending workflow can mean an income figure appearing in a credit score field or a property type appearing in a borrower ID field.

Step three: add audit trail fields to the schema. Beyond the LOS data fields, every AI output schema for lending should include fields that support the audit trail: the borrower or application identifier, the date and time of the AI analysis, the AI tool version or model identifier, the name of the human reviewer, and the verification status of each calculated figure. These fields are not for the LOS; they are for the institution's documentation system and the model-risk file required under OCC Bulletin 2026-13.

Step four: include source document citations in the schema. Every calculated figure in the JSON output should have a corresponding source document citation field. This is the JSON equivalent of the cite-or-refuse principle: the schema enforces that every figure has a traceable source, and any figure without a populated source citation fails validation before it can be entered into the LOS. A validation rule that rejects JSON objects with empty source citation fields is a technical implementation of the human-verification requirement.

Step five: define verification status and flag fields. The schema should include a verification status field for the overall output (values: PENDING_HUMAN_REVIEW, REVIEWED, APPROVED_FOR_LOS_ENTRY) and flag fields for each condition the institution wants to automatically detect, such as declining income, income below policy threshold, missing documentation, or DTI threshold exceeded. Flags are Boolean (true/false) or enumerated values, not prose descriptions, so that downstream rules engines can process them without natural-language parsing.

A minimal but complete schema for an adverse-action reason package, in JSON format:

{
  "application_id": "APP-2026-004417",
  "adverse_action_date": "2026-06-09",
  "decision": "DENY",
  "reasons": [
    {
      "reason_code": "DTI_EXCEEDS_MAXIMUM",
      "reason_text": "Debt-to-income ratio of 51 percent exceeds the maximum permitted 43 percent",
      "source_factor": "Monthly debt obligations",
      "source_document": "Credit Report, Equifax, June 2026 pull",
      "factor_value": "51.2",
      "policy_threshold": "43.0",
      "reg_b_category": "Excessive obligations in relation to income",
      "verified": false,
      "verified_by": null,
      "verified_date": null
    },
    {
      "reason_code": "DELINQUENCY_HISTORY",
      "reason_text": "One or more accounts with 90-day delinquency in the past 24 months",
      "source_factor": "Payment history",
      "source_document": "Credit Report, Equifax, June 2026 pull, account ending 4421",
      "factor_value": "1 account, 90-day delinquency, March 2025",
      "policy_threshold": "Zero 90-day delinquencies in past 24 months",
      "reg_b_category": "Delinquent past or present credit obligations with others",
      "verified": false,
      "verified_by": null,
      "verified_date": null
    }
  ],
  "fcra_consumer_reporting_agency": null,
  "fcra_review_required": true,
  "human_reviewer_required": true,
  "verification_status": "PENDING_HUMAN_REVIEW"
}

This schema accomplishes several things simultaneously. Each reason carries its own verification status fields (verified, verified_by, verified_date), which must be populated by the human reviewer before the notice can be released. The FCRA (Fair Credit Reporting Act, 15 U.S.C. Section 1681 et seq., which requires specific disclosures when a consumer report is used in an adverse action) fields are included but flagged for separate human review, because the model cannot independently determine which consumer reporting agency was used. The reg_b_category field maps each reason to a recognized Regulation B (Reg B, 12 CFR Part 1002) reason code, enabling automated validation that the stated reasons are within the accepted set.

Making the Core and the LOS Actually Ingest AI Output

Designing a schema is the first half of the integration problem. The second half is making the bank's systems accept the JSON. This section addresses the practical pathways for connecting AI-generated structured output to the core and the LOS.

Path one: direct API integration. If the LOS vendor exposes an API (application programming interface, a defined connection point that allows one software system to send data to another), the structured AI output can be submitted directly via the API. The mapping from JSON fields to LOS fields is handled by a lightweight integration layer, and the LOS's own validation rules catch any field type or format errors before the data is committed. Most major LOS platforms offered API access as a premium feature by 2026, and the vendor's API documentation specifies the exact field names and data formats the API accepts.

Path two: file-based exchange. For LOS platforms that do not expose an API, or for institutions that have not yet integrated their AI tools via API, structured output can be exchanged through a defined file format: JSON files exported from the AI tool and imported into the LOS through its file import function. This path requires more manual handling at the import step, but the structured format still provides validation advantages over prose: the import can be checked against the expected schema before the import runs, catching field errors before data enters the LOS rather than after.

Path three: copy-paste with field validation. For institutions at the earliest stages of AI integration where neither API nor file import is available, structured output still provides value over prose through a field-by-field copy-paste workflow. Instead of the processor reading a paragraph and re-extracting the income figure, the structured JSON output presents each value in its field context (field name: value) so the processor sees exactly which field each value belongs to, copies the value directly, and enters it into the corresponding LOS field. This eliminates the interpretation step and reduces the error rate, even without technical integration.

Path four: middleware and RPA. Between direct API integration and manual copy-paste lie middleware solutions and Robotic Process Automation (RPA) tools that can read structured output and programmatically populate LOS fields without a native API. RPA tools are widely used in banking for exactly this kind of field mapping, and they operate on structured data far more reliably than on prose. A JSON output that produces the same field structure for every application is a robust target for an RPA workflow; a prose output that varies in structure from application to application is not.

Integration design considerations specific to lending AI:

Validation before entry. Every pathway should include a validation step before data enters the LOS, checking that required fields are present, that field types match LOS expectations, that calculated figures are internally consistent (does the sum of the income sources equal the total?), and that verification status fields indicate human review is complete. Data that fails validation should not enter the LOS until the failure is resolved by the human reviewer.

Version locking. When the AI's output schema changes, existing LOS field mappings may break. The institution should maintain version locking: each version of the AI output schema should be explicitly mapped to the LOS field configuration in effect at the time, and any schema change should go through a change management process that includes LOS compatibility testing before deployment.

Audit trail preservation. The JSON output, including its source citations, flag fields, verification status, and reviewer identity fields, should be archived with the loan file in the document management system, not just the extracted values that entered the LOS fields. The archived JSON is the institution's evidence, in an OCC examination or an adverse-action challenge, that the AI output was structured, verifiable, and reviewed before it populated the LOS.

Structured Output for BSA/AML Workflows

The Bank Secrecy Act (BSA), Anti-Money Laundering (AML), and Suspicious Activity Report (SAR) workflows present a distinct structured output challenge. The BSA and AML compliance system is alert-driven: the transaction monitoring system generates alerts when transaction patterns meet defined thresholds, and BSA analysts review those alerts to determine whether to escalate, close, or file a SAR with FinCEN (the Financial Crimes Enforcement Network, the Treasury bureau responsible for collecting and analyzing financial intelligence). An AI tool that assists with alert summarization and SAR narrative drafting needs to produce output in a format that the BSA analyst, the SAR filing system, and the institution's BSA compliance records can all use.

The structured output schema for a BSA/AML alert analysis:

{
  "alert_id": "ALT-2026-118844",
  "account_ids": ["CHK-00441197", "SAV-00441197"],
  "alert_type": "STRUCTURING_PATTERN",
  "alert_period_start": "2026-04-01",
  "alert_period_end": "2026-05-31",
  "transaction_count": 14,
  "total_cash_volume": 87400.00,
  "transactions_near_ctr_threshold": 8,
  "transactions_above_ctr_threshold": 0,
  "currency_transaction_reports_filed": 0,
  "ai_analysis_summary": {
    "pattern_description": "Fourteen cash deposits totaling $87,400 over 61 days. Eight deposits ranged from $9,100 to $9,800, falling below the $10,000 CTR (Currency Transaction Report) reporting threshold. No single deposit exceeded $10,000.",
    "source_data": "Alert data ALT-2026-118844, transaction records provided by compliance system",
    "pattern_flag": "POSSIBLE_STRUCTURING",
    "characterization_note": "Classification as suspicious or non-suspicious requires BSA officer review. This flag identifies the pattern for human evaluation only."
  },
  "sar_narrative_draft": "Between April 1, 2026 and May 31, 2026, account holder [REDACTED] made fourteen cash deposits to accounts CHK-00441197 and SAV-00441197 totaling $87,400. Eight deposits, totaling $76,500, were in amounts ranging from $9,100 to $9,800. No single deposit exceeded the $10,000 threshold for Currency Transaction Report filing. No CTRs were filed during this period. The deposit pattern may warrant review for potential structuring activity under 31 U.S.C. Section 5324.",
  "open_questions": [
    "Is there a documented business purpose for regular large cash transactions for this account holder?",
    "Has this account holder previously been the subject of a SAR filing?",
    "Are the deposit locations consistent with the account holder's stated business operations?"
  ],
  "sar_recommendation": null,
  "sar_decision": null,
  "bsa_officer_review_required": true,
  "verification_status": "PENDING_BSA_OFFICER_REVIEW"
}

Several features of this schema are worth noting. The pattern_flag field identifies the transaction pattern (POSSIBLE_STRUCTURING) without characterizing it as confirmed suspicious activity; the characterization_note field explicitly states this flag is for human evaluation only. The sar_recommendation and sar_decision fields are null and empty, reflecting the system prompt's hard constraint against AI making SAR filing decisions. The open_questions field preserves the BSA analyst's judgment gaps in structured form, making it easy for the analyst to work through the specific unknowns rather than reassessing the entire alert from scratch. The entire structure can be saved to the BSA compliance records system as a documented analytical record, even if no SAR is filed.

The CTR (Currency Transaction Report, a mandatory FinCEN form required for cash transactions over $10,000) reference is included because structuring, the practice of breaking transactions into amounts below the CTR threshold to avoid reporting, is a specific BSA violation under 31 U.S.C. Section 5324. The AI output's reference to this statute in the draft narrative is appropriate; the BSA officer's determination of whether the pattern constitutes structuring is not.

The Verification Handoff: From Structured Output to Human Review

Structured output solves the formatting and ingestion problem, but it does not solve the accuracy problem. A JSON object with wrong figures is still wrong; it is just wrong in a format the LOS can import. The structured output workflow must include an explicit human verification step, and the schema's verification status fields are the mechanism for enforcing that step.

The verification workflow for a structured income analysis output:

Step one: automated schema validation. Before the JSON object reaches a human reviewer, it passes through automated validation: are all required fields present? Do all data types match the schema definitions? Are all source citation fields populated? Do the calculated totals match the sum of the components? Validation failures are caught here, before human review, reducing the reviewer's scope to exceptions that automation cannot catch.

Step two: human review of source citations. The reviewer opens each source document cited in the JSON and confirms that the figure in the JSON field matches the figure at the cited location in the source document. For an income analysis, this means checking the W-2 Box 1 figure against the year_1 gross_wages field, the Schedule C Line 31 figure against the self_employment adjusted net income field, and so on. Each confirmation updates the verified field in the JSON to true and populates the verified_by and verified_date fields with the reviewer's identity and the date of confirmation.

Step three: human review of completeness. The reviewer checks whether the structured output's income sources match the complete set of income sources in the file. An AI that extracted W-2 income and Schedule C income but missed a Schedule E rental income page left out of the submission would produce an income total that is too low. Completeness review requires the reviewer to check the file against the output, not just the output against the file.

Step four: human approval for LOS entry. When all source citation verifications are complete and the completeness check is passed, the reviewer updates the verification_status field to APPROVED_FOR_LOS_ENTRY and records their identity in the overall reviewer field. Only a JSON object with APPROVED_FOR_LOS_ENTRY status can be submitted to the LOS integration layer. This status gate is the technical enforcement of the human-approval requirement.

Step five: archive the pre-entry JSON. Before the approved JSON is ingested by the LOS, the complete JSON object (including all source citations, flag fields, verification status updates, and reviewer identity) is archived in the institution's document management system with the loan file. The archived JSON is the audit record that links the LOS field values back to the AI analysis and the human verification that preceded LOS entry.

This five-step workflow is what the opening scenario was missing. The processor's twenty-minute struggle with re-entry would have been replaced by a ten-minute verification of the JSON's source citations, followed by a one-click or one-API-call LOS import. The math is simple: the structured workflow is faster, more accurate, and produces a defensible audit trail. The prose workflow is slower, more error-prone, and leaves the institution unable to demonstrate, in a fair-lending examination, that the figures in the LOS were grounded in verified source documents.

Connecting Structured Output to Fair-Lending and Exam Readiness

The connection between structured output and fair-lending compliance is more direct than it might appear. ECOA (the Equal Credit Opportunity Act) and Reg B require that adverse-action reasons be specific and accurate. Disparate impact under ECOA is an outcome-level problem: when a facially neutral process produces denial rates that disproportionately affect a protected class, the process is discriminatory regardless of the stated intent. Testing for disparate impact requires clean, consistent, comparable data across all applications the model touched. That data comes from the LOS fields.

If income figures enter the LOS through manual re-entry from AI prose, with different processors interpreting income summaries differently (one includes rental income, another excludes it; one uses gross self-employment income, another uses the adjusted figure), the LOS data is inconsistent in ways that are unrelated to the actual differences between borrowers. Disparate-impact testing on inconsistent data produces false results: the algorithm may appear to produce disparate outcomes when the real explanation is inconsistent data entry, or may appear to produce consistent outcomes when there is real disparity hidden in the noise. Structured output, by contrast, produces the same field structure for every application, enforces the same income calculation methodology every time, and flags every exception for human review rather than leaving income treatment to individual processor judgment. The structured output workflow is not just a technical convenience; it is a prerequisite for the kind of consistent, auditable record that ECOA disparate-impact testing requires.

For exam readiness under OCC Bulletin 2026-13, the institution that uses structured AI output is substantially better positioned than one that uses prose. An examiner reviewing AI-assisted underwriting files will ask three questions: (1) What did the AI produce? (2) Did a human review it before it entered the LOS? (3) Can you demonstrate that the LOS figures match the AI analysis? An institution with archived JSON objects, completed verification status fields, reviewer identity records, and LOS import logs can answer all three questions in minutes. An institution with a folder of prose outputs and LOS records that may or may not reflect those outputs cannot answer the third question at all.

The 38 percent of mortgage lenders that were using AI or machine learning in underwriting as of 2024, up from 15 percent in 2023, are operating under the OCC's 2026 expectations regardless of whether their AI workflows produce structured or prose output. The ones who have built structured output workflows have a governance advantage that will be visible the next time an examiner arrives. The ones who have not built those workflows are holding a collection of prose outputs that may have been very useful in the moment and are nearly impossible to reconstruct into a defensible audit trail after the fact.

Key Takeaways

• Bank systems (the core, the LOS) run on typed, formatted data fields, not prose. When AI generates prose, every bridge to a data field is a manual step that introduces error and breaks the audit trail. Structured output closes that gap.
• JSON is the practical standard for lending AI structured output because it is both human-readable and machine-parsable, and most modern LOS and core platforms can ingest it via API, file import, or integration middleware.
• A lending AI output schema should include LOS data fields, source document citation fields, audit trail fields (tool version, reviewer identity, verification status), and flag fields for policy-threshold exceptions, declining income, and missing documentation.
• The adverse-action reason schema must include reg_b_category mapping, source document citations for each reason, and individual verified/verified_by/verified_date fields that must be populated by a human reviewer before any notice can be released. FCRA disclosure fields should be included but flagged for separate human determination.
• For BSA/AML workflows, the structured output schema must include null fields for SAR recommendation and SAR decision, a hard constraint note on the pattern flag that classification belongs to the BSA officer, and an open-questions field that surfaces unknowns for analyst review.
• The five-step verification workflow for structured output -- automated schema validation, human source citation review, completeness check, human LOS entry approval, and pre-entry JSON archiving -- is the technical implementation of the human accountability the ECOA and OCC Bulletin 2026-13 require.
• Consistent structured output across all applications is a prerequisite for reliable disparate-impact testing. Inconsistent data entry from prose-to-LOS manual re-entry introduces noise that corrupts fair-lending analysis and may mask or mimic discriminatory patterns.
• An institution with archived JSON outputs, completed verification status fields, and LOS import logs can answer an examiner's three audit questions (what did the AI produce, was it reviewed, and do the LOS figures match) in minutes. An institution relying on prose outputs may not be able to answer the third question at all.