[Ally Case Study] - One Time Passcode Loop Fix

As a Senior UX Designer for Ally, I’ve had the opportunity to work on a number of interesting projects across a variety of spaces. For this project, product came to design and made us aware of a critical flow defect that was affecting a number of users across the platform. I built a solution that resolved this defect while having minimal impact on risk and the UX as a whole.

The Problem

When a borrower applies for a loan with Ally Lending, they need to verify some information about themselves so that we know we’re sending the information to the right email address. Once a borrower has entered their information, we ask them to go to their email and enter the code we send them. That flow looks like this for anyone that doesn’t use the Gmail app for iOS:

When someone uses the Gmail app for iOS, however, they run into an issue where they get stuck in a loop. If configured to use the “Safari” browser, the user can’t leave the browser session and come back. The only way to get back to the user’s email is to close the session, forcing them to start over.

What the flow actually looks like this this:

Considerations

From a risk perspective, there are a few considerations that have to be made for the implementation of this session loading solution. Firstly, it is mathematically possible (though exceptionally unlikely) that a bad actor could intercept the session link and discover personally identifiable information (PII) at the review screen. This creates an opportunity for identity theft, so mitigating that course of action is a top priority.

The first way to prevent this is to not show any PII that was entered in the first part of the experience before the session resume. That way, if someone was able to intercept the session resume link, there wouldn’t be any PII to access. This does, however, impact the user on the review screen.

The second option was to attack the problem from an info-sec perspective. I suggested we bring in the security and engineering teams to assess what options we had available to us. I proposed that through the use of rate limiting and REST service protections, we might be able to defeat brute force attacks and DDoS opportunities in such a way that it reduces the likelihood of an interception to be effectively zero.

The third option was the simplest option. I suggested we use explicit language in the email that directs users not to use the Gmail app for iOS and to instead continue their application on a desktop computer or in the native iOS Mail app.

Decision

Ultimately, we chose to proceed with option 1. I fought really hard for the third option, but our business stakeholders decided they were comfortable degrading the UX in order to reduce the number of calls to our customer support center without creating a security risk where a third-party could intercept the application. Despite having the support of my team and executive director, our business partners moved forward with the session resume flow. Sometimes, the impact on the UX is less important that the impact on the bottom line.