The Brief

The brief for this project was from a mobile only challenger bank called Wolla, who wanted to create an alternative method for resetting a user's password. The current system involves a customer support representative manually resetting a user's password. This is both time consuming for Wolla and means that a customer has to wait ~2 hours to be able to access their bank account, which is a huge amount of friction for the user.

The solution has to use no less than two independent types of Multi-Factor Authentication ( to reduce risk of any Wolla account being compromised.

Competitor Analysis

  1. Monzo

Monzo actually uses the 'magic email' system for all logins, negating the need for a password reset flow at all. This method uses two genuine types of Multi-Factor Authentication (MFA), something you have: the phone/email account and something you know: the user's PIN. However, in the Wolla brief, the information lost was the user's PIN. The secondary information that Monzo uses is therefore not useful in this case.

+ Speed of login

+ Ease of login

- Relies on data our users don't have access to

2. Revolut

Revolut does not cover two types of MFA, only something you have: the phone. I also question the security of the something you have being the phone that an attacker may have stolen. I don't believe that this solution is secure enough for Wolla's needs.

+ Speed of login

+ Ease of login

- Lack of security

3. Halifax

The Halifax app has by far the most security (as may be expected from a traditional bank). However, the downside of this is that it takes longer to log in and is a more involved process. There is a risk of user drop-off at this point, and the complex rules for the memorable data would make it more likely for a user to forget this next time they log in and have to start the process again. (I actually checked my history and I've personally reset this data 4 times, so that would seem to be the case).

+ High security

- Slow to login

- Difficult to remember memorable data


An initial idea I had was to supplement a 'magic email' solution with memorable data. However, I couldn't assume that Wolla already had data like this stored, and adding a new flow to the app to ask users to add this data would both increase complexity and wouldn't solve the problem for users who had already forgotten their PIN (they wouldn't be able to log in to add the memorable data).

The Design

My proposed solution takes the 'magic email' concept, but adds extra security in the form of user data. As I didn't want to ask users to add their own memorable data, I decided to use data that Wolla already has. To open a bank account in the UK, certain data is required, including both date of birth and address. I've therefore added date of birth and postcode as requirements for a user to be able to reset their PIN. This is data that any user would know without having to look it up (unlike NI number, for example) but having two separate types of data increases the security.

This solution now covers two independent types of MFA - something you have: both the phone and email address, as well as something you know: the user's date of birth and postcode.

I believe this solution should be simple for users, and secure enough to prevent unauthorised access.

The design can be viewed over the next two pages of this document.


Due to the short turnaround of this exercise, user testing was difficult. I conducted some informal guerrilla testing, and found that the design was understandable and easy to use. Considering that frictionless interaction was one of my goals, I consider this prototype to be a success.

I did, however, have to make some copy changes for clarity and brevity. Ideally, I'd need to test this design on more users, which I would do in a fuller project.

Next Steps

  • Further user testing

  • Adding Wolla branding

  • Implementing (or creating!) the Wolla design system

Measures of success:

  • Amount of time customer support spends on calls decreases

  • Analytics for the password reset flow (for all stages, to track user drop off)