Context
Symcor | 2022–2023
Open banking is a regulated framework that lets consumers securely share their financial data with third-party services through standardized channels — instead of handing over credentials or downloading statements.
The system involves four parties: consumers who authorize access to their data, data providers (banks and credit unions) who hold it, data recipients (fintechs) who use it to power their services, and the utility — the infrastructure layer that provides the consent management system and data-sharing protocols connecting all three.
My work focused on this utility layer, designing the consent and authorization experience that sits at the center of every connection.
Role
Lead designer. Owned the full design lifecycle: discovery, ideation, testing, iteration, and handoff. Collaborated closely with product and development teams throughout.
Impact
Now in production on Symcor's Open Banking platform, powering live data sharing between major Canadian financial institutions and fintech apps — replacing risky screen scraping with user-permissioned access.
Open Banking - The Consent Flow
All company names, brands, and data shown in the sample screens are fictitious and used for demonstration purposes only. They do not represent any real institution or individual.
The Problem
Regulatory Complexity
Open banking was emerging in Canada — no established domestic pattern to follow. Unlike the UK (PSD2) or Australia (CDR), the Canadian framework was still being defined.
White-Label System
The solution had to work across any bank and any fintech, not a single brand. That meant designing a system with the flexibility to adapt to different partners while keeping the consent experience consistent.
The Research
I studied consent patterns across the UK's PSD2, Australia's Consumer Data Right, and the FDX standard to understand how other markets handled authorization, data disclosure, and terms presentation.
These patterns informed the first version of the flow. I then handed the research to product to validate against Canada's emerging regulatory direction while I moved into design in parallel.
Before finalizing the flow, I tested the initial version with 8 participants in moderated 1:1 sessions, with a facilitator and note-taker while users shared their screen and thought aloud. What surfaced there shaped the decisions that follow.
The Consent Flow
The flow spans five stages across two environments.
Users begin on the data recipient (fintech) side with onboarding and initial consent, then are handed off to the data provider (bank) to authenticate and authorize data sharing. Once complete, they return to the data recipient's environment to manage their consent ongoing.
Part 1: The Data Permission Model
Stage: Data Recipient - Consent
The Problem
During consent, users see the specific data clusters the fintech is requesting — such as account details, transaction history, or payment information.
Giving users full control over this selection is central to the consent experience, but if they opt out of everything, the service won't function. The design had to balance user control with functional viability.
The Solution
Testing on the initial flow pointed the way. Transparency and trust were the qualities users rated highest, while security rated lowest — a signal that people trusted the flow more when they could see what was being shared, not less when they had fewer choices. Hiding the mandatory data would have worked against exactly what built trust.
Data clusters therefore were split into mandatory and optional — mandatory ones required for the fintech to function, optional ones left to the user's discretion.
I used read-only checkboxes for mandatory clusters to maintain visual consistency, keeping all shared data visible and transparent rather than hiding what users couldn't change.
Part 2: The T&C Placement Story
Stage: Data Provider - Authentication & Authorization
Version 1: The International Baseline
Flow: Bank login → T&C → Data disclosure → Account selection → Review
T&C sat immediately after login, following international precedent — but users agreed to terms before seeing any data or accounts. Consent before context.
Version 2: Simplification
Flow: Bank login → Account selection → T&C → Review
Removed the data disclosure step and moved T&C after account selection. Tighter, but now users were choosing which accounts to expose before understanding the terms governing that access.
Version 3: Regulatory Alignment with FDX
Flow: Bank login → Data disclosure → T&C → Account selection
Two forces drove this version. Product aligned with the FDX standard, bringing data disclosure back. And testing on the initial flow had surfaced a clear signal: a third of participants wanted the terms earlier, most before bank login. So rather than revert to Version 1, I placed T&C directly after data disclosure and before account selection — users see what's requested, review the terms that govern it, then act. The final screen folds account selection and an inline T&C checkbox into one confirmation point. Consent now sits between understanding and action, and stays accessible throughout.
The Summary
Designing consent in an emerging regulatory space meant every decision had to stand on its own reasoning. But reasoning wasn't the only input. I tested the initial flow with real users, watched where their understanding broke, and let that reshape the design — the T&C repositioning and the permission model both trace directly back to what users struggled with in those sessions.
The initial flow scored well on trust and transparency but lower on security perception, which told me the work wasn't more assurance language but more visibility. Clarity over reassurance carried through every decision after.