1. Purpose of this document

Colorado SB 26-189 takes effect January 1, 2027 and reaches the automated decision-making technology used in deposit account opening. Glide has reviewed the statute in detail and prepared this document for the financial institutions it serves. It describes how automation works on the Glide platform, classifies each component under the statute, explains how Glide meets the obligations that fall to it as the technology provider, and shows how the platform equips your institution to meet its obligations as a deployer.

Glide's compliance posture rests on a structural fact about the platform: Glide is not a black-box decision engine. Every decision rule on the platform is authored and approved by your institution. Glide configures the system to your instructions, records everything it does, keeps a human in control of every outcome, and provides the documentation and records the law expects. This document walks through each requirement of the statute and shows how it is addressed.

2. Colorado SB 26-189 in brief

SB 26-189 was signed on May 14, 2026 and takes effect January 1, 2027. It replaces the 2024 Colorado AI Act (SB 24-205) and regulates automated decision-making technology, meaning technology that processes personal data and uses computation to produce an output that makes or materially influences a consequential decision. Financial and lending services is an enumerated consequential-decision category, and deposit account eligibility falls within it.

Three features of the statute matter most for account opening:

• It applies to banks and credit unions. The financial institution exemption that existed under the prior law was removed. Institutions cannot rely on prudential regulator oversight for an exemption.

• It carves out fraud and compliance controls. Technology used for fraud prevention, identity verification, anti-money-laundering and counter-terrorist-financing controls, and sanctions screening is expressly outside scope. A significant part of the account-opening path, including identity verification and watchlist screening, sits inside these carve-outs.

• It recognizes existing consumer protection law. A creditor that complies with ECOA, Regulation B, and FCRA adverse action notice requirements is treated as satisfying the statute's notice and disclosure requirements for that same decision.

The statute assigns duties by role. Developers of covered technology must provide deployers with documentation covering intended uses, data categories, known limitations, and instructions for human review, must notify deployers of material changes, and must retain records for at least three years. Deployers must give consumers notice before automation influences a consequential decision, must provide a plain-language explanation within 30 days of an adverse outcome, must offer a path to correct inaccurate personal data and to request meaningful human review, and must retain records for at least three years. The Colorado Attorney General enforces the law; there is no private right of action, and a 60-day cure period applies before January 1, 2030.

This summary is provided for context and is not legal advice. Your counsel's reading of the statute governs.

3. How decisioning works on Glide

Understanding how Glide makes decisions is the foundation for everything else in this document, because the design itself answers most of the questions the statute asks.

Your rules, transparently applied

Glide's account-opening decision engine evaluates thresholds and conditions that your institution defines, reviews, and approves, applied to application data and third-party verification results. The engine itself is rule-based: it is not trained on member data and does not produce scores of its own. Some of the inputs those rules evaluate are model-derived and can change as the underlying vendor data changes, such as Plaid identity verification results and ChexSystems/QualiFile risk data. Glide documents each of these inputs, and the rules that act on them remain fully visible to your institution: Glide can show you exactly what every configured rule does.

A human confirms every outcome

Automation on Glide routes applications; people decide them. Three controls make that concrete:

• Auto-approvals are confirmed by staff. An application is auto-approved only when it passes every rule your institution has configured, and every auto-approval is then confirmed by an institution staff member using Glide's confirm approval feature before it is finalized.

• Auto-denial is off unless you ask for it. Auto-denial rules are configured only at an institution's request, and most institutions on Glide do not enable them. Where they are enabled, staff can always reverse an auto-denial and decide the application manually.

• Everything else goes to a person. Applications that do not clearly pass route to the Pending queue, where your staff review the application and its supporting reports with full authority to approve, deny, or override. Business and trust applications always route to human review.

Third-party inputs are mapped, not hidden

Some inputs to your rules come from third-party services: ChexSystems/QualiFile deposit risk data, Plaid identity verification and fraud risk checks, watchlist and sanctions screening, and credit bureau data where credit-report decisioning is enabled. Glide documents what data is sent to each vendor and what output is consumed, and identifies which of these sit inside the statute's fraud-prevention, identity-verification, and sanctions carve-outs. Appendix A classifies every component.

