Canada was supposed to have open banking by now. The Bank of Canada was still in info-gathering as of March 2026, no committed launch date, Phase 1 read access slipping past the original 2026 target. Even when it lands, the first version will be read-only and will not cover every account type. Treasury teams cannot wait.
Plaid is the obvious workaround. It is also the obvious non-starter for the buyers who need this most.
Why Plaid does not fit regulated finance
Plaid is itself the data processor. Every transaction your CFO buyer downloads through Plaid first passes through Plaid’s systems. For a household user that is a fine trade-off. For a family office, a fund, or a Canadian SMB with cross-border compliance constraints, it is not. They cannot send the underlying transactions to a third-party data processor and they cannot get their auditor or their counsel to sign off if they do.
The closest competitors are Plaid-bound too. Era, Mint, Copilot. Every one of them is structurally a data processor between the bank and the user. That is the design they cannot back out of.
What works instead
WKWebView and LLM-as-compiler. The bank session lives on the user’s device. The credentials never leave the phone. The extraction code is generated by an LLM exactly once per bank and then runs free forever.
This sounds exotic. It is not. It is the same shape every browser-based password manager has used for fifteen years, with an extractor compiled at install time instead of hand-written by an engineer at the vendor.
The phone is the secure execution environment. The server is the brain. Credentials never touch the wire.
The architecture
The iOS app opens the bank’s real website in a WKWebView. The user logs in normally. Cookies live in the WebView, on the device, like they would in Safari. The app does not see the password. The server does not see it either.
Once the user is on the transactions page, the app captures the DOM and sends a cleaned copy to the model with a strict JSON schema. The model returns a pure JavaScript extractor. The extractor is verified against the same DOM that produced it, hashed, and cached locally and on the server for future syncs.
Every subsequent sync runs the cached extractor. No model call. Deterministic. Free. Offline-capable. The model is invoked again only when the bank changes their UI.
Why the labs will not own this
Hosted lab products are exactly the wrong place for this workload. Every CFO buyer asks the same question on the first call: who at your company can read my transactions. The right answer is nobody. A hosted product cannot give that answer. A device-side product can.
This is also why the eventual hosted version of OpenTeller still keeps the credential-never-leaves-device property. The phone is the secure execution environment. The server is the brain: parser distribution, regeneration orchestration, transaction storage, billing. The phone holds the keys. The server holds the patterns.
Where this goes
Family offices and Canadian SMBs are the natural first market. The same architecture extends to any vertical where data residency is a hard constraint. Legal firms with privileged discovery. Healthcare providers under HIPAA or PHIPA. Defense contractors in sovereign cloud environments. None of these can hand the data to Plaid. All of them want the conversational, MCP-shaped query surface that makes the data useful.
Open banking will land in Canada eventually. By the time it does, the on-device architecture will already be the right shape for everywhere else the lab-hosted aggregators cannot go.