Material Change

Created: September 26, 2026 · Updated: September 26, 2026 · Author: Richard Owen, President and CEO, Buckler · Reading time: ~20 min · Jurisdiction: Canada, United States

Role Product & Due Diligence Compliance & Supervision

Stage Material Change

Regulator CIRO CSA

Series Product Series, Part 2

Overview

Every firm that offers investment products has to monitor them for material change, which Canadian rules call significant change. The rules that require it are covered elsewhere in this library. This guide is about how it actually works: the machinery that turns a written policy into a daily check on every product, and a check into an alert that reaches the right person.

That machinery has three parts. Rules say precisely what counts as a change worth looking at. An engine runs every rule against every product on a schedule and records what it found. Alerts carry the result to the people who have to act, at a volume they can actually handle. Each part can fail on its own, and a weakness in any one of them undoes the other two.

This is the second of five guides in the Product series. It follows Product Approval, which covers how products get onto the shelf, and sets out how to write monitoring rules, how a monitoring engine runs, and how to design alerts, with worked examples, responsibilities for the firm and the advisor, and an example written process. The next guide, From Alert to Decision, picks up where an alert is raised.

For the regulatory basis, see Material Change: When to Reopen a KYP Assessment and Canada vs US: KYP Standards Compared. For testing the data behind the engine, see Auditing KYP Monitoring Data.

Part One

The Rules

A policy says "monitor for significant changes." A system needs something much more specific: which number, compared to what, how often, and what happens when it crosses a line. Canadian regulators found that many firms had monitoring in place but no definition of what a significant change was.[1] Writing the rules is how that gap gets closed.

Specification

Anatomy of a Rule

The fields every monitoring rule needs before a system can run it

A rule is complete when someone who didn't write it could implement it without asking a question. That takes more fields than most policy documents record.

Field	What It Specifies	Example
Rule ID and name	A stable identifier that never changes, even when the rule does	MF-07 Management Fee Increase
Scope	Which products the rule applies to	All mutual fund series on the shelf or held
Type	Threshold (a number crosses a line) or event (something happens)	Event
Metric or event	The exact data field or event being tested	Management fee rate for the series
Data source	Where the value comes from, and a fallback	Fund data vendor; fund amendment filings as fallback
Comparison basis	What the value is compared to: a fixed level, the product's own history, or a peer group	The series' own prior value
Condition	The precise test that constitutes a breach	Current rate is higher than the prior recorded rate
Window	The period the metric is measured over, if any	Not applicable
Frequency	How often the rule is evaluated	Daily, and on every new filing
Severity	The level the alert is raised at	Important
Settle window	How long a reviewed breach stays closed before it can alert again, and what reopens it early	Closed until the fee changes again
Missing-data behaviour	What happens if the value can't be obtained	Record "could not evaluate" and route to data owner
Owner	The person or committee accountable for the rule	Product Committee
Version and effective date	So every alert can be tied to the rule in force when it fired	v2.1, effective 2026-07-01

Two fields are left out more than any others. Comparison basis decides whether a rule finds products behaving differently from their peers or just catches every market move; see the discussion of relative thresholds in Monitoring for Material Change. Missing-data behaviour decides whether a gap in the data is visible or silently counted as a pass.

Examples

Worked Examples

Rules across asset classes, and one written out in full

The rules below show how threshold and event rules look when written to the specification above. The thresholds are illustrations of the mechanics, not recommended settings; each firm should calibrate its own.

Rule	Type	Condition	Frequency	Severity
EQ-01 Dividend Cut	Event	Declared dividend per share is lower than the prior declaration	On each declaration	Critical
EQ-04 Relative Drawdown	Threshold	Price decline from 12-month high exceeds the sector's decline by more than 20 percentage points	Daily	Watch
MF-03 Quartile Drop	Threshold	Three-year peer-category quartile falls by one or more quartiles	Monthly	Important
MF-07 Management Fee Increase	Event	Management fee rate for any series increases	Daily and on filings	Important
MF-11 Portfolio Manager Change	Event	Named lead portfolio manager changes	Daily and on filings	Critical
ETF-02 Tracking Difference	Threshold	Rolling 12-month tracking difference is worse than the category median by more than 0.50%	Monthly	Watch
ETF-05 Closure Notice	Event	Issuer announces termination, delisting or merger	Daily	Critical
SP-04 Barrier Proximity	Threshold	Worst-performing underlying is within 10% of the barrier level	Daily	Important (Critical within 5%)
ALT-02 Audit Overdue	Event	Audited financial statements not received within the period set in firm policy after fiscal year-end	Daily	Critical
ALT-05 Redemption Gate	Event	Redemptions suspended, gated or terms changed	Daily and on notices	Critical

Written out in full, a single rule looks like this:

Rule Specification: SP-04 Barrier Proximity

Illustrative

Scope

All outstanding structured notes with a barrier or buffer feature, on the shelf or held in client accounts.

Type

Threshold.

Metric

For each note, the closing level of each underlying divided by its barrier level, minus one. For worst-of notes, the lowest result across underlyings.

Source

