Transparent Banking
- Status
- Field report v1
- Timeframe
- 1 month to build; 3 months to measure
- Role
- Head of Product Design
- Team
- 1 designer, 1 PM, 2 developers, support analytics, legal, growth
- 22%
- Reduction in charge-related support calls among exposed users
- 30-40%
- Users exposed through top quick-action placement
- 3 months
- Measurement window after launch
- GFF 2024
- Publicly launched at Global Fintech Fest
Banking information existed, but users could not use it.
Charges were hard to understand. Terms and conditions were written in legalese. App permissions were requested without clear explanation. Data practices were vague.
Call-center data showed that charge-related queries were a major support driver. The problem was not only that information was missing. It was that the information users needed to trust the bank was scattered, technical, or hidden inside low-visibility surfaces.
From disclosure to trust infrastructure.
We stopped treating transparency as a compliance box to tick and started building it as part of the product.
Transparent Banking became a visible trust surface, not just a charges or T&C page.
From
“Where do we disclose this?”
To
“What does the user need to understand before they trust the bank?”
- Simplified charges
- Upcoming charges specific to the user’s account
- Charges already levied
- Simplified terms and conditions
- Banking glossary / banking dictionary
- App permissions and why they are needed
- Data stored about the user
- How user data is used
- Secure data practices
- Complaints / key fact sheet
- Transparency pledge
The philosophy extended beyond the section itself. Charges were also shown upfront before account creation, even if that could create a small funnel hit, because long-term trust and acquisition quality mattered more than hiding friction.
Create one visible trust destination
Charges, T&Cs, permissions, data practices, complaints, and commitments were brought into a single user-facing hub instead of being scattered across support and legal surfaces.
Make charges personal
A generic schedule of charges explains what the bank can charge. Users needed to understand what had been charged to their own account and what could be charged next.
Use plain language, not banking language
The section simplified terms, charges, permissions, and data practices so users could understand them without legal or financial interpretation.
Fight for high-visibility placement
Transparent Banking was not immediately monetizable, so placing it in the top four quick actions required alignment with growth around trust, brand, and support-cost impact.
Turn transparency into philosophy
The goal was not just to publish one section. The principle had to influence other journeys, including showing charges upfront before account creation.
- Charge noticed
- User confused
- Searches app / support
- Calls customer care
- Waits for explanation
- Trust erodes
- Charge noticed
- Opens Transparent Banking
- Checks simplified / upcoming / levied charges
- Understands reason
- Avoids support call
- Trust improves
Transparent Banking, end to end
The full journey that earns customer trust through transparency.
22% reduction in charge-related support calls among users who visited Transparent Banking.
- Source
- Month-on-month call-center data for charge-related calls, filtered for users who visited Transparent Banking.
- Measurement window
- Observed over three months after launch.
- Scope
- Charge-related support calls only, not total support calls.
- Attribution
- Directionally attributable to Transparent Banking because the reduction was observed among users exposed to the section. This gave confidence that wider exposure could reduce charge-related calls at a broader level.
- Placement
- Placed in the top four quick actions, exposing it to approximately 30-40% of users.
As Head of Product Design, I led the discovery and framing of Transparent Banking.
I listened to customer-care calls to understand where users were getting confused, especially around charges. I also ran user interviews to identify what else belonged in a transparency section beyond charges and terms.
- Identified charge-related support calls as a major problem
- Shaped Transparent Banking as a trust philosophy, not a utility page
- Directed the information architecture and UX
- Expanded the section through user interviews and stakeholder input
- Aligned product, growth, legal, support, and engineering
- Pushed for high-visibility placement despite unclear immediate monetization
Transparency is not disclosure.
Disclosure protects the bank. Transparency helps the user.
Trust can reduce cost.
Clear explanations can reduce avoidable support calls.
Non-monetizable surfaces can be strategic.
Not every important product surface has immediate revenue ROI.
Plain language is a product decision.
Simplifying banking language can change user trust and behavior.
From explanation to control.
The next evolution is to integrate DPDP and turn Transparent Banking into a Consent Centre.
Users should be able to review every consent they have given to the bank, including account-opening consent, standing instructions, WhatsApp communication consent, data-use consent, and other permissions, and revoke them from one central place.
Transparent Banking should evolve from explaining trust to giving users control over it.