Skip to content

UserConfidenceScore

ianbjacobs edited this page Sep 17, 2018 · 10 revisions

This is a draft document with no consensus. It is for discussion purposes.

Background To Discussion on User Confidence Score

In the card payments industry, risk analysis places an important role in fraud reduction. The 3-D Secure 2 specification from EMVCo describes two approaches for gathering data to verify the cardholder. The first involves using JavaScript from an issuing bank to gather device data. The second involves explicit multifactor authentication of the user.

For some time, the Web Payments Working Group has discussed whether and how to improve on this work by integrating standard features into browsers. This document describes at a very high level, an idea for a standard browser API whereby the browser could issue one or more "confidence scores" that could be used as input to risk analysis processes.

Examples

The following examples are for discussion purposes.

Standard scoring for device characteristics

  1. High risk device
    • Confirmed fraudulent transaction reported involving this device
    • Suspicious behavior
  2. Moderate risk device
    • Device alteration (e.g., rooted, unlock bootloader)
    • Other patterns (e.g., specific pages visited)
  3. Neutral device
    • New device or no known good or bad history
  4. Trusted device
    • Device account linkage tenure of at least 6 months AND positive financial activity each month from same device for at least 3 months
  5. Highly Trusted device
    • Device/Token Requestor account linkage tenure of at least 12 months AND positive financial activity each month from same device for at least 6 months

Standard scoring for user

Note: These may or may not involve a user account.

  1. High risk user
    • User did not complete successful authentication within last 30 days.
    • Suspicious behavior.
    • Fraudulent activity due to illegitimate user behavior identified.
  2. Moderate risk user
    • Recent password reset
    • Recent unusual number of failed logins
  3. Neutral user
    • New user or no known good or bad history
  4. Trusted user
    • User tenure of at least 6 months AND Positive Financial activity each month for at least 3 months
  5. Highly Trusted user
    • User successfully authenticated within last 30 days, or
    • Token Requestor account tenure of at least 12 months AND Positive Financial activity each month for at least 6 months

Benefits

  • An API would eliminate the need for third-party JavaScript and could reduce the amount of data requested.
  • It would also allow for consistency across browsers and may improve data quality. There are also opportunities to achieve data consistency with the native SDK version of 3 D-Secure 2.
  • There are also opportunities to improve user privacy and user experience through browser configurations and consent mechanisms.

Other Notes

  • Browser could provide stable opaque identifier to issuer. Issuer could monitor usage over time and assign risk to that identifier + card combination.
Clone this wiki locally