Shared Hash Map Fraud Management via Blockchain

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional fraud management systems rely on expensive third-party databases for fraud data, leading to high costs and limited access to shared fraud data for real-time management.

Innovation Solution

Implementing a shared hash map system that uses a blockchain to store fraud data, allowing multiple systems to share, access, and update fraud information securely, reducing reliance on third-party systems and enhancing data accessibility.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If third-party databases are used for fraud data storage, then fraud data can be maintained and accessed, but high costs are incurred and access is limited

Engineering Contradiction:
Improvefraud data accessVSAvoidcost
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

Multiple independent systems merge their fraud data into a shared blockchain-based hash map, creating a unified fraud intelligence repository that benefits all participants without requiring expensive third-party intermediaries

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

A decentralized blockchain-based hash map structure serves as an intermediary that enables secure, transparent sharing of fraud data among multiple systems without relying on costly third-party database providers

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If conventional fraud management systems are used, then fraud data can be stored, but access to shared fraud data for real-time management is limited

Engineering Contradiction:
Improvereal-time fraud managementVSAvoidshared fraud data accessibility
Core Design Contradiction:
ProductivityVSLoss of information

Solution Approach 1:

The blockchain-based hash map structure serves multiple systems simultaneously, enabling universal access to fraud data across different organizations and facilitating real-time collaborative fraud management

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

Solution Approach 2:

Fraud data is pre-hashed and stored in the blockchain structure in advance, enabling rapid retrieval and real-time fraud detection without delays associated with traditional data sharing mechanisms

Inventive Principle:
Principle #10Preliminary action

3Reliability

If centralized fraud data storage is used, then data can be maintained, but malicious modifications cannot be prevented

Engineering Contradiction:
Improvedata integrityVSAvoidmalicious modifications
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

Instead of trusting centralized storage to prevent modifications, the system inverts the approach by using cryptographic hashing and blockchain immutability to detect and prevent malicious changes, making the system resistant to tampering

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The blockchain structure provides continuous feedback through its immutable ledger, allowing systems to verify the integrity of fraud data and detect any unauthorized modifications immediately

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS11797998B2System, method, and computer program product for fraud management with a shared hash map
Publication Date: 2023.10.24 VISA INTERNATIONAL SERVICE ASSOCIATION
  • US11797998B2 patent drawing
  • US11797998B2 patent drawing
  • US11797998B2 patent drawing

AI summary

A method, system, and computer program product for fraud management with a shared hash map. A shared hash map may include a plurality of identifiers mapped to a plurality of buckets by at least one hash function. One or more buckets of the plurality of buckets may include at least one blockchain. The at least one blockchain may include fraud data associated with one or more fraudulent transactions. A method may include storing the shared hash map, receiving an update to the shared hash map, and providing a copy of the shared hash map. A method may include storing a local copy of the shared hash map, receiving transaction data associated with a transaction, accessing fraud data in the local copy of the shared hash map, and determining an authorization or a denial of the transaction based on the fraud data.