Identity and Authentication Projects

Due to the sensitivity of this space, the details of the flows and nuanced experiences need to remain confidential.

This started real small. And then it just. kept. growing. We. had. so. many. questions.

 
 

THE ORIGINAL PROBLEM SPACE

When I joined Capital One in the fall of 2019, I became responsible for Identity Design across the Commercial Bank, but primarily focused on an urgent task within Treasury Management. The team was starting to synthesize and wrap qualitative client research and was creating wireflows to reimagine user enrollment.

60% of client servicing tickets were related to enrollment or passwords. The existing enrollment process (real screen shot left) was…less than ideal.

5,000 RSA tokens were set to expire in January and the desire was to push users to mobile and reduce call volume through proactive change management. The business didn’t like RSA tokens because:

  1. They believed tokens were hard to use.

  2. Tokens were expensive to license and procure.

  3. There was a cyber security finding against tokens at that time.

There were more than 15 different client-facing logins just in Treasury Management, many provided by vendor solutions.

SSO was desired, so how do you do that and provide 100% access?


SYNTHESIS AND ESTABLISHING THE CURRENT STATE

The team had already completed more than 30 interviews focused on the problems with the current authentication experiences, mobile versus landlines, employer mindsets and restrictions around mobile, and hard tokens of course. I helped facilitate synthesis across design, product, and tech as an initial learning experience and to get to know my team.

The basic TL;DR —- people were used to tokens; were told to use tokens; and thought they were more secure than mobile.

Yes, that’s literally a tackle box full of tokens from an existing client who engages with multiple banks. But some users have multiple tokens for multiple logins to the same bank — think about an accountant who services multiple companies.

When I asked for the usage and metrics data, it was rather unclear. 80% of users renewed hard tokens. 93% of the top 20% of clients by revenue used hard tokens…but 64% of that data was marked as “N/A.” Wait, what?

Basically, authentication policies at companies…vary.

Company policy is no mobile access to banking
— Existing Client
We’re mostly working against inertia, not policy.
— Study Participant
We don’t want the cell phone used for banking or transactional ... using it solely for auth is okay though.
— Existing client

quick and dirty concept testing | workshopping the future mobile state

At this point we did some quick and dirty concept testing to get some detailed sentiment findings. We tested three screens — login page, username/password, and then the different MFA method. We tested sentiment for hard tokens, voice/IVR, SMS OTP, and App Access (AKA push auth).

The concept testing showed that individual users strongly preferred mobile MFA solutions; but their companies’ policies were split.

My team mapped the current state mobile and non-mobile enrollment processes, and proposed a future state for mobile push authentication, and documented alternative journeys. We also started prepping for a workshop with design, product, tech, architecture, and cyber. We wanted to walk through the current state process journey mapped to personas and then walk through a concept of the future for mobile push authentication.

outcomes at this point

  1. Without a new solution in place, my product partner and I wrote servicing scripts based on the user sentiments and research and provided training to transition users to the existing mobile app OTP offering as the 5,000 RSA tokens expired. We hoped to use it as a learning opportunity. For a variety of reasons, only a tiny amount of users converted to mobile —- this was pre-Covid.

  2. I also went and shadowed servicing as we provided training to listen to calls, map their processes, get to know them, and learn about their day-to-day with authentication issues and what information they use to authenticate users who call.

  3. Among other things, the workshop and shadowing servicing confirmed that we didn’t have validated mobile phone numbers for our users (say what!?). This kicked off a mobile phone number collection design pilot.

TL;DR - It was clear we needed both a mobile, and a non-mobile solution to reach 100% of use cases.


EXPANDING THE SCOPE TO ALL OF COMMERCIAL after a reorg

A reorg at this point combined Treasury Management and Commercial Card into one B2B Payments team. Before committing to development and change management, the new leadership wanted us to consider:

  1. A generic mobile solution across all of Commercial Banking, not just treasury management

  2. Alternatives to RSA and the subsequent impacts to enrollement

Okay, makes sense, let’s roll…

My team designed, tested and spec’ed a mobile phone number collection flow and pilot. I’m a fan of documentation outside of the the design file.

We inventoried experiences and validated that the enrollment design would scale across the Commercial Banking uses cases —- irrespective of when that was adopted across the 25+ applications.

I lead research on hard token replacements for RSA with product, enterprise, tech, and supplier management support.

After deciding on an RSA alternative, we created a simplified evaluation of Yubikey versus Voice OTP as the backup mobile solution.

My team performed the first unmoderated usertesting.com study in the commercial bank to compare task completion alternatives.

We also completed a data inventory of all of the fields for user profiles across the commercial bank as we started designing out generic user preferences. This became the basis for a central identity database.

We wanted to know the worst cases. We redesigned the user preferences preference page and navigation to make it generic leading to 3X additional usage.

 

We have a solution now. We’re good, right? Not…exactly.


considering a partnership with consumer identity

We’d nailed down a lot of must haves and desired functionality. Before committing to development and change management, VP+ leadership asked us to consider a partnership with consumer identity who had created different infrastructure but an order of magnitude more teams supporting it.

  1. We needed phone number collection —- they provided a version of that.

  2. We wanted mobile push authentication — they provided a version of that.

  3. We wanted to consider SMS OTP — theirs was more secure with future options for “step up” for risky transactions

  4. There were other reasons I won’t mention.

  5. There were reasons not to partner with them as well. (Permissions was a big one).

I lead the design effort to evaluate and compare uses cases with partnership from consumer identity’s awesome designers. We re-imagined our flows taking into consideration different aspects of the consumer experience while product and tech consider timelines, LOE, and order of operations.

At the end of the engagement we facilitated an internal-to-commercial design sprint to build alignment. That workshop resulted in the final scoping and future path. The decision was made that consumer identity was the end destination for many, but not all experiences and infrastructure.

And we had a strategy!! But one that required a lot of technical components to be built and migrated first. Those first steps are happening now.


Matt does a lot with a little. Despite being significantly under-resourced, he has managed to provide support for everything I’ve asked of him. This has required creative thinking and careful resource management, but he’s done a great job making strategic investments with his design team, and appropriately pushing back on me to confirm that the priority and problem statement are clear before offering help.
— 360 feedback from product