1. Executive Summary

Canadian Tire Bank needs to prove, with data, that its anti-money laundering (AML) program is effective. Since March 2026 that is the legal standard, and the penalties for falling short have risen sharply. This proposal describes how I would build and run the AML Intelligence Hub: one reporting-only database, fed by every AML source system, that powers a small set of role-based dashboards for the board, AML leadership, operations, the first line and audit.

The design is not theoretical. It adapts AIDA, a job-search platform I designed and built on my own. AIDA collects data from more than 50 sources in different formats, standardizes it into one PostgreSQL database, scores it with a single shared function, and publishes it through a separate, secure portal where each user sees only their own data. The AML Hub applies the same pattern to alerts, cases, customers, screening results and regulatory reports, on the bank's own Azure and Power BI platform.

The recommendation: start with an executive scorecard and an investigations dashboard in the first 90 days, built on a certified KPI dictionary and daily reconciled data, then add one capability every quarter.

2. The Business Problem

2.1 The regulatory bar has moved

Effectiveness is now the test. A compliance program must be “reasonably designed, risk-based and effective”. Failing that standard is a very serious violation.
Penalties rose up to 40 times. For violations after March 26, 2026, maximums reach $20 million per very serious violation, and FINTRAC can require compliance agreements and compliance orders.
Data is now under scrutiny. Recent enforcement against large Canadian banks showed regulators test whether monitoring actually covers the bank's products and data, not only whether a policy exists.

2.2 What that means for Canadian Tire Bank

Scale: about 2.3 million Triangle Mastercard holders and roughly $7.3 billion in receivables, making the bank Canada's seventh-largest card issuer.
Channel risk: savings, TFSA and GIC accounts are opened and run online, with no branch, which raises money-mule and identity risk.
New money-like flows: Canadian Tire Money, conversions from RBC Avion points, and more loyalty partners announced. Each adds data that must be monitored, measured and reported.

2.3 The problem statement

The bank must show the regulator, the board and its own leaders, with data, that its AML program works. In most banks of this size that proof is still pulled by hand from separate systems each time someone asks. That is slow, hard to defend in an exam, and gives leaders no early warning.

3. The Why, the What and the How

	Answer
Why	Prove program effectiveness to FINTRAC, OSFI, the board and audit; see risk early (backlogs, coverage gaps, weak rules); stop rebuilding the same report by hand every month.
What	One reporting-only AML database as the single source of truth; a KPI dictionary where every measure is defined once, in code; five role-based dashboards, each with a written “what changed and why” note.
How	Reuse the AIDA pattern (collect, standardize, score, publish) on the bank's own Azure, Databricks or Synapse, and Power BI platform, released in 90-day steps, most-used reports first.

4. Proof It Works: AIDA

I designed and built AIDA on my own, starting in July 2026, using AI tools throughout the build. It is running today:

Collect: four n8n collector workflows (company career pages, Job Bank Canada, 51 employer applicant-tracking feeds and the Adzuna API), each its own workflow, never merged. The largest have more than 100 nodes.
Store and score: a PostgreSQL database on a Mac Mini in Toronto is the single source of truth. One database function scores every posting with a 7-layer weighted matrix, and every workflow calls that same function.
Review: the machine scores, a person decides. A human review step (“Data Queen”) confirms every recommendation before a client sees it.
Guardrails: the loader refuses a malformed file before writing anything, after a bad file once wiped good data.
Publish: a one-way sync pushes only what users need to a PocketBase database on an Ubuntu server in Quebec. The source database is never exposed.
Consume: job seekers, recruiters and administrators each log in and see only their own data: scored jobs, custom resumes, interview playbooks and candidate comparisons.

5. From AIDA to the AML Intelligence Hub

Every part of AIDA has a direct AML equivalent:

In AIDA today	In the AML Intelligence Hub	Why it matters to AML
Collectors for 50+ job sources in different formats	Connectors for monitoring, card, deposit, KYC, screening and reporting systems	Every AML question answered from one place
Employer feed registry: last run, row count, status	Source registry with daily reconciliation to each system	Proves completeness to audit and regulators
One database function scores every posting	Every KPI defined once as a certified SQL function	Same number in every report and meeting
Loader refuses a bad file before writing	Quality gates hold a bad load; yesterday's data stays, labelled	No silent errors in board reporting
Machine scores, a person decides	Analytics flags; an analyst or model committee decides	Human judgment stays accountable
Private database, one-way sync to a secure portal	Reporting-only database, separate from systems of record	Fast dashboards without touching production
Users see only their own data	Power BI row-level security by role and business line	Least-privilege access to sensitive data