4. Roles under the statute

SB 26-189 assigns different duties to the developer of covered technology and the deployer that uses it for consequential decisions. On the Glide platform the split is clean: Glide builds and operates the engine; your institution authorizes the rules and owns the decisions.

5. How Glide addresses each requirement

5.1 Developer documentation

What the law requires: Developers must provide deployers with documentation covering the technology's intended uses, the categories of data it uses, known limitations, and instructions for appropriate use and human review.

This document is that documentation. It describes what Glide's automation is for (routing and decisioning deposit account applications under institution-approved rules), what data it uses (application data and the third-party verification results listed in Appendix A), its boundaries (Glide's account-opening product does not make lending decisions, which are handled by your loan origination system, and applies no post-opening account restrictions), and how human review works (Section 3 and Section 5.5).

Beyond this general document, Glide produces a Decisioning Rule Specification for your institution on request: every configured rule, its inputs, its trigger condition, and its action, scoped to your live instance. Together, the two artifacts give your compliance team and your examiner a complete picture of the automation in your account-opening path.

5.2 Record retention

What the law requires: Developers and deployers must retain records sufficient to demonstrate compliance for at least three years from the decision.

Glide retains decision records for a minimum of three years and, in practice, does not delete data at all unless your institution instructs us to. Your three-year deployer obligation is met by default on the platform, with no configuration required.

5.3 Reconstructing any decision

What the law requires: The 30-day explanation duty and the record-keeping duty together mean a deployer must be able to show why a decision came out the way it did.

Every application on Glide carries an Activity Trail: a chronological, append-only record of everything that happened to it. It captures status changes and the selected deny reason, the checks that ran, pending reasons, the staff actor and timestamp on every action, overrides with their written justifications, disclosure acceptance with IP address and device details, member blocks, rescinds, and core synchronization attempts.

An auto-approval means the application passed every rule your institution configured, and the Activity Trail shows each check that ran; a staff member then confirms the approval. Where your institution ever needs more detail than the Activity Trail and the documents Glide provides, complete underlying decision logs are available from Glide on request. There is no decision on the platform that cannot be reconstructed.

5.4 Pre-use notice to consumers

What the law requires: Deployers must give consumers clear notice before automated decision-making technology is used to make or materially influence a consequential decision about them.

Glide provides the applicant-facing surfaces where your counsel-approved notice text is displayed: the Disclosures page, which captures acceptance with IP address, device, browser, operating system, and timestamp, plus the Preferences, Eligibility, and Additional Questions pages where additional text can be placed. Because the notice can simply be shown to every applicant, no state-by-state targeting is needed: Colorado applicants are always covered.

Your institution supplies the text it is comfortable with, on advice of counsel; Glide places it, displays it, and permanently records each applicant's acceptance.

5.5 Adverse-outcome explanation

What the law requires: Within 30 days of an adverse consequential decision, deployers must give the consumer a plain-language explanation of the decision. The statute treats compliance with ECOA, Regulation B, and FCRA adverse action requirements as satisfying its notice and disclosure duties for that same decision.

Glide delivers this through the adverse action notice framework the industry already trusts. Adverse action notices can be configured for any denial reason your institution uses. By default, Glide automatically generates and sends an adverse action notice whenever an FCRA denial reason is used, such as a ChexSystems denial. Deny reason lists are configurable per institution, so the explanations your applicants receive are the ones your compliance team has approved.

Because SB 26-189 expressly recognizes ECOA and FCRA adverse action compliance, an institution using Glide's adverse action notices is using the exact mechanism the statute points to.

5.6 Meaningful human review and reconsideration

What the law requires: Consumers must have a path to request human review and reconsideration of an adverse automated outcome, performed by a person with authority to change the decision.

Override authority is complete on Glide. Staff decide every pended application. Staff can reverse an auto-denial and decide the application manually. Failed fraud, identity, watchlist, document, and verification checks can be overridden, and every fraud override requires a written reason that is recorded in the Activity Trail and surfaced in the Fraud Override Report with the staff member's name, the failed checks, the justification, and the date. And because auto-denial rules exist only where an institution has requested them, most Glide institutions have no automated adverse outcome to reconsider in the first place: an unsuccessful application was already reviewed by a person.

