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 powers Symcor's Open Banking platform, enabling secure data sharing between Canadian financial institutions and fintech apps — replacing risky screen scraping with user-permissioned access.
Designing Trust:
Building Canada's Open Banking Consent Experience
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.
Unfamiliar Mechanism
Designing the moment where users decide whether to grant a fintech access to their banking data. This is a high-stakes, low-trust interaction — users are being asked to share financial information through an unfamiliar mechanism.
White-Label Requirement
The solution needed to be white-label — it had to work across different banks and fintechs, not just one brand. That meant designing a system, not a single product.
Small Team
Small in-house team. No dedicated research function. I was operating as both the designer and the person scoping the problem space.
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.
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
Designing Autonomy Within Constraints
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
Data clusters 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
Iterative Decision-Making Under Shifting Requirements
Stage: Data Provider - Authentication & Authorization
Version 1: The International Baseline
Flow: Bank login → T&C → Data cluster disclosure → Account selection → Review → Redirect to fintech
Placed T&C immediately after login, before users saw any data details. This followed international precedent but meant users were agreeing to terms before understanding what data would be shared or which accounts were involved — consent before context.
Version 2: Simplification
Flow: Bank login → Account selection → T&C → Review → Redirect to fintech
Streamlined the flow by removing the data clusters step and moving T&C after account selection. This reduced friction, but created a different problem: users were choosing which accounts to expose before understanding the terms governing that access.
Version 3: Regulatory Alignment with FDX
Flow: Bank login → Data cluster disclosure → T&C → Account selection → Redirect to fintech
Reintroduced data clusters for FDX alignment and repositioned T&C directly after — so users first see what data is being requested, then review the terms that govern it, before selecting accounts. The final screen combines account selection with an inline T&C checkbox, giving users a single confirmation point with full visibility. This meant T&C now sits between understanding and action, and remains accessible at the moment of commitment.
The Summary
Designing consent in an emerging regulatory space meant every decision had to stand on its own reasoning — no established playbook, no large-scale user testing to fall back on. This project sharpened how I balance user clarity, compliance, and system flexibility under real constraints.
If I could revisit it, I'd push harder for usability testing — not to change the decisions, but to strengthen the evidence behind them.