Figure 1. AIDA as built today

Figure 1. AIDA's working architecture: many sources in, one trusted database, secure role-based portals out.

6. Target Architecture

The hub has five layers on the platform the bank already uses. Canadian Tire has published that it runs Azure Synapse, Azure Data Lake (Delta format) and Power BI, and in February 2026 launched its MOSaiC platform on Azure. The posting names Power BI or Tableau and Databricks, Python, Spark or SAS. The bank may keep its own stack separate from retail; I would confirm that with Technology in month one. The pattern works on any of these.

Figure 2. AML Intelligence Hub target architecture, with controls running under every layer.

7. How We'd Build It

The build uses only tools the bank already licenses, so there is no new vendor and no third-party risk review. Canadian Tire runs Azure Data Lake, Azure Synapse and Power BI, and its other data postings name Databricks, PySpark, Airflow and Git. The bank's own stack is still to be confirmed.

Layer	Tool	How we'd use it
Collect	Azure Data Factory or Databricks Workflows	One scheduled pipeline per source, logged in a source registry
Store and prepare	Azure Data Lake (Delta) + Databricks (PySpark, SQL)	Raw, then clean, then curated: alerts, cases and customers joined
Quality gates	Databricks data-quality rules or Python checks	A failed check holds the load; dashboards keep yesterday's data, labelled
Reporting database	Databricks SQL (or Azure SQL)	Star schema; each KPI written once as a SQL function or view
Access and lineage	Unity Catalog or Microsoft Purview + Entra ID	Access by role; every number traced back to its source
Dashboards	Power BI (dev, test and prod workspaces)	One shared data model, row-level security, scheduled board packs
Code control	Git (Azure DevOps or GitHub)	Every SQL, notebook and report change versioned and peer reviewed

If the bank is moving to Microsoft Fabric, the design is unchanged: OneLake replaces the data lake, Fabric Data Factory replaces Azure Data Factory, and Power BI is built in. In a later phase, Azure OpenAI could draft the “what changed and why” commentary, only after model risk review and with a person approving every note.

8. Likely Source Systems

Canadian Tire Bank's AML vendors are not public. These are the usual feeds for a card-and-deposit bank of this size, to confirm in the first month:

Source	Likely system	What the hub takes
Transaction monitoring and cases	A commercial AML platform (e.g. NICE Actimize, SAS, Oracle, Verafin)	Alerts, rule hits, case outcomes, analyst actions
Card transactions	Card processor files for Triangle Mastercard	Payments, refunds, credit balances, cash paid at store
Deposits	Core ledger for savings, TFSA and GIC	Account opening, deposits, withdrawals, transfers
KYC and customer risk	Onboarding and ID-check tools; risk-rating engine	Risk rating, PEP flags, due-diligence dates
Sanctions screening	Name and payment screening engine	Hits, clear times, true matches, list versions
Regulatory reporting	FINTRAC reporting module or API	STR, LCTR, EFTR and property reports, filing times
Other	Fraud platform, Triangle loyalty, learning system, QA tools	Mule signals, Canadian Tire Money flows, training, test results

9. The Reporting Database: One KPI, One Definition

The AML Reporting Mart is a small star schema built only for reporting:

Facts (events): alerts, cases, STRs and other reports, screening hits, reviews, daily balances.
Dimensions (context): customer, account, product, rule, analyst, date, channel.
Control tables: source registry, load log, KPI dictionary, commentary.

Every KPI is written once as a SQL function and every dashboard, extract and exam pack calls it. This is the same idea as AIDA's single scoring function, so the numbers always agree. For example:

-- KPI-TM-03 Owner: AML Operations
create function kpi_escalation_rate(
  p_from date, p_to date)
returns table (rule_id text, alerts int,
escalated int, rate numeric) as $$
  select rule_id, count(*),
  count(*) filter (where case_id is not null),
  round(avg((case_id is not null)::int)*100, 1)
  from fact_alert
  where created_date between p_from and p_to
  group by rule_id;
$$ language sql;

10. Who Uses It, and What They Ask

