Centralized Data Service for Payment Risk Assessment

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current payment authorization systems lack the ability to accurately assess the risk of transactions across multiple payment services due to limited access to historical transaction data, leading to potential fraudulent transactions and increased computational resources spent on chargebacks.

Innovation Solution

A central service is introduced to collect and store historical transaction data from multiple payment services, allowing for secure querying and encryption, which provides more accurate risk assessment by incorporating additional data into the authorization process.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If historical transaction data is stored locally at each payment service, then risk assessment accuracy is improved, but device complexity and memory requirements increase

Engineering Contradiction:
Improverisk assessment accuracyVSAvoiddata storage complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

A centralized data service is introduced as an intermediary between payment services and historical transaction data. The data service stores and manages transaction data from multiple payment services, allowing individual services to query historical data without maintaining local storage. This resolves the contradiction by externalizing the storage burden while preserving access to comprehensive historical data for accurate risk assessment.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Measurement precision

If comprehensive historical transaction data is accessed across multiple payment services, then fraud detection accuracy is improved, but data security risks increase

Engineering Contradiction:
Improvefraud detection accuracyVSAvoiddata security risks
Core Design Contradiction:
Measurement precisionVSObject-affected harmful factors

Solution Approach 1:

The system segments data access into two distinct layers: a centralized data service that stores comprehensive transaction data, and payment services that query only the specific historical data needed for authorization decisions. This segmentation allows comprehensive data to be available for improved fraud detection while limiting exposure of sensitive data to only those services with legitimate access needs, thereby reducing security risks.

Inventive Principle:
Principle #1Segmentation

3Speed

If each payment service maintains its own historical transaction data, then authorization speed is improved, but loss of information increases due to limited data scope

Engineering Contradiction:
Improveauthorization speedVSAvoidhistorical transaction data scope
Core Design Contradiction:
SpeedVSLoss of information

Solution Approach 1:

The centralized data service is designed to serve multiple payment services simultaneously, providing universal access to aggregated historical transaction data from all connected services. This multi-functional approach allows any payment service to benefit from the comprehensive data pool without requiring individual services to maintain their own complete historical records, thus preventing information loss while maintaining authorization speed through efficient querying.

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

Data Source

PatentUS10078839B1Centralized system for data retrieval
Publication Date: 2018.09.18 BLOCK INC
  • US10078839B1 patent drawing
  • US10078839B1 patent drawing
  • US10078839B1 patent drawing

AI summary

This disclosure describes, in part, techniques for storing transaction data at a central service, and techniques for querying information associated with the data from the central service when authorizing payment instruments for transactions. For instance, a central service may receive historical transaction data from multiple payment services that authorize payment instruments for merchants, and then store the historical transaction data in one or more databases. A payment service may then receive a request to authorize a payment instrument for a transaction between a merchant and a customer. Based on receiving the request, the payment service can send the central service a message that includes a query for information associated with historical transaction data corresponding to the payment instrument. In response, the payment service can receive the information from the central service and authorize the payment instrument using the information.