# Building a Canadian-Controlled Financial Data Layer for the Regulated and Agentic Era

## PIASSES Investment and Infrastructure White Paper

Version 1.0. 2026-08-19. Research last verified: 2026-08-19.

## Abstract

Canada is moving from informal, credential-based financial-data sharing toward a supervised consumer-driven banking framework, while payments rails are modernized and digital sovereignty becomes federal policy. Connectivity alone does not answer the resulting infrastructure question: how permissioned institution data becomes reliable financial facts that institutions, developers, and software agents can use without losing meaning, evidence, or control. This paper argues for a Canadian-controlled control plane above raw institution APIs and below products and agents, sets out the architecture PIASSES has implemented, and describes the eighteen-month path from that foundation to institutional design-partner evidence.

## Contents

- Executive Summary
- 1. Canada's Financial-Data Transition
- 2. Connectivity Is Necessary, but Not Sufficient
- 3. Financial Data Changes Meaning
- 4. The Institutional Evidence Problem
- 5. AI Raises the Trust Requirement
- 6. Digital Sovereignty as a Control Model
- 7. PIASSES Architecture
- 8. Current Product State
- 9. Current Scope and Next Stage
- 10. Market Entry
- 11. Competitive Landscape
- 12. Business Model
- 13. How the Moat Compounds
- 14. Roadmap
- 15. Risks and Counterarguments
- 16. Capital Purpose
- Conclusion
- References

## Executive Summary

Canada is moving from informal, credential-based financial data sharing toward a supervised consumer-driven banking framework. At the same time, payments infrastructure is being modernized, operational resilience expectations for federally regulated institutions are explicit, and federal policy has elevated digital sovereignty from a specialist concern to a public strategy. These shifts create an infrastructure problem that connectivity alone does not solve: how to turn permissioned institution data into reliable financial facts that institutions, developers, and software agents can use without losing meaning, evidence, or control. (S01, S02, S09, S16, S18)

PIASSES proposes a Canadian-controlled control plane above raw institution APIs and below products and agents. The architecture is institution APIs, to an adapter boundary, to source observations, to canonical financial records, to REST and MCP, to deterministic intelligence. The company is not proposing a consumer budgeting application, a payments network, or an LLM product. It is proposing institutional financial-data infrastructure for the regulated and agentic era.

PIASSES already has a substantial infrastructure foundation: a shared domain and application core, fail-closed consent and authorization, PostgreSQL-backed durable sandbox state, REST and MCP parity, provenance and data-quality contracts, deterministic intelligence, a provider boundary, and an institution conformance environment. The next stage is durable institution ingestion, normalization, and pilot-path operations.

This financing stage is designed to connect the implemented planes into a restart-safe, evidence-preserving institution ingestion path and convert that technical foundation into design-partner evidence. The thesis is ambitious, but the milestones are concrete.

## 1. Canada's Financial-Data Transition

Consumer-driven banking, also described by the federal government as open banking, is a framework that lets individuals and businesses direct sharing of their financial data with approved service providers. The Consumer-Driven Banking Act received royal assent in March 2026 as part of the Budget 2025 implementation statute. The Act establishes a framework for safe data sharing and assigns supervisory responsibility to the Bank of Canada, including supervision of participating entities, accredited third-party service providers, an external complaints body, and a technical standards body. (S07, S03, S51)

On 26 June 2026, the Department of Finance pre-published proposed Consumer-Driven Banking Regulations. The Canada Gazette, Part I, published those proposed regulations on 27 June 2026. The comment period is 60 days and closes 26 August 2026. Finance Canada states that the regulations would further specify data scope, accreditation, national security, duties of participating entities, liability, duties of accredited third-party service providers, the technical standards body, evidentiary privilege, assessment fees, and violations. Coming into force is described as staggered, beginning with accreditation, followed by common rules and assessment fees within one year of final publication. Significant portions of the Act and the proposed regulations are not yet in force. (S02, S01, S52)

The transition away from screen scraping is a central policy justification. Finance Canada and the Gazette both state that about nine million Canadians currently share financial data by providing confidential banking credentials. The government argues that this practice raises security, liability, and privacy risks and that API-based sharing is intended to replace it. The prohibition of screen scraping is not described as immediately operative; Budget 2025 materials state that the prohibition is intended to come into force once the framework is fully operational, with further consultation on timing. (S02, S03, S01)