Audience	The question they ask	Dashboard	How often
Board Risk Committee, CEO, CAMLO, AVP AML	Is the program effective and within risk appetite?	Executive AML Risk Scorecard	Monthly, quarterly
AML Operations, Model Risk, Internal Audit	Are our rules finding the right activity, with no gaps?	Transaction Monitoring Effectiveness	Monthly
Investigations managers, financial intelligence unit	Are we keeping up, and filing on time?	Investigations and Regulatory Reporting	Daily, weekly
1st-line business partners, KYC operations	Which customers need action, and how fast?	Customer Risk, KYC and Enhanced Due Diligence	Weekly
Technology and data partners, data governance	Can we trust today's numbers?	Data Quality and Source Health	Daily

11. Sample Dashboards

Mockups in Canadian Tire styling. All figures are made up for illustration; the official logo would be added from the bank's brand portal.

Figure 3. Executive AML Risk Scorecard, for the AVP AML, CAMLO and Board Risk Committee: key risk indicators against appetite, program pillar scores and a written “what changed and why”.

Figure 4. Transaction Monitoring Effectiveness, for AML Operations, Model Risk and Internal Audit: which rules earn their keep, and where money laundering patterns have no coverage by product.

Figure 5. Investigations and Regulatory Reporting, for investigations managers: alert inflow against outflow, backlog age against the 30-day appetite, and FINTRAC filing timeliness.

Figure 6. Customer Risk, KYC and Enhanced Due Diligence, for first-line partners: money-mule risk on new online savings accounts and the high-risk review-to-exit funnel.

Figure 7. Data Quality and Source Health, for technology, data governance and audit: AIDA's source registry idea applied to the bank's feeds.

12. Data Governance and Controls

The reporting is itself a control, so it is built and run like one:

Control	How it works
Quality gates	A load that fails its checks is held. Dashboards keep yesterday's data and say so.
Reconciliation	Daily row counts and totals are matched to every source system and logged.
KPI dictionary	Each KPI has an owner, a plain-language definition, one SQL function and a sign-off date.
Lineage	Every number traces back to the source file, load time and function version.
Access and privacy	Role-based, least-privilege access, fully logged, in line with privacy law and bank policy.
Change and model control	Versioned code, peer review and testing; any scoring model goes through model risk review.

13. Who Builds It

This is resourced the standard way: a project intake (PMO) request for a confirmed share of a junior developer's time. I would fill the solution architect role myself and own the result; the developer builds pipelines and reports to my designs. Whether that is an Azure, Databricks or Power BI developer depends on the bank's approved platform, to be confirmed in month one. I have delivered this way for 20 years; software projects rarely come with direct reports. Production pipelines and source systems are normally restricted to Technology, and that is the right design: at a bank, the person who defines a KPI should not be the only person who can change the pipeline that feeds it.

Role	Responsibilities
Me: solution architect, owner and analytics lead	Solution architecture and technical design; requirements with AML leaders and operations; the KPI dictionary, data model and KPI SQL; Power BI design; testing numbers against source; roadmap and presenting results
Developer (junior, allocated through PMO intake)	Builds pipelines and reports to my designs. Azure, Databricks or Power BI developer: to be confirmed once the platform is known
Platform and security (shared)	Environments, licences, access groups, security review and production release
Data owners and AML experts (part-time)	Explain each source and confirm the numbers are right
Model Risk and Internal Audit (reviewers)	Sign off on scoring models and controls

What I can start on my own in month one: the report inventory, the KPI dictionary and a prototype scorecard built from existing extracts.

14. AI Strategy: Faster Work, No Customer Data

Canadian Tire already uses AI at scale. ChatCTC, an internal assistant on Azure OpenAI, is used by thousands of corporate employees; CeeTee is a customer-facing shopping assistant; and MOSaiC, built with Microsoft, turns sales and loyalty data into retail insight. A “Data in Action” program governs AI risk. I found no public mention of AI in the bank's AML work, which is normal: anything that scores or predicts falls under OSFI's model risk expectations.

The strategy for the AML Intelligence Hub is simple: AI works on the code and the numbers, never on the customers.

	What it means
Where AI helps	Writing and reviewing SQL and pipeline code; documenting KPIs, lineage and controls; building test cases and synthetic test data; drafting “what changed and why” notes from summary numbers; summarizing new regulatory guidance.
The data boundary	No customer, account or transaction records ever go to AI. AI sees only code, table designs, KPI definitions and aggregated totals. It runs on the enterprise Azure OpenAI service Canadian Tire already uses, if the bank approves, and every prompt and output is logged.
Guardrails	AI has no route to production data or systems. A person reviews and applies every change. Anything that scores or predicts goes through model risk review. A person signs off before anyone else sees AI output.

Proven in AIDA: AI with no way to do harm