To make the consumer-facing path concrete, Glide recommends two operating practices, and supports both:

• Prepare your call center and branch staff to receive manual review requests. An applicant who calls or emails with the same information used to apply can be looked up immediately, and staff can review and re-decide the application from the dashboard.

• Put the review path in the notice itself. Glide recommends the adverse action email or letter include instructions for requesting a manual review, for example contacting the institution with the information used on the application so it can be located. Glide configures this into your notice template.

5.7 Correction of inaccurate personal data

What the law requires: Consumers must be able to have factually incorrect personal data used by the system corrected.

Institution staff can correct application data directly on the Glide dashboard, including name, date of birth, and identification details, and every edit is written to the Activity Trail with the actor and timestamp. Where a verification result needs to be re-run after a correction, re-verification paths exist within the application flow. The same manual-review channel described in Section 5.6 serves as the consumer's route to raise a correction: the applicant contacts your institution, staff locate the application, correct the data, and re-decide.

5.8 Notification of material changes

What the law requires: Developers must notify deployers of material updates or modifications to the covered technology.

Glide operates a formal, documented Change Management Policy covering the full development lifecycle, owned by Glide's CTO and reviewed annually. Every production change follows a standardized process: planning and risk assessment, stakeholder communication, testing in a staging environment that is strictly separated from production, code review by an engineer other than the author, documented authorization before deployment, verification in production, and post-change review. Changes are categorized by risk, from minor changes through hotfixes and emergency changes, each with defined controls, and rollback-ready backups are maintained at every deployment.

For decisioning specifically, nothing about your rules changes without your institution's request and approval, and configuration changes go through user acceptance testing before release. Stakeholders are notified when changes go live, and Glide maintains a public changelog of platform releases. Material changes to decisioning behavior are communicated to affected institutions directly.

5.9 Non-discrimination

What the law requires: The statute targets automated systems whose outputs produce biased or unlawful consequential decisions. Federal fair lending law, principally ECOA, governs the substance of credit and account decisions.

Glide's structural answer to discrimination risk is transparency. Every decision rule on the platform is institution-authored, so your rule set is the complete description of the decision logic Glide applies, and Glide supplies clear technical documentation of exactly how the technology works, including the third-party inputs your rules evaluate. Glide also provides decision-level data extracts so your compliance team can run whatever fair lending analysis your program requires.

Two points of context your compliance team should have:

• Sensitive variables are yours to weigh. The platform supports rule variables including applicant age and geography. Rules using these carry ECOA considerations, and Glide advises institutions to review them with compliance before enabling and to confirm periodically which are live. Glide will tell you exactly which variables are active in your instance as part of your rule specification. Note that field-of-membership eligibility rules are lawful statutory membership criteria, not the biased or unfair technology outputs SB 26-189 targets; credit unions enforcing a field of membership are not implicated by doing so.

• Lending decisions are out of Glide's path. Glide's account-opening product does not make loan decisions; final loan decisioning is handled by your loan origination system. Prequalification offers surfaced through Glide are informational and are not consequential decisions made by the platform.

6. What your institution should do, and how Glide helps

The statute leaves a small number of deployer actions that only your institution can take. Each one has a defined path on Glide.

Appendix A: Component inventory and classification

Every automated component in the Glide platform, its function, Glide's role, and its assessment under SB 26-189. Final legal classification is for your counsel; this inventory gives them the complete factual basis.

Qualifications

This document is not legal advice, and Glide offers no opinion on how SB 26-189 applies to any particular institution; that determination belongs to your counsel. Statements about platform behavior reflect Glide's product as of August 2026 and describe it generally; configuration varies by institution, and Glide will confirm the specifics of your live instance, including your Decisioning Rule Specification and active variables, on request through your digital program management team.

Glide aligns its generative AI program to the NIST AI Risk Management Framework, which is voluntary guidance rather than a certification.

This document serves as the developer documentation SB 26-189 requires technology providers to furnish to the institutions that deploy their systems. It describes intended uses, system behavior, data inputs, human review controls, and change management for the automated components of the Glide platform.