The file sat in the underwriter's queue for eleven hours before anyone noticed the problem. A borrower had applied for a $485,000 conventional mortgage on a single-family home in a suburban market. The institution's AI pre-scoring tool had flagged the file as "refer to manual underwriting" after identifying that the borrower's qualifying income fell below the threshold for automatic approval at the requested debt-to-income (DTI, the ratio of total monthly debt obligations to gross monthly income, the primary underwriting metric for consumer credit) ratio. The flag included a confidence score and three contributing factors. What it did not include was any indication of which underwriter had reviewed it, whether the "refer" was an AI output or a human determination, or when the human review was supposed to occur. The loan origination system (LOS, the software managing the application through closing) showed a single status field: "Under Review." The borrower was calling the loan officer daily for an update. The underwriter, returning from a two-day training, had a queue of nineteen files without clear priority or handoff notes. She worked through them by date, and the pre-scored file, lacking any timestamp on the AI action, sat in the middle of the stack rather than at the top where a time-sensitive exception belonged. When the file eventually cleared with an approval, the borrower had spent twelve business days waiting for a decision that took thirty minutes of actual underwriter time once the file was picked up. The AI pre-scoring saved no time at all, because the handoff from AI to human was undesigned.

What a Handoff Contract Is and Why It Matters

A handoff contract is the explicit, documented specification of what happens at the boundary between AI activity and human activity in a workflow. It answers five questions for every boundary in the origination-to-decision process: what output the AI must produce before the handoff occurs, what condition triggers the handoff, who the human recipient is and how they are notified, what the human must do to acknowledge and complete the handoff, and how both the AI action and the human action are recorded in the LOS. A handoff contract is not a workflow diagram, though it should be reflected in one. It is a binding operational specification that the LOS is configured to enforce.

The word "contract" is deliberate. OCC Bulletin 2026-13, the April 2026 interagency model-risk update that superseded OCC 2011-12 and brought generative AI under model-risk, fair-lending, third-party, and board-governance expectations, asks institutions to demonstrate that human accountability was present at every consequential decision point in AI-assisted processes. Demonstrating that requires a prior specification of what human accountability looks like at each boundary, not a post-hoc reconstruction. The handoff contract is that prior specification. Without it, the boundary between AI and human is a gap in the record, not a control.

