Case Study · 2023 · Banking / Open Banking
An end-to-end Open Banking experience for Cynergy Bank — turning a complex API ecosystem into a clear, secure and confident customer journey.
0%
Task completion
0%
Faster journeys
0%
Fewer consent drop-offs
0M+
Annual API transactions
Customers expect banking to work inside the products they already use. Open Banking makes that possible — but only if the experience feels legitimate, transparent and recoverable.
Behind a single customer action sat third-party apps, authentication, consent, Open Banking APIs, Wipro's platform and Cynergy Bank's core systems. The UX task was to make that invisible complexity feel clear and trustworthy.
An end-to-end experience built on four principles — transparency, consent, control and confidence — covering authentication, permissions, account information, beneficiaries, payments and failure recovery.
Product / UX Designer across discovery, journeys, information architecture, consent and payment flows, negative scenarios, wireframes, visual design and prototypes, working with a design lead, a UX designer, BAs and engineering.
95% task completion, 40% reduction in journey time, 35% reduction in consent drop-offs, and an experience supporting 20M+ annual API transactions.
What sits behind one tap
From a system view, APIs simply make banking services accessible. From the customer's view, the same moment raises uncomfortable questions — and money is involved.
Questions customers actually ask
Problem statement
How might we simplify complex Open Banking journeys so customers can securely access banking services through third-party providers while clearly understanding consent, authentication, permissions and transaction status?
Who felt it
Customers of Cynergy Bank using authorised third-party apps.
Why it mattered
Financial information and real money — hesitation becomes abandonment.
Business consequence
Consent drop-offs break the value of the whole API programme.
Constraints
Regulated flows, API behaviour, multi-party ecosystem, four platforms.
The earliest and most useful thing I learned: designing only the screens the customer touches ignores the systems that decide what those screens can honestly say.
What the customer sees
What happens behind it
Cynergy Bank
Owns banking operations, data and security.
Wipro platform
Provides the Open Banking APIs and integration layer.
Developer portal
Documentation and resources for TPPs and developers.
Rather than one user, this product had five stakeholders whose needs constrained each other. I framed the research around what each one had to understand or protect.
What do I need to understand before I trust this?
What do we need to integrate successfully with the platform?
What operations and data must stay secure and controlled?
How do APIs and documentation stay predictable?
How do business, design, technology and compliance stay aligned?
Customers needed confidence they were inside a legitimate banking flow — especially at the moment of redirection.
Users needed to know exactly which information they were granting access to, and why it was needed.
Consent had to feel like an active decision, not a screen people were pushed through.
Banking journeys cannot assume success — every failure needed an explanation and a way forward.
Failure states the experience had to account for
Opportunity statement
Treat the handover between third-party app and bank not as a technical redirect, but as a trust transition — the single moment where the entire journey is either believed or abandoned.
Nine stages, mapped from the customer's perspective and annotated with the UX goal at each transition.
Stage 01
The customer logs into the third-party application.
Customer goal: access a banking-related service.
Stage 02
The customer chooses Cynergy Bank as their bank.
Customer question: “Why am I being asked to connect my bank?”
Stage 03
Permissions and requested information are shown.
UX goal: make the request understandable before asking for consent.
Stage 04
The customer authenticates through the banking journey.
UX goal: maintain confidence while moving between systems.
Stage 05
The customer explicitly approves the requested access.
UX goal: transparency and control.
Stage 06
The TPP sends the authorised request through the APIs.
TPP → Wipro Open Banking APIs → Cynergy Bank.
Stage 07
The bank validates and processes the request.
Account details, balance, available funds, transactions, beneficiary or payment initiation.
Stage 08
The response travels back through the platform.
Cynergy Bank → Wipro APIs → TPP.
Stage 09
The TPP presents the result to the customer.
The customer sees the outcome, not the API complexity.
The APIs were organised around capabilities. The experience had to be organised around what people were trying to do.
Information architecture
Connect bank
Accounts
Payments
Permissions
Support
Core flow · connecting a bank account
The critical moment is the transition between the TPP and the bank — designed as a trust transition rather than a redirect.
Payment journey
Payments carry higher emotional risk than viewing information, so status and recovery became first-class requirements: what happened, is my money safe, was it successful, what next.
Instead of asking only what happens when everything works, I worked through what happens when it doesn't. This is the contribution that moved the work from screen design to service design.
| Scenario | Customer concern | UX response |
|---|---|---|
| Session timeout | “Do I need to start again?” | Clear status + recovery |
| API timeout | “Did my request reach the bank?” | Explain the processing state |
| Payment failure | “Did money leave my account?” | Clear outcome + next action |
| Invalid request | “What did I do wrong?” | Human-readable explanation |
| Authentication failure | “Why can't I continue?” | Explain + retry |
| Insufficient funds | “Why was the payment rejected?” | Clear reason + recovery |
| Expired consent | “Why am I being asked again?” | Explain renewed authorisation |
Every debate about wording, placement or number of steps was resolved against these four.
01
Tell users what is happening. What data? Why? Who?
02
Let users make informed decisions. Consent should feel like a choice.
03
Make every system transition understandable. Never leave users wondering.
04
Every failure provides a path forward — not just “something went wrong”.
Wireframes let the team agree on permission clarity, authentication transitions, status and recovery before anything was styled. Business approval was required before moving into visual design.
Wireframes focused on
Visual direction — trust, clarity, stability, confidence
The objective was never to make banking look technical — it was to make the complexity feel invisible.
The prototype connected the major journeys end to end so the team could judge the experience as a whole. Flows and scenarios were reviewed with the Business Analyst and wider team before final visual design.
Account connection
Select bank → Authentication → Consent → Connected
Account information
Account → Balance → Available funds → Transactions
Beneficiary
Beneficiaries → Add → Verify → Confirmation
Payments
Payment → Review → Authentication → Processing → Status
Recovery
Error → Explanation → Action → Recovery
Iteration cycle
The most important shift was moving from “does this screen work?” to “does the complete service make sense?”
Reported project outcomes. The larger value was an experience that could sit on top of a complex Open Banking ecosystem without losing trust.
0%
Task completion
0%
Reduction in journey time
0%
Reduction in consent drop-offs
0M+
Annual API transactions supported
Qualitative outcome
I worked in a team of three designers — a design lead, a UX designer and me — alongside business analysts, stakeholders and engineering.
The contribution I am most proud of is thinking through what could go wrong, rather than designing only the happy path.
Why it mattered
In a multi-party ecosystem, the honest answer to “what should the user see next?” depends on what the API can confirm.
How it changed my approach
I now start by mapping system states before layouts.
Why it mattered
Timeouts, rejections and expired consent were where customers decided whether to trust the bank again.
How it changed my approach
I treat negative scenarios as required deliverables, not edge cases.
Why it mattered
Drop-offs were less about steps and more about people not understanding what they were approving.
How it changed my approach
I write permission content before designing the permission screen.
Why it mattered
Removing detail felt cleaner but left people uncertain about their money.
How it changed my approach
I sequence information by moment instead of reducing it.
Why it mattered
BA reviews surfaced regulatory and API realities that would have invalidated pretty flows.
How it changed my approach
I bring flows to BAs early, in low fidelity.
Open Banking created an opportunity for customers to access banking services through authorised third-party providers. Behind every simple action sat authentication, consent, APIs, security, third-party applications and Cynergy Bank's core systems.
I mapped the ecosystem, researched customer behaviour, identified trust and usability barriers, created journeys and information architecture, explored positive and negative scenarios, developed wireframes, collaborated with business stakeholders, and translated the validated experience into visual designs and prototypes.
The result simplified account connectivity, consent, authentication, account information, beneficiary management and payments while giving people clear status and a path out of failure — with 95% task completion, 40% faster journeys, 35% fewer consent drop-offs and support for 20M+ annual API transactions.
Great UX doesn't remove complexity from the system — it removes unnecessary complexity from the customer's experience.