When the update of the UI redesign was so fast that they missed privacy
I joined Bitwala GmbH in Berlin as a Lead QA Engineer in April 2021. Shortly after I started, I learned that the company was undertaking a major product rebrand, driven by legal claims regarding the old logo and marketing considerations.
Bitwala was positioned as a German neobank (a digital-first financial company with no physical branches), combining bank cards, SEPA payments (Single Euro Payments Area), and traditional bank accounts with crypto wallets for Bitcoin (a digital currency) and Ethereum (an open-source blockchain network for the Ether digital currency).
We had several development squads, but QA capacity was limited. When I joined, there were only three QA specialists supporting more than 20 software developers. In the middle of this intensive rebranding sprint, I was responsible for verifying the web application, mobile apps, and supporting services. This meant rapidly taking over the deployed iOS apps and validating them against a broad range of business scenarios.
One day, I reported 20 separate defects, including UI visual defects, functional issues, and layout issues. However, one issue stood out. While testing different scenarios with different accounts in staging, primarily onboarding, verification, and money-transfer flows. I discovered a serious session-management flaw.
The defect was introduced during the rebrand, when the web application’s session and navigation handling changed alongside the redesigned interface. The new UI could reuse previously loaded account data, but the logout flow did not reliably clear the client-side session state, cached API (Application Programming Interface) responses, or authenticated user context.
As a result, if a customer used a shared computer, logged in, and then left without logging out, the next person using that browser would still be able to see the previous customer’s account balances and personally identifiable information (PII). The exposure would persist until the application loaded a new page, which would then refresh the session state.
My immediate concern was that the same issue could exist in production. Unfortunately, it did.
We treated it as a critical privacy and security incident. The fix ensured that logout, session expiry, and user switching fully cleared authentication tokens, cached account data, locally stored user data, and the in-memory application state. We also added regression coverage for shared-device scenarios, including user switching, app closing and reopening, session expiry, and navigation after logout.
Fortunately, we identified and contained the issue before it became a broader incident. It also created an important learning opportunity for the whole team.
Lessons learned:
- Security and privacy checks must be maintained for release criteria, even during branding or design-focused initiatives.
- Session invalidation, user switching, and shared-device scenarios require explicit regression coverage.
- Client-side caches and application state must be cleared as thoroughly as authentication credentials.
- Staging should closely reflect production so that security issues are found before release.
- QA capacity must scale with product complexity and release scope.
- A successful rebrand is not only visual, but it must also preserve customer trust, privacy, and security.