Barrier levels from the note's pricing supplement, recorded in the product register at issue. Underlying closing levels from the market data vendor.

Condition

Distance to barrier of 10% or less raises an Important alert; 5% or less escalates it to Critical; any breach of the barrier raises a separate event alert (SP-05).

Frequency

Daily, after market close.

Settle window

Once reviewed, the alert stays closed while the note remains in the same band. Moving into a closer band reopens it immediately.

Missing data

If any underlying level or the barrier level is unavailable, record "could not evaluate" and route to the data owner the same day.

Owner

Structured Products Committee. Version 1.3, effective 2026-07-01.

For the product-specific triggers behind these examples, see the Investment Monitoring guides for equities, mutual funds and ETFs, structured products, segregated funds and annuities, model portfolios and alternatives and private markets.

Pitfalls

Rule-Writing Mistakes

The errors that make a rule set look complete when it isn't

A threshold with no comparison basis. "Returns fall significantly" can't be coded. "Trailing one-year return is more than 5 points below the peer-category median" can.
A frequency faster than the data. Checking a quarterly-reported number daily produces nothing but repeated results; the rule's frequency should match how often its data actually changes.
A frequency slower than the risk. The same logic in reverse: a daily-moving risk checked monthly will be noticed late.
Everything is Critical. If most rules are Critical, the label stops meaning anything. Severity should reflect what the firm must do in response, not how important the rule-writer felt the metric was.
Only thresholds. The most consequential changes - a manager leaving, a redemption gate, a fee change - are events. A rule set built only from market data misses them.
No missing-data behaviour. Without it, a product whose data stopped arriving looks exactly like a product with nothing to report.
Rules edited in place. Without versions, no past alert can be tied to the rule that raised it.

Part Two

The Engine

The engine is whatever runs the rules - a vendor platform, an in-house system, or in small firms a well-controlled spreadsheet process. Its job is the same regardless: evaluate every rule against every product on schedule, and leave a record that it did.

Process

The Daily Loop

Eight steps from data to record

Load the Population

Every product on the shelf and every security held in client accounts.

Refresh Data

Pull market, fund, issuer and event data for each product.

Validate Data

Check completeness and staleness before any rule runs.

Evaluate Rules

Run each applicable rule version against each product.

Compare to State

Check each result against open alerts and settle windows.

Create or Update Alerts

Open new alerts, escalate existing ones, group related ones.

Route

Send each alert to the product committee, advisors or data owner.

Write the Record

Store every evaluation, including the ones that found nothing.

Step 1 decides what the engine can see: a product missing from the population is never evaluated at all. Step 3 decides whether the engine can be trusted; see Auditing KYP Monitoring Data. Step 8 is what turns monitoring into evidence. Canadian regulators found firms that had current information on file but no evidence it was reviewed,[1] and expect firms that use automated systems for KYP to describe those processes in detail in their written policies.[1]

States

Four Outcomes, Not Two

Every evaluation should end in one of four recorded states

A simple engine records "breach" or "no breach." That isn't enough. Every evaluation should end in one of four states, each recorded:

State	Meaning	What Happens Next
Breached	The rule's condition was met	An alert is opened, escalated or grouped
Cleared	The rule ran on valid data and the condition was not met	Recorded as evidence the product was checked
Suppressed	The condition was met, but a reviewed alert is inside its settle window	Recorded, not re-alerted; reopens if the break-through condition is met
Could not evaluate	Data was missing, stale or invalid	Routed to the data owner as its own exception

The fourth state matters most. An engine that quietly treats "could not evaluate" as "cleared" will report a clean shelf precisely when it knows least.

Sourcing

Build or Buy

What to weigh, whichever route a firm takes

Consideration	Questions to Ask
Coverage	Does it cover every product type the firm offers and holds, including alternatives, structured notes and transfers-in?
Rule flexibility	Can the firm write its own rules, with its own thresholds, comparison bases and severities, and version them?
Event detection	Does it detect events from filings and notices, or only thresholds from market data?
Evaluation states	Does it record cleared, suppressed and could-not-evaluate outcomes, not just breaches?
Reproducibility	Can it show what data and rule version produced any past result?
Workflow	Does it route alerts and record the review and decision, or only raise them?
Advisor view	Can advisors see alerts for the products they deal in, and record their response?
Oversight	Can the firm evidence that the system is functioning appropriately, and is the vendor subject to the firm's vendor oversight?

Whichever route is chosen, the firm remains responsible for the result. A vendor's platform can run the rules; it can't own the definition of what a significant change is for the firm's shelf.

Part Three

The Alerts

An alert is the point where the machine hands over to people. Designed well, it tells the right person exactly what changed and what they need to do. Designed badly, it becomes noise that everyone learns to clear without reading.

Content

Anatomy of an Alert

What every alert should carry so the recipient can act without searching

Field	Purpose
Alert ID and status	Unique reference; open, in review, closed or reopened
Product	Name, identifier, category and current shelf status
Rule and version	Which rule fired, in which version
What changed	The value before and after, or the event, with the date detected
Source	The data or document that met the condition, with a link
Severity	Critical, Important or Watch, and why
Exposure	How many advisors and accounts hold the product, and the total amount held
Required action and due date	What the recipient must do, and by when, set by severity
History	Previous alerts on the same product and rule, and how they were resolved