Bank of Canada materials confirm that the Bank will administer the framework, supervise participants, set standards for governance, risk management, and operational resilience, and that the Department of Finance is leading regulation development with Bank support. Proposed regulations have been published in Part I of the Gazette. This is an oversight path in construction, not a completed supervisory machine. (S05)

Payments modernization is a parallel rail, not the same product. Payments Canada describes the Real-Time Rail as a real-time exchange, clearing, and settlement system supporting instant, data-rich payments, with a target launch in the fourth quarter of 2026 after industry solution-assurance testing. Participant onboarding is sequenced. By-law and rules approval in 2026 is a legal milestone, not proof that the system is already in nationwide production use. PIASSES does not initiate payments and does not claim to operate this rail. (S09, S10, S11, S12)

Comparable jurisdictions illustrate why connectivity and a control layer are different problems. The United Kingdom built open banking as a mandated API regime with a dedicated implementation entity. Australia built the Consumer Data Right as a cross-sector data-portability regime. Those systems are useful evidence that regulated access creates operating, standards, and consent problems beyond the first connection. They are not evidence that Canada has adopted UK or Australian rules. Canadian institutions will operate under the Consumer-Driven Banking Act, Bank of Canada supervision, and OSFI guidance for federally regulated entities, not under a copied foreign playbook. (S25, S26, S27, S13)

Timing therefore has two readings. First, the direction is no longer speculative: legislation exists, proposed regulations are public, a supervisor is named, and a payments rail is in late testing. Second, implementation remains contingent: consultation is still open as of 19 August 2026, coming-into-force dates are staggered and not fully specified, and live consumer-driven banking is not an accomplished fact. PIASSES should be evaluated as an infrastructure bet on that transition, not as an operator of the finished regime. (S01, S52)

## 2. Connectivity Is Necessary, but Not Sufficient

Connectivity companies proved that consumers and businesses will share financial data when the resulting products are useful. That proof is valuable. It is also incomplete as a description of the regulated era. An institution API can return JSON and still leave downstream systems unsure whether a transaction is pending or posted, whether a later record supersedes an earlier one, whether a balance is fresh, whether a missing amount is zero, or whether a raw payload should ever be shown to an agent.

The control-layer thesis is that regulated sharing creates a second-order infrastructure need around the connection itself. Accreditation, security, authentication, consent, record keeping, technical standards, and oversight appear in the proposed Canadian framework. Those requirements raise the cost of treating financial data as a disposable integration detail. They also raise the value of reusable conformance, evidence, and canonicalization. (S01, S02)

CGAP and related open-API research have long distinguished pipes from the operating capabilities required to run them safely: identity, consent, standards, monitoring, and operational process. Academic work on open-banking security and consent tracking likewise treats access as only one part of a trust problem that includes lineage, purpose limitation, and accountability. PIASSES uses that literature as context, not as a claim that Canada has adopted a foreign rulebook. (S38, S35, S36)

The practical implication is category discipline. PIASSES is not a broader aggregator than Flinks or Plaid. It is infrastructure for institution-grade evidence and provider-neutral facts. Connectivity remains necessary. It is not the whole system.

The thesis does not require incumbents to fail. It holds in a world where connectivity networks keep winning consumer-app distribution: institutions would still need conformance, evidence, canonical meaning, and a control model for the data they emit. That is a narrower market than open banking as a whole, and it is the market PIASSES is built to enter.

## 3. Financial Data Changes Meaning

Financial records are not static rows. A pending debit can post, fail, or remain unfinished. A posted item can later be reversed. A source system can correct an amount, a date, or a counterparty and thereby invalidate a downstream total that looked final yesterday. A balance can be accurate at observation time and stale at decision time. These are ordinary banking facts. They become extraordinary when software, including agents, treats them as durable truth.

Missing is not zero. Unknown is not missing. Unsupported is not redacted. Not applicable is not a modelling inconvenience. PIASSES encodes those distinctions as a closed value-state contract because coercing absence into a number is how credit, cash, and agent tools silently misstate a person or an institution. Exact-money semantics likewise refuse floating-point rounding and provider sign conventions as sources of canonical meaning.

