Issuer Access Token Management for Cardholder Data Consent

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Issuers are often excluded from the process of granting or revoking access to a consumer's financial data by Fintechs, leading to a lack of control over consumer consent management and potential unauthorized access.

Innovation Solution

A computing system with a processor and database is used to generate and manage issuer access tokens, allowing issuers to control and revoke digital access tokens for Fintechs, ensuring consumer consent is managed and monitored.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If issuers are excluded from the process of granting or revoking access to consumer's financial data by Fintechs, then Fintechs can operate independently with direct consumer access, but issuers lose control over consumer consent management and cannot prevent unauthorized access

Engineering Contradiction:
Improveindependent access managementVSAvoidconsumer data security
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent introduces an intermediary consent management system that sits between the issuer and the Fintech access requests. This intermediary receives access requests from Fintechs, verifies consumer consent through the issuer's authentication system, and only grants access when proper authorization is confirmed. This resolves the contradiction by enabling independent Fintech operations while maintaining issuer control and consumer data security through the intermediary verification layer.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If consumers grant direct access to Fintechs without issuer involvement, then access processes become simpler and faster, but consumers cannot revoke access through their issuer and may forget which Fintechs have access

Engineering Contradiction:
Improveaccess grant speedVSAvoidaccess revocation capability
Core Design Contradiction:
ProductivityVSEase of operation

Solution Approach 1:

The patent implements preliminary action by having consumers authenticate and grant consent through the issuer's authentication system before Fintechs can access their data. The issuer pre-issues access tokens only after verifying consumer authorization. This allows fast Fintech access once granted, while maintaining the issuer's ability to revoke access later through the same authentication channel, resolving both the speed and revocation capability needs.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If issuers implement comprehensive consent management systems to track and control all Fintech access, then consumer data security is improved, but system complexity and implementation costs increase

Engineering Contradiction:
Improveconsent management controlVSAvoidsystem architecture
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent leverages the existing issuer authentication system to perform multiple functions: verifying consumer identities, managing consent preferences, issuing access tokens to Fintechs, and revoking access when needed. By making the authentication system universal and multi-functional rather than creating separate dedicated consent management infrastructure, the patent achieves comprehensive consent management control while minimizing additional system complexity.

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

Data Source

PatentUS20250272665A1Systems and methods for consent management by issuers on behalf of cardholders
Publication Date: 2025.08.28 MASTERCARD INT INC
  • US20250272665A1 patent drawing
  • US20250272665A1 patent drawing
  • US20250272665A1 patent drawing

AI summary

A computer system includes a database, a communication interface, and a processor. The processor is programmed to receive a request message from an issuer computing device. The consent message includes a client ID and encrypted transaction card details for a transaction card account. The processor is also programmed to decrypt transaction card details. The processor is also programmed to match the client ID to the transaction card details using a BIN mapping table stored in the database. Based on the mapping, the processor generates an issuer access token. The issuer access token is associated with the transaction card account. The processor stores the issuer access token in the database and transmits the token to the issuer computing device.