The last field is the one most often missing. A reviewer who can see that the same fund breached the same rule twice last year, and why each was closed, makes a better decision in less time.

Design

Severity and Routing

Deciding in advance who gets what, and how fast they must act

Severity should be defined by the response it requires, and routing should follow from severity. The matrix below uses the Critical, Important and Watch levels from The Continuous KYP Playbook: Who Does What. Timeframes are illustrative.

Severity	Goes To	Required Response	Illustrative Timeframe
Critical	Product committee; every advisor holding or offering the product; supervision	Product review and a recorded decision; advisors informed of the outcome	Review opened within 1 business day; decision within 5
Important	Product owner; advisors holding or offering the product	Documented assessment of the change; escalation if warranted	Assessment within 10 business days
Watch	Product owner	Noted and tracked; reviewed together at the next scheduled product review	By next scheduled review
Could not evaluate	Data owner	Fix the data or document why it can't be obtained	Within 3 business days

Volume

Controlling Noise

Four techniques that keep alerts meaningful

Group

Combine alerts for one product from several rules into a single case, so it's reviewed once.

Deduplicate

Update an open alert when the same condition persists, rather than opening a new one each day.

Settle

Keep a reviewed alert closed for a defined period, reopening only if the condition worsens.

Recognize Market Events

When many products breach at once because of a market move, raise one market-level case instead of hundreds of product alerts.

Each technique has a risk: grouping can hide a second problem, and settle windows can hold a worsening situation closed. The controls are the same for all four - write the logic down, record every suppressed result, and define the break-through conditions that reopen an alert immediately. A useful health check is the share of alerts closed with no action: if it's very high, the rules need recalibrating, not the reviewers.

Roles

Responsibilities and Written Process

Who does what, and what the firm writes down

What the Firm Needs to Do

Write complete rules. Every field in the specification, for every product type offered or held.
Own and version the rule set. A named committee approves changes; every version is kept.
Run the engine on the full population. Shelf and held securities, on each rule's schedule.
Record all four outcomes. Including cleared and could-not-evaluate.
Define severity by response. With routing and timeframes set in advance.
Control noise transparently. Grouping, deduplication and settle windows written down, with every suppressed result recorded.
Calibrate regularly. Review rules that never fire, always fire, or are closed without action.

What the Individual Advisor Needs to Do

Receive alerts for their products. Know where alerts arrive and check them on a set routine.
Act within the timeframe. Respond to Critical and Important alerts by their due dates.
Read the change, not just the flag. Understand what changed and what it means for the product.
Report what the engine misses. Tell the product owner about changes they learn of that didn't raise an alert.
Flag noise. Report alerts that are consistently irrelevant, so rules can be recalibrated.

Example: Written Process for Monitoring Rules and Alerts

Illustrative

Rule set. The Product Committee owns the monitoring rule set. Every rule is specified with the fields in the firm's rule template, including comparison basis, frequency, severity, settle window and missing-data behaviour.

Change control. New rules and changes are approved by the Committee, tested before deployment, and recorded as a new version with an effective date. Prior versions are retained.

Population. The monitoring system evaluates every product on the shelf and every security held in client accounts. The population is reconciled to the shelf register and holdings daily.

Evaluation. Each rule runs on its defined schedule. Every evaluation is recorded as breached, cleared, suppressed or could not evaluate, with the data used and the rule version applied.

Alerts. Breaches raise alerts carrying the product, rule, change, source, severity, exposure, required action, due date and history. Alerts are routed according to the severity matrix.

Noise controls. Grouping, deduplication, settle windows and market-level cases operate as documented in the rule set. Suppressed results are recorded and break-through conditions reopen alerts immediately.

Exceptions. Could-not-evaluate results are routed to the data owner and resolved or explained within three business days.

Calibration. The Committee reviews rule performance quarterly, including rules that never fire, rules that fire on most products, and alerts closed with no action.

Five Questions to Test Monitoring Mechanics

Could someone who didn't write a rule implement it from its written specification alone?
Does the rule set include event rules, not just market-data thresholds?
Does every evaluation end in one of four recorded states, including could not evaluate?
Does every alert show what changed, its source, the exposure, and its history?
Is alert volume reviewed and rules recalibrated, rather than left to reviewers to manage?

A note on scope: This guide describes practical approaches to building product monitoring. It is general information, not legal, compliance or technology advice. The rule fields, example rules, thresholds, severity matrix, timeframes and written process are illustrations, not recommended settings or prescribed requirements; each firm should design and calibrate its own. For the regulatory requirements behind monitoring, see the linked regulatory guides.

References

Joint CSA/CIRO Staff Notice 31-368, Client Focused Reforms: Review of Registrants' Know Your Client, Know Your Product and Suitability Determination Practices and Additional Guidance, December 10, 2025. Monitoring for significant changes, pp.16-18; KYP policies and procedures, including automated systems, p.34. Source document (PDF)