Source schema differences compound the problem. Two institutions can represent the same economic event with different identifiers, lifecycle labels, booking dates, and payload shapes. If canonical identity collapses to a provider record ID, the product inherits the provider. If raw payloads leak into audit logs, product APIs, or agent context windows, the institution has lost containment even if the original API call was authorized.

Lineage, quality, and freshness are therefore not analytics features. They are part of the record. A freshness assessment that cannot cite an observation time, an evaluation time, a threshold, and an age is not an assessment. A quality issue without factual evidence is a score pretending to be a fact. PIASSES keeps quality deterministic and factual, with no probabilistic confidence number in canonical outputs.

The W3C PROV family of recommendations is a useful language for talking about provenance without inventing a private vocabulary from scratch: entities, activities, agents, derivation, and generation. PIASSES does not claim to implement PROV-O as a public API. It does claim that financially consequential records carry source observations, transformation classification, supersession lineage, and field-level provenance for amounts, dates, and classification. That is the institutional translation of provenance: an auditor or an agent can ask what was observed, what was transformed, and what replaced what. (S29, S58)

TruChain and related open-banking integrity research make a similar point from another direction: if shared financial data can be altered or stripped of evidence after the fact, downstream products inherit an unverifiable history. PIASSES does not use a blockchain. The relevant requirement is weaker and more operational: append-only source evidence, payload containment, and canonical records that can cite their observations. Research is support for the problem statement, not a claim that PIASSES has productized any one paper. (S34)

## 4. The Institutional Evidence Problem

Once financial data is shared under a supervised framework, institutions need more than a successful HTTP response. They need to know whether an outbound API conformed to an expected contract, whether a page of data was observed, whether a replay created duplicate evidence, whether a checkpoint advanced after a failed write, and whether raw payloads were quarantined or copied into every downstream store.

OSFI Guideline B-10 sets expectations for third-party risk management by federally regulated financial institutions, including accountability for outsourced activities and proportionate management of third-party arrangements. Guideline B-13 sets expectations for technology and cyber risk management, including operational resilience and cyber security. These are not PIASSES certifications. They are the institutional climate in which a financial-data vendor will be questioned: who operates the system, what evidence exists, and what happens in failure. (S13, S14, S15)

Basel Committee principles for operational resilience similarly treat the ability to deliver critical operations through disruption as a supervisory concern. International standards are comparable context. They do not mean Canada has copied Basel text into consumer-driven banking regulations. (S24)

Today, PIASSES proves the canonical data, consent, persistence, delivery, and intelligence layers in a controlled synthetic-data environment. The next engineering stage connects institution observations to that existing foundation through durable ingestion, checkpointed resume, and normalization that does not create duplicate evidence.

Idempotency and audit completeness are part of the same evidence problem. If a write can succeed while its audit record does not, or if a replay can create a second financial fact from the same source page, the institution cannot trust the history it will later show to a supervisor, a partner, or an agent. The current environment is designed so business state and success audit commit together, and so identical replays of a write return the same result. Those properties are proven against synthetic data and remain to be proven against live institution pages, schema drift, and production operations.

## 5. AI Raises the Trust Requirement

PIASSES is not an LLM company and does not claim to solve financial reasoning. The relevant research finding is narrower: models remain unreliable on multi-step numerical and evidence-grounded financial questions, and agent systems that tool-call into financial data inherit every defect in those inputs.

FinQA constructed a dataset of financial questions requiring numerical reasoning over reports and showed that even strong models lagged expert performance. FinanceBench later found large gaps between claimed financial-question-answering ability and actual open-book performance on real company documents. The Finance Agent Benchmark extends the problem into tool-using agents with expert-authored tasks. These papers are not about open banking. They are about the brittleness of machine financial reasoning when evidence is incomplete, unstructured, or easy to misread. (S31, S32, S33)

If agents become a distribution path for permissioned financial data, then provenance, freshness, value states, and payload containment become safety properties. An agent that treats a pending transaction as cash, a stale balance as current, or a raw account-number-shaped string as harmless context is not a clever product. It is an uncontrolled decision system. PIASSES aims to give software and agents a safer financial-data substrate: strict output schemas, sanitized text, and the same authorization path on REST and MCP.

