US20230020968A1 - Systems and methods for verifying digital payments - Google Patents
Systems and methods for verifying digital payments Download PDFInfo
- Publication number
- US20230020968A1 US20230020968A1 US17/953,199 US202217953199A US2023020968A1 US 20230020968 A1 US20230020968 A1 US 20230020968A1 US 202217953199 A US202217953199 A US 202217953199A US 2023020968 A1 US2023020968 A1 US 2023020968A1
- Authority
- US
- United States
- Prior art keywords
- transaction
- blacklist
- learning model
- machine learning
- terminal device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 47
- 238000010801 machine learning Methods 0.000 claims abstract description 46
- 230000006399 behavior Effects 0.000 claims abstract description 26
- 238000004891 communication Methods 0.000 claims abstract description 21
- 238000012795 verification Methods 0.000 claims description 44
- 238000012545 processing Methods 0.000 claims description 20
- 238000012706 support-vector machine Methods 0.000 claims description 7
- 238000010200 validation analysis Methods 0.000 claims description 6
- 230000007613 environmental effect Effects 0.000 claims description 5
- 238000013136 deep learning model Methods 0.000 claims description 4
- 230000000903 blocking effect Effects 0.000 claims 1
- 230000000717 retained effect Effects 0.000 claims 1
- 238000012549 training Methods 0.000 description 35
- 230000008569 process Effects 0.000 description 9
- 230000000694 effects Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 235000013361 beverage Nutrition 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013145 classification model Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013135 deep learning Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/018—Certifying business or products
- G06Q30/0185—Product, service or business identity fraud
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N20/00—Machine learning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N20/00—Machine learning
- G06N20/10—Machine learning using kernel methods, e.g. support vector machines [SVM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3224—Transactions dependent on location of M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
- G06Q20/40145—Biometric identity checks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4015—Transaction verification using location information
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/26—Government or public services
- G06Q50/265—Personal security, identity or safety
Definitions
- the present disclosure relates to systems and methods for verifying digital payments, and more particularly to, systems and methods for verifying digital service payments using machine learning models to determine whether an authentication is waived.
- a digital service payment platform can provide convenient person-to-person payments for various services.
- a recipient e.g., a passenger
- the service payment platform can send a payment request to the passenger.
- the passenger then can submit the payment using the service payment platform, which distributes a portion to the driver.
- many malicious activities can happen on the service payment platform. For example, criminals may first register a fake service provider and a fake service recipient on the service payment platform. The criminals may then create fake service orders and use credit cards of victims to pay the fake services for cashing out moneys. Other malicious activities may include fake payment receipt, fake orders, bank account fraud, etc.
- the service payment platform may request service recipients to provide authentication information to verify the online payment.
- the service payment platform may ask the passenger to enter a preset password or identification (e.g., social security) information before processing the payment transaction.
- the authentication operation can effectively block the malicious activities, frequently requesting the authentication information may significantly deteriorate user experience of the payment services. Therefore, the service payment platform needs to make a balance between the user experience and the digital payment security. How to identify suspicious payment transactions plays a key role for the success of a digital service payment platform.
- Embodiments of the disclosure address the above problems by verifying digital service payments using machine learning models to determine whether an authentication can be waived.
- Embodiments of the disclosure provide a system for verifying digital payments for a payment platform.
- the system includes a communication interface configured to receive service data associated with a transaction from a terminal device associated with a user of the payment platform.
- the system further includes at least one processor configured to automatically determine whether an authentication is waived for the transaction based on the received service data and a blacklist generated using a machine learning model.
- the blacklist includes a list of suspicious users and transaction behaviors.
- the at least one processor further configured to approve the transaction without requesting user authentication information from the terminal device when the authentication is waived.
- the at least one processor also configured to request the user authentication information from the terminal device and validate the user authentication information when the authentication is not waived.
- Embodiments of the disclosure also provide a method for verifying digital payments for a payment platform.
- the method includes receiving, by a communication interface, service data associated with a transaction from a terminal device associated with a user of the payment platform.
- the method further includes automatically determining, by at least one processor, whether an authentication is waived for the transaction based on the received service data and a blacklist generated using a machine learning model.
- the blacklist includes a list of suspicious users and transaction behaviors.
- the method also includes approving the transaction, by the at least one processor, without requesting user authentication information from the terminal device when the authentication is waived.
- the method additionally includes requesting the user authentication information from the terminal device and validating, by the at least one processor, the user authentication information when the authentication is not waived.
- Embodiments of the disclosure further provide a non-transitory computer-readable medium having instructions stored thereon that, when executed by at least one processor, causes the at least one processor to perform a payment verification method for a payment platform.
- the method includes receiving service data associated with a transaction from a terminal device associated with a user of the payment platform.
- the method further includes automatically determining whether an authentication is waived for the transaction based on the received service data and a blacklist generated using a machine learning model.
- the blacklist includes a list of suspicious users and transaction behaviors.
- the method also includes approving the transaction without requesting user authentication information from the terminal device when the authentication is waived.
- the method additionally includes requesting the user authentication information from the terminal device and validating the user authentication information when the authentication is not waived.
- FIG. 1 illustrates an exemplary payment verification system, according to embodiments of the disclosure.
- FIG. 2 illustrates a block diagram of an exemplary risk management device, according to embodiments of the disclosure.
- FIG. 3 is a flowchart of an exemplary payment verification process, according to embodiments of the disclosure.
- FIG. 4 illustrates an exemplary user interface for making a service payment, according to embodiments of the disclosure.
- FIG. 5 illustrates an exemplary user interface for requesting an authentication, according to embodiments of the disclosure.
- FIG. 6 illustrates an exemplary user interface for displaying a transaction processing result, according to embodiments of the disclosure.
- FIG. 7 is a flowchart of an exemplary method for verifying a service payment, according to embodiments of the disclosure.
- the disclosed systems and methods automatically determine whether an authentication is waived for an online payment transaction based on received service data and a blacklist generated using machine learning models. If the authentication is waived, the disclosed systems and methods approve the payment transaction without requesting the user authentication information. If the user authentication is not waived, the disclosed systems and methods request the user authentication information and validate the user authentication information. For example, after a transportation service, a passenger submits a payment to a driver through a digital service payment platform.
- the digital service payment platform includes a risk management device to determine whether authentication information of the passenger is waived and approve the payment transaction directly.
- the risk management device applies the blacklist generated using machine learning models on received data associated with the service payment.
- the risk management device approves the payment transaction without requiring authentication; otherwise, the risk management device requests the authentication information of the passenger for payment verification. After receiving the passenger authentication information, the risk management device compares the passenger authentication information with known user authentication information and determines whether the transaction is approved.
- FIG. 1 illustrates an exemplary payment verification system 100 (referred to as “system 100 ” hereafter), according to embodiments of the disclosure.
- system 100 may be configured to automatically verify the service payment submitted by the service user.
- system 100 may include components for performing two phases, a training phase and a payment verification phase.
- system 100 may include a training database 110 and a blacklist generation device 120 .
- system 100 may include a risk management device 130 .
- system 100 may include more or less of the components shown in FIG. 1 .
- system 100 may include only risk management device 130 .
- system 100 may optionally include a network 106 to facilitate the communication among the various components of system 100 , such as training database 110 , devices 120 and 130 , and a terminal device 103 .
- network 106 may be a local area network (LAN), a wireless network, a cloud computing environment (e.g., software as a service, platform as a service, infrastructure as a service), a client-server, a wide area network (WAN), etc.
- LAN local area network
- cloud computing environment e.g., software as a service, platform as a service, infrastructure as a service
- client-server e.g., a client-server
- WAN wide area network
- the various components of system 100 may be remote from each other or in different locations, and be connected through network 106 as shown in FIG. 1 .
- certain components of system 100 may be located on the same site or inside one device.
- training database 110 may be located on-site with or be part of blacklist generation device 120 .
- blacklist generation device 120 and risk management device 130 may be inside the same computer or processing device.
- blacklist generation device 120 may communicate with training database 110 to receive training data.
- the training data may be collected from multiple sources, e.g., terminal device 103 and other data sources 105 .
- terminal device 103 may be a mobile phone, a wearable device, a PDA, etc. used by the user (e.g., the passenger) to make a payment for the service.
- terminal device 103 may collect at least one of transaction information, user profile information, service information associated with the terminal device, time information, or terminal device information.
- the transaction information may include a transaction amount, bank account information of a payee (e.g., service provider), bank account information of a payer (e.g., service user), etc.
- the user profile information may include a user's name, contact information (e.g., phone number), address, etc. Additionally, each set of user profile data in the training further include the corresponding ground truth safety labels (e.g., safe user or unsafe user).
- the service information associated with the terminal device may include the service information received from the terminal device such as a service description, a service start time and end time, a service geographic location, a service provider, a service recipient (e.g., the user), etc.
- the time information may include a payment time, a service request time, a service completion time, previous service times, etc.
- the terminal device information may include an Internet Protocol (IP) address of the terminal device, a device environmental identifier, etc.
- IP Internet Protocol
- Other data sources 105 may include third party vendors (e.g., credit bureaus, data analysis companies), mass media (e.g., newspapers, magazines, the Internet), public records of departments, agencies, and offices of the federal or state governments, etc.
- Blacklist generation device 120 may use the training data received from training database 110 to train a list of suspicious users and transaction behaviors (e.g., blacklist 115 ).
- blacklist 115 may include a list of names of the suspicious users. For example, a person with criminal records (e.g., robbery, theft, battery, and assault) may be included in blacklist 115 .
- blacklist 115 may further include transaction behaviors associated with malicious activities. For example, blacklist 115 may include a transaction behavior of a total transaction amount exceeding $1000 within past 24 hours. This transaction behavior may help detecting malicious activities such as illegal credit card cash out in the form of wallet transfer. As another example, blacklist 115 may include a transaction behavior of a total number of transactions exceeding 5 in the past 24 hours.
- the threshold numbers are only exemplary and can be determined during training.
- the training phase may be performed “online” or “offline.”
- An “online” training refers to performing the training phase contemporarily with the payment verification phase, e.g., updating blacklist 115 in real-time just prior to determining whether the authentication is waived for the service payment.
- An “online” training may have the benefit to obtain a most updated blacklist based on the training data that is then available.
- an “online” training may be computational costive to perform and may not always be possible if the training data is large and/or the models are complicate. For example, to avoid the user noticing a time delay, the time needed to complete the payment verification phase can be limited to 200 milliseconds.
- “online” training may be implemented before the payment verification phase. Otherwise, an “offline” training is used where the training phase is performed prior to the payment verification phase.
- the “offline” training may have blacklist 115 updated offline and reused for determining whether the authentication is waived for the service payment. For example, blacklist generation device 120 may update blacklist 115 every hour based on new transaction information and threat intelligence received in a previous hour. After an update, some existing suspicions users in blacklist 115 may be removed from blacklist 115 if these users no longer meet conditions. New users may be added to blacklist 115 if their transaction behaviors meet certain conditions. An exemplary condition may be making more than 6 payments within the past 24 hours.
- Blacklist generation device 120 may be implemented with hardware specially programmed by software that performs the training process.
- blacklist generation device 120 may include a processor and a non-transitory computer-readable medium.
- the processor may conduct the training by performing instructions of a training process stored in the computer-readable medium.
- Blacklist generation device 120 may additionally include input and output interfaces to communicate with training database 110 , network 106 , and/or a user interface (not shown).
- the user interface may be used for selecting sets of training data, adjusting one or more parameters of the training process, selecting or modifying content of blacklist 115 , and/or manually or semi-automatically providing ground-truth associated with a training data (e.g., whether the person associated with certain behaviors is independently confirmed as a suspicious user through other channels).
- Blacklist 115 may be used by risk management device 130 to determine whether the authentication is waived for the service payment.
- Risk management device 130 may receive blacklist 115 from blacklist generation device 120 .
- Risk management device 130 may include a processor and a non-transitory computer-readable medium (discussed in detail in connection with FIG. 2 ).
- the processor may perform instructions of a sequence of payment verification processes stored in the medium.
- Risk management device 130 may additionally include input and output interfaces to communicate with terminal device 103 , network 106 , and/or a user interface (not shown).
- the user interface may be used for selecting service data for payment verification, initiating the payment verification process, and displaying a transaction processing result, etc.
- Risk management device 130 may communicate with terminal device 103 to receive service data including transaction information, user profile information, service information associated with the terminal device, time information, or terminal device information. Consistent with the present disclosure, the service data may be acquired by terminal device 103 . Risk management device 130 may use blacklist 115 received from blacklist generation device 120 to perform one or more of: (1) determining whether the user authentication is waived for the payment transaction, (2) approving the transaction without requesting user authentication information when the authentication is waived, and (3) requesting the user authentication information and validate the user authentication information when the authentication is not waived.
- FIG. 2 illustrates a block diagram of an exemplary risk management device 130 , according to embodiments of the disclosure.
- risk management device 130 may receive the service data from terminal device 103 and blacklist 115 from blacklist generation device 120 .
- Risk management device 130 may process the service data to determine whether the user authentication is waived. If the user authentication is waived, risk management device 130 may approve the payment transaction without requesting the user authentication from terminal device 103 . If the user authentication is not waived, risk management device 130 may request the user authentication from terminal device 103 and validate the user authentication. For example, risk management device 130 may compare the received user authentication with a known user authentication. If the received user authentication matches the known user authentication, risk management device 130 may approve the payment transaction; otherwise, risk management device 130 may block the payment transaction.
- risk management device 130 may include a communication interface 202 , a processor 204 , a memory 206 , and a storage 208 .
- risk management device 130 may include different modules in a single device, such as an integrated circuit (IC) chip (implemented as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA)), or separate devices with dedicated functions.
- IC integrated circuit
- ASIC application-specific integrated circuit
- FPGA field-programmable gate array
- one or more components of risk management device 130 may be located in a cloud, or may be alternatively in a single location or distributed locations. Components of risk management device 130 may be in an integrated device, or distributed at different locations but communicate with each other through a network (not shown).
- Communication interface 202 may send data to and receive data from components such as terminal device 103 and other data sources 105 via communication cables, a Wireless Local Area Network (WLAN), a Wide Area Network (WAN), wireless networks such as radio waves, a cellular network, and/or a local or short-range wireless network (e.g., BluetoothTM), or other communication methods.
- communication interface 202 can be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection.
- ISDN integrated services digital network
- communication interface 202 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN.
- Wireless links can also be implemented by communication interface 202 .
- communication interface 202 can send and receive electrical, electromagnetic or optical signals that carry digital data streams representing various types of information via a network.
- communication interface 202 may receive service data (e.g., transaction information) from terminal device 103 .
- Communication interface 202 may further receive the user authentication data (e.g., salted and hashed password, token, or credentials) from terminal device 103 when the user authentication is not waived based on the initial determination using received service data.
- Communication interface 202 may also provide the received data to storage 208 for storage or to processor 204 for processing.
- Processor 204 may be a processing device that includes one or more general processing devices, such as a microprocessor, a central processing unit (CPU), a graphics processing unit (GPU), and the like. More specifically, processor 204 may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor running other instruction sets, or a processor that runs a combination of instruction sets. Processor 204 may also be one or more dedicated processing devices such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), system-on-chip (SoCs), and the like.
- ASICs application specific integrated circuits
- FPGAs field programmable gate arrays
- DSPs digital signal processors
- SoCs system-on-chip
- Processor 204 may be configured as a separate processor module dedicated to performing payment verification based on the service data (and the user authentication if not waived) received from terminal device 103 . Alternatively, processor 204 may be configured as a shared processor module for performing other functions. Processor 204 may be communicatively coupled to memory 206 and/or storage 208 and configured to execute the computer-executable instructions stored thereon.
- Memory 206 and storage 208 may include any appropriate type of mass storage provided to store any type of information that processor 204 may need to operate.
- Memory 206 and storage 208 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible (i.e., non-transitory) computer-readable medium including, but not limited to, a ROM, a flash memory, a dynamic RAM, and a static RAM.
- memory 206 may include an in-memory database 210 (e.g., Redis) for attaining minimal response time (e.g., microseconds) by eliminating the need to access disks (e.g., storage 208 ).
- blacklist 115 may be stored in in-memory database 210 to minimize determination time that whether an authentication is waived.
- Memory 206 and/or storage 208 may be configured to store one or more computer programs that may be executed by processor 204 to perform service data processing and payment verification disclosed herein.
- memory 206 and/or storage 208 may be configured to store program(s) that may be executed by processor 204 to determine whether the user authentication is waived based on the received service data from terminal device 103 , and process the payment transaction according to the determination.
- Memory 206 and/or storage 208 may be further configured to store information and data used by processor 204 .
- memory 206 and/or storage 208 may be configured to store the various types of data (e.g., service data) from terminal device 103 and data related to location and setting of terminal device 103 .
- Memory 206 may store intermediate data such as information generated based on the service data for comparing with keys in blacklist 115 .
- Memory 206 may further store known authentication information of the users.
- Storage 208 may store various logs for reporting or business intelligence (BI) purposes.
- the various types of data may be stored permanently, removed periodically, or disregarded immediately after each frame of data is processed.
- processor 204 includes multiple modules, such as a suspicious transaction determination unit 240 , an authentication validation unit 242 , and the like. These modules (and any corresponding sub-modules or sub-units) can be hardware units (e.g., portions of an integrated circuit) of processor 204 designed for use with other components or software units implemented by processor 204 through executing at least part of a program.
- the program may be stored on a computer-readable medium, and when executed by processor 204 , it may perform one or more functions.
- FIG. 2 shows units 240 and 242 both within one processor 204 , it is contemplated that these units may be distributed among multiple processors located near or remotely with each other.
- units 240 and 242 of FIG. 2 may execute computer instructions to perform payment verification.
- FIG. 3 is a flowchart of an exemplary payment verification process, according to embodiments of the disclosure.
- the user may use the terminal device (e.g., terminal device 103 ) to log onto a frontend (e.g., frontend 301 ) of the service payment platform to submit the service payment.
- FIG. 4 illustrates an exemplary user interface 400 for making a service payment, according to embodiments of the disclosure.
- user interface 400 (as an example of frontend 301 ) allows the user to provide service information 415 , a payment amount 425 , and recipient information 435 .
- Service information 415 can include a brief description of the service, such as travel, utility, childcare, landscaping, etc.
- Payment amount 425 includes a monetary amount (e.g., dollar) paid for the service.
- Recipient information 435 include the service user's bank information (e.g., bank name, bank account type, account number, etc.). It is contemplated that user interface 400 may request information other than above mentioned. For example, user interface 400 may further request a service order number, detailed service description, service provider's name, etc. The user may input the information by any suitable means, such as typing, selecting from a dropdown list, etc. As shown in FIG.
- user interface 400 may also include a button (e.g., button 445 ) for assisting the service user to contact a customer service department before submitting the service payment.
- the service user may click a button (e.g., button 455 ) to submit the service payment.
- the service data including the service payment information is sent to a backend gateway 302 from frontend 301 .
- the service data may include the transaction information collected by user interface 400 (e.g., service information, the transaction amount, and service recipient information), the user profile, the previous service information (e.g., travel history), the service geographic location, the IP address of terminal device 103 , or the device environmental identifier.
- backend gateway 302 may receive the service data and distribute the received data into multiple places. For example, backend gateway 302 may send the service data logs to a logging system 304 for future reporting and BI purposes. Logging system 304 may be further used for training new machine learning models and updating blacklist 115 . The service data may also be sent to a risk management decision center 303 (referred to as “center 303 ” hereafter).
- center 303 risk management decision center
- center 303 may employ suspicious transaction determination unit 240 to compare the received service data with blacklist 115 .
- blacklist 115 may include a list of suspicious user identifiers (ID) (e.g. user names), a threshold of transaction amount, a list of suspicious IP addresses, and a list of suspicious transaction locations.
- ID suspicious user identifiers
- blacklist 115 is generated based on training data such as blacklist offline 351 , offline deep features 352 , and offline transactions 353 .
- blacklist offline 351 may include a list of suspicious users with criminal charges (e.g., robbery, theft, battery, and assault).
- the data may be periodically collected from the government resources.
- Blacklist offline 351 may further include a list of suspicious users with financial issues (e.g., loan default, bankruptcy, and the like) obtained from third party credit bureaus.
- offline deep features 352 are generated using machine learning models including a deep learning model, a rule-based model, or a support vector machine (SVM).
- the machine learning models may be trained based on training data in training database 110 .
- offline deep features 352 may include a user ID, a transaction amount threshold, a transaction frequency, a transaction location, a terminal device IP address, a user credit score, etc.
- Blacklist generation device 120 may provide offline deep features 352 through a business application programming interface (API) 362 .
- blacklist generation device 120 may train a machine learning model (e.g., a deep learning classification model) to classify existing service users into a group of suspicious users and a group of safe users.
- API business application programming interface
- blacklist generation device 120 may apply another machine learning model (e.g., a rule-based model) on data of offline transactions 353 (e.g., transaction amount, transaction location, or transaction frequency) to generate rules of suspicious transaction behaviors.
- a rule may be that if the transaction frequency exceeds 6 times for a single user within past 24 hours, the authentication information is required.
- offline transactions 353 may be obtained through a payment API 363 from other data sources 105 or terminal device 103 .
- suspicious transaction determination unit 240 may be configured to generate a set of corresponding keys based on the received service data from terminal device 103 for comparing with the keys in blacklist 115 .
- the keys in blacklist 115 may be a list of suspicious users and transaction behaviors. For example, suspicious transaction determination unit 240 may extract the user ID and the transaction amount from the received service data. If the extracted user ID matches any of user IDs listed in blacklist 115 , suspicious transaction determination unit 240 may generate a call back 305 to request the user to enter the authentication information in frontend 301 . Similarly, if the transaction amount exceeds the threshold transaction amount listed in blacklist 305 , suspicious transaction determination unit 240 may generate call back 305 to request the user to enter the authentication information in frontend 301 .
- FIG. 5 illustrates an exemplary user interface 500 for requesting an authentication, according to embodiments of the disclosure.
- user interface 500 of frontend 301 includes an authentication description 510 , an authentication input field 520 , a reset button 530 , a contact us button 540 , and a submit button 550 .
- authentication description 510 describes what type of authentication is required to enter in authentication input field on user interface 500 .
- a password is required for verifying the payment.
- other types of authentication such as SSN or biometric information (e.g., fingerprint, face with/without masks, voice, and the like) can be acceptable authentications.
- processor 204 may request to enter the SSN of the user in authentication input field 520 for verifying the payment. If the user forgets the authentication, the user can use reset button 530 to reset the authentication. For example, if the user forgets the password, he can press reset button 530 , which will prompt him to follow certain steps for resetting the password. If the user wants to contact the customer service department before submitting the authentication, the user can use contact us button 540 to reach the customer service department. After entering the authentication, the user may use submit button 550 to submit the authentication information from frontend 301 to backend gateway 302 .
- backend gateway 302 may send the received data to logging system 304 for reporting and BI purposes. Backend gateway 302 may further send the received data to center 303 .
- center 303 may send the data to a verification and disposition center 306 for validating the received authentication information.
- verification and disposition center 306 may employ authentication validation unit 242 in risk management device 130 to compare the received authentication information from frontend 301 with the stored authentication information in memory 206 .
- Authentication validation unit 242 may retrieve the stored user authentication information through a check API 307 , and compare the retrieved user authentication with the received authentication information from terminal device 103 .
- check API may call the corresponding APIs (e.g., SSN API 308 , or other APIs 309 ) to complete the authentication comparison as shown in FIG. 3 .
- verification and disposition center 306 may approve the transaction by sending call back 305 including a transaction approval message to frontend 301 .
- verification and disposition center 306 may block the transaction of the service payment by sending call back 305 including a disapproval message to frontend 301 .
- a transaction block message may display on terminal device 103 .
- FIG. 6 illustrates an exemplary user interface 600 for displaying a transaction processing result, according to embodiments of the disclosure.
- user interface 600 displays a message of transaction being processed in a field 610 .
- the message indicates the transaction is approved by verification and disposition center 306 .
- User interface 600 may further include a contact us button 620 for providing the CPO entrance for customer service purposes to help the user with any technical difficulties such as time out or unstable signals.
- center 303 may waive the authentication for the transaction when the received server data of the transaction does not match any keys in blacklist 115 . Center 303 may then send call back 305 including the transaction approval message to frontend 301 , and user interface 600 may display the message of transaction being processed on terminal device 103 as shown in FIG. 6 . If the transaction is not approved, the message displayed in field 610 may be changed accordingly to reflect the result.
- FIG. 7 is a flowchart of an exemplary method 700 for verifying a service payment, according to embodiments of the disclosure.
- Method 700 may be performed by risk management device 130 and particularly processor 204 or a separate processor not shown in FIG. 2 .
- Method 700 may include steps S 702 -S 720 as described below. It is to be appreciated that some of the steps may be optional, and some of the steps may be performed simultaneously, or in a different order than shown in FIG. 7 .
- risk management device 130 may be configured to receive service data from terminal device 103 .
- the service data may include the transaction amount, service information, and service recipient information.
- the service data may include a transportation expense (e.g., trip fare), a service content description, a passenger name, and a payment method.
- the service data may further include the user (e.g., service recipient) profile, the information of the previous trips, the geographical location of the service, the IP address of terminal device 103 , or the environmental identifier of terminal device 103 .
- risk management device 130 may be configured to determine whether a user authentication information is waived for the transaction based on the received service data and blacklist 115 .
- blacklist 115 may be trained by blacklist generation device 120 using the machine learning models (e.g., deep learning models, rule-based models, SVMs, and the like). Blacklist 115 may include a list of suspicious users and transaction behaviors. In some embodiments, blacklist generation device 120 may retrain each machine learning model at a predetermined frequency. Blacklist 115 therefore may be updated periodically based on the retrained machine learning models. For example, blacklist generation device 120 may retrain the transaction related models every hour. Blacklist 115 therefore can include an updated transaction pattern and exclude an outdated transaction pattern when determining whether the payment the user authentication information is waived for a new transaction.
- the machine learning models e.g., deep learning models, rule-based models, SVMs, and the like.
- Blacklist 115 may include a list of suspicious users and transaction behaviors.
- blacklist generation device 120 may retrain each
- risk management device 130 may approve the transaction in step S 708 . If the service data match any key (e.g., suspicious user name, transaction amount threshold) in blacklist 115 (step S 706 : Yes), risk management device 130 may be configured to request the user authentication information for verifying the payment. For example, the service user's name may match a suspicious user name listed in blacklist 115 , the transaction amount may exceed a transaction amount threshold listed in blacklist 115 , or the combination of multiple blacklists. The list of suspicious users and the transaction amount threshold may be generated using different machine learning models trained by blacklist generation device 120 at different frequencies.
- risk management device 130 may be configured to send a request to terminal device 103 to collect the user authentication information.
- risk management device 130 may be further configured to determine what type of user authentication information to request, which may depend on the known user authentication information stored in risk management device 130 . For example, if the user has created a password, risk management device 130 may request the password as the user authentication information. If the user did not create a password, risk management device 130 may request other types of user authentication information for verifying the payment, such as an SSN or a driver's license number.
- risk management device 130 may be configured to receive the user authentication information from terminal device 103 .
- the user authentication information may include a password, an SSN, or user biometrics (e.g., fingerprint, face, voice, and the like).
- risk management device 130 may be configured to validate the received user authentication information. For example, risk management device 130 may compare the received user authentication information with the known user authentication information. The known user authentication information may be provided by the user before the transaction is stored in memory 206 of risk management device 130 .
- risk management device 130 may block the transaction of the service payment in step S 718 . If the received user authentication information matches the known user authentication information stored in risk management device 130 (step S 716 : Yes), risk management device 130 may approve the transaction of the service payment in step S 720 .
- the disclosed embodiments can be applied or adapted for verifying payments to other types of services submitted by other types of service users.
- the service may be childcare, landscaping, HVAC maintenance, house repairs, food and beverage service, etc.
- the disclosed embodiments may be further applied or adapted for verifying payments for non-services, such as merchandises, utilities, performances, etc.
- the computer-readable medium may include volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other types of computer-readable medium or computer-readable storage devices.
- the computer-readable medium may be the storage device or the memory module having the computer instructions stored thereon, as disclosed.
- the computer-readable medium may be a disc or a flash drive having the computer instructions stored thereon.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Software Systems (AREA)
- Entrepreneurship & Innovation (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Economics (AREA)
- Quality & Reliability (AREA)
- Computer Hardware Design (AREA)
- Medical Informatics (AREA)
- Artificial Intelligence (AREA)
- Development Economics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Mathematical Physics (AREA)
- Operations Research (AREA)
- Computing Systems (AREA)
- Tourism & Hospitality (AREA)
- Evolutionary Computation (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Embodiments of the disclosure provide systems and methods for verifying digital payments for a payment platform. The system includes a communication interface configured to receive service data associated with a transaction from a terminal device associated with a user of the payment platform. The system further includes at least one processor configured to automatically determine whether an authentication is waived for the transaction based on the received service data and a blacklist generated using a machine learning model. The blacklist includes a list of suspicious users and transaction behaviors. The at least one processor further configured to approve the transaction without requesting user authentication information from the terminal device when the authentication is waived. The at least one processor also configured to request the user authentication information from the terminal device and validate the user authentication information when the authentication is not waived.
Description
- The is a continuation of U.S. application Ser. No. 17/086,448, filed Nov. 1, 2020, which is incorporated by reference herein in its entirety.
- The present disclosure relates to systems and methods for verifying digital payments, and more particularly to, systems and methods for verifying digital service payments using machine learning models to determine whether an authentication is waived.
- A digital service payment platform can provide convenient person-to-person payments for various services. For example, a recipient (e.g., a passenger) of a transportation service can pay for the service using a digital service payment platform. Upon the completion of the transportation service, the service payment platform can send a payment request to the passenger. The passenger then can submit the payment using the service payment platform, which distributes a portion to the driver. However, many malicious activities can happen on the service payment platform. For example, criminals may first register a fake service provider and a fake service recipient on the service payment platform. The criminals may then create fake service orders and use credit cards of victims to pay the fake services for cashing out moneys. Other malicious activities may include fake payment receipt, fake orders, bank account fraud, etc.
- To block the above-mentioned malicious activities, the service payment platform may request service recipients to provide authentication information to verify the online payment. For example, the service payment platform may ask the passenger to enter a preset password or identification (e.g., social security) information before processing the payment transaction. Though the authentication operation can effectively block the malicious activities, frequently requesting the authentication information may significantly deteriorate user experience of the payment services. Therefore, the service payment platform needs to make a balance between the user experience and the digital payment security. How to identify suspicious payment transactions plays a key role for the success of a digital service payment platform.
- Embodiments of the disclosure address the above problems by verifying digital service payments using machine learning models to determine whether an authentication can be waived.
- Embodiments of the disclosure provide a system for verifying digital payments for a payment platform. The system includes a communication interface configured to receive service data associated with a transaction from a terminal device associated with a user of the payment platform. The system further includes at least one processor configured to automatically determine whether an authentication is waived for the transaction based on the received service data and a blacklist generated using a machine learning model. The blacklist includes a list of suspicious users and transaction behaviors. The at least one processor further configured to approve the transaction without requesting user authentication information from the terminal device when the authentication is waived. The at least one processor also configured to request the user authentication information from the terminal device and validate the user authentication information when the authentication is not waived.
- Embodiments of the disclosure also provide a method for verifying digital payments for a payment platform. The method includes receiving, by a communication interface, service data associated with a transaction from a terminal device associated with a user of the payment platform. The method further includes automatically determining, by at least one processor, whether an authentication is waived for the transaction based on the received service data and a blacklist generated using a machine learning model. The blacklist includes a list of suspicious users and transaction behaviors. The method also includes approving the transaction, by the at least one processor, without requesting user authentication information from the terminal device when the authentication is waived. The method additionally includes requesting the user authentication information from the terminal device and validating, by the at least one processor, the user authentication information when the authentication is not waived.
- Embodiments of the disclosure further provide a non-transitory computer-readable medium having instructions stored thereon that, when executed by at least one processor, causes the at least one processor to perform a payment verification method for a payment platform. The method includes receiving service data associated with a transaction from a terminal device associated with a user of the payment platform. The method further includes automatically determining whether an authentication is waived for the transaction based on the received service data and a blacklist generated using a machine learning model. The blacklist includes a list of suspicious users and transaction behaviors. The method also includes approving the transaction without requesting user authentication information from the terminal device when the authentication is waived. The method additionally includes requesting the user authentication information from the terminal device and validating the user authentication information when the authentication is not waived.
- It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
-
FIG. 1 illustrates an exemplary payment verification system, according to embodiments of the disclosure. -
FIG. 2 illustrates a block diagram of an exemplary risk management device, according to embodiments of the disclosure. -
FIG. 3 is a flowchart of an exemplary payment verification process, according to embodiments of the disclosure. -
FIG. 4 illustrates an exemplary user interface for making a service payment, according to embodiments of the disclosure. -
FIG. 5 illustrates an exemplary user interface for requesting an authentication, according to embodiments of the disclosure. -
FIG. 6 illustrates an exemplary user interface for displaying a transaction processing result, according to embodiments of the disclosure. -
FIG. 7 is a flowchart of an exemplary method for verifying a service payment, according to embodiments of the disclosure. - Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings.
- The disclosed systems and methods automatically determine whether an authentication is waived for an online payment transaction based on received service data and a blacklist generated using machine learning models. If the authentication is waived, the disclosed systems and methods approve the payment transaction without requesting the user authentication information. If the user authentication is not waived, the disclosed systems and methods request the user authentication information and validate the user authentication information. For example, after a transportation service, a passenger submits a payment to a driver through a digital service payment platform. The digital service payment platform includes a risk management device to determine whether authentication information of the passenger is waived and approve the payment transaction directly. The risk management device applies the blacklist generated using machine learning models on received data associated with the service payment. If the passenger and the transaction attributes are not found on the blacklist, the risk management device approves the payment transaction without requiring authentication; otherwise, the risk management device requests the authentication information of the passenger for payment verification. After receiving the passenger authentication information, the risk management device compares the passenger authentication information with known user authentication information and determines whether the transaction is approved.
-
FIG. 1 illustrates an exemplary payment verification system 100 (referred to as “system 100” hereafter), according to embodiments of the disclosure. In some embodiments,system 100 may be configured to automatically verify the service payment submitted by the service user. As shown inFIG. 1 ,system 100 may include components for performing two phases, a training phase and a payment verification phase. To perform the training phase,system 100 may include atraining database 110 and ablacklist generation device 120. To perform the payment verification phase,system 100 may include arisk management device 130. In some embodiments,system 100 may include more or less of the components shown inFIG. 1 . For example, when ablacklist 115 is pre-trained and provided,system 100 may include onlyrisk management device 130. - In some embodiments,
system 100 may optionally include anetwork 106 to facilitate the communication among the various components ofsystem 100, such astraining database 110,devices terminal device 103. For example,network 106 may be a local area network (LAN), a wireless network, a cloud computing environment (e.g., software as a service, platform as a service, infrastructure as a service), a client-server, a wide area network (WAN), etc. In some embodiments,network 106 may be replaced by wired data communication systems or devices. - In some embodiments, the various components of
system 100 may be remote from each other or in different locations, and be connected throughnetwork 106 as shown inFIG. 1 . In some alternative embodiments, certain components ofsystem 100 may be located on the same site or inside one device. For example,training database 110 may be located on-site with or be part ofblacklist generation device 120. As another example,blacklist generation device 120 andrisk management device 130 may be inside the same computer or processing device. - As shown in
FIG. 1 ,blacklist generation device 120 may communicate withtraining database 110 to receive training data. The training data may be collected from multiple sources, e.g.,terminal device 103 andother data sources 105. In some embodiments,terminal device 103 may be a mobile phone, a wearable device, a PDA, etc. used by the user (e.g., the passenger) to make a payment for the service. For example,terminal device 103 may collect at least one of transaction information, user profile information, service information associated with the terminal device, time information, or terminal device information. In some embodiments, the transaction information may include a transaction amount, bank account information of a payee (e.g., service provider), bank account information of a payer (e.g., service user), etc. In some embodiments, the user profile information may include a user's name, contact information (e.g., phone number), address, etc. Additionally, each set of user profile data in the training further include the corresponding ground truth safety labels (e.g., safe user or unsafe user). In some embodiments, the service information associated with the terminal device may include the service information received from the terminal device such as a service description, a service start time and end time, a service geographic location, a service provider, a service recipient (e.g., the user), etc. In some embodiments, the time information may include a payment time, a service request time, a service completion time, previous service times, etc. In some embodiments, the terminal device information may include an Internet Protocol (IP) address of the terminal device, a device environmental identifier, etc.Other data sources 105 may include third party vendors (e.g., credit bureaus, data analysis companies), mass media (e.g., newspapers, magazines, the Internet), public records of departments, agencies, and offices of the federal or state governments, etc. -
Blacklist generation device 120 may use the training data received fromtraining database 110 to train a list of suspicious users and transaction behaviors (e.g., blacklist 115). In some embodiments,blacklist 115 may include a list of names of the suspicious users. For example, a person with criminal records (e.g., robbery, theft, battery, and assault) may be included inblacklist 115. In some embodiments,blacklist 115 may further include transaction behaviors associated with malicious activities. For example,blacklist 115 may include a transaction behavior of a total transaction amount exceeding $1000 within past 24 hours. This transaction behavior may help detecting malicious activities such as illegal credit card cash out in the form of wallet transfer. As another example,blacklist 115 may include a transaction behavior of a total number of transactions exceeding 5 in the past 24 hours. The threshold numbers are only exemplary and can be determined during training. - In some embodiments, the training phase may be performed “online” or “offline.” An “online” training refers to performing the training phase contemporarily with the payment verification phase, e.g., updating
blacklist 115 in real-time just prior to determining whether the authentication is waived for the service payment. An “online” training may have the benefit to obtain a most updated blacklist based on the training data that is then available. However, an “online” training may be computational costive to perform and may not always be possible if the training data is large and/or the models are complicate. For example, to avoid the user noticing a time delay, the time needed to complete the payment verification phase can be limited to 200 milliseconds. If the training phase can be completed in milliseconds, “online” training may be implemented before the payment verification phase. Otherwise, an “offline” training is used where the training phase is performed prior to the payment verification phase. The “offline” training may haveblacklist 115 updated offline and reused for determining whether the authentication is waived for the service payment. For example,blacklist generation device 120 may updateblacklist 115 every hour based on new transaction information and threat intelligence received in a previous hour. After an update, some existing suspicions users inblacklist 115 may be removed fromblacklist 115 if these users no longer meet conditions. New users may be added toblacklist 115 if their transaction behaviors meet certain conditions. An exemplary condition may be making more than 6 payments within the past 24 hours. -
Blacklist generation device 120 may be implemented with hardware specially programmed by software that performs the training process. For example,blacklist generation device 120 may include a processor and a non-transitory computer-readable medium. The processor may conduct the training by performing instructions of a training process stored in the computer-readable medium.Blacklist generation device 120 may additionally include input and output interfaces to communicate withtraining database 110,network 106, and/or a user interface (not shown). The user interface may be used for selecting sets of training data, adjusting one or more parameters of the training process, selecting or modifying content ofblacklist 115, and/or manually or semi-automatically providing ground-truth associated with a training data (e.g., whether the person associated with certain behaviors is independently confirmed as a suspicious user through other channels). -
Blacklist 115 may be used byrisk management device 130 to determine whether the authentication is waived for the service payment.Risk management device 130 may receiveblacklist 115 fromblacklist generation device 120.Risk management device 130 may include a processor and a non-transitory computer-readable medium (discussed in detail in connection withFIG. 2 ). The processor may perform instructions of a sequence of payment verification processes stored in the medium.Risk management device 130 may additionally include input and output interfaces to communicate withterminal device 103,network 106, and/or a user interface (not shown). The user interface may be used for selecting service data for payment verification, initiating the payment verification process, and displaying a transaction processing result, etc. -
Risk management device 130 may communicate withterminal device 103 to receive service data including transaction information, user profile information, service information associated with the terminal device, time information, or terminal device information. Consistent with the present disclosure, the service data may be acquired byterminal device 103.Risk management device 130 may useblacklist 115 received fromblacklist generation device 120 to perform one or more of: (1) determining whether the user authentication is waived for the payment transaction, (2) approving the transaction without requesting user authentication information when the authentication is waived, and (3) requesting the user authentication information and validate the user authentication information when the authentication is not waived. - For example,
FIG. 2 illustrates a block diagram of an exemplaryrisk management device 130, according to embodiments of the disclosure. Consistent with the present disclosure,risk management device 130 may receive the service data fromterminal device 103 and blacklist 115 fromblacklist generation device 120.Risk management device 130 may process the service data to determine whether the user authentication is waived. If the user authentication is waived,risk management device 130 may approve the payment transaction without requesting the user authentication fromterminal device 103. If the user authentication is not waived,risk management device 130 may request the user authentication fromterminal device 103 and validate the user authentication. For example,risk management device 130 may compare the received user authentication with a known user authentication. If the received user authentication matches the known user authentication,risk management device 130 may approve the payment transaction; otherwise,risk management device 130 may block the payment transaction. - In some embodiments, as shown in
FIG. 2 ,risk management device 130 may include acommunication interface 202, aprocessor 204, amemory 206, and astorage 208. In some embodiments,risk management device 130 may include different modules in a single device, such as an integrated circuit (IC) chip (implemented as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA)), or separate devices with dedicated functions. In some embodiments, one or more components ofrisk management device 130 may be located in a cloud, or may be alternatively in a single location or distributed locations. Components ofrisk management device 130 may be in an integrated device, or distributed at different locations but communicate with each other through a network (not shown). -
Communication interface 202 may send data to and receive data from components such asterminal device 103 andother data sources 105 via communication cables, a Wireless Local Area Network (WLAN), a Wide Area Network (WAN), wireless networks such as radio waves, a cellular network, and/or a local or short-range wireless network (e.g., Bluetooth™), or other communication methods. In some embodiments,communication interface 202 can be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection. As another example,communication interface 202 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be implemented bycommunication interface 202. In such an implementation,communication interface 202 can send and receive electrical, electromagnetic or optical signals that carry digital data streams representing various types of information via a network. - Consistent with some embodiments,
communication interface 202 may receive service data (e.g., transaction information) fromterminal device 103.Communication interface 202 may further receive the user authentication data (e.g., salted and hashed password, token, or credentials) fromterminal device 103 when the user authentication is not waived based on the initial determination using received service data.Communication interface 202 may also provide the received data tostorage 208 for storage or toprocessor 204 for processing. -
Processor 204 may be a processing device that includes one or more general processing devices, such as a microprocessor, a central processing unit (CPU), a graphics processing unit (GPU), and the like. More specifically,processor 204 may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor running other instruction sets, or a processor that runs a combination of instruction sets.Processor 204 may also be one or more dedicated processing devices such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), system-on-chip (SoCs), and the like. -
Processor 204 may be configured as a separate processor module dedicated to performing payment verification based on the service data (and the user authentication if not waived) received fromterminal device 103. Alternatively,processor 204 may be configured as a shared processor module for performing other functions.Processor 204 may be communicatively coupled tomemory 206 and/orstorage 208 and configured to execute the computer-executable instructions stored thereon. -
Memory 206 andstorage 208 may include any appropriate type of mass storage provided to store any type of information thatprocessor 204 may need to operate.Memory 206 andstorage 208 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible (i.e., non-transitory) computer-readable medium including, but not limited to, a ROM, a flash memory, a dynamic RAM, and a static RAM. In some embodiments,memory 206 may include an in-memory database 210 (e.g., Redis) for attaining minimal response time (e.g., microseconds) by eliminating the need to access disks (e.g., storage 208). For example,blacklist 115 may be stored in in-memory database 210 to minimize determination time that whether an authentication is waived.Memory 206 and/orstorage 208 may be configured to store one or more computer programs that may be executed byprocessor 204 to perform service data processing and payment verification disclosed herein. For example,memory 206 and/orstorage 208 may be configured to store program(s) that may be executed byprocessor 204 to determine whether the user authentication is waived based on the received service data fromterminal device 103, and process the payment transaction according to the determination. -
Memory 206 and/orstorage 208 may be further configured to store information and data used byprocessor 204. For instance,memory 206 and/orstorage 208 may be configured to store the various types of data (e.g., service data) fromterminal device 103 and data related to location and setting ofterminal device 103.Memory 206 may store intermediate data such as information generated based on the service data for comparing with keys inblacklist 115.Memory 206 may further store known authentication information of the users.Storage 208 may store various logs for reporting or business intelligence (BI) purposes. The various types of data may be stored permanently, removed periodically, or disregarded immediately after each frame of data is processed. - As shown in
FIG. 2 ,processor 204 includes multiple modules, such as a suspicioustransaction determination unit 240, anauthentication validation unit 242, and the like. These modules (and any corresponding sub-modules or sub-units) can be hardware units (e.g., portions of an integrated circuit) ofprocessor 204 designed for use with other components or software units implemented byprocessor 204 through executing at least part of a program. The program may be stored on a computer-readable medium, and when executed byprocessor 204, it may perform one or more functions. AlthoughFIG. 2 showsunits processor 204, it is contemplated that these units may be distributed among multiple processors located near or remotely with each other. - In some embodiments,
units FIG. 2 may execute computer instructions to perform payment verification.FIG. 3 is a flowchart of an exemplary payment verification process, according to embodiments of the disclosure. In some embodiments, the user may use the terminal device (e.g., terminal device 103) to log onto a frontend (e.g., frontend 301) of the service payment platform to submit the service payment. For example,FIG. 4 illustrates anexemplary user interface 400 for making a service payment, according to embodiments of the disclosure. As shown inFIG. 4 , user interface 400 (as an example of frontend 301) allows the user to provideservice information 415, apayment amount 425, andrecipient information 435.Service information 415 can include a brief description of the service, such as travel, utility, childcare, landscaping, etc.Payment amount 425 includes a monetary amount (e.g., dollar) paid for the service.Recipient information 435 include the service user's bank information (e.g., bank name, bank account type, account number, etc.). It is contemplated thatuser interface 400 may request information other than above mentioned. For example,user interface 400 may further request a service order number, detailed service description, service provider's name, etc. The user may input the information by any suitable means, such as typing, selecting from a dropdown list, etc. As shown inFIG. 4 ,user interface 400 may also include a button (e.g., button 445) for assisting the service user to contact a customer service department before submitting the service payment. The service user may click a button (e.g., button 455) to submit the service payment. - Returning to
FIG. 3 , when the service user clicksbutton 445 inFIG. 4 , a Contact entrance for customer service purposes may be provided to help the user with any technical difficulties such as time out or unstable signals. In some embodiments, when the service user clicksbutton 455 inFIG. 4 , the service data including the service payment information is sent to abackend gateway 302 fromfrontend 301. Consistent with the present disclosure, the service data may include the transaction information collected by user interface 400 (e.g., service information, the transaction amount, and service recipient information), the user profile, the previous service information (e.g., travel history), the service geographic location, the IP address ofterminal device 103, or the device environmental identifier. In some embodiments,backend gateway 302 may receive the service data and distribute the received data into multiple places. For example,backend gateway 302 may send the service data logs to alogging system 304 for future reporting and BI purposes.Logging system 304 may be further used for training new machine learning models and updatingblacklist 115. The service data may also be sent to a risk management decision center 303 (referred to as “center 303” hereafter). - In some embodiments,
center 303 may employ suspicioustransaction determination unit 240 to compare the received service data withblacklist 115. For example,blacklist 115 may include a list of suspicious user identifiers (ID) (e.g. user names), a threshold of transaction amount, a list of suspicious IP addresses, and a list of suspicious transaction locations. As shown inFIG. 3 ,blacklist 115 is generated based on training data such as blacklist offline 351, offlinedeep features 352, andoffline transactions 353. Consistent with some embodiments, blacklist offline 351 may include a list of suspicious users with criminal charges (e.g., robbery, theft, battery, and assault). In some embodiments, the data may be periodically collected from the government resources. Blacklist offline 351 may further include a list of suspicious users with financial issues (e.g., loan default, bankruptcy, and the like) obtained from third party credit bureaus. - In some embodiments, offline
deep features 352 are generated using machine learning models including a deep learning model, a rule-based model, or a support vector machine (SVM). The machine learning models may be trained based on training data intraining database 110. In some embodiments, offlinedeep features 352 may include a user ID, a transaction amount threshold, a transaction frequency, a transaction location, a terminal device IP address, a user credit score, etc.Blacklist generation device 120 may provide offlinedeep features 352 through a business application programming interface (API) 362. For example,blacklist generation device 120 may train a machine learning model (e.g., a deep learning classification model) to classify existing service users into a group of suspicious users and a group of safe users. The suspicious users may be added to blacklist 115 for requiring the authentication information to verify the payment. Similarly,blacklist generation device 120 may apply another machine learning model (e.g., a rule-based model) on data of offline transactions 353 (e.g., transaction amount, transaction location, or transaction frequency) to generate rules of suspicious transaction behaviors. For example, an exemplary rule may be that if the transaction frequency exceeds 6 times for a single user within past 24 hours, the authentication information is required. In some embodiments,offline transactions 353 may be obtained through apayment API 363 fromother data sources 105 orterminal device 103. - In some embodiments, suspicious
transaction determination unit 240 may be configured to generate a set of corresponding keys based on the received service data fromterminal device 103 for comparing with the keys inblacklist 115. Consistent with some embodiments, the keys inblacklist 115 may be a list of suspicious users and transaction behaviors. For example, suspicioustransaction determination unit 240 may extract the user ID and the transaction amount from the received service data. If the extracted user ID matches any of user IDs listed inblacklist 115, suspicioustransaction determination unit 240 may generate a call back 305 to request the user to enter the authentication information infrontend 301. Similarly, if the transaction amount exceeds the threshold transaction amount listed inblacklist 305, suspicioustransaction determination unit 240 may generate call back 305 to request the user to enter the authentication information infrontend 301. -
FIG. 5 illustrates anexemplary user interface 500 for requesting an authentication, according to embodiments of the disclosure. As shown inFIG. 5 ,user interface 500 offrontend 301 includes anauthentication description 510, anauthentication input field 520, areset button 530, acontact us button 540, and a submitbutton 550. In some embodiments,authentication description 510 describes what type of authentication is required to enter in authentication input field onuser interface 500. For example, as shown inFIG. 5 , a password is required for verifying the payment. Consistent with the present disclosure, other types of authentication such as SSN or biometric information (e.g., fingerprint, face with/without masks, voice, and the like) can be acceptable authentications. For example, if the password information is not stored or available inmemory 206,processor 204 may request to enter the SSN of the user inauthentication input field 520 for verifying the payment. If the user forgets the authentication, the user can usereset button 530 to reset the authentication. For example, if the user forgets the password, he can press resetbutton 530, which will prompt him to follow certain steps for resetting the password. If the user wants to contact the customer service department before submitting the authentication, the user can use contact usbutton 540 to reach the customer service department. After entering the authentication, the user may use submitbutton 550 to submit the authentication information fromfrontend 301 tobackend gateway 302. - Returning to
FIG. 3 , when the service user clicks contact usbutton 540 inFIG. 5 , Contact entrance for customer service purposes may be provided to help the user with any technical difficulties such as time out or unstable signals. In some embodiments,backend gateway 302 may send the received data tologging system 304 for reporting and BI purposes.Backend gateway 302 may further send the received data tocenter 303. In some embodiments,center 303 may send the data to a verification anddisposition center 306 for validating the received authentication information. For example, verification anddisposition center 306 may employauthentication validation unit 242 inrisk management device 130 to compare the received authentication information fromfrontend 301 with the stored authentication information inmemory 206.Authentication validation unit 242 may retrieve the stored user authentication information through acheck API 307, and compare the retrieved user authentication with the received authentication information fromterminal device 103. Depending on the type of authentication information, check API may call the corresponding APIs (e.g.,SSN API 308, or other APIs 309) to complete the authentication comparison as shown inFIG. 3 . If the received authentication information matches the retrieved authentication, verification anddisposition center 306 may approve the transaction by sending call back 305 including a transaction approval message tofrontend 301. If the received authentication information does not match the retrieved authentication, verification anddisposition center 306 may block the transaction of the service payment by sending call back 305 including a disapproval message tofrontend 301. A transaction block message may display onterminal device 103. - For example,
FIG. 6 illustrates anexemplary user interface 600 for displaying a transaction processing result, according to embodiments of the disclosure. As shown inFIG. 6 ,user interface 600 displays a message of transaction being processed in afield 610. The message indicates the transaction is approved by verification anddisposition center 306.User interface 600 may further include acontact us button 620 for providing the CPO entrance for customer service purposes to help the user with any technical difficulties such as time out or unstable signals. - In some embodiments,
center 303 may waive the authentication for the transaction when the received server data of the transaction does not match any keys inblacklist 115.Center 303 may then send call back 305 including the transaction approval message to frontend 301, anduser interface 600 may display the message of transaction being processed onterminal device 103 as shown inFIG. 6 . If the transaction is not approved, the message displayed infield 610 may be changed accordingly to reflect the result. -
FIG. 7 is a flowchart of anexemplary method 700 for verifying a service payment, according to embodiments of the disclosure.Method 700 may be performed byrisk management device 130 and particularlyprocessor 204 or a separate processor not shown inFIG. 2 .Method 700 may include steps S702-S720 as described below. It is to be appreciated that some of the steps may be optional, and some of the steps may be performed simultaneously, or in a different order than shown inFIG. 7 . - In step S702 of
FIG. 7 ,risk management device 130 may be configured to receive service data fromterminal device 103. Consistent with the present disclosure, the service data may include the transaction amount, service information, and service recipient information. For example, for a transportation service, the service data may include a transportation expense (e.g., trip fare), a service content description, a passenger name, and a payment method. The service data may further include the user (e.g., service recipient) profile, the information of the previous trips, the geographical location of the service, the IP address ofterminal device 103, or the environmental identifier ofterminal device 103. - In step S704,
risk management device 130 may be configured to determine whether a user authentication information is waived for the transaction based on the received service data andblacklist 115. Consistent with the present disclosure,blacklist 115 may be trained byblacklist generation device 120 using the machine learning models (e.g., deep learning models, rule-based models, SVMs, and the like).Blacklist 115 may include a list of suspicious users and transaction behaviors. In some embodiments,blacklist generation device 120 may retrain each machine learning model at a predetermined frequency.Blacklist 115 therefore may be updated periodically based on the retrained machine learning models. For example,blacklist generation device 120 may retrain the transaction related models every hour.Blacklist 115 therefore can include an updated transaction pattern and exclude an outdated transaction pattern when determining whether the payment the user authentication information is waived for a new transaction. - If the service data does not match keys on blacklist 115 (step S706: No),
risk management device 130 may approve the transaction in step S708. If the service data match any key (e.g., suspicious user name, transaction amount threshold) in blacklist 115 (step S706: Yes),risk management device 130 may be configured to request the user authentication information for verifying the payment. For example, the service user's name may match a suspicious user name listed inblacklist 115, the transaction amount may exceed a transaction amount threshold listed inblacklist 115, or the combination of multiple blacklists. The list of suspicious users and the transaction amount threshold may be generated using different machine learning models trained byblacklist generation device 120 at different frequencies. - In step S710,
risk management device 130 may be configured to send a request toterminal device 103 to collect the user authentication information. In some embodiments,risk management device 130 may be further configured to determine what type of user authentication information to request, which may depend on the known user authentication information stored inrisk management device 130. For example, if the user has created a password,risk management device 130 may request the password as the user authentication information. If the user did not create a password,risk management device 130 may request other types of user authentication information for verifying the payment, such as an SSN or a driver's license number. - In step S712,
risk management device 130 may be configured to receive the user authentication information fromterminal device 103. Consistent with the present disclosure, the user authentication information may include a password, an SSN, or user biometrics (e.g., fingerprint, face, voice, and the like). - In step S714,
risk management device 130 may be configured to validate the received user authentication information. For example,risk management device 130 may compare the received user authentication information with the known user authentication information. The known user authentication information may be provided by the user before the transaction is stored inmemory 206 ofrisk management device 130. - If the received user authentication information does not match the known user authentication information stored in risk management device 130 (step S716: No),
risk management device 130 may block the transaction of the service payment in step S718. If the received user authentication information matches the known user authentication information stored in risk management device 130 (step S716: Yes),risk management device 130 may approve the transaction of the service payment in step S720. - Although the some of the embodiments are described in the context of a transportation service provided to a passenger and the passenger being the service use who uses the service payment platform to pay for the service, it is contemplated that the disclosed embodiments can be applied or adapted for verifying payments to other types of services submitted by other types of service users. For example, the service may be childcare, landscaping, HVAC maintenance, house repairs, food and beverage service, etc. The disclosed embodiments may be further applied or adapted for verifying payments for non-services, such as merchandises, utilities, performances, etc.
- Another aspect of the disclosure is directed to a non-transitory computer-readable medium storing instructions which, when executed, cause one or more processors to perform the methods, as discussed above. The computer-readable medium may include volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other types of computer-readable medium or computer-readable storage devices. For example, the computer-readable medium may be the storage device or the memory module having the computer instructions stored thereon, as disclosed. In some embodiments, the computer-readable medium may be a disc or a flash drive having the computer instructions stored thereon.
- It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed system and related methods. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed system and related methods.
- It is intended that the specification and examples be considered as exemplary only, with a true scope being indicated by the following claims and their equivalents.
Claims (20)
1. A payment verification system for a payment platform, comprising:
a communication interface configured to receive service data associated with a transaction from a terminal device associated with a user of the payment platform;
at least one processor configured to:
generate a blacklist using at least one machine learning model, wherein the blacklist includes a set of keys associated with suspicious users and transaction behaviors;
maintain the blacklist in a memory associated with the payment platform;
automatically determine an authentication is waived for the transaction and approve the transaction without requesting user authentication information from the terminal device when the service data received from the terminal device do not match any key of the set of keys associated with the suspicious users and the transaction behaviors included in the blacklist; and
automatically determine the authentication is not waived and request the user authentication information from the terminal device for validation when at least one of the service data matches one or more keys of the set of keys included in the blacklist.
2. The payment verification system of claim 1 , wherein to generate the blacklist using the at least one machine learning model, the at least one processor is further configured to:
classify users into a group of suspicious users and a group of safe users using the at least one machine learning model; and
add identifications of the suspicious users to the blacklist.
3. The payment verification system of claim 1 , wherein to generate the blacklist using the at least one machine learning model, the at least one processor is further configured to:
generate rules of suspicious transaction behaviors using the at least one machine learning model; and
add thresholds associated with the rules of the suspicious transaction behaviors to the blacklist.
4. The payment verification system of claim 1 , wherein the keys associated with the suspicious users are generated by a first machine learning model and the keys associated with the transaction behaviors are generated by a second machine learning model different from the first machine learning model.
5. The payment verification system of claim 4 , wherein the first machine learning model and the second machine learning model are trained at different frequencies.
6. The payment verification system of claim 1 , wherein the service data associated with the transaction further comprises at least one of a transaction amount, service information, recipient information, a user profile, previous trips, geo-locations, an Internet Protocol (IP) address of the terminal device, or an environmental identifier of the terminal device.
7. The payment verification system of claim 1 , the at least one processor is further configured to:
validate the user authentication information;
approve the transaction when the user authentication information is validated; and
block the transaction when the user authentication information fails to validate.
8. The payment verification system of claim 1 , wherein the at least one machine learning model is retrained using service data logs that reflect an updated transaction pattern,
wherein the at least one processor is further configured to:
update the blacklist using the retrained machine learning model.
9. The payment verification system of claim 8 , wherein the at least one machine learning model is retained at a predetermined frequency,
wherein blacklist is updated periodically using the retrained machine learning model.
10. The payment verification system of claim 1 , wherein the at least one machine learning model includes at least one of a deep learning model, a rule-based model, or a support vector machine (SVM).
11. A payment verification method for a payment platform, comprising:
receiving, by a communication interface of a processing device, service data associated with a transaction from a terminal device associated with a user of the payment platform;
generating, by at least one processor of the processing device, a blacklist using at least one machine learning model, wherein the blacklist includes a set of keys associated with suspicious users and transaction behaviors;
maintaining, by the at least one processor of the processing device, the blacklist in a memory of the processing device;
automatically determining, by the at least one processor of the processing device, an authentication is waived for the transaction and approve the transaction without requesting user authentication information from the terminal device when the service data received from the terminal device do not match any key of the set of keys associated with the suspicious users and the transaction behaviors included in the blacklist; and
automatically determining, by the at least one processor of the processing device, the authentication is not waived and request the user authentication information from the terminal device for validation when at least one of the service data matches one or more keys of the set of keys included in the blacklist.
12. The payment verification method of claim 11 , wherein generating the blacklist using the at least one machine learning model further comprises:
classifying users into a group of suspicious users and a group of safe users using the at least one machine learning model; and
adding identifications of the suspicious users to the blacklist.
13. The payment verification method of claim 11 , wherein generating the blacklist using the at least one machine learning model further comprises:
generating rules of suspicious transaction behaviors using the at least one machine learning model; and
adding thresholds associated with the rules of the suspicious transaction behaviors to the blacklist.
14. The payment verification method of claim 11 , wherein the keys associated with the suspicious users are generated by a first machine learning model and the keys associated with the transaction behaviors are generated by a second machine learning model different from the first machine learning model.
15. The payment verification method of claim 14 , wherein the first machine learning model and the second machine learning model are trained at different frequencies.
16. The payment verification method of claim 11 , wherein the service data associated with the transaction further comprises at least one of a transaction amount, service information, recipient information, a user profile, previous trips, geo-locations, an Internet Protocol (IP) address of the terminal device, or an environmental identifier of the terminal device.
17. The payment verification method of claim 11 , further comprising:
validating the user authentication information;
approving the transaction when the user authentication information is validated; and
blocking the transaction when the user authentication information fails to validate.
18. The payment verification method of claim 11 , wherein the at least one machine learning model is retrained at a predetermined frequency using service data logs that reflect an updated transaction pattern,
wherein the method further comprises:
updating the blacklist periodically using the retrained machine learning model.
19. The payment verification method of claim 11 , wherein the at least one machine learning model includes at least one of a deep learning model, a rule-based model, or a support vector machine (SVM).
20. A non-transitory computer-readable medium having instructions stored thereon that, when executed by at least one processor, causes the at least one processor to perform a payment verification method for a payment platform, the payment verification method comprising:
receiving, by a communication interface of a processing device, service data associated with a transaction from a terminal device associated with a user of the payment platform;
generating a blacklist using at least one machine learning model, wherein the blacklist includes a set of keys associated with suspicious users and transaction behaviors;
automatically determining, by the at least one processor of the processing device, an authentication is waived for the transaction and approve the transaction without requesting user authentication information from the terminal device when the service data received from the terminal device do not match any key of the set of keys associated with the suspicious users and the transaction behaviors included in the blacklist; and
automatically determining the authentication is not waived and request the user authentication information from the terminal device for validation when at least one of the service data matches one or more keys of the set of keys included in the blacklist.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/953,199 US20230020968A1 (en) | 2020-11-01 | 2022-09-26 | Systems and methods for verifying digital payments |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/086,448 US11488178B2 (en) | 2020-11-01 | 2020-11-01 | Systems and methods for verifying digital payments |
US17/953,199 US20230020968A1 (en) | 2020-11-01 | 2022-09-26 | Systems and methods for verifying digital payments |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/086,448 Continuation US11488178B2 (en) | 2020-11-01 | 2020-11-01 | Systems and methods for verifying digital payments |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230020968A1 true US20230020968A1 (en) | 2023-01-19 |
Family
ID=81379083
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/086,448 Active 2040-12-12 US11488178B2 (en) | 2020-11-01 | 2020-11-01 | Systems and methods for verifying digital payments |
US17/953,199 Pending US20230020968A1 (en) | 2020-11-01 | 2022-09-26 | Systems and methods for verifying digital payments |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/086,448 Active 2040-12-12 US11488178B2 (en) | 2020-11-01 | 2020-11-01 | Systems and methods for verifying digital payments |
Country Status (1)
Country | Link |
---|---|
US (2) | US11488178B2 (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11941599B2 (en) * | 2020-12-31 | 2024-03-26 | Capital One Services, Llc | Machine-learning based electronic activity accuracy verification and detection of anomalous attributes and methods thereof |
US20220318350A1 (en) * | 2021-03-30 | 2022-10-06 | Cisco Technology, Inc. | Dynamic transaction-aware web application authentication using call intercepts |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190392450A1 (en) * | 2018-06-22 | 2019-12-26 | Mastercard International Incorporated | Systems and methods for authenticating online users in regulated environments |
US20210042752A1 (en) * | 2019-08-08 | 2021-02-11 | Mastercard International Incorporated | Methods, system and computer program products for implementing authentication waiver based electronic payment transactions |
WO2021034589A1 (en) * | 2019-08-16 | 2021-02-25 | Amazon Technologies, Inc. | Predicting successful exemptions to strong authentication requirements |
WO2021041168A1 (en) * | 2019-08-28 | 2021-03-04 | Amazon Technologies, Inc. | Eligibility determination for delegation exemption to strong authentication requirements |
WO2021041105A1 (en) * | 2019-08-28 | 2021-03-04 | Amazon Technologies, Inc. | Selecting exemptions to strong authentication requirements |
US20210065291A1 (en) * | 2019-08-28 | 2021-03-04 | Amazon Technologies, Inc. | User interfaces that differentiate payment instruments having a trusted beneficiary |
US20210304204A1 (en) * | 2020-03-27 | 2021-09-30 | Paypal, Inc. | Machine learning model and narrative generator for prohibited transaction detection and compliance |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150039513A1 (en) * | 2014-02-14 | 2015-02-05 | Brighterion, Inc. | User device profiling in transaction authentications |
US9684775B2 (en) * | 2014-10-15 | 2017-06-20 | Qualcomm Incorporated | Methods and systems for using behavioral analysis towards efficient continuous authentication |
US20160239649A1 (en) * | 2015-02-13 | 2016-08-18 | Qualcomm Incorporated | Continuous authentication |
US11210670B2 (en) * | 2017-02-28 | 2021-12-28 | Early Warning Services, Llc | Authentication and security for mobile-device transactions |
US10965668B2 (en) * | 2017-04-27 | 2021-03-30 | Acuant, Inc. | Systems and methods to authenticate users and/or control access made by users based on enhanced digital identity verification |
US10650128B2 (en) * | 2017-10-18 | 2020-05-12 | Mastercard International Incorporated | Methods and systems for automatically configuring user authentication rules |
US11080617B1 (en) * | 2017-11-03 | 2021-08-03 | Paypal, Inc. | Preservation of causal information for machine learning |
CN108596434B (en) * | 2018-03-23 | 2019-08-02 | 卫盈联信息技术(深圳)有限公司 | Fraud detection and methods of risk assessment, system, equipment and storage medium |
CN112166450A (en) * | 2018-04-17 | 2021-01-01 | 维萨国际服务协会 | System and method for processing cardless transactions |
US10803458B1 (en) * | 2018-12-20 | 2020-10-13 | Worldpay, Llc | Methods and systems for detecting suspicious or non-suspicious activities involving a mobile device use |
US20210004807A1 (en) * | 2019-07-01 | 2021-01-07 | Raymond Anthony Joao | Apparatus and method for providing transaction security and/or account security |
WO2021011769A1 (en) * | 2019-07-17 | 2021-01-21 | Sidewalk Labs LLC | Methods, systems, and media for secure authentication of users using one or more biometric recognition systems |
US11615174B2 (en) * | 2019-08-30 | 2023-03-28 | Biocube Technologies Inc | Method and a system to locally store and authenticate a data of a user |
US20210192524A1 (en) * | 2019-12-20 | 2021-06-24 | Paypal, Inc. | Feature-Based Recurrent Neural Networks for Fraud Detection |
SG10202000100YA (en) * | 2020-01-06 | 2020-07-29 | Alipay Labs Singapore Pte Ltd | Biometric based user identity verification |
US11562365B2 (en) * | 2020-01-30 | 2023-01-24 | Capital One Services, Llc | User authentication based on a user interaction associated with a transaction |
US11671424B2 (en) * | 2020-04-28 | 2023-06-06 | Paypal, Inc. | Machine learning techniques for performing authentication based on a user's interaction with a client device |
US20210383391A1 (en) * | 2020-06-03 | 2021-12-09 | Fidelity Information Services, Llc. | Systems and methods for fraud dispute of pending transactions |
US11734558B2 (en) * | 2020-06-12 | 2023-08-22 | Paypal, Inc. | Machine learning module training using input reconstruction techniques and unlabeled transactions |
CN112184241B (en) * | 2020-09-27 | 2024-02-20 | 中国银联股份有限公司 | Identity authentication method and device |
-
2020
- 2020-11-01 US US17/086,448 patent/US11488178B2/en active Active
-
2022
- 2022-09-26 US US17/953,199 patent/US20230020968A1/en active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190392450A1 (en) * | 2018-06-22 | 2019-12-26 | Mastercard International Incorporated | Systems and methods for authenticating online users in regulated environments |
US20210042752A1 (en) * | 2019-08-08 | 2021-02-11 | Mastercard International Incorporated | Methods, system and computer program products for implementing authentication waiver based electronic payment transactions |
WO2021034589A1 (en) * | 2019-08-16 | 2021-02-25 | Amazon Technologies, Inc. | Predicting successful exemptions to strong authentication requirements |
WO2021041168A1 (en) * | 2019-08-28 | 2021-03-04 | Amazon Technologies, Inc. | Eligibility determination for delegation exemption to strong authentication requirements |
WO2021041105A1 (en) * | 2019-08-28 | 2021-03-04 | Amazon Technologies, Inc. | Selecting exemptions to strong authentication requirements |
US20210065291A1 (en) * | 2019-08-28 | 2021-03-04 | Amazon Technologies, Inc. | User interfaces that differentiate payment instruments having a trusted beneficiary |
US20210304204A1 (en) * | 2020-03-27 | 2021-09-30 | Paypal, Inc. | Machine learning model and narrative generator for prohibited transaction detection and compliance |
Also Published As
Publication number | Publication date |
---|---|
US20220138768A1 (en) | 2022-05-05 |
US11488178B2 (en) | 2022-11-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10402827B2 (en) | Biometrics transaction processing | |
US11019055B1 (en) | Biometric authentication, decentralized learning framework, and adaptive security protocols in distributed terminal network | |
US10546296B2 (en) | Public ledger authentication system | |
US9864987B2 (en) | Account provisioning authentication | |
CN107194806B (en) | Server for mobile phone loan | |
US9171306B1 (en) | Risk-based transaction authentication | |
US8170953B1 (en) | Systems and method for screening payment transactions | |
US20230020968A1 (en) | Systems and methods for verifying digital payments | |
US8296232B2 (en) | Systems and methods for screening payment transactions | |
US20220222673A1 (en) | Identity-based transaction processing | |
US11714913B2 (en) | System for designing and validating fine grained fraud detection rules | |
CN102197407A (en) | System and method of secure payment transactions | |
US20110173122A1 (en) | Systems and methods of bank security in online commerce | |
CN109544335B (en) | Transaction data processing method, device, equipment and storage medium based on blockchain | |
CA2436319A1 (en) | Payment validation network | |
US20170161745A1 (en) | Payment account fraud detection using social media heat maps | |
US20170353436A1 (en) | Compromise alert and reissuance | |
US10846699B2 (en) | Biometrics transaction processing | |
US20180225656A1 (en) | Transmitting sensitive data from a digital wallet on a user device to a designated server for use by a transaction card application process | |
US20190266600A1 (en) | System and method for monetary transaction | |
CN112686666A (en) | Electronic wallet transaction method and device for railway business system | |
US20230177495A1 (en) | Systems and methods for digital identity score | |
US20220383323A1 (en) | Fraud detection systems and methods | |
WO2023055345A1 (en) | Device security with one-way function | |
WO2023003552A1 (en) | Secure interaction using uni-directional data correlation tokens |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: BEIJING DIDI INFINITY TECHNOLOGY AND DEVELOPMENT CO., LTD., CHINA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ZHAI, JINJIAN;REEL/FRAME:061219/0452 Effective date: 20201026 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |