Issuer Domain Controls on Payment Tokens

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Financial instrument issuers lack the ability to specify domain restrictions or controls on payment tokens, as existing systems often impose network-imposed restrictions without allowing issuer-defined settings.

Innovation Solution

The system allows issuers to specify and apply their own domain controls or restrictions on payment tokens by using a bank identification number (BIN) or cryptogram parameters, enabling dynamic control over device-specific, merchant-specific, time-specific, geography-specific, or authentication-level-specific transactions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the payment network applies domain restrictions or controls on tokens, then fraud reduction is improved, but issuer control over transaction restrictions is lost

Engineering Contradiction:
Improvefraud reductionVSAvoidissuer control
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system segments control authority between the payment network and the issuer. The payment network provides baseline domain restrictions for fraud reduction, while the issuer can overlay additional custom restrictions. This segmentation allows both parties to maintain appropriate control levels without one completely overriding the other.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system merges the payment network's domain restrictions with the issuer's custom restrictions into a combined control framework. Both sets of restrictions are applied together during transaction processing, allowing the benefits of network-level fraud prevention to be combined with issuer-specific control requirements.

Inventive Principle:
Principle #5Merging (Combining)

2Reliability

If the payment network imposes network-imposed restrictions on tokens, then transaction security is improved, but issuer-defined settings are lost

Engineering Contradiction:
Improvetransaction securityVSAvoidissuer-defined settings
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The issuer defines custom domain restrictions in advance during token request, before transactions occur. These pre-defined restrictions are then applied automatically during transaction processing alongside network-imposed restrictions, ensuring issuer preferences are honored without requiring real-time intervention.

Inventive Principle:
Principle #10Preliminary action

3Manufacturing precision

If custom issuer-specific domain controls are implemented, then transaction control precision is improved, but system complexity increases

Engineering Contradiction:
Improvetransaction control precisionVSAvoidsystem complexity
Core Design Contradiction:
Manufacturing precisionVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary mechanism (custom domain restriction parameters passed during token request) that enables precise issuer control without requiring the issuer to build complex restriction management systems from scratch. The payment network and token service provider handle the complexity of enforcement, while the issuer simply defines its policy parameters.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3753275B1Systems and methods for issuer-specified domain controls on a payment instrument
Publication Date: 2024.05.08 JPMORGAN CHASE BANK NA
  • EP3753275B1 patent drawingFigure 1
  • EP3753275B1 patent drawingFigure 2
  • EP3753275B1 patent drawingFigure 3

AI summary

Systems and methods for issuer-specified domain control on a payment instrument are disclosed. In one embodiment, in an information processing apparatus comprising at least one computer processor, a method for issuer-specified domain controls on a payment instrument may include: (1) receiving, from an issuer of a financial instrument, an identification of a domain control or restriction on a payment token for the financial instrument, the domain control or restriction to be applied by the issuer; (2) requesting generation of the payment token with a pass-through indicator from a token service provider; (3) receiving, from the token service provider, the payment token; and (4) storing an association of the domain control or restriction and the payment token.