In the opening story, the AI pre-scoring tool produced a referral with a confidence score and contributing factors. That is a reasonable AI output. But the handoff contract was missing: there was no specification of who received the referral, how they were notified, what their response obligation was, or how the response was logged. The result was a file that sat, neither in the AI's queue nor clearly in any human's queue, for eleven hours. In a residential mortgage, that delay is a customer experience failure. In a commercial credit with a rate-lock expiration, it can be a material financial loss. And in a fair-lending context, if files belonging to protected-class borrowers accumulate disproportionate queue time because of undesigned handoffs, the operational failure becomes a disparate-impact risk under ECOA (the Equal Credit Opportunity Act) and Reg B (the CFPB's implementing regulation, 12 CFR Part 1002).

Anatomy of the Decision Boundary

The decision boundary is the specific handoff point that carries the highest legal and compliance weight in the origination workflow: the boundary between AI pre-scoring and the underwriter's credit decision. Everything upstream of this boundary is pre-decision processing. The underwriter's action at this boundary is the credit decision. The LOS must enforce a human action event at this boundary before the file can advance to approval, conditional approval, or decline status, and the event must be attributable to a specific, credentialed human.

A well-designed decision boundary has five elements.

Element 1: A defined AI output package. The AI pre-score is not useful to an underwriter as a bare confidence score. The handoff contract specifies what the AI output package must contain: the score or recommendation, the contributing factors in descending order of weight, the policy parameters used in the evaluation, any flags for policy exceptions, and a timestamp for the scoring event. A pre-score that the underwriter cannot interpret without additional system queries is not an actionable handoff; it is a burden transfer. The handoff contract should specify the exact format of the AI output package and require the LOS to display it to the human recipient in a standard, readable layout.

Element 2: A clear routing rule. For each possible AI output, the handoff contract specifies exactly which human is responsible for the next action. A clean pre-approval (all policy parameters met, no flags) may route to a senior processor for condition checklist generation, with the underwriter reviewing the complete file before final sign-off. A clean pre-decline may route directly to the underwriter. A referral (file falls outside automated parameters, requires judgment) routes to the underwriter immediately, with a specified response window. The routing rule must be unambiguous: a file that meets multiple routing conditions should have a priority rule that determines the single routing destination. Ambiguous routing creates the queue-management problem from the opening story.

Element 3: A notification with a response window. The routing rule sends the file to a human recipient, but the handoff contract must also specify how the human is notified and what their response obligation is. LOS task assignment with an email notification and a 24-hour response window for routine referrals, a 4-hour window for files with pending rate locks, and a same-business-day window for exceptions identified as time-sensitive are examples of notification specifications that can be enforced by the LOS. The response window is part of the handoff contract, not a general expectation. If the human has not acted within the window, the LOS escalates to a supervisor. The escalation is also part of the handoff contract.

Element 4: A defined human action event. The handoff contract specifies what the underwriter must do to close the handoff. For a referral to manual underwriting, the closing action is typically: review the AI output package, verify the input data against the source documents, apply the institution's credit policy, and record a decision (approve, approve with conditions, or decline) with a decision code in the LOS. "Reviewed" is not a sufficient closing action if the file can sit in a "reviewed" status for an indefinite period without a decision event. The handoff contract specifies the decision event and the decision code, and the LOS enforces that the decision event is a required field before the file can advance.

Element 5: A dual-event log. The handoff contract requires the LOS to log both the AI action (pre-score produced, timestamp, tool version) and the human action (review completed, decision recorded, underwriter identifier, timestamp) as distinct, queryable events in the loan file history. The dual-event log is the audit trail that answers the examiner's question: was there a human who reviewed this AI pre-score before the credit decision was made? The log must be structured so that the question can be answered by querying the LOS data, not by asking the underwriter to remember.

Tagging Every AI-Touched Element

The handoff contract governs the boundary between AI and human activity, but the broader audit trail requirement extends to every element in the file that the AI touched before the handoff occurred. A complete loan file at the decision boundary contains AI-generated or AI-assisted elements from all the upstream processing stages: the AI-extracted income figures, the AI-classified documents, the AI-completeness-check results, the pre-score itself, and any AI-drafted text (initial condition letters, missing-document request language, income-calculation summaries). Each of these elements must carry a tag.

The tag structure should capture: the originating system or tool (including the specific vendor and model version where applicable), the date and time of the AI action, the confidence level or quality metric where the AI tool provides one, and whether the output has been human-validated and by whom. The last element is the most important for the decision boundary: when the underwriter begins their review, they need to know which figures in the file have been verified by a human and which are still in AI-draft status. A file where all the income figures carry an "AI-extracted, not yet validated" tag tells the underwriter exactly what they still need to verify before they can make a decision. A file where AI-extracted and human-verified figures look identical on the screen creates the failure mode where the underwriter trusts a figure that was never validated.

The tag display requirement is not just an audit requirement; it is a workflow-quality requirement. Underwriters who can immediately identify which elements of a file have been human-validated work faster and more accurately than those who must re-verify every figure on the assumption that none were checked. Designing the LOS to display validation status at the field level is an investment in underwriter productivity, not just in compliance documentation.

For AI-generated text in the file, the tagging requirement applies at the document level rather than the field level. A credit memo draft produced by an AI drafting tool carries a document-level tag: AI-generated, tool name, version, date, not yet human-reviewed. When the underwriter reviews and edits the draft, the tag updates: AI-generated, human-reviewed and approved by [identifier], date. When the underwriter substantially rewrites sections, the tag notes: AI-generated, substantially revised by [identifier], date. The history of the document's provenance is preserved in the LOS record. This is not bureaucracy for its own sake. It is the record that allows the institution, in a fair-lending examination or an adverse-action challenge, to demonstrate exactly what was AI-generated and what was human-authored in the credit decision record.

The Override Record and Why It Matters

An override occurs when the human underwriter's decision at the decision boundary differs from the AI pre-score recommendation. A pre-score that recommended decline and an underwriter decision of approve is an upward override. A pre-score that recommended approve and an underwriter decision of decline is a downward override. A pre-score that flagged for referral and an underwriter decision that did not follow the flagged exceptions is a referral override. Each of these is a legitimate exercise of human judgment, and the handoff contract must specifically accommodate and document each type.

Overrides are not failures of the workflow. They are precisely the point of the workflow: the AI produces a recommendation, the human applies judgment and policy expertise, and the human's decision is what the institution stands behind. What makes overrides dangerous is not their occurrence but their undocumented occurrence. An underwriter who routinely overrides pre-score recommendations without recording the basis for the override creates an invisible pattern. If that pattern correlates with protected-class membership, the institution has a fair-lending problem with no paper trail for the defense. Under ECOA and Reg B, outcomes matter regardless of intent. An unexplained override pattern that disadvantages a protected class is a disparate-impact violation even if the underwriter never thought about the borrower's protected class.

The handoff contract requires overrides to be documented with a mandatory reason-code field and an optional notes field. The reason code captures the category of the override: credit exception based on compensating factors, policy exception approved by credit committee, documentation exception pending additional evidence, or other. The notes field allows the underwriter to describe the specific compensating factor or policy basis. The LOS must enforce that the override event is recorded before the file status changes, and the override record must be preserved in the loan file history as a queryable event.

For institutions subject to fair-lending examination, the override record is one of the primary data sources for the examiner's disparate-impact analysis. An examiner who can query the LOS for all override events in a twelve-month period, segment them by override direction (upward or downward), and cross-reference them with applicant demographic data to test for patterns is doing exactly what OCC 2026-13 expects. An institution whose LOS supports that query, because the handoff contract required override documentation, is in a fundamentally different examination posture than one whose overrides were decided verbally and are not retrievable from the system.

The Adverse-Action Handoff

The adverse-action handoff is the second critical decision boundary in the origination workflow, and it requires its own handoff contract specification. The ECOA and Reg B obligation for adverse action is distinct from and more specific than the obligation to make a credit decision: the institution must deliver, within a specified timeframe, a written notice identifying the specific reasons for the adverse action at the level of specificity required by the regulation. "Credit score below required threshold" is not a sufficient reason code. "Insufficient income relative to monthly obligations" is closer, but the Reg B guidance and the CFPB's examination procedures require reasons that are specific to the borrower's actual file, not generic categories.

AI tools can assist in generating adverse-action reason codes from the underwriter's decision notes and the verified file data. The assistance is valuable: the process of identifying the top principal reasons (reflecting common adverse-action notice practice) from a complex file, ranking them in order of significance, and drafting them in plain language is time-consuming for an underwriter handling volume. An AI tool that produces a draft reason-code package reduces that time significantly. The handoff contract for adverse action governs the boundary between the AI-drafted reason codes and the notice that is delivered to the borrower.

The adverse-action handoff contract has three required elements beyond the standard handoff contract elements. First, the human reviewer must specifically confirm that each stated reason matches the actual basis for the denial, not just that the denial was appropriate. This is a distinct review action from approving the denial decision. The LOS must capture the reviewer's confirmation of the reasons as a separate event from the confirmation of the decision status. Second, the human reviewer must confirm that the stated reasons do not include any element that is prohibited under ECOA (no reason that reflects or proxies protected class membership), even if the AI-generated draft does not flag the element. The human reviewer's training and judgment are the control here, not the AI tool's output. Third, the human reviewer must confirm the timeliness of the notice: under Reg B, the adverse-action notice must be delivered within 30 days of the adverse action, and the LOS must flag files where the notice generation event is approaching the deadline.

The adverse-action handoff contract is where the legal asymmetry between approvals and denials is most operationally visible. An approval with a deficient handoff contract causes queue-management problems and model-risk documentation gaps. A denial with a deficient adverse-action handoff contract causes an ECOA compliance failure. The consequences are categorically different, and the handoff contract design must reflect that difference.

Handoff Contracts for Complex Credit and Exception Processing

The standard origination workflow covers the majority of files at most institutions: files that fall within clear policy parameters and can be processed without significant exception handling. Complex credits, policy exceptions, and BSA/AML (Bank Secrecy Act and Anti-Money Laundering, the regulatory regime requiring financial institutions to maintain programs to detect and report financial crimes) referrals require handoff contracts that accommodate non-standard routing and extended review timelines.

A complex credit is one where the borrower's financial situation requires analysis beyond the standard income and asset verification process: a self-employed borrower with multiple entities, a borrower with income from a recent business sale, a borrower with complex debt obligations including contingent liabilities, or a commercial real estate borrower with a property that requires specialized collateral analysis. For complex credits, the AI pre-scoring step is typically not the primary decision driver; the underwriter's analysis is the primary process. But AI tools can still assist within the underwriter's workflow, and the handoff contract for complex credits must specify which AI assistance is permitted (policy lookup, document retrieval, financial ratio calculation), which outputs require human validation before use in the analysis, and how the AI assistance is logged within a step that is otherwise human-required.

Policy exceptions require a handoff contract that routes the file to a credit committee or a senior credit officer for a separate approval layer. The AI pre-scoring tool should identify policy exceptions in its output package, flagging the specific parameter that is out of policy (DTI above the standard limit, LTV above the standard limit, credit score below the standard minimum) and the magnitude of the exception. The handoff contract for exceptions must specify who can approve each type and magnitude of exception, what supporting documentation is required for the exception request, and how the exception approval is recorded and preserved in the LOS. An exception that was approved verbally in a credit committee meeting and never recorded in the LOS is an audit and model-risk documentation failure.

BSA/AML referrals are a separate handoff category that most origination workflow maps handle inadequately. The credit analyst or underwriter who observes suspicious activity indicators in a borrower's financial documents (income inconsistent with stated occupation, large cash deposits without clear explanation, transaction patterns that suggest structuring) has an obligation to route the file appropriately within the institution's BSA program. This is not a credit decision; it is a separate compliance determination. The handoff contract for BSA referrals must specify who receives the referral, how it is documented in a manner that does not compromise any Suspicious Activity Report (SAR, the required regulatory filing under BSA for suspected money laundering or financial crime) investigation, and how the credit process is paused or continued while the BSA review occurs. This handoff contract must be designed in coordination with the institution's BSA/AML compliance team and must not be resolved by a credit officer acting independently.

Testing and Maintaining the Handoff Contract

A handoff contract that is written but not tested is a paper control. The operational test of a handoff contract is whether the LOS, in actual practice, prevents a file from advancing past a decision boundary without the specified human action event. Testing the handoff contract requires running test files through the LOS and confirming that each boundary behaves as specified.

The testing protocol for a decision boundary should include at minimum: a file that the AI pre-scores as a clear approve (confirm that the LOS does not advance the file to approved status without a human decision event), a file that the AI pre-scores as a clear decline (confirm that the LOS does not generate an adverse-action notice without the human reviewer specifically approving the reason codes), a file that the AI pre-scores as a referral (confirm that the routing logic delivers the file to the correct underwriter with the specified notification and response window), and a file where the underwriter overrides the pre-score recommendation (confirm that the override reason-code field is mandatory and that the override event is logged with the required attribution).

For institutions using AI drafting tools within human-required steps, the testing protocol should also include: a file where the underwriter uses an AI drafting tool to produce a credit memo (confirm that the tool usage is logged and that the draft is tagged as AI-generated), and a file where the AI drafting tool produces an adverse-action reason-code draft (confirm that the draft is tagged as AI-generated and that the human reviewer's approval of the specific reasons is a distinct, mandatory event before the notice can be sent).

Maintaining the handoff contract requires a review trigger for changes to the AI tools, changes to the LOS configuration, regulatory updates, or credit policy changes. OCC 2026-13's ongoing monitoring requirement means that the handoff contract is a living document, not a one-time specification. Each time the institution makes a material change to an AI tool or to the workflow it governs, the handoff contract must be reviewed and updated. The review event should itself be logged in the model-risk management record as evidence of ongoing governance.

The underwriter at the opening story's institution eventually worked through the queue, and the borrower's mortgage closed without a compliance event. But the institution had no record of the twelve-day processing delay, no evidence that the delay did not affect protected-class borrowers disproportionately, and no handoff contract that would prevent the same pattern on the next high-volume week. The technology was adequate. The governance was the gap. A handoff contract, enforced in the LOS and tested before deployment, fills that gap before the examiner arrives to ask why the files sat.

Key Takeaways

• A handoff contract is a binding operational specification that answers five questions at every AI-to-human boundary: what the AI must produce, what triggers the handoff, who receives it and how, what human action closes it, and how both events are logged. Without this specification, AI-to-human boundaries are gaps in the record, not controls.
• The decision boundary between AI pre-scoring and the underwriter's credit decision is the most consequential boundary in the workflow: the LOS must enforce a human decision event before the file advances, the human action must be attributable to a specific, credentialed individual, and the dual-event log must preserve both the AI action and the human action as distinct, queryable records.
• Every AI-touched element in the file must carry a tag identifying the originating tool, the model version, the timestamp, and the validation status, and AI-generated and human-validated values must be stored in separate, distinguishable fields so that the underwriter's review is informed by which figures have been verified and which have not.
• Override documentation is a fair-lending control, not just a quality-management record: override patterns that correlate with protected-class membership create a disparate-impact risk under ECOA regardless of intent, and the handoff contract's override record is one of the primary data sources the examiner will use to test for that pattern.
• The adverse-action handoff requires the human reviewer to specifically confirm each stated reason code in addition to confirming the denial decision, because the ECOA and Reg B obligation is on the accuracy and specificity of the stated reasons, not just on the appropriateness of the denial.
• Handoff contracts must be tested operationally by running test files through the LOS and confirming that each boundary behaves as specified, because a handoff contract that exists only on paper is a paper control, not an operational one.
• OCC Bulletin 2026-13 requires ongoing monitoring and change management: each material change to an AI tool, to the LOS configuration, or to the credit policy that affects a governed step requires a review and update of the relevant handoff contract, logged in the model-risk management record as evidence of active governance.