What is a tokenized digital identity?
Digital identity is the sum of all digitally available data about an individual, organization, or physical object - e.g. date of birth, purchase history, physical location, organization’s performance history - the list goes on. And creating a digital representation of that data is creating a tokenized digital identity.
A big problem, and an opportunity
The current process for identity verification is complex. We leave digital attributes scattered everywhere. And significant pain points, like failed transactions and fraud, affect not only the consumer but the businesses as well.
Thomson Reuters identified this unique opportunity and created the Digital Identity team to create and implement digital identity solutions for financial institution customers and their consumers. The team was a small group of 11 representing UX and design, product, engineer, and business development and strategy. We were set up to function like a start-up, allowing us to be nimble, collaborative, and fast-paced. As the senior UX architect, I led the user experience and design.
Creating a multi-pronged solution
We needed to create a platform that transformed the way our customers exchanged identity attributes with their consumers and identity providers. It had be agnostic and able to make sense of data from different sources. It had to have real-time identity verification, as that is severely lacking in the digital identity landscape. Our customers needed it to work with their existing technologies and infrastructure, and be able to customize it to their needs. And their consumers needed a way to securely share, verify, and control their identity and its attributes.
Our solution was to create a multi-faceted platform consisting of:
Front end layer plugged into the customer’s existing native mobile applications for seamless enrollment and ongoing digital wallet management of tokenized digital identity.
Web portal giving the customer the ability to configure the platform based on their authorization requirements.
Flag and rules engine that helps the customer determine risk and authorization levels and automate step-up authentication.
Algorithmic confidence score that indicates the likelihood a person is who they say they are.
Cryptographically secure back end layer that maps individual attributes to identity providers for verification and authentication.
The implementation was broken into three phases:
Prove - Build a “demonstrator” to confirm we can tie internal TR data, 3rd party data, external technology platforms, and TR together. And without existing user research, test our assumptions on the user experience.
Pilot - Targeted initial deployments will test US Government, US / Australian Payment Clearing, and Retail Banking use cases.
Deployment - Pilot and customer feedback will strengthen the platform for wider adoption and additional use cases.
Defining the use cases
We identified two main use cases:
Enrollment of service
High risk transactions authentications.
Two basic user personas were created to represent the customer and their consumer
Bank of Costa as our customer with Jane as their risk manager
Michael as Bank of Costa’s customer, the end user or consumer
The “Online Payment Transaction Verification” user scenario and journey map were created to map out the bank and their customer’s journeys. Existing Bank of Costa customers will be asked to re-enroll since they will need to verify their identities; new customers will simply enroll.
Creating the user experience
For the demonstrator, we built a web portal for Bank of Costa, as well as a native mobile banking app.
In the portal, Bank of Costa (most likely their Risk Manager) will be able to:
Choose preferred identity attributes and accepted documents.
Configure thresholds for validation.
Set up flags and rules.
To choose which identity attributes to require from the customer, and which documents are accepted, the Risk Manager just has to toggle off and on based on Bank of Costa’s preferences.
The Risk Manager will then need to define a ‘pass score’ for Document Verification, Selfie Match, and ID Proofing — three main components to validation. Anything below the score will be flagged or declined.
We had gone through a few iterations for this specific interaction. At first we tried a more granular approach. But it was confusing. We knew the pass score would be easy to understand, but how do you communicate what each component means and that the scores would sit within their own individual ranges?
I started to explore the idea of a guided experience — a more elegant approach to a walk-through. When the Risk Manager configures the thresholds for the first time, the UI will be a little different vs. after the thresholds have been configured.
For each of the components, we present the user a question that helps them understand what each component means. And then we only ask for a score value. Once the user inputs a score in whichever component they choose to start with, the UI opens up to a more detailed view. The detailed view explains the score’s logic and shows the range, where pass and fail ranges lie, and additional configurations specific to ID Proofing and its data sources.
Once the user saves the configurations, the UI updates to show just the score slider, which can be expanded back to the detailed view, but without all the contextual information, as it will be redundant by that point.
And finally, the portal also gives the Risk Manager a way to flag, fail, and pass enrollment — choose the outcome. This was another interaction that proved to be complex. We wanted to avoid having the user create each rule via a bunch of drop-downs. We first explored Natural Language Processing, allowing the user to simply type out a rule and it would auto-fill based on the context. And while the concept was interesting, it proved to be complex in a different way.
So we ended up going with the most straightforward approach. Show all the different combinations the user can create a rule for in a table layout, and keep the interactions simple. The user simply chooses to turn them off or on, the outcome, and if none of the rules apply choose the outcome for those instances.
Once the Risk Manager has completed setting up the enrollment configurations, new and existing customers will be able enroll for the service. The enrollment flow is simple and straightforward.
During the ideation process, I also explored an alternative concept that could potentially minimize the amount of steps during enrollment. It would leverage the customer’s front-facing camera from their mobile device. It never came to fruition due to lack of time and resources to research.
Once the customer, Michael, is re-enrolled, their experience could look something like the diagram below. Here, Michael has initiated large purchase on Apple.com. Bank of Costa app will authenticate customer's identity using biometrics, and allow purchase to go through.
Additional User Scenarios
We explored a scenario working with the US CBP and while leveraging Mobile Passports. But we pivoted to focus on financial institutions.
We explored and conceptualized a scenario of federated identity and how it can improve a mundane task like renting a car.
Credits
Team lead: Bob Schukai
Creative direction and UX architecture: Jennifer Lee
Product management: Jennifer Singh and Bryan Colcord
Software development: Kevin Zimmerman, Ralph Duverna, Sangeetha Glova
Software architecture: Marco Pierleoni and Mario Morgado
Project management: Claudia Schaper