NIST's AI Risk Management Framework likewise treats data quality, provenance, and governance as risk controls rather than as optional documentation. Again, this is context. Canada has not adopted NIST as consumer-driven banking law. (S28)

## 6. Digital Sovereignty as a Control Model

The Government of Canada defines digital sovereignty as the ability to exercise autonomy over digital infrastructure, data, and intellectual property, and to operate effectively regardless of where technologies are developed, hosted, or supported. The same paper is explicit that complete digital autonomy is impossible in an interconnected world, and that using a Canadian supplier or storing data in Canada does not by itself place information outside foreign lawful-access regimes. (S16)

The 2018 public-cloud data-sovereignty white paper warned that foreign laws can create data-sovereignty risks even when data is stored in Canada. That older paper remains useful because it separates residency from control, a distinction later sovereignty work still needs. (S17)

In June 2026, the Prime Minister launched AI for All, a national AI strategy that frames sovereignty around Canadian control over how AI is built, governed, and used, including data, compute, cloud, procurement, privacy, and standards. The strategy language includes building in Canada and directing procurements for sovereign capabilities toward Canadian firms first. That is industrial policy. It is not a contract with PIASSES, a grant award, or a requirement that banks buy Canadian financial-data software. (S18, S19, S20)

For PIASSES, practical sovereignty is a control model: Canadian IP, governance, jurisdiction, processing location, key custody, operational control, audit evidence, portability, recovery rights, procurement exposure, and independence of roadmap. Foreign components can still appear in a stack. The investor question is whether Canadian institutions would retain meaningful control over the systems they depend on if PIASSES became part of that stack. Today that control model is a product direction, not a production deployment.

The same logic applies to keys, recovery, and procurement. If encryption keys, administrative credentials, or restore paths are controlled by a vendor whose roadmap, jurisdiction, or commercial incentives the institution cannot influence, location of the data is a weak comfort. OSFI third-party risk guideline is explicit that federally regulated financial institutions remain accountable for activities they outsource. A Canadian-controlled vendor is not automatically safer, but a vendor whose intellectual property, operating company, and recovery obligations sit in Canada can make those accountability conversations more concrete. (S13)

Procurement will test this argument. If institutions buy only on price and connector count, sovereignty language will not close deals. This paper therefore treats Canadian control as a design constraint and a possible buying criterion, not as a substitute for reliability, security, or commercial proof. Foreign infrastructure can be part of the stack. The question is whether Canadian institutions retain meaningful control over the systems, evidence, keys, and recovery paths they depend on.

## 7. PIASSES Architecture

In institutional language, PIASSES is a read-only-first financial-data platform intended to normalize consented institution data into provider-neutral records while keeping provider details replaceable. REST and MCP are sibling interfaces over one domain and application core. Neither interface owns separate business logic.

The intended operating pipeline is institution APIs, then an adapter boundary, then source evidence, then canonical records, then REST and MCP, then deterministic intelligence. Today PIASSES proves the canonical data, consent, persistence, delivery, and intelligence layers in a controlled synthetic-data environment. An institution conformance environment already exists. Connecting institution observations to that foundation through durable ingestion and normalization is the next engineering stage.

Authorization treats client permission and consumer consent as two independent dimensions. Both must pass. Unknown scopes fail closed. Consent is a state machine with explicit connection binding rather than an inferred missing value. Audit events are sanitized and, on the persisted path, designed so success audit is owned in the same database transaction as business state. Invalid authorization state is intended to fail closed rather than silently widen access.

REST and MCP parity is part of that judgement. If the HTTP surface and the agent surface diverge, the company has two policy stacks and two opportunities to leak a raw payload, skip a consent check, or invent a second meaning for the same account. The current design refuses that split: both interfaces call the same application core. That architectural choice is already present. Production traffic over both surfaces is a later operating state.

A useful way to read the architecture is as an institutional control plane. The adapter boundary is where provider variety is absorbed. Source observations are where evidence is preserved. Canonical records are where meaning is stabilized. REST and MCP are where authorized consumers receive the same facts under the same policy. Deterministic intelligence is where summaries are computed without inventing a second, probabilistic truth. If any of those layers is skipped, the system collapses back into a connector with a nicer logo.

