Compliance & Risk 9 min read Updated October 2026

Colorado AI Act (SB 26-189) for Banks, Lenders & Insurers: ADMT Compliance Guide

SB 24-205, the original Colorado AI Act, never took effect — blocked in federal court, then repealed. SB 26-189 replaced it with a narrower automated decision-making technology (ADMT) framework covering financial/lending services and insurance, effective January 1, 2027.

Educational content, not professional advice — AI output and figures here can be wrong. Verify before you rely on it. Full disclaimer →

The Colorado AI Act You've Heard About Is Dead — Here's What Replaced It

If your compliance team has a binder on "the Colorado AI Act" dated 2024 or early 2026, it's describing a law that never took effect. SB 24-205, Colorado's original AI Act, was signed in 2024 with a framework built around "high-risk artificial intelligence systems" and broad proactive risk-management obligations. Its effective date was pushed from February 1, 2026 to June 30, 2026 by a special-session bill (SB25B-004, signed August 28, 2025). Before that date arrived, a federal magistrate judge in the District of Colorado blocked the state from enforcing it — xAI had sued on constitutional grounds, and the Department of Justice intervened in support of xAI's position. Colorado's legislature then repealed SB 24-205 outright rather than fight the injunction, and reenacted a narrower replacement: SB 26-189, signed into law in May 2026.

SB 26-189 drops the "high-risk AI system" framing entirely and rebuilds around automated decision-making technology (ADMT) — a narrower, more specific target than its predecessor, and one with a direct and explicit application to financial services. The operative requirements take effect January 1, 2027, with the Colorado Attorney General's office running a parallel rulemaking process to fill in implementation detail.

What Counts as ADMT, and What Triggers the Law

SB 26-189 defines ADMT as technology that processes personal data and uses computation to generate output — a prediction, recommendation, classification, ranking, or score — that is used to make, guide, or materially assist a decision about an individual. Not every model clears the bar: the law's substantive obligations only trigger when the ADMT materially influences a consequential decision.

A consequential decision is one that relates to a consumer's access to, eligibility for, selection for, or compensation for a covered domain — or to a differentiated price, cost-sharing, or other material term that could materially limit, delay, effectively deny, or otherwise alter that access. The law lists seven covered domains: education, employment, residential real estate, financial or lending services, insurance, health care, and essential government services. Financial and lending services and insurance are named explicitly — this is not a law institutions in this sector can treat as someone else's problem.

  • "We run a credit underwriting model that scores small-business loan applications and a separate claims-triage model that flags auto insurance claims for expedited vs. standard review. For each model: (1) does its output materially influence a consequential decision as SB 26-189 defines it — walk through the 'financial or lending services' and 'insurance' covered-domain language against what the model's score actually does downstream; (2) is our institution the developer, the deployer, or both, given that the credit model was built in-house and the claims-triage model is licensed from a third-party vendor; (3) flag any part of either model's current documentation that would need to change to support a developer transparency package or a deployer consumer notice."

Developer Duties: The Transparency Package

If your institution builds or substantially modifies an ADMT system — including customizing a third-party model enough to count as a substantial modification — you're a developer under the statute, with obligations that run to your deployers rather than directly to consumers. The core duty is a transparency package: documentation covering the system's intended use, the data categories used to train and operate it, known limitations, and the metrics and methods used to evaluate its performance and test for unlawful discrimination. Developers must also issue update notices within a reasonable time after a substantial modification, and retain ADMT records for at least three years after each record is created.

  • "Draft the developer transparency package for our in-house credit underwriting model, covering: (1) intended use — underwriting decisioning for small-business term loans $50K-$500K; (2) data categories used in training and operation — business financials, bureau data, bank transaction history, industry NAICS code, time in business; (3) known limitations — thinner performance evidence for businesses under 12 months old and for industries outside our top 10 NAICS codes by training volume; (4) the discrimination-testing methodology we use — disparate impact testing on protected classes vs. our approved population, run quarterly. Format as the document we'd hand to an internal deployer (our own retail lending division) to satisfy SB 26-189's developer-to-deployer transparency obligation, written for a compliance officer audience, not a data scientist audience."

Deployer Duties: Notice and the Adverse-Outcome Explanation

