Validating an assumption · myBCA

Balancing privacy and transparency in money transfers

Before sending money, people want confidence that they have enough balance to complete the transfer. myBCA's transfer screen didn't provide that reassurance. This independent exploration looks at why that small gap matters, and how a simple interaction could address it.

Project

Independent UX Exploration

Role

Self-initiated

Timeline

2025

Status

Concept

myBCA transfer to BCA account screen, showing the transfer amount field with no balance displayed anywhere on screen — The final transfer experience, allowing users to verify their available balance without leaving the transaction flow.

A small gap, but a real one.

myBCA is the mobile banking app of BCA, one of Indonesia's largest banks. Most people don't memorize their bank balance, yet that's exactly what the transfer flow expects. Before entering an amount, users have to estimate whether they have enough funds because their balance isn't visible.

The missing information

Without knowing their available balance, users have two choices: rely on memory or leave the transfer flow to check their account before starting again.

Why it matters

If users estimate too high, the transfer ends with an insufficient balance error after they've already completed the form. The interruption is small, but it happens at the worst possible moment: just before committing to the transaction.

myBCA transfer screen paired with the insufficient-balance error that appears when the entered amount exceeds the real, unseen balance — The transfer journey ends with an insufficient balance error because users couldn't verify their available funds earlier in the flow.

What eleven people told me.

I first noticed this in my own daily banking and wondered whether other people experienced the same thing. So I ran a small survey with 11 active mobile banking users. It wasn't formal research, but the pattern was remarkably consistent.

8 of 11

went back to check their balance before completing a transfer.

7 of 11

said seeing their balance during the transfer would make them feel more confident.

From the survey

"It would save time because I wouldn't need to check my balance before starting the transfer."

Research participant

Privacy versus transparency.

If showing the balance solves the problem, why isn't it already there? That became the next question to answer, and the survey pointed to a clear explanation.

One participant put it plainly: they often make transfers in public and don't want people seeing their balance. Others shared the same concern. Several assumed the balance was intentionally hidden for privacy or security. Showing it in plain sight, on a train or while waiting in a queue, can feel unnecessarily exposed.

From the survey

"Sometimes I make transactions in public, I don't want people to peek at my balance."

Research participant

So the real question wasn't 'How do we show the balance?' It was 'How do we show it only when users choose to see it?'

Giving users control
through a toggle.

The balance stays hidden by default, masked behind dots so nothing sensitive is exposed until users choose to reveal it. One tap shows the balance, and another hides it again.

I didn't redesign the screen. Instead, I placed the balance inside the existing Source Account card, where users already look when choosing which account to send from. The right information, in the right place, at the right moment, with users in control of when it appears.

Source Account card in myBCA shown in two states: balance masked as IDR followed by dots, and balance revealed after one tap — The proposed interaction keeps the balance hidden by default and reveals it only when users choose to see it.

Hidden by default, protecting sensitive information until users choose to reveal it.

One tap reveals the balance, and one tap hides it again.

Placed inside the Source Account card, where users already look before making a transfer.

The honest outcome.

This was an independent design exploration, not a client brief or a shipped feature. I started with a friction I experienced myself, validated it through a small user survey, and explored how it could be solved without disrupting the existing transfer flow.

I can't measure the impact because the concept was never implemented. What I can say is this: the problem is real, the constraint is real, and the proposed solution is small enough to fit naturally into the existing experience while directly addressing the friction.

If I took this further

I'd validate whether the masked balance clearly communicates that it can be revealed, and whether hiding it by default matches what users naturally expect when making transfers in public.

Reflection

Sometimes a product doesn't need a redesign. It needs one less thing to worry about.

Keep exploring