The current environment can be exercised end to end: create a workspace and client, establish synthetic consumer consent, connect a sandbox institution, read canonical accounts, balances, transactions, quality, and intelligence, then revoke consent and observe protected reads fail closed. That journey demonstrates interface and policy completeness in a controlled environment. Live institution connectivity remains a later stage.

## 8. Current Product State

Implemented: shared domain and application core; twelve canonical capabilities behind one registry; versioned REST and remote MCP; PostgreSQL-backed durable sandbox state for organizations, workspaces, API clients, credentials, consumers, consents, connections, canonical financial records, idempotency, and audit events; fail-closed consent and authorization; exact-money and value-state contracts; source observation and provenance contracts; record correction and supersession lineage; freshness and factual data-quality modelling; a provider boundary; deterministic financial intelligence; an institution API conformance environment and testkit; REST and MCP parity over the shared core.

Partially implemented: the institution-to-intelligence flow. The data, consent, persistence, delivery, and intelligence planes exist. They are not yet connected into one durable institution-to-canonical-to-intelligence operating pipeline. Institution API behaviour is proven in a conformance environment. Connecting those observations into durable default-path ingestion is the next stage.

Planned next: durable source-observation persistence for institution HTTP reads; durable per-connection checkpoint or cursor state; append-before-checkpoint progression; restart-safe resume; and replay-safe evidence. Explicitly deferred from that stage: source-to-canonical normalization, record matching, public institution ingestion routes, background scheduling, intelligence changes, model work, deployment, production authentication, and live institution connectivity.

That stage is the first use of capital. The scope is explicit: connect the implemented foundation to durable institution ingestion, then take that path into a Canadian-hosted pilot environment.

## 9. Current Scope and Next Stage

PIASSES currently proves its canonical data, consent, persistence, delivery, intelligence, and conformance layers in a controlled synthetic-data environment. The current environment uses sandbox-only authentication and synthetic financial data. Production authentication, live institution connectivity, and production operations are part of the pilot-path build rather than present claims.

This financing is intended to unlock durable institution ingestion, normalization, a Canadian-hosted pilot environment, and design-partner operations. Completing that path would convert the existing foundation into institution-tested evidence.

The following remain outside current claims: live bank connectivity; production open-banking deployment; accreditation; live consumer financial data; payment initiation; background synchronization; completed durable institution-to-canonical ingestion; production-readiness evidence; signed commercial contracts; and government endorsement.

## 10. Market Entry

The first customer lane is Canadian banks and participating institutions that need to expose, validate, operate, and improve their own consumer-authorized outbound financial APIs. PIASSES does not select external aggregators for banks. The downstream lane is real but secondary: developers and agent builders consuming provider-neutral canonical data through REST or MCP.

The wedge is conformance and readiness rather than national consumer-app coverage. That is a deliberate choice against competing first on distribution. The go-to-market motion is founder-led design partnerships with credit unions, regional institutions, and regulated service providers. Design-partner validation is the next commercial proof point.

Credit unions and regional institutions are a plausible early market because participating institutions will need to meet the framework's core data-sharing requirements while many operate with smaller internal platform teams than Canada's largest banks. The first value moment is an institution validating an institution-owned read API against a deterministic conformance profile before live rollout. Testing whether that moment is valuable to institutions is an explicit objective of this financing stage.

## 11. Competitive Landscape

Flinks is a Canadian financial-data and embedded-finance company. Its public site claims connectivity across more than 15,000 financial institutions in North America, enrichment, document verification, and account-to-account payments, including Interac Request for Money and EFT. National Bank of Canada invested to acquire control in 2021. Flinks has published its own reading of the 2026 draft consumer-driven banking regulations and positions itself as infrastructure for institutions and fintechs. Those are incumbent strengths. PIASSES is pursuing a different wedge: institution-grade conformance, evidence, canonical financial semantics, and Canadian-controlled delivery around the emerging standardized API regime. (S39, S40, S41)

Plaid entered Canada in 2018, opened a Toronto office, announced a data-access agreement with RBC in 2022 covering more than 14 million RBC digital clients, and announced a North American data-access agreement with TD in 2023. Plaid's support materials state that over 99 percent of Canadian deposit accounts are covered, including the large banks and more than 100 other institutions. Plaid also states support for approximately 10,000 institutions in the United States. Coverage, partnerships, and developer distribution are incumbent strengths. PIASSES is not competing on that coverage axis. (S43, S44, S45, S46)