If your institution actually uses the ADMT to make or influence a decision about a consumer, you're a deployer — and deployer duties run directly to the consumer. Deployers must give clear and conspicuous notice at the point of interaction that a consequential decision will be influenced by ADMT, before the decision is made. If the ADMT contributes to a consequential decision with an adverse outcome for the consumer, the deployer must provide a plain-language explanation of the ADMT's role in that decision within 30 days of the consumer's request.

That 30-day plain-language explanation duty sits close to, but is legally distinct from, the adverse action notice requirements under the Equal Credit Opportunity Act and Regulation B that credit decisions already carry — see our regulatory compliance coverage for the federal side. SB 26-189 doesn't replace ECOA/Reg B; a Colorado-covered credit decision now needs to satisfy both.

  • "Draft the point-of-interaction ADMT notice for our online small-business loan application, to display before the applicant submits financial data for underwriting. It must clearly and conspicuously disclose that automated decision-making technology will materially influence the lending decision, in plain consumer-facing language, not legal boilerplate. Keep it under 75 words and draft three variants: (A) a banner above the application form, (B) a checkbox-adjacent disclosure at submission, (C) a one-sentence version for a mobile app's application flow."
  • "A small-business loan applicant was declined and has requested, under SB 26-189, a plain-language explanation of the ADMT's role in that decision. Underwriting inputs: business credit score 580 (below our 620 minimum), 8 months in business (below our 12-month minimum), debt-service coverage ratio 0.95 (below our 1.10 minimum). The model weighted DSCR most heavily in this decline. Draft the 30-day response: plain language, no model internals or trade-secret scoring logic disclosed, but specific enough that the applicant understands which factors drove the outcome and that automated scoring — not a human's individual judgment — produced the result."

Where to Start

Inventory first: list every model or scoring system your institution uses in lending, underwriting, pricing, or claims that touches an individual consumer's outcome, and sort each into developer, deployer, or both. For anything already in production, the developer transparency package and deployer consumer notices are the two concrete deliverables due before January 1, 2027 — start drafting both now, since the Attorney General's rulemaking will refine detail but isn't expected to change the core obligations. See also our Agentic AI Governance checklist for the broader model-oversight pattern SB 26-189 fits into, and CFPB adverse action coverage for how this interacts with existing federal credit-decision disclosure duties.

Frequently Asked Questions

Is the Colorado AI Act still SB 24-205?

No. SB 24-205, the original 2024 Colorado AI Act, never actually took effect. Its start date was pushed from February 2026 to June 30, 2026 by a special-session bill, and before that date arrived a federal magistrate judge blocked Colorado from enforcing it after xAI sued on constitutional grounds with the Department of Justice intervening in support. Colorado then repealed SB 24-205 outright and replaced it with SB 26-189, signed into law in May 2026, which takes a narrower approach built around "automated decision-making technology" (ADMT) rather than the original's broader "high-risk artificial intelligence system" framework. Any compliance material still describing SB 24-205's original risk-management obligations is describing a law that no longer exists.

Does Colorado's ADMT law apply to credit underwriting and insurance models?

Yes. SB 26-189 defines seven "covered domains" where a consequential decision triggers the law's obligations: education, employment, residential real estate, financial or lending services, insurance, health care, and essential government services. A credit underwriting model, a loan pricing algorithm, an insurance underwriting or claims-triage score, and similar systems squarely fall within the financial/lending-services and insurance domains whenever they materially influence a decision about a specific consumer.

What is the difference between a "developer" and "deployer" under SB 26-189?

A developer builds or substantially modifies the ADMT system; a deployer is the institution that actually uses it to make or influence a decision about a consumer. A bank that licenses a third-party credit-scoring model is typically the deployer, while the vendor that built the model is the developer — though an institution that builds its own underwriting model in-house is both. The two roles carry different duties: developers owe deployers a transparency package and update notices; deployers owe consumers point-of-interaction notice and, after an adverse outcome, a plain-language explanation.

When does SB 26-189 take effect?

January 1, 2027. The Colorado Attorney General's office is running a parallel rulemaking process to fill in implementation detail before that date, but the core developer and deployer obligations are already set in the statute itself and don't depend on the rulemaking completing.

Using Claude at your firm?

Connect Claude to live financial data via MCP — EDGAR, FDIC, BIS, CME and 18 more.

New guides & tools — free

Get notified when we add new MCP servers, finance AI guides, and eval results.

Try These Skills

Browse all Compliance & Risk tools →
FEEDBACK