Finance · OSFI E-23GLBA
AI adoption with a defensible regulatory file.
On-premise open-weight models give credit unions, banks, and insurersbanks, credit unions, and insurers copilots and document pipelines whose every version is pinned, evaluated, and documented — a clean model-risk file for OSFI Guideline E-23, effective May 1, 2027a clean model-risk file for examiners, with GLBA safeguards satisfied by architecture — while member data never leaves the institution’s perimeter.
The problem
You can’t govern a model you don’t control.
OSFI Guideline E-23 — finalized September 2025, effective May 1, 2027 — brings AI and machine learning squarely into model risk management for federally regulated financial institutions. It demands an enterprise model inventory, lifecycle governance, documented validation, and controls proportional to model risk. Here is the structural conflict: a cloud AI API is a model that changes on the vendor’s schedule, behind an interface you cannot inspect. The version you validated last quarter may not be the version answering members today. That is not a governance gap you can paper over — it is the absence of the thing E-23 requires you to govern.
The GLBA Safeguards Rule makes financial institutions accountable for customer information across their entire service-provider chain, and examiners increasingly treat AI vendors as exactly that — another provider to risk-assess, contract with, and continuously monitor. Meanwhile the model behind the API changes on the vendor’s schedule, behind an interface you cannot inspect: the version your model-risk team validated may not be the version answering customers today.
Add the data problem — lending files, member records, and internal analytics flowing through third-party infrastructure with its own retention policies and legal exposure — and the institutional calculus is clear. The deadline pressure is real, but the deeper issue is structural: rented models cannot produce the documentation regulators are now asking for.
The architecture
Pinned, evaluated, documented — by construction.
Self-hosted open weights invert the governance problem. The model is a fixed artifact on your hardware: checksummed at download, pinned in production, and upgraded only when your own evaluation harness says the new release wins — with the old version retained for reproducibility. We deliver the harness, the validation records, and the change-management documentation as part of the deployment, structured for your second line of defence.
The working bench: GLM-5.2 as the copilot and document-processing workhorse, DeepSeek-class models for overnight batch analytics at zero marginal cost. Member data, lending files, and internal analytics stay entirely inside the institution’s perimeter — SSO, role-based access, full audit logging, zero third-party API calls.
Deployment blueprint
The credit unionregional bank, on paper.
A prairie credit unionregional institution deploys a member-service copilot and document pipeline on owned hardware — every model version pinned, evaluated, and documented into a clean E-23model-risk file. Read the full reference architecture.
Read the financial services blueprintQuestions we get
Frequently asked questions
What does OSFI Guideline E-23 require for AI models?
OSFI Guideline E-23 (Model Risk Management, finalized September 2025, effective May 1, 2027) requires federally regulated financial institutions to maintain an enterprise-wide model inventory, lifecycle governance, documented validation, and risk-rated controls for models — explicitly including AI and machine learning. A model you cannot pin, inspect, or re-validate is a model you cannot govern. On-premise open-weight deployment gives you a fixed artifact: pinned weights, documented evaluations, and version control that satisfies the lifecycle requirements by construction.
Why is a cloud AI API hard to defend in a model-risk file?
Because the model changes under you. Cloud providers update, deprecate, and silently adjust models on their own schedule — which means the version you validated is not the version in production, and your validation documentation is stale the moment the vendor ships an update. Self-hosted weights are pinned: the model you validated is byte-for-byte the model serving members, until you decide to upgrade and re-validate.
How does this address GLBA and customer data safeguards?
The GLBA Safeguards Rule requires financial institutions to protect customer information across their service-provider chain. An on-premise deployment removes the AI vendor from that chain entirely: customer data, lending files, and internal analytics never leave the institution’s perimeter, so there is no third-party AI processor to assess, contract with, or monitor.
What workloads justify the hardware for a mid-sized institution?
The typical bench is a member-service or staff copilot, document processing for lending and onboarding, and overnight batch analytics. A single-rack GLM-5.2 deployment serves those workloads for a mid-sized institution, with DeepSeek-class models handling high-volume batch reasoning. Break-even against metered APIs arrives around two million tokens per day — a threshold institutional workloads pass quickly.
Can the deployment be examined by our regulator or auditors?
Yes — that is the point. Every component is inspectable: pinned model versions, training and fine-tuning records, evaluation harness results, access logs, and change management. We deliver the model-risk documentation alongside the deployment, structured so your second line and your examiners can trace every model decision.
Go deeper
OSFI E-23 AI compliance
What the guideline requires and why May 2027 is closer than it looks.
The CLOUD Act and Canadian data
Why a Canadian cloud region run by a US provider isn’t sovereignty.
What on-premise LLM deployment costs
Hardware tiers, and the ~2M tokens/day break-even against APIs.
Deploy GLM-5.2 on-premise
The single-rack copilot workhorse: 744B MoE, 40B active, MIT.
Deploy DeepSeek on-premise
Cost-efficient reasoning for high-volume batch analytics.
Hosting & maintenance retainer
Evaluations, migrations, and documentation as models evolve.
Build the model-risk file before the deadline builds it for you.
The two-week sovereignty assessment maps your data classes, E-23 and safeguards obligations, and workloads — and hands you a written architecture with a real cost model.
Book a sovereignty assessment