Mastercard open banking, institution internal builds, and other infrastructure vendors are also relevant. Internal build is the most important alternative. Banks already run core systems, API programs, and vendor risk processes. They can assemble conformance tests, payload stores, and developer portals. PIASSES is betting that a reusable, provider-neutral evidence layer is cheaper and more interoperable than every institution rebuilding the same machinery, especially once agents consume the data. Design-partner work will test whether institutions value that reusable evidence and canonicalization layer enough to buy rather than rebuild it internally. (S47)

## 12. Business Model

The commercial model is enterprise contracts plus usage-based delivery. Recurring revenue comes from annual platform contracts for conformance, canonical data, monitoring, and support. The land motion includes implementation services, adapters, conformance work, and managed onboarding. Expansion comes from usage-based fees tied to consented data delivery and developer or agent usage.

Non-dilutive programs are treated as a capital-efficiency edge, not as the business model. PIASSES makes no claim of eligibility, application, or award for IRAP, SR&ED, or any other program.

PIASSES expects institution platform contracts to anchor the commercial relationship, with implementation and onboarding at entry and usage-based delivery expanding as consented data volume and downstream developer or agent usage grow. Commercial pricing will be developed with early institution design partners.

## 13. How the Moat Compounds

PIASSES's defensibility begins with its canonical semantics, provenance model, conformance architecture, and shared REST/MCP control plane. It is designed to compound through institution-specific integration knowledge, conformance evidence, operating history, institutional trust, developer adoption, and switching costs as deployments grow.

That defensibility is expected to deepen with execution: canonical semantics; conformance knowledge; institution-specific integration knowledge; source-evidence history; operational reliability; institutional trust; developer adoption; switching cost; and IP where genuinely protectable. It is a venture path about accumulated trust and infrastructure knowledge, not a claim of a mature present-day network effect or a dominant barrier to entry.

## 14. Roadmap

The eighteen-month plan is: today, a local infrastructure sandbox; 0 to 6 months, durable institution ingestion; 6 to 12 months, a Canadian-hosted pilot environment; 12 to 18 months, two to three design-partner pilots. Legal and IP work sits beside the engineering sequence. This is a plan. It is not a guaranteed delivery schedule and it is not the federal implementation timetable.

The first six months are the engineering proof the round should buy: durable source observations, checkpointed ingestion, restart-safe replay, and institution-to-canonical normalization on a path that can later host a Canadian pilot. The following year is commercial proof: a hosted environment institutions can inspect, then a small number of design-partner pilots. Completing both stages would move the next financing conversation from architecture intent to institution-tested operating evidence.

## 15. Risks and Counterarguments

- Regulatory timing: consultation, staggered coming-into-force, and screen-scraping prohibition timing can slip. Urgency for institution spend would slip with it.
- Incumbent response: Flinks, Plaid, Mastercard open banking, and bank platforms can add evidence, canonicalization, or Canadian-control messaging.
- Internal bank build: the buyer can decide the problem is real and still keep it in-house.
- Enterprise sales cycles: even a correct product can wait years in procurement.
- Product-market fit: institutions may buy connectivity and accreditation help, not a canonical layer.
- Procurement and third-party risk: OSFI-shaped vendor review can block a young company.
- Sovereignty as a weak buying criterion: boards may treat it as rhetoric unless it maps to audit, keys, and recovery.
- Integration complexity: live institution APIs will be messier than a fictional sandbox.
- Security and compliance burden: production-path authentication, hosting, and operations are still ahead.
- Funding and execution risk: a small founding team must hire, sequence, and finish the ingestion bridge.

None of these risks is exotic. The relevant pre-seed question is which risks this financing can convert into evidence. Regulatory timing risk is real and public: consultation is still open and coming-into-force remains staggered. Incumbent and internal-build risk is structural: connectivity companies and banks already occupy the relationship surface. Product-market fit is the central commercial proof point. The financing is intended to test it through institution design partnerships and pilots. Capital should be judged as the cost of turning those known risks into evidence.

