OSFI Guideline E-23 takes effect May 1, 2027 and defines a model broadly enough to pull AI assistants used in fraud and AML work into scope. If analysts rely on an AI copilot to make or support decisions, the institution owes the same governance package it owes for any other material model: inventory, validation, monitoring, change control, and audit trail.
Why AI assistants are models under E-23
E-23 defines a model as 'an application of theoretical, empirical, judgmental assumptions or statistical techniques, including AI/ML methods, which processes input data to generate results.' An AI assistant that reads transaction records and produces investigation outputs that an analyst acts on fits that definition cleanly.
The key test is not whether the AI assistant is called a 'model' internally, it is whether its outputs feed into decisions the institution is responsible for. For a fraud copilot in a bank, the answer is yes.
Materiality: fraud and AML copilots are rarely low-risk
E-23 asks institutions to tier models by risk. Models supporting customer-impacting decisions, regulatory reporting, or fraud and AML outcomes default toward higher materiality. A copilot drafting SAR narratives, triaging alerts, or scoping cases will almost always land in the material tier.
Tiering drives the depth of validation, documentation, and monitoring required. Material AI assistants need model cards, independent validation evidence, drift monitoring, and incident response playbooks on file.
The explainability requirement
A material AI model under E-23 needs documented explanations of how its outputs are produced. For a fraud copilot that means more than 'we use an LLM.' The evidence package should cover: what data the model reads, how retrieval is scoped, how reasoning is constrained, how the model's answers are grounded in records, how analysts verify answers, and how edge cases are handled.
A grounded AI assistant has an advantage here. Because its answers cite the records they come from, the explanation includes a verifiable trail. A generic chatbot that produces free-form answers has no such trail and will struggle under second-line review.
Audit trail and monitoring
Every conversation with the copilot, every record it accessed, and every output an analyst used should be logged in a way that supports later review. If the model answers 100 questions a day and 95 of those answers inform case decisions, those 95 need to be reviewable by second-line defence and by examiners.
Monitoring should cover accuracy drift (are answers staying grounded), usage drift (are analysts using it in new contexts), and incident flags (where did the copilot answer wrong, and how was that caught).
The vendor cascade
If the AI copilot is from a third-party vendor, the institution still owns the model risk. The vendor must produce an E-23 evidence package that the bank's second-line team can ingest into its own inventory: model card, validation report, monitoring dashboards, data lineage, change control, and incident response.
UMCA ships AI Navigator with this evidence package by design. It is not a bolt-on, it is how the product is built. The audit trail, access logs, grounding records, and governance documentation are available to the bank's model risk team on day one.
