At 9:14 on a Monday morning, a regional bank's mortgage operations manager pulled up the origination dashboard and counted the queue: 47 files at various stages between application receipt and underwriter review. Fourteen had been sitting for more than three days without a single human touch because the processor assigned to them was clearing a compliance exception on a separate file. The bank had just deployed an AI document-extraction tool two months earlier and was seeing real gains in processing speed on clean files, but nobody had drawn a clear line between where the AI ran unsupervised and where a human had to be present. The operations manager had a working mental model, but it lived in her head. Nothing in the loan origination system (LOS, the software platform that manages the loan from application receipt through closing and funding) reflected which steps were AI-assisted and which required human sign-off. When an OCC examiner arrived for a routine visit six weeks later and asked to see the AI workflow documentation, the operations manager spent two days reconstructing from memory what the process actually was. That reconstruction was the compliance event. The technology worked. The workflow design was missing.

Why Workflow Design Is the Actual Work at L3

Levels 1 and 2 of this program built two capabilities: understanding what different kinds of AI do and do not do in a lending context, and using AI tools to produce verified, compliant outputs on individual tasks. A credit analyst who completed L2 can draft a credit memo with an AI tool, verify every figure against source documents, and produce an adverse-action notice grounded in the actual file. That is real and valuable. It is also, by itself, an individual skill rather than an institutional workflow.

Level 3 is about the bigger container: the end-to-end origination workflow from application intake to credit decision, designed so that AI contributes at every step where it genuinely helps, stops where human judgment is required, and leaves a complete documented trail that an examiner can reconstruct. This is harder than any individual task because it requires making explicit decisions that most institutions leave implicit: exactly which steps are AI-assisted, exactly which steps are human-only, what triggers a handoff from AI to human, and how the system records who did what to which file at which point.