## 16. Capital Purpose

External capital would be used to connect the implemented infrastructure foundation to durable institution ingestion, establish pilot-path operations, and convert technical progress into design-partner evidence. The operating priorities remain build, prove, partner, and protect: complete the ingestion and canonicalization path, demonstrate restart safety and audit integrity, support institution design partnerships, and protect genuinely defensible intellectual property. Financing structure and terms are discussed directly with prospective investors. This paper is an information brief, not an offering document, and it is not a solicitation to buy securities.

## Conclusion

Canada is rebuilding the legal and operational conditions under which financial data moves. Connectivity companies have already proved demand for access. The next infrastructure challenge is to make permissioned data conformant, evidence-preserving, operationally reliable, provider-neutral, and safe for both conventional software and increasingly autonomous systems. PIASSES is entering that transition with a working infrastructure foundation and a defined path from institution conformance to durable ingestion, canonical financial facts, and design-partner deployment. The investment case is that Canada's regulated financial-data transition will require more than connectivity. It will require trusted evidence, stable financial meaning, operational control, and infrastructure that institutions can depend on. PIASSES is being built for that layer.

## References

- S01. Canada Gazette, Part I, Consumer-Driven Banking Regulations. Government of Canada. June 27, 2026. https://gazette.gc.ca/rp-pr/p1/2026/2026-06-27/html/reg3-eng.html
- S02. Government pre-publishes regulations to prevent fraud and facilitate the next phase of consumer-driven banking. Department of Finance Canada. June 26, 2026. https://www.canada.ca/en/department-finance/news/2026/06/government-pre-publishes-regulations-to-prevent-fraud-and-facilitate-the-next-phase-of-consumer-driven-banking.html
- S03. Budget 2025: Canada's Consumer-Driven Banking Framework. Department of Finance Canada. November 4, 2025. https://www.canada.ca/en/department-finance/programs/financial-sector-policy/open-banking-implementation/budget-2025-canadas-framework-for-consumer-driven-banking.html
- S05. Consumer-driven banking. Bank of Canada. Accessed August 19, 2026. https://www.bankofcanada.ca/regulatory-oversight/consumer-driven-banking/
- S07. Consumer-Driven Banking Act. Justice Laws Website. March 26, 2026. https://laws-lois.justice.gc.ca/eng/acts/C-36.78/FullText.html
- S09. Real-Time Rail payment system. Payments Canada. Accessed August 19, 2026. https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system
- S10. Real-Time Rail testing and launch. Payments Canada. Accessed August 19, 2026. https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system/testing-and-launch
- S11. Canada's Real-Time Rail Quarterly Update: 2026 Q3. Payments Canada. July 1, 2026. https://www.payments.ca/canadas-real-time-rail-quarterly-update-jude-pinto-2026-q3
- S12. By-law and rules approved for Canada's Real-Time Rail. Payments Canada. June 30, 2026. https://www.payments.ca/critical-milestone-achieved-law-and-rules-approved-canadas-real-time-rail
- S13. Third-Party Risk Management Guideline (B-10). OSFI. May 1, 2024. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/third-party-risk-management-guideline
- S14. Technology and Cyber Risk Management (B-13). OSFI. January 1, 2024. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-risk-management
- S15. Third-party risk. OSFI. March 6, 2026. https://www.osfi-bsif.gc.ca/en/about-osfi/osfi-knowledge-centre/third-party-risk
- S16. Digital Sovereignty: A Framework to improve digital readiness of the Government of Canada. Government of Canada. November 12, 2025. https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/cloud-services/digital-sovereignty/digital-sovereignty-framework-improve-digital-readiness.html
- S17. Data Sovereignty and Public Cloud White Paper. Government of Canada. November 1, 2018. https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/cloud-services/digital-sovereignty/gc-white-paper-data-sovereignty-public-cloud.html
- S18. Prime Minister Carney launches AI for All. Prime Minister of Canada. June 4, 2026. https://www.pm.gc.ca/en/news/speeches/2026/06/04/prime-minister-carney-launches-ai-all-canadas-new-national-artificial
- S19. AI for All news release. Prime Minister of Canada. June 4, 2026. https://www.pm.gc.ca/en/news/news-releases/2026/06/04/prime-minister-carney-launches-ai-all-canadas-new-national-artificial
- S20. Canada's National Artificial Intelligence Strategy: AI for All. Innovation, Science and Economic Development Canada. June 4, 2026. https://ised-isde.canada.ca/site/ised/en/canadas-national-artificial-intelligence-strategy-ai-all
- S24. Principles for operational resilience. Basel Committee on Banking Supervision. March 31, 2021. https://www.bis.org/bcbs/publ/d516.htm
- S25. Open banking. UK Financial Conduct Authority. Accessed August 19, 2026. https://www.fca.org.uk/firms/open-banking
- S26. Open Banking. Open Banking Limited. Accessed August 19, 2026. https://www.openbanking.org.uk/
- S27. Consumer Data Right. Australian Government. Accessed August 19, 2026. https://www.cdr.gov.au/
- S28. AI Risk Management Framework. NIST. January 26, 2023. https://www.nist.gov/itl/ai-risk-management-framework
- S29. PROV-Overview. W3C. April 30, 2013. https://www.w3.org/TR/prov-overview/
- S31. FinQA: A Semantic Parsing Dataset for Financial Question Answering. ACL Anthology. November 1, 2021. https://aclanthology.org/2021.emnlp-main.300/
- S32. FinanceBench: A New Benchmark for Financial Question Answering. arXiv. November 20, 2023. https://arxiv.org/abs/2311.11944
- S33. The Finance Agent Benchmark. arXiv. August 1, 2025. https://arxiv.org/abs/2508.00828
- S34. TruChain: Trusted, verifiable and immutable open banking data. arXiv. July 11, 2025. https://arxiv.org/abs/2507.08286
- S35. Security Challenges in Open Banking. MDPI. January 1, 2025. https://www.mdpi.com/2674-1032/5/2/38
- S36. ConsenTrack: Consent data tracking in open banking. Springer. January 1, 2023. https://link.springer.com/article/10.1007/s44230-023-00023-5
- S38. Technology Building Blocks for an Open API Strategy. CGAP. January 1, 2020. https://www.cgap.org/research/reading-deck/technology-building-blocks-for-open-api-strategy
- S39. Flinks. Flinks. Accessed August 19, 2026. https://www.flinks.com/
- S40. Open Banking in Canada: Draft Consumer-Driven Banking Regulations. Flinks. July 20, 2026. https://www.flinks.com/blog/open-banking-canada-2026-launch-fintech-institutions
- S41. National Bank of Canada invests $103M in Flinks. Cision / National Bank of Canada. August 25, 2021. https://www.newswire.ca/news-releases/national-bank-of-canada-invests-103m-in-flinks-including-30m-in-growth-capital-815619089.html
- S42. Plaid. Plaid. Accessed August 19, 2026. https://plaid.com/
- S43. Accelerating financial access in Canada. Plaid. June 14, 2022. https://plaid.com/blog/plaid-expands-presence-in-canada/
- S44. What institutions does Plaid support? Plaid. Accessed August 19, 2026. https://support.plaid.com/hc/en-us/articles/17549112773783-What-institutions-does-Plaid-support
- S45. US and Canada Bank Coverage Explorer. Plaid. Accessed August 19, 2026. https://plaid.com/docs/institutions/
- S46. TD Bank Group and Plaid enter into North American data-access agreement. TD Bank Group. December 14, 2023. https://td.mediaroom.com/2023-12-14-TD-Bank-Group-and-Plaid-enter-into-North-American-data-access-agreement
- S47. Mastercard Open Banking. Mastercard. Accessed August 19, 2026. https://www.mastercard.com/global/en/business/open-banking.html
- S51. The new Consumer-Driven Banking Act explained. DLA Piper. April 1, 2026. https://www.dlapiper.com/en-us/insights/publications/2026/04/the-new-consumer-driven-banking-act-explained
- S52. Open banking in Canada: Key insights into the proposed regulations. Norton Rose Fulbright. August 1, 2026. https://www.nortonrosefulbright.com/en/knowledge/publications/83263b6e/open-banking-in-canada-key-insights-into-the-proposed-regulations
- S58. PROV-DM: The PROV Data Model. W3C. April 30, 2013. https://www.w3.org/TR/prov-dm/