Canadian dealers and advisers must assess the securities they make available, approve them before clients can buy them, and monitor them for significant changes.[1] Their registered individuals must understand the structure, features, risks and costs of what they recommend.[2] And in their December 2025 review, Canadian regulators found that "annual monitoring alone was not found to be sufficient."[3]
That has pushed many firms to look for a system that does more than they can do with spreadsheets and annual reviews. The difficulty is that "KYP system" means very different things to different vendors. Some tools detect changes in fund data. Some compare products for advisors. Some manage disclosures or supervision. Few cover the whole job, and an RFP written around one vendor's feature list will miss what the others leave out.
This blueprint sets out what an end-to-end KYP system should do, and what an RFP needs to ask for to find out whether a platform does it. It covers the capabilities that make up the whole job; requirements for data, AI, securities coverage, workflow, advisors and supervision, reporting, infrastructure and user experience, each with RFP questions; how to decide what to buy and what to build; a scoring model; proof-of-concept scenarios; and red flags.
The requirements are written so a firm can lift them directly into its own RFP. Priorities are marked Must (a firm without it will have a gap it has to fill some other way) or Should (valuable, but a firm can work around it).
An end-to-end KYP system covers the life of every product, from the documents that describe it to the evidence that the firm understood it.
Each step depends on the one before it. A system that monitors well but can't show how the product was approved leaves the firm unable to say what it is monitoring against. A system that approves well but can't reach advisors leaves the firm's knowledge stuck at head office.
Platforms sold into the Canadian market for KYP tend to start from one part of the job and extend outward. Understanding where a platform started helps predict where its gaps will be.
| Platform Type | Where It Starts | Typical Strengths | Where Gaps Often Appear |
|---|---|---|---|
| Change detection tools | Fund data feeds | Frequent monitoring of fund attributes; configurable materiality thresholds; alerts | Assessment and approval workflow; primary documents; securities beyond funds and ETFs |
| Advisor sales and proposal platforms | Proposals and product comparisons | Advisor experience; off-shelf warnings; acknowledgements | Head-office due diligence; how changes are detected; depth of product analysis |
| Compliance and supervision suites | Compliance, disclosure and supervision | Supervisory dashboards; audit trails; disclosure delivery; product risk ratings | Depth of product assessment; complex products; primary document analysis |
| Research and data providers | Ratings, research and data | Broad data coverage; analyst research; comparison tools for advisors | Firm-specific approval and shelf governance; linking alerts to the firm's own holdings and advisors |
None of these is a criticism. Each type does its own job well. The point for a buyer is that most firms will either choose one platform and fill its gaps, or combine several. Either way, the RFP needs to test every capability, not just the ones a given vendor leads with. A firm that assembles several tools also needs to ask how they connect: a change detected in one system is of little use if the approval record lives in another and the advisor acknowledgement in a third.
Each area below sets out what to look for, then the questions to put in the RFP. Ask vendors to show, not describe: every Must requirement should be demonstrated on the firm's own products.
Data is the requirement most often under-specified, and the one that decides everything else. A system can only detect changes in what it reads. If it reads a data feed of fund attributes, it will catch a fee change in the feed. It won't catch a new risk factor added to a prospectus, a change in redemption terms in an offering memorandum, or an amendment that the feed doesn't carry.
Canadian regulators have said third-party reports can support a firm's KYP work, but firms should document their own analysis.[3] A system built only on third-party summaries makes that harder.
| Ref | Requirement | Ask the Vendor | Priority |
|---|---|---|---|
| D1 | Reads primary documents: Fund Facts, ETF Facts, simplified prospectuses and amendments, annual information forms, MRFPs, financial statements, offering memoranda, term sheets and pricing supplements, and regulatory filings | Which document types do you read directly? From which sources? Show a change detected from a document rather than a data feed. | Must |
| D2 | Uses structured market and reference data for prices, holdings, ratings and identifiers | Which data providers do you use? Can the firm bring its own licences? | Must |
| D3 | Every data point traceable to its source document or feed, with date | Show the source for any value on screen, in one click. | Must |
| D4 | Stores a fixed copy of each document version used | If an issuer replaces a document online, can you show the version you used? | Must |
| D5 | Maps every identifier (FundSERV code, CUSIP, ISIN, ticker) down to series or share class | How do you handle series, share classes, mergers and name changes? | Must |
| D6 | Stated freshness for each data type | How quickly after filing is a document read? How often is each data type refreshed? | Must |
| D7 | Reports missing or stale data as a gap, never as "no change" | What happens when a source is unavailable? Show the result. | Must |
| D8 | Handles scanned and poorly formatted documents | What is your accuracy on scanned term sheets and offering memoranda? | Should |
| D9 | French-language documents | Do you read French documents, and at what accuracy? | Should |
AI is what makes reading primary documents at scale practical. It is also where a buyer needs to be most careful. Canadian securities regulators expect AI systems to be fit for purpose, tested before and after adoption, and explainable enough for the firm to meet its record keeping requirements.[4] Firms inside bank or insurance groups will also need AI tools to fit their group's model risk framework.[5]
The single most useful test of an AI-driven KYP system is whether every output is tied to its source. An AI that summarizes a prospectus is only useful if the reviewer can check each statement against the page it came from.
| Ref | Requirement | Ask the Vendor | Priority |
|---|---|---|---|
| A1 | Every AI output cites its source document, page or data point | Show an AI-generated product summary with sources for each statement. | Must |
| A2 | Outputs without a source are flagged, not presented as fact | What happens when the AI can't find support for a statement? | Must |
| A3 | Validation results available, broken down by document and product type | Provide your accuracy results for extraction and change detection, by document type. | Must |
| A4 | The firm can run its own test set | Can we test the system against documents where we already know the answers? | Must |
| A5 | Model, prompt and configuration versions recorded on every output | Would we know which model version produced a given output a year from now? | Must |
| A6 | Advance notice of model changes, with a test period | How and when do you notify clients of model changes? | Must |
| A7 | AI does not approve products or change product status | Which actions can the AI take without a person? | Must |
| A8 | Reviewer corrections captured and fed into monitoring | How are corrections recorded, and do they change the model's behaviour for our firm? | Should |
| A9 | Firm data not used to train shared models without consent | Is our data used to train models used by other clients? | Must |
Coverage is often described as a list of asset classes. That isn't enough. A system that "covers structured products" may hold the issue terms but not watch barrier levels or issuer credit. The RFP should ask what is monitored for each type, not just whether the type is in the system.
| Product Type | What an End-to-End System Should Monitor | Priority |
|---|---|---|
| Mutual funds | Fees and series, manager and sub-advisor changes, mandate and strategy changes, risk rating, mergers and terminations, fund size and flows, performance against category | Must |
| ETFs | All of the above plus tracking difference, premium or discount to NAV, liquidity, index changes, leverage or inverse features | Must |
| Segregated funds and annuities | Guarantee levels and resets, fees including guarantee fees, underlying fund changes, insurer financial strength, contract changes | Must, if offered |
| Equities | Corporate actions, credit and ratings changes, regulatory filings, price and volatility events, trading halts | Must |
| Fixed income | Credit ratings, issuer events, call and redemption features, liquidity | Must |
| Structured products | Barrier and call levels against the underlying, observation dates, issuer credit, estimated value, secondary market availability | Must, if offered |
| Alternative mutual funds | Leverage, short exposure, strategy drift, liquidity, fees including performance fees | Must, if offered |
| Private and exempt-market funds | Redemption gates and queues, valuation frequency and lag, leverage, key person events, service provider changes, audited statements | Must, if offered |
| Managed and model portfolios | Changes to underlying holdings, model changes, drift from stated strategy, overlay manager changes | Should |
Ask for a coverage map. Request the vendor's list of every product on the firm's current shelf, with what the system can monitor for each. Gaps found now are cheaper than gaps found after launch.
Canadian regulators expect approval records to show "meaningful consideration" of the elements assessed, and where firms rely on algorithmic models, evidence of ongoing oversight.[3] The workflow is where that evidence is created.
| Ref | Requirement | Ask the Vendor | Priority |
|---|---|---|---|
| W1 | Product assessment templates by complexity tier, covering structure, features, risks, costs and parties | Show the assessment for a complex product. Can we set our own templates and tiers? | Must |
| W2 | Cost comparison against approved alternatives | How is cost compared, and against what? | Must |
| W3 | Approval workflow with named reviewers, committee sign-off, conditions and rationale | Walk through an approval from request to decision. | Must |
| W4 | A single product register at series level, with defined statuses (approved, watch, restricted, suspended, wind-down, removed) | Can status changes flow to order entry to block or flag purchases? | Must |
| W5 | Configurable monitoring rules with thresholds, severity and owners | Can compliance change a rule without a vendor release? Is every rule change logged? | Must |
| W6 | Alert routing by severity to product, supervision and the advisors who hold the product | Show an alert reaching the advisors whose clients hold the product. | Must |
| W7 | Noise control: grouping, deduplication and settle periods | What is the typical number of alerts per product per month? How do you prevent duplicates? | Must |
| W8 | Product review workflow from alert to decision, with defined outcomes and timeframes | Show an alert being triaged, reviewed, decided and closed. | Must |
| W9 | Holdings mapping to the register, with exceptions for unmatched and off-shelf positions | How do you match client holdings to the shelf? How are transferred-in products handled? | Must |
| W10 | Removal and wind-down plans tracked to the last position | How is a product removal managed and tracked? | Should |
The firm's approval of a product doesn't replace each advisor's own obligation to understand it.[2] A KYP system should support that obligation directly, and give supervisors a view of who has kept up.
| Ref | Requirement | Ask the Vendor | Priority |
|---|---|---|---|
| S1 | An advisor view of alerts, product statuses and the products held in their book | Show what an advisor sees when they log in. | Must |
| S2 | Plain-language product summaries, updated after every review decision, with sources | Who writes summaries, and how quickly are they updated? | Must |
| S3 | Acknowledgement of product decisions, tracked by advisor | Show acknowledgement tracking and escalation for an overdue advisor. | Must |
| S4 | Advisor product notes, in the advisor's own words, kept with the product | Can advisors record product notes? Are they kept separately from client files? | Should |
| S5 | Annual product-by-product attestation against a book list the system produces | Can the system generate each advisor's book list and record attestations product by product? | Should |
| S6 | Training conditions linked to products | Can a product be restricted to advisors who have completed training? | Should |
| S7 | Supervisory dashboards and exception reports: overdue reviews, overdue acknowledgements, purchases in suspended products | Show the supervisor's daily view. | Must |
| S8 | Escalation rules applied automatically | Can escalations be configured and recorded? | Should |
When a regulator asks how the firm meets its KYP obligations, the answer should be a report the system produces, not a file assembled by hand. Canadian regulators also expect policies to describe automated systems in detail,[3] so the vendor's documentation matters as much as its reports.
| Ref | Requirement | Ask the Vendor | Priority |
|---|---|---|---|
| R1 | Complete audit trail: every assessment, approval, alert, review, decision, notice, acknowledgement and status change, with user and time | Can records be altered after the fact? Show the audit trail for one product. | Must |
| R2 | State of the program as at any past date | Show the shelf, product statuses and open alerts as at a date six months ago. | Must |
| R3 | Product file export: full history of one product in one document | Produce the full file for a product we name. | Must |
| R4 | Program metrics: monitoring coverage, holdings match rate, review timeliness, acknowledgement rates, exceptions | Which program metrics are available out of the box? | Must |
| R5 | Regulatory exam pack generated from the system | What would you produce for a regulatory exam of our KYP program? | Should |
| R6 | Vendor documentation detailed enough for the firm's policies | Provide the documentation you would give us to describe your system in our policies. | Must |
| R7 | Retention for the firm's required period, with export on exit | How long are records kept? In what format can we take them if we leave? | Must |
| R8 | Scheduled and ad hoc reports for committees and senior management | Show a committee report and a senior management summary. | Should |
| Ref | Requirement | Ask the Vendor | Priority |
|---|---|---|---|
| I1 | Canadian data residency for firm and client data | Where is our data stored and processed, including by AI services and subprocessors? | Must |
| I2 | Independent security assurance, such as a SOC 2 Type II report | Provide your latest report and any exceptions noted. | Must |
| I3 | Single sign-on and role-based access | Which identity providers do you support? How are roles defined? | Must |
| I4 | Integration with back office, order entry and holdings sources | Which back-office systems have you integrated with? How is status sent to order entry? | Must |
| I5 | APIs and data export | Which data and events are available by API? | Must |
| I6 | Integration with CRM and advisor desktops | Can alerts and summaries appear in the advisor's existing tools? | Should |
| I7 | Availability, support and incident commitments | What are your uptime commitment, support hours and incident notification terms? | Must |
| I8 | Business continuity and exit plan | What happens to our records and monitoring if you are acquired or stop operating? | Must |
| I9 | Subprocessors, including AI model providers, disclosed | List your subprocessors and where they operate. | Must |
A KYP system has at least four kinds of user: product analysts, committee members, advisors and supervisors. Each needs something different, and a system designed for one often frustrates the others. The best test is time: how long does it take each user to do their most common task?
| Ref | Requirement | Ask the Vendor | Priority |
|---|---|---|---|
| U1 | Role-based views for analysts, committees, advisors and supervisors | Show each role's home screen. | Must |
| U2 | An advisor can clear their daily alerts in minutes | Time an advisor clearing a typical day's alerts. | Must |
| U3 | Any answer about a product traceable to source in one or two clicks | Starting from an alert, how many clicks to the source document? | Must |
| U4 | English and French interfaces | Is the full interface available in French? | Must, where required |
| U5 | Accessibility to a recognized standard, such as WCAG 2.1 AA | Which accessibility standard do you meet? | Should |
| U6 | Usable on tablet and mobile for alerts and summaries | Show alerts and summaries on a phone. | Should |
Requirements tell vendors what to answer. The process around them decides whether the answers can be trusted.
No platform removes the firm's own work. The RFP should make clear what the firm expects the vendor to supply, and what the firm will configure or build itself.
| Component | Vendor Should Supply | Firm Configures or Builds |
|---|---|---|
| Data and documents | Collection, reading and storage of documents and data; source links | Any proprietary or private product documents not publicly available |
| Monitoring rules | A starting rule library by product type | Thresholds, severity and owners that match the firm's risk appetite |
| Assessment and approval | Templates and workflow | Complexity tiers, committee structure, approval authorities |
| Product register | The register and status model | The firm's shelf, conditions and status-to-order-entry connection |
| Advisor content | Summaries with sources | Firm-specific guidance and training requirements |
| Policies and procedures | Detailed system documentation | The firm's written KYP policies, referencing the system |
| Integrations | APIs and standard connectors | Connections to the firm's back office, order entry and CRM |
| Oversight | Validation results and change notices | The firm's own testing, supervision and vendor oversight |
Any Must requirement a vendor can't meet should be scored as a gap the firm will have to fill, with its cost added to the vendor's price. The weights below are illustrative; firms should set their own before responses arrive, not after.
| Area | Illustrative Weight | Why |
|---|---|---|
| Data and securities coverage | 25% | Decides what the system can see at all |
| Workflow | 20% | Where the firm's evidence is created |
| AI and explainability | 15% | Decides whether outputs can be relied on and defended |
| Reporting and documentation | 15% | Decides whether the firm can prove what it did |
| Advisors and supervision | 10% | Carries knowledge to where recommendations are made |
| Infrastructure and security | 10% | Must requirements here are usually pass or fail |
| User experience | 5% | Tested directly in the proof of concept |
Score cost separately, over at least three years, including the firm's own configuration, integration and ongoing oversight work, and the cost of filling any gaps.
Demonstrations on a vendor's chosen examples show what a system can do at its best. Scenarios on the firm's own products show what it will do in practice. Give each shortlisted vendor the same material and the same time.
| If the Vendor Says | Ask |
|---|---|
| "We cover all asset classes" | What do you monitor for each one, on our shelf specifically? |
| "Our AI reads every document" | Show your accuracy by document type, and let us test it. |
| "You'll never miss a change" | What happens when a source is unavailable? What is your missed-change rate on known changes? |
| "The approval workflow is configurable" | Show us an approval with committee sign-off configured for our structure, today. |
| "Everything is audited" | Show the program as at a date six months ago. |
| "It's on the roadmap" | Score it as not available. Ask for the date in the contract if it matters. |
| "Our data provider handles that" | Which provider, what is refreshed and how often, and who is accountable when it is wrong? |
A firm can buy a system. It can't buy its way out of its KYP obligations. The selection itself should be run so that the firm can later show why the system it chose is fit for the job.