Network Token Assurance Level for Fraud Security

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing tokenization systems struggle to identify the source or issuer of a payment token, and they lack interoperability between different payment networks, limiting their adoption and integration.

Innovation Solution

The proposed solution involves assigning a token assurance level and associated data to each token, which is used to verify the legitimacy of the token and its issuer. This process includes identification and verification (ID&V) methods to ensure that the token is replacing a valid primary account number (PAN), and the token assurance level is based on the type and entity performing the ID&V.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If payment tokens are used to replace PANs, then security against fraud is improved, but the ability to identify the source or issuer of the token deteriorates

Engineering Contradiction:
Improvesecurity against fraudVSAvoididentification of token source
Core Design Contradiction:
ReliabilityVSLoss of information

Solution Approach 1:

The token is segmented into multiple components: a token value for transaction processing and a separate token assurance level indicator for identification. This segmentation allows the token to simultaneously provide security through obfuscation while maintaining identifiability through the separate assurance level component, resolving the contradiction between hiding PAN information and identifying token source.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A token service provider acts as an intermediary between the PAN and the token. The service provider issues tokens with associated assurance levels based on ID&V processes, enabling the system to maintain both security (through tokenization) and identification capability (through the intermediary's assurance level assignment).

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If tokens are restricted to a particular network, then token management and security control are improved, but interoperability between payment networks deteriorates

Engineering Contradiction:
Improvetoken management controlVSAvoidinteroperability between networks
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The token assurance level mechanism is designed to be universal across multiple payment networks. The assurance level indicators and ID&V processes can be implemented across different networks, allowing tokens to maintain their security properties while being recognized and processed by multiple networks, thus achieving both control and interoperability.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system uses parameter changes in the form of token assurance levels that can be adjusted based on the network context. Different networks can recognize and interpret the same token structure with appropriate assurance levels, enabling interoperability while maintaining each network's security standards through parameter-based adaptation.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS12205110B2Network token system
Publication Date: 2025.01.21 VISA INTERNATIONAL SERVICE ASSOCIATION
  • US12205110B2 patent drawing
  • US12205110B2 patent drawing
  • US12205110B2 patent drawing

AI summary

Embodiments of the invention are directed to methods, apparatuses, computer readable media and systems for providing, along with a token, a token assurance level and data used to generate the token assurance level. At the time a token is issued, one or more Identification and Verification (ID&V) methods may be performed to ensure that the token is replacing a PAN that was legitimately used by a token requestor. A token assurance level may be assigned to a given token in light of the type of ID&V that is performed and the entity performing the ID&V. Different ID&Vs may result in different token assurance levels. An issuer may wish to know the level of assurance and the data used in generating the level of assurance associated with a token prior to authorizing a payment transaction that uses the token.