Cross-Payment Fraud Scoring With Unified Event Mapping
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing machine learning models for fraud prevention are ineffective when transactions span multiple payment types, as they fail to account for varying merchant tolerances and transaction reversibility across different payment methods.
Innovation Solution
A single machine learning model trained to detect fraud across multiple payment types using a payment scoring event (PSE) structure, which maps transaction data into a unified format, and employs a decline model with configurable thresholds tailored to individual merchant preferences.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a single machine learning model is used for fraud detection across multiple payment types, then the system can handle diverse payment methods and adapt to varying merchant tolerances, but the model complexity and training difficulty increase significantly
Solution Approach 1:
The patent segments the fraud detection problem by creating separate machine learning models for different payment types (credit card, debit card, ACH, Alternative Payment Methods). Each model is trained on payment-type-specific transaction data and fraud patterns, allowing the system to handle diverse payment methods with specialized models rather than one complex universal model
Solution Approach 2:
The patent implements a universal fraud detection system that processes multiple payment types through a common architecture. The system uses a unified data collection framework, standardized feature engineering approaches, and consistent model evaluation metrics across all payment types, enabling the system to handle diverse payments with a multi-functional framework
2Measurement precision
If transaction data is collected and processed for multiple payment types, then fraud detection accuracy improves, but the data processing time and computational resources increase
Solution Approach 1:
The patent segments data collection and processing by payment type, collecting transaction data, merchant data, and device data separately for each payment category. This segmentation allows parallel processing of different payment types and reduces the computational burden on any single processing pipeline, maintaining accuracy while improving efficiency
Solution Approach 2:
The patent performs preliminary data processing by pre-collecting and pre-processing transaction data, merchant data, and device data before fraud analysis. Historical transaction data is pre-labeled with fraud outcomes, and features are pre-engineered from raw data, reducing the processing time required during actual fraud detection operations
3Adaptability or versatility
If separate fraud detection approaches are used for different payment types, then merchant tolerance preferences can be accommodated, but the system complexity and maintenance burden increase
Solution Approach 1:
The patent applies local quality by allowing different fraud detection models and parameters for different payment types based on merchant tolerance preferences. Each payment type can have customized fraud thresholds, risk weights, and detection sensitivity levels tailored to the specific characteristics of that payment method and the merchant's risk appetite for that category
Solution Approach 2:
The patent implements dynamic fraud detection by allowing merchants to adjust tolerance preferences and risk parameters for different payment types in real-time. The system can dynamically modify fraud thresholds and detection criteria based on changing merchant preferences, transaction patterns, and emerging fraud threats across different payment categories
Data Source
AI summary
In an example embodiment, a solution is provided wherein a single machine learning model is trained and used to detect fraud across multiple payment types. More particularly, the concept of a payment scoring event (PSE) is introduced. A PSE is a data structure that stores multiple pieces of information about a transaction (or potential transaction). A mapping is then maintained between each payment type to be supported and the PSE structure. Each of these transaction types may have its own mapping indicating which fields in the PSR its own fields map to. The use of these mappings allows for additional payment methods to be introduced and supported at any time, necessitating only the creation of a mapping for an additional payment method.