I built AIDA with AI from day one, and designed it so an AI agent cannot act on its own:

No route to production. AI sessions run in an isolated workspace with no access to the database, Docker or scheduled jobs. Every step that touches those is run by me.
No credentials. AI never holds or enters passwords; credentials live only inside the server process.
People apply every change. AI writes SQL as a file. I review it, run it, and then run its paired read-only check; read-only queries always come first.
Validated hand-offs. AI review output is a structured file. The loader rejects anything malformed before a single row is written, and sets the file aside.
Machine first, AI second. One deterministic SQL function scores every posting; AI works only on the reviewed shortlist.
A person decides. Nothing reaches a client until a person has reviewed and approved it.

The result: an AI agent cannot change AIDA's data or infrastructure on its own; only a person can, through a reviewed step. Because AI is a narrow, deliberate layer rather than a dependency, AIDA costs about $15 a month to run.

15. Delivery Roadmap

When	Focus	Deliverables
Days 1–30	Listen and take stock	Meet AML leaders and data owners; list every report and source; draft the KPI dictionary and agree the top 10 measures with Mark.
Days 31–60	Build the foundation	Source registry and the first three feeds (monitoring, FINTRAC reports, KYC risk); quality gates and reconciliation; scorecard draft with commentary.
Days 61–90	First release	Executive and Investigations dashboards live; access by role; KPIs certified; 12-month roadmap to the AML committee.
Months 4–6	Widen coverage	Monitoring effectiveness and coverage; customer risk, KYC and enhanced due diligence; automated exam evidence packs.
Months 7–12	Advanced analytics	Alert prioritization through model risk review; automated below-the-line testing; mule-network analytics; AI-drafted commentary that a person approves.

16. Why Me for This Role

What the role needs	Where I have done it
Large programs in banks	$3.1M, 18-month Salesforce CRM rollout for Scotia Global Banking and Markets; Barclays, Tier1's flagship client, taken from RED to GREEN within weeks
Solutions delivered	MASS Engines: acquisition data migration and marketing automation projects up to $1.8M. HSS: JDE-integrated customer portal (about 10 hours saved per rep per week) and AI case automation (80 hours saved per week)
Data design with the client's own tools	15 years designing and delivering Salesforce solutions, including complex data schemas, on each client's standard platform
Every role on a project	Project manager, business analyst, administrator, solution architect and trainer; Salesforce Certified Administrator and Platform Developer I; PMP
SQL, Python and data at scale	AIDA: PostgreSQL core with one shared scoring function, Python and n8n pipelines across 50+ sources, 59 schema migrations
Value for money	Built AIDA on free and open-source software; it costs about $15 a month to own and operate
AML domain	2 years delivering AML software and analytics on the Alessa platform, closed with audit-ready sign-off
Delivery without direct reports	20 years leading matrixed project teams through confirmed time allocations

Straight talk: Power BI and Databricks at bank scale would be new platforms for me. The SQL, Python and data modelling underneath are what I work in every day.

17. Assumptions and Sources

Assumptions to confirm

The bank's AML vendors, data platform and data owners (not public).
How much AML reporting is produced by hand today.
The bank's approved data platform (Databricks, Synapse or Fabric), Power BI licensing, and a confirmed allocation of a junior developer's time through project intake (Azure, Databricks or Power BI, depending on the platform).
Whether the bank's data platform is shared with, or separate from, Canadian Tire's retail stack.

Sources

FINTRAC, “Administrative monetary penalties: changes following legislative amendments” (Bill C-12, in force March 26, 2026).
Fasken, “FINTRAC provides information on recent changes to Canada's AML regime”, April 2026.
Canadian Tire Corporation, “CTC completes strategic review of its Financial Services business”, December 6, 2024.
Canadian Tire Corporation Q4 2025 earnings call highlights (Financial Services).
Microsoft customer story, “Canadian Tire modernizes data platform with Azure Synapse Analytics and Power BI”, January 2023.
Canadian Tire Corporation, “CTC expands Microsoft collaboration… retail intelligence platform”, February 18, 2026.
Microsoft customer story, “Canadian Tire Corporation uses Azure AI services to boost employee productivity” (ChatCTC).
Canadian Tire Corporation, “More Than A Trend: Responsible AI is Essential to Retail Success”, 2024.
BNN Bloomberg, “Canadian Tire turning to AI to drive growth amid economic headwinds”, August 13, 2026.
Mark Bachrynowski, LinkedIn profile; Canadian Tire Bank job posting JR161216.