OCC 2023-17 Third-Party Risk Management for AI Underwriting Vendors

Short answer: OCC Bulletin 2023-17 is the interagency framework banks use to evaluate any third-party relationship, including AI underwriting vendors. Issued in June 2023 by the OCC, Federal Reserve, and FDIC, it replaced the OCC's prior third-party guidance (Bulletins 2013-29 and 2020-10) with a single risk-based lifecycle: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination, with governance, oversight, documentation, and independent reviews running across all five stages.

An AI underwriting vendor is a third-party relationship in scope. The bulletin does not call out AI by name, but it covers technology service providers and tells banks to scale scrutiny to the actual risk. Spreading, global cash flow, and credit memo generation touch credit decisioning, so most banks treat the relationship as a "critical activity" under the bulletin's framing. OCC Bulletin 2024-11 (May 2024) added a community-bank guide that shows how to apply the same lifecycle proportionally without watering down the standard.

This page walks the five lifecycle stages with the AI-specific overlay your vendor-management team actually needs to apply, then drops into the SOC 2 Type II report (the document most AI vendors hand you first) and the four things to verify inside it. Model risk sits in a separate frame and is handled in the examiner readiness guide and the SR 11-7 glossary entry; SOC 2 covers operational controls, not model accuracy, and the two reviews do not substitute for each other.

If you want the broader regulatory rollout context first, start with the AI-Assisted Underwriting Playbook and the AI underwriting governance frameworks guide. This page stays focused on the third-party piece.

What Are the Five Lifecycle Stages Under OCC 2023-17?

The five stages are not new. What 2023-17 did was consolidate the earlier OCC, Federal Reserve, and FDIC guidance into one interagency text, so a bank that runs a single program now satisfies all three agencies. For AI underwriting vendors, each stage has a specific overlay that does not appear in a generic SaaS purchase.

1. Planning

Before any vendor outreach, write down what the AI is supposed to do, which credit decisions it touches, and which data classes flow through it. A spreading tool that ingests tax returns and personal financial statements is handling non-public personal information; a credit memo generator touches the actual write-up that goes to committee. That classification determines the criticality tier, which determines the depth of every downstream stage.

The planning artifact most banks produce here is a one-page use-case statement: the workflow boundary, the data classes touched, the criticality tier, and the model-risk classification of each AI component (deterministic extraction, quantitative estimate, generative summarization). That last column is where 2023-17 hands off to SR 26-2 and OCC Bulletin 2026-13, the model risk frame that superseded SR 11-7 on April 17, 2026.

2. Due Diligence and Third-Party Selection

Due diligence is the section most banks already run well for non-AI vendors. The AI overlay adds four items on top of standard financial-stability, regulatory-history, and operational-resilience review.

• Zero-training contractual posture. The vendor and any subprocessor cannot use bank or borrower data to train, improve, or fine-tune foundation models. This is contractual, not aspirational.
• Model risk owner inside the vendor. A named person, not a team. They sign the model documentation and respond to validation questions.
• Override audit-trail surface. When an analyst changes a value the AI extracted or a flag the AI raised, the system has to record the original output, the new value, the user, the timestamp, and the reason. If the platform overwrites silently, that is a deal breaker for examiner review.
• SOC 2 Type II report. The dedicated section below covers what to actually look for inside it. A SOC 2 Type I or an in-progress audit is not a substitute.

3. Contract Negotiation

The contract is where the diligence findings turn into enforceable language. Generic SaaS templates miss the AI-specific points. The five clauses that matter most for an AI underwriting vendor:

• Data residency. Where inference runs, where data is stored, and what residency commitments the vendor's inference providers have made.
• Model-change notification. A defined window (30 days is typical) before any change to the underlying model. The notification should describe what changed and why.
• Zero-training data use. Echoed from diligence into the contract, with subprocessor flow-down.
• Incident reporting. A timeline (often 72 hours) for security incidents, model regressions that materially change outputs, and inference-provider outages.
• Termination data portability. At exit, the vendor returns spreads, override history, audit logs, and the source-document mappings in a usable schema. "Export to PDF" is not portable; CSV or JSON with documented field meanings is.

4. Ongoing Monitoring

Most banks let monitoring slip after go-live because the annual SOC 2 cycle anchors everything else. For an AI vendor, that gap matters. Models change between audits. The monitoring program that holds up at exam should produce, at a minimum, an annual SOC 2 Type II report with no material exceptions; quarterly SOC 2 bridge letters between audits; a model-change log captured in real time by the vendor and reviewed by the bank's model risk owner; SLA performance reports; and an override-rate review that tracks whether analysts are correcting the AI more or less than they used to.

Override-rate drift is the leading indicator no one watches. If a tax-return extraction tool was running at a 6 percent override rate and is now at 11 percent, the model has changed, the file mix has changed, or the analysts have lost trust. All three are answerable, but only if the bank is looking.

5. Termination

Termination planning happens at contract signing, not at the actual exit. The bank should know in advance how data egress works, what audit-log fields come back, how long the vendor retains residual records, and how source-document mappings survive a migration. If those answers are vague at signing, the exit will be painful.

How Do You Read a SOC 2 Type II Report for an AI Vendor?