OCC Bulletin 2026-13, the April 2026 interagency model-risk guidance that superseded OCC 2011-12 and brought generative AI explicitly under model-risk, fair-lending, third-party, and board-governance expectations, does not merely ask whether the institution used AI. It asks the institution to demonstrate that it knew, at each decision point, what role the AI played, that human accountability was intact at the points that required it, and that the overall process did not produce disparate impact on protected classes under ECOA (the Equal Credit Opportunity Act, which prohibits credit discrimination on enumerated bases) and Regulation B (Reg B, the CFPB's implementing regulation for ECOA, 12 CFR Part 1002). A workflow map is how the institution answers those questions without reconstructing from memory.

The workflow design skill this chapter builds is not diagramming for its own sake. It is the foundation on which the handoff contract (lesson 3.1.2), the retrieval setup (lesson 3.1.3), the bias testing program (chapter 3.3), and the model-risk audit trail (chapter 3.6) all sit. A clear process map makes everything downstream easier and makes the institution's AI posture defensible rather than improvised.

The Origination-to-Decision Spine

The standard residential mortgage origination process, which serves as the anchor example throughout this chapter, has seven broad stages: application intake, document collection and stacking, income and asset verification, credit analysis and pre-scoring, underwriter review and decision, adverse-action or conditional-approval processing, and file closing and funding. Commercial and consumer loan processes share the same spine with different document requirements and decisioning criteria. A small-dollar consumer loan may compress stages two through four into a near-automated step; a large commercial real estate credit may expand stages two through four into weeks of back-and-forth. But the spine holds.

Against this spine, a workflow map answers four questions for every step: Is this step AI-assisted, AI-automated (runs without a human touch), human-only, or a hybrid that requires human review of AI output? What specific AI capability is deployed, if any, and what model or tool is it? What triggers the step, meaning what condition or event causes it to begin? And what output must the step produce, including what must be logged, before the file advances to the next stage?

Running through these questions for each step in a residential mortgage is the practical work of this lesson. The answers reveal where AI helps, where it must stop, and where the most common workflow design mistakes live.

Stage 1: Application Intake. This stage runs from the moment a borrower submits an application, whether through a digital point-of-sale system, a loan officer conversation, or a paper form, through the moment the application is recorded in the LOS as a complete submission. The AI capability most commonly deployed here is form parsing and initial data extraction: pulling the borrower's stated income, employment, property address, and loan purpose into structured LOS fields. This is an AI-assisted step, not a human-only step, but it is not fully AI-automated either. The AI extraction must be validated against the application document before the file advances, because errors in the initial LOS record propagate through every downstream step. The human role at this stage is validation, not original data entry. The workflow must specify who performs the validation, what a passing validation looks like, and where the validation event is recorded in the LOS.

A common workflow design mistake at stage 1 is treating AI extraction as both the input and the validation. If the same AI system that parsed the application is also the one flagging potential extraction errors, it will miss consistent errors that fall within its confidence threshold. The validation step must involve a human reviewing the LOS record against the original application, at least for the key figures that drive underwriting: income, loan amount, property address, and loan purpose.

Stage 2: Document Collection and Stacking. This stage runs from application acceptance through the point at which all required documents (pay stubs, W-2s, tax returns, bank statements, asset statements, the purchase and sale agreement, title, homeowners insurance, and any required supplemental documentation) have been received, reviewed for completeness, and organized in the LOS document management system. AI capabilities deployed here typically include document-type classification (which document is a W-2, which is a bank statement, which is a lease agreement), completeness checking against a checklist tied to the loan type and program, and automated requests to the borrower for missing items.

The classification and completeness-checking functions are genuinely AI-ready: the error cost of misidentifying a document type or missing a required item is recoverable, the AI can operate at speed across large queues, and the human review step (processor review of the stacked file before it advances to income verification) provides a natural quality gate. The borrower communication function is AI-assisted but requires human oversight for anything beyond a templated missing-document request. Nuanced borrower communication about exceptions, unusual circumstances, or program guidance requires a human loan officer.

Stage 3: Income and Asset Verification. This is the first stage where the AI-ready versus human-only distinction becomes load-bearing for credit quality and compliance. Income and asset verification requires extracting specific figures from complex documents (Schedule C, Schedule E, Schedule K-1, operating statements, brokerage account statements) and applying income-calculation rules that vary by income type, loan program, and the institution's credit policy. AI extraction tools can substantially accelerate the document-reading step; they cannot reliably apply institution-specific income-calculation rules without explicit grounding in the policy documents.

The workflow map for this stage must mark extraction as AI-assisted and income calculation as human-verified-AI-assisted or human-only, depending on the institution's configuration. Where AI tools calculate qualifying income, the human underwriter or processor must verify the calculation against the source documents and the policy manual before the figure is entered into the LOS as a verified income figure. The difference between a verified income field and a draft income field must be explicit in the LOS data model, because the downstream credit decision rests on the verified figure.

Stage 4: Credit Analysis and Pre-Scoring. This is the step where AI pre-scoring tools are most commonly deployed and where the workflow design stakes are highest. A credit pre-scoring tool analyzes the borrower's credit profile, income, assets, collateral, and requested loan terms against the institution's credit policy parameters and produces a recommendation: a preliminary approve, a preliminary decline, or a referral to manual underwriting for cases that fall outside clear policy bounds. AI is genuinely useful here for throughput: a tool that can correctly identify clear approvals and refer exceptions for human review allows underwriters to focus their time on files that require judgment rather than processing volume.

The critical workflow design principle for pre-scoring is that the AI's output is a recommendation, not a decision. The workflow must make this explicit in both the LOS configuration and the documented process. An AI pre-score labeled as "decision" in the LOS, even if only by careless labeling, creates a model-risk and fair-lending documentation problem: it implies the AI made the credit decision, which is precisely what OCC 2026-13 says must not happen. The workflow must specify a human review step that follows the pre-score, and the human reviewer's action (approve, decline, or refer) must be recorded as a distinct event in the LOS with a timestamp and the reviewer's credential.

Stage 5: Underwriter Review and Decision. This is the human-only core of the process. The underwriter reviews the complete verified file, the AI pre-score and its basis, any exceptions or risk flags identified in earlier stages, and the institution's credit policy. The underwriter's decision, whether to approve, conditionally approve, or decline, belongs entirely to the underwriter. No AI output, pre-score, or recommendation substitutes for this determination. The workflow must reflect that the underwriter's decision is the credit decision, and the LOS must capture it with the underwriter's identifier, timestamp, and the decision code in a field that is clearly distinct from any AI-generated recommendation.

AI assistance is permitted within the underwriter review step for drafting (credit memos, condition letters, adverse-action reason drafts), lookup (policy lookups against the institution's current policy documents), and analysis tools that help the underwriter evaluate specific risk elements. But each use of AI within the underwriter review step must be tagged in the workflow: which element of the underwriter's work product was AI-assisted, which tool produced it, and what verification step the underwriter applied before incorporating it into the file.

Stage 6: Adverse-Action or Conditional-Approval Processing. When the underwriter declines a file or issues a conditional approval, the process generates a borrower-facing communication. For adverse action under ECOA and Reg B, this communication must include specific, accurate reasons for the decision. AI tools can assist in drafting these reasons from the underwriter's decision notes and the verified file. The draft must be reviewed and approved by a human before it is sent, and the review must confirm that the stated reasons match the actual basis for the decision. This is an AI-assisted step with mandatory human approval before output.

Stage 7: File Closing and Funding. Post-decision processing includes condition clearing, document preparation, title and insurance confirmation, and funding authorization. AI tools are deployed at varying levels across these sub-steps. The workflow map must identify each one, mark the human review points, and specify what gets logged. The audit trail requirement runs through closing: every AI-touched element in the file must be identifiable in the LOS record.

Marking AI-Ready Versus Human-Only

A workflow map becomes operationally useful when it marks each step with a clear designation. The four-category system below aligns with what OCC 2026-13 asks institutions to demonstrate about their AI deployment.

Category A: AI-Automated. The step runs without a required human touch under normal conditions. Examples include document classification, completeness checking against a static checklist, and automated request generation for missing items. Requirements for category A designation: the error cost is low and recoverable (a misclassified document is caught at the next human review point before it affects the credit decision), the AI tool's performance has been validated and is monitored, and the step feeds into a category C or D step rather than directly into a consequential decision.

Category B: AI-Assisted, Human-Validated. AI performs the primary work, and a human must validate the output before it advances. Examples include income extraction (AI pulls figures, human verifies against source documents), pre-scoring (AI produces a recommendation, human makes the credit call), and adverse-action reason drafting (AI generates reason codes, human confirms accuracy and approves the notice). Category B steps require the LOS to maintain two fields: the AI-generated value and the human-validated value. The workflow must specify what a passing validation looks like and where the validation event is logged.

Category C: Human-Required, AI-Supported. A human performs the step and may use AI tools as aids, but human judgment is the primary input and the human's action is the decision. Examples include underwriter review, complex exception analysis, BSA/AML (Bank Secrecy Act and Anti-Money Laundering) referral decisions, and adverse-action reason approval. AI tools used within category C steps are support tools; they do not independently generate outputs that enter the file without human review.

Category D: Human-Only. No AI tools are deployed in this step. Examples include disclosure delivery and explanation to the borrower, relationship calls where nuanced loan-structure negotiation occurs, and internal override discussions. Human-only designation reflects either that the step requires relational judgment that AI cannot provide, that the regulatory or relationship risk of AI involvement is unacceptable to the institution, or both.

Assigning each step in the origination workflow to one of these four categories is the core of the mapping exercise. The exercise produces two things the institution needs: a process document it can show an examiner, and a configuration specification it can use to build or configure the LOS to enforce the designated behavior at each step.

Tagging AI-Touched Elements in the LOS

The process map establishes the intended workflow. The LOS configuration enforces it in practice and generates the audit trail that proves it was followed. The tagging requirement is the bridge between the paper process and the electronic record.

Every AI-generated or AI-assisted field, document, or output in the loan file must carry a tag that identifies it as such. The tag structure should capture three elements: the originating tool or system, the timestamp of the AI action, and the version of the model or tool that produced the output. For a field like verified monthly income, the LOS record should distinguish between the AI-extracted draft value and the human-validated final value, and the history of both values should be retained rather than overwritten. When an underwriter overrides an AI pre-score recommendation, that override must be recorded with the underwriter's identifier, the original recommendation, and the basis for the override.

This tagging structure serves four purposes. The first is audit reconstruction: when an examiner asks to see what role AI played in a specific credit decision, the LOS record answers the question without requiring manual reconstruction. The second is fair-lending monitoring: when the institution runs its periodic disparate-impact analysis, it can identify which files involved AI pre-scoring or AI-assisted income extraction, segment outcomes by that variable, and test whether AI-assisted files show different approval rates across demographic groups. The third is model performance monitoring: by tracking the delta between AI-extracted and human-validated values across a population of files, the institution can measure its AI tools' accuracy and detect drift. The fourth is legal protection: in the event of an adverse-action challenge, the institution can demonstrate exactly what the AI produced, what the human underwriter reviewed, and that the human made the decision.

Institutions that skip the tagging requirement because it requires LOS configuration work typically discover, during an exam or a fair-lending review, that they cannot answer basic questions about their AI deployment at the file level. The operations manager in the opening story spent two days reconstructing from memory what the workflow was. A tagging framework would have made that reconstruction unnecessary and would have made the examiner's inquiry routine rather than stressful.

The Decision Boundary and What Makes It Explicit

The decision boundary is the specific point in the workflow where the AI process hands off to a human and the human makes the consequential determination. Making the decision boundary explicit means three things: it is named in the process document, it is enforced by the LOS (the file cannot advance past the decision point without a human action), and it is logged with an identifier and a timestamp that prove the human action occurred.

The decision boundary in a residential mortgage origination workflow sits between stage 4 (pre-scoring) and stage 5 (underwriter review and decision). The AI pre-score is a category B output: it was produced by AI, it is an input to the underwriter's analysis, and it must be reviewed and acted on by a human before the file advances. The LOS must not permit a file to move from "pre-scored" to "approved" or "declined" without a human action event in between. This is not a philosophical preference. It is the operational implementation of the accountability principle that OCC 2026-13 requires and that ECOA requires for adverse action.

Decision boundaries also exist within stages. In stage 3, the income verification step has a boundary between AI extraction and human validation: the AI-extracted income figure must be confirmed or corrected by a human before it is used in the pre-score. In stage 6, the adverse-action notice has a boundary between AI-drafted reasons and human-approved reasons. Each of these boundaries must be named, enforced, and logged.

A workflow map that identifies all decision boundaries, marks what is AI versus human on each side of each boundary, and specifies what LOS event captures the human action at each boundary is a complete workflow map. A map that lacks any of these three elements is an incomplete workflow map, regardless of how detailed it is in other respects.

The legal asymmetry between approvals and denials sharpens the decision boundary requirement for adverse action. An approval does not require a statement of reasons. A denial triggers the adverse-action obligation under ECOA and Reg B: specific, accurate reasons delivered in a compliant timeframe, on a compliant form, at the correct level of specificity. The decision boundary in the adverse-action workflow is not just a model-risk document; it is a legal compliance control. When the AI drafts the reason codes and the human approves them, the legal obligation belongs to the institution and specifically to the human reviewer who approved the notice. The institution must be able to demonstrate that a human reviewed and approved the specific reasons stated in the notice, not just that a human approved the file status change.

Common Workflow Design Mistakes

Institutions that have deployed AI in their origination workflows without a formal process mapping exercise tend to share a set of predictable design mistakes. Understanding these patterns is useful both for institutions building workflows from scratch and for those auditing existing deployments.

Mistake 1: Treating the pre-score as the decision. The most common and the most consequential error. It manifests as an LOS configuration where the AI pre-score changes the file status directly (from "processing" to "approved" or "declined") without a required human action event. The human underwriter may be reviewing files on a sample basis, but the LOS record does not capture human review as a required step in the workflow. Under OCC 2026-13, this configuration makes the AI tool a decision-maker, not a recommendation engine, which triggers the full model-risk management, independent validation, and fair-lending testing requirements that apply to credit-decision models. Fixing this mistake requires both a process change and a LOS reconfiguration, and it may require retroactive model-risk documentation for the period during which the AI was operating as a decision-maker.

Mistake 2: Undocumented AI tool use within human-required steps. An underwriter who uses an AI drafting tool to produce a credit memo and submits it without logging that AI assistance was used has created a gap in the model-risk documentation. This is not because using AI drafting tools is wrong; it is because OCC 2026-13 requires the institution to know which elements of its credit process involved AI and to have documented the verification controls for each. A workflow that allows undocumented AI tool use within category C steps cannot satisfy the audit requirements of the 2026-13 framework.

Mistake 3: AI-extracted values overwriting human-validated values. In LOS configurations where the AI-extraction tool is integrated with the same field that stores the final verified value, a re-run of the extraction tool (triggered by a document update, for example) can overwrite a human-validated figure with a new AI-generated value. The workflow must ensure that the human-validated field is write-protected after validation and that any subsequent AI extraction is written to a separate draft field for re-validation. This is a data architecture requirement that must be specified in the workflow design before the LOS is configured.

Mistake 4: Undifferentiated audit trails. A LOS event log that records "income field updated" without capturing whether the update was performed by an AI extraction tool or by a human underwriter is not an adequate audit trail for OCC 2026-13. The tagging requirement described above is not satisfied by general system logs; it requires AI-action and human-action events to be distinguishable at the field and document level.

Mistake 5: Incomplete decision boundaries at adverse action. Institutions that correctly enforce the decision boundary at the pre-score stage sometimes fail to enforce it at the adverse-action notice stage. An AI-drafted adverse-action notice that is sent after a human approves the file-status change, without the human separately approving the specific reasons stated in the notice, is a compliance gap. The Reg B obligation is on the accuracy of the stated reasons, not just on the decision to deny. The workflow must require human approval of the reason codes specifically, as a distinct event from the approval of the credit decision.

Mistake 6: No process for AI tool updates. When a vendor updates the AI extraction or pre-scoring tool, the workflow documentation becomes stale if there is no process to review and update it. OCC 2026-13's model-risk framework requires ongoing monitoring and change management. A workflow design that does not include a review trigger for material AI tool updates will drift out of compliance without anyone noticing until an exam or an incident surfaces the gap.

Building the Workflow Map: A Practical Starting Point

For an institution that does not yet have a formal AI workflow map, the following five-step process produces a working first draft that can be reviewed with compliance and model-risk teams and used as the basis for LOS configuration work.

Step 1: Enumerate every step in the current origination process. Start with the LOS configuration, not a theoretical process. Pull the list of workflow states, required tasks, and document requirements from the LOS administration screens. Add any off-LOS steps (email-based document collection, spreadsheet-based income calculation, external AI tools) that are part of the actual process but not reflected in the LOS. This typically produces a list of 25 to 45 discrete steps for a residential mortgage origination process, depending on complexity and loan type.

Step 2: Mark every step where an AI tool is currently used. Interview the processors, underwriters, and operations staff who do the work, not just the technology team that deployed the tools. Frontline staff are typically using AI tools in ways that the technology team did not anticipate, and vice versa. The goal is a complete picture of actual AI use, not just intended AI use. Mark each AI-involved step with the tool name, the version if known, and the general nature of the AI task (extraction, classification, drafting, scoring).

Step 3: Assign each AI-involved step to a category (A, B, C, or D as defined above). For each step where AI is used, determine whether the step requires human validation of the AI output (category B), whether the human is the primary actor and the AI is a support tool (category C), or whether the step is appropriate for full AI automation (category A). If there are steps where AI is being used but the institution is not comfortable assigning any of these categories, that discomfort is diagnostic: it indicates a step where the workflow design needs explicit decisions before the configuration can be treated as compliant.

Step 4: Identify and map all decision boundaries. For each category B step, identify the specific human action that constitutes the validation event and confirm that the LOS captures that action as a distinct, timestamped event. For the primary credit decision boundary (between pre-score and underwriter decision), confirm that the LOS prevents advancement without a human decision event. For the adverse-action boundary, confirm that human approval of the reason codes is a separate event from approval of the decision status. Document the boundaries in the workflow map with explicit notation of what LOS event captures each boundary.

Step 5: Specify the tagging requirements for each AI-assisted field and document. For each field or document that AI produces or assists in producing, specify the tag structure (originating tool, timestamp, model version) and confirm that the LOS stores the AI-generated value and the human-validated value separately. Where the current LOS configuration does not support the tagging requirements, document the gap and assign a remediation timeline. The gap document itself is part of the model-risk management record.

This five-step process produces a workflow map that is sufficient for the compliance and model-risk conversation, sufficient for the LOS configuration review, and sufficient for the examiner inquiry that the operations manager in the opening story could not answer. It does not need to be beautiful. It needs to be accurate, complete, and maintained as the workflow evolves.

An institution's AI posture is not demonstrated by the sophistication of the tools it deploys. It is demonstrated by the clarity with which it can explain what each tool does, where the human decision points are, and how the LOS record proves that the process was followed on every file. The workflow map is the institutional answer to that question, and building it is the first discipline of the AI-integrated practitioner.

Key Takeaways

• A workflow map is not a formality: it is the document that answers the examiner's question about AI deployment without requiring manual reconstruction, and it is the configuration specification that makes the LOS enforce the intended process rather than allowing it to drift.
• The four-category designation system (AI-Automated, AI-Assisted/Human-Validated, Human-Required/AI-Supported, Human-Only) provides a consistent vocabulary for marking each step in the origination process and aligns with the accountability framework OCC Bulletin 2026-13 requires institutions to demonstrate.
• Every AI-touched element in the loan file must carry a tag identifying the originating tool, the timestamp, and the model version, and the LOS must store AI-generated and human-validated values in separate fields with both preserved in the record history.
• The decision boundary between AI pre-scoring and the underwriter's credit decision is the most consequential boundary in the workflow: the AI pre-score is a recommendation, not a decision, and the LOS must enforce a human action event before the file status changes from pre-scored to decided.
• Legal asymmetry sharpens the adverse-action boundary: the institution must demonstrate not only that a human approved the denial but that a human specifically reviewed and approved the reason codes stated in the adverse-action notice, because those reasons carry the ECOA and Reg B obligation.
• The six common workflow design mistakes (treating the pre-score as the decision, undocumented AI use within human steps, AI values overwriting validated values, undifferentiated audit trails, incomplete adverse-action boundaries, and no process for tool updates) are each individually discoverable in an exam and collectively represent the gap between an institution that deployed AI and an institution that governed AI.
• The five-step mapping process (enumerate all steps, mark AI use, assign categories, identify decision boundaries, specify tagging) produces a compliant first draft that is accurate and maintainable, not just a theoretical diagram with no connection to the actual LOS configuration.