I sat on a panel last week at the Financial Data and Technology Association's (FDATA) 2026 Global Open Finance Summit in Toronto, titled “View From Financial Institutions” and moderated by Alex Johnson of Fintech Takes. Representatives from a Canadian digital bank, a major Canadian bank operating across multiple countries, and a large U.S. card issuer and bank with operations extending into Canada and the U.K. joined me to talk through where open finance actually stands today, on both sides of the U.S. – Canadian border and beyond. The session ran under the Chatham House Rule, so what follows reflects the substance of the discussion without attributing specific comments to specific speakers or institutions, aside from my own.
The moderator framed the whole conversation around a useful split: every institution approaches consumer-permissioned data sharing both offensively, i.e. building products and experiences that create value, and defensively, i.e. making sure it's safe, compliant, and something the institution can stand behind. What came through over the course of the discussion is that these aren't sequential stages. The panel kept circling back to the same point from both directions: the products only work if the underlying trust and risk management hold up, and the risk management only earns its keep if it's protecting something customers actually want to use.
A few concrete use cases came up repeatedly.
Onboarding was one: using consumer-permissioned data to reduce the amount of manual document verification a new customer, particularly a small business, has to go through.
Credit access was another: using cash-flow data to give customers earlier access to their own funds; to close gaps like payment holds that create disproportionate frustration relative to their actual risk; and to help thin-file customers (such as newcomers to a country with limited local credit history) to get recognised for the financial behaviour they can actually demonstrate, like paying rent on time.
Panellists pointed to mortgage lending as another clear opportunity: the back-and-forth of repeated document requests during a lending decision creates friction for the customer and inefficiency for the institution. Consumer-permissioned data access can streamline a lot of that.
Personalisation came up too, the idea that most product offers today are generic because institutions don't actually have a full picture of the customer's financial life, and that permissioned data changes what's possible there.
And in the U.K., a meaningful share of the energy right now is going into payments: for example card issuers using open banking payment initiation as a lower-cost, often easier way for customers to repay their credit cards. I specifically highlighted the new industry-led scheme, the UK Payments Initiative (UKPI), built to create real competition with the card networks using the combination of native open banking payment initiation and Faster Payments (the domestic real-time payment rail).
The most useful reframe of the day, for me, was the idea that consent should be treated less like a one-time event and more like an ongoing relationship, closer to a subscription than a signature. It's easy to design a consent screen that looks clear and then to watch user testing reveal that customers have no real idea what they agreed to. The panel's shared view was that a level of friction, a moment that actually makes someone pause and understand, is not the enemy of a good customer experience (even though fintechs often regard friction as close to a dirty word). What matters is providing the right amount of clarity at the point it's needed: what data, for how long, for what purpose, and how to switch it off.
The subscription analogy also extends to what happens after the initial consent. Customers forget what they signed up for and what's still quietly running in the background, the same way most people have a forgotten mobile app still doing something on their phone. The panel's view was that institutions have a responsibility periodically to remind customers what's being shared and for what purpose. Not because of compliance obligations, but because it's the difference between a customer who trusts the system and one who otherwise eventually may feel taken advantage of.
Asked where the biggest operational challenges have actually been, the answers were consistent: legacy systems that were never built to expose data this way, the work of reconciling an institution's own customer data with data arriving from outside sources, and a long tail of operational questions that have nothing to do with technology. Who are the various participants in the ecosystem, and what are they actually doing? Who handles a customer complaint that touches three (or maybe more) parties in a data chain? If one institution identifies a fraudulent actor, does that information reach any other participant before the same bad actor tries their luck elsewhere? None of this shows up in an Application Programming Interface (API) specification, and all of it turned out to be a bigger lift than providing those APIs.
This is the part of the discussion where I had the most to add, given where Invela sits in this ecosystem. Fraud isn't a competitive problem between institutions; whoever gets hit today, it's someone else's problem tomorrow. So treating it as proprietary just means everyone re-learns the same lessons separately and slower. That's the case for something closer to a shared intelligence utility: if a bad actor shows up in one part of the ecosystem, everyone else should be able to know quickly, not months later after their own losses force the discovery.
The second point I made, and one I think holds regardless of who's saying it, is that rigorous onboarding checks say nothing about what an entity is doing next week, particularly as agentic activity becomes more common. A thorough one-time assessment is necessary but is not sufficient: it has to be paired with ongoing, continuous monitoring. Further, that monitoring genuinely has to happen at the ecosystem level, because any single institution only ever sees a slice of what a given third party is doing across the market. Alongside that, there's real work to be done connecting this to the insurance industry, because liability commitments only mean something if there's a balance sheet standing behind whoever is deemed to be liable when a claim actually gets made.
The closing question was simple: what's the one unresolved issue standing between open finance and its full potential. Every answer, in one form or another, came back to trust. And more specifically to how a market builds and sustains a credible accreditation and trust framework as the ecosystem grows, rather than treating it as a one-time gate that's checked once and then assumed to hold. A related point that came up: this can't be a bar so high that only the largest players can clear it, nor so token that it stops meaning anything, and it has to keep being re-done as the ecosystem changes. Interoperability was the other theme that came up: as data increasingly flows in every direction between institutions, providers, and the vendors sitting between them, a consistent, standard experience is what lets customers actually develop trust in the system as a whole, as opposed to in any single relationship.
My own biggest takeaway, watching this conversation happen across a challenger bank, a global bank, and a major card issuer, is how much agreement there already is on what the problem is. Everyone on that stage agreed that trust has to be earned continuously rather than certified once. The harder question, and the one I think about most, is what infrastructure actually makes that possible at ecosystem scale rather than leaving each institution to solve it alone.
Invela is the infrastructure layer that makes open finance trustworthy - accrediting who's in the network, monitoring risk in real time, and ensuring liability lands in the right place.
-p-2000.jpg)