Every AI underwriting vendor will hand you a SOC 2 Type II report under NDA. Most vendor-management teams stop at "report exists" and move on. That misses the point. The report is structured. Four things matter when the vendor is an AI underwriting platform.

Observation period

Type II means controls were tested over a window, not at a single point. A 3-month or 6-month period is technically valid but tells you very little about a full operating year. Twelve months is the cleanest full-cycle view and what most banking customers expect. If the report covers a shorter window, ask why and ask for the next one. A bridge letter does not extend an old report; it confirms no material changes since.

Trust services criteria in scope

SOC 2 has five trust services criteria: Security (mandatory), Availability, Confidentiality, Processing Integrity, and Privacy. Lending AI vendors typically scope Security plus Availability and Confidentiality. Security alone is the floor; without Confidentiality, the report does not specifically test that customer data is protected from unauthorized disclosure, which is the whole point of zero-training language. Processing Integrity is interesting for an AI workflow but rare; do not penalize a vendor for not carrying it as long as they answer the model-side questions separately.

Exceptions and management responses

Read the exceptions section. An exception is a control that did not operate as designed during the observation period. A small number of exceptions with clean management responses is normal. A pattern of repeat exceptions, or a material exception in a control that maps to a core promise of the platform (logical access, change management, data segregation), is a finding worth a follow-up call. Banks that skip this section catch the problem at exam instead.

Subservice organization carve-outs

This is the AI-specific question. Every AI vendor depends on inference providers, usually Google Cloud (Vertex AI), AWS (Bedrock), or a similar hyperscaler. The SOC 2 report has to declare whether those providers are carved out (you rely on their separate SOC 2) or carved in (their controls are tested inside the vendor's audit). Neither is automatically right, but the bank's vendor-management team has to know which model applies and where their reliance sits. Aloan's AI data security page is explicit: Vertex AI and Bedrock are carved into the security boundary, and both providers separately maintain SOC 2 Type II, ISO 27001, FedRAMP, HIPAA eligibility, and GDPR compliance.

What AI-Specific Risks Sit On Top of the Standard 2023-17 Lifecycle?

Four risks show up on every AI underwriting vendor file. The vendor-management team has to address each one explicitly, not roll them up into a generic "technology risk" line.

Three of the four sit inside 2023-17's lifecycle. The model-risk column is the one most likely to get missed because it belongs to a different examiner conversation. The cleanest programs treat model risk and third-party risk as parallel tracks for the same vendor, with shared diligence inputs and separate validation evidence.

What Does Proportionality Look Like for a Community Bank?

OCC Bulletin 2024-11 was issued in May 2024 as a community-bank guide to 2023-17. It does not change the lifecycle, the criticality concept, or the governance backbone. It shows community banks how to run the same program at a scale that matches the institution. The same proportionality lens is reinforced in OCC Bulletin 2025-26 on the model-risk side.

In practice, proportionality changes three things for a community bank vendor-management program:

• Depth of diligence scales to criticality. The community bank does not need a 40-person vendor risk team to read a SOC 2. It needs a documented review by someone qualified, with a written conclusion and follow-up actions.
• Documentation reflects the actual operation. A two-page risk assessment that describes what really happens is better than a 30-page template that no one signs.
• Monitoring cadence matches the activity. A vendor used for analyst-assistance work does not need the same monitoring intensity as the bank's core. SOC 2 Type II annually, bridge letters quarterly, model-change notifications as they occur, and an override-rate dashboard reviewed each quarter is a defensible cadence for most community-bank AI deployments.

Examiners do not credit a community bank for running a thin program. They credit one for running a right-sized one tied to the actual activity, with documentation an outside reviewer can follow.

How Does Aloan Map to OCC 2023-17?

This page is the third-party risk frame, not a sales page. The worked example below shows how one AI underwriting vendor lines up against the bulletin so a vendor-management team has a reference point for what the documentation should look like, regardless of which vendor they end up selecting.

• SOC 2 Type II. Aloan has completed an independent SOC 2 Type II audit covering Security, Availability, and Confidentiality. The report is available under NDA through trust.aloan.ai.
• Inference providers carved in. Google Cloud Vertex AI and AWS Bedrock are carved into the security boundary. Both providers separately maintain SOC 2 Type II, ISO 27001, FedRAMP, HIPAA eligibility, and GDPR compliance. The AI data security page walks the architecture.
• Zero-training contractual posture. Both Vertex AI and Bedrock provide contractual guarantees that customer inputs and outputs are not used to train, improve, or fine-tune foundation models. That language is echoed in the Aloan contract.
• Override audit trail. Every figure links to its source page on the underlying document. Override history (original value, new value, user, timestamp, reason) is preserved per credit and surfaceable to an examiner without leaving the platform.
• Documentation pack. The vendor-management bundle includes the SOC 2 Type II report, the data processing agreement, the model documentation, and architecture diagrams sufficient for a community-bank TPRM file under 2024-11.

The point is not that Aloan is the only vendor that can show this. The point is that this is what the documentation should look like. If a vendor cannot answer all five of these directly, the file is not ready.

One-Page TPRM Checklist for AI Underwriting Vendors

Frequently Asked Questions About OCC 2023-17 and AI Underwriting Vendors