Server and method for assessing risk of user's account for multiple types of on-demand services
By storing user behavior profiles in the server and adjusting user risk scores using machine learning, the complexity of user account risk management across different types of on-demand services is solved, and unified assessment and management of user account risks is realized, and data processing is reduced Complexity and storage costs.
Patent Information
- Application Number
- CN202380044213.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-06-02
- Filing Date
- 2023-05-04
- Publication Date
- 2024-12-27
AI Technical Summary
The prior art is difficult to effectively monitor and manage user account risks across different types of on-demand services, resulting in increased data processing complexity and storage costs, and it is difficult to achieve global monitoring of potential fraud and risky behavior of users.
Design a server and method to store user behavior profiles, assign user risk scores to user accounts, adjust scores based on events, and use machine learning to update the score table, determine account risks, trigger activation or deactivation of accounts, and determine transaction processing priorities .
It realizes unified assessment and management of user accounts risks of multiple types of on-demand service users, reduces data processing complexity and storage costs, and improves the monitoring ability of potential fraud.
Smart Images

Figure CN119213456A_ABST
Abstract
Description
Technical Field
[0001] Various embodiments are directed to servers and methods for assessing the risk of a user's account for various types of on-demand services. Background Art
[0002] Due to the development of information technology and users' growing expectations for immediacy, businesses offer a wide range of on-demand services. On-demand services can allow users to satisfy their needs via instant access to goods and / or services. Due to the growth of on-demand services, businesses subsequently offer multiple types of on-demand services (also referred to as "different vertical businesses") via a single platform, such as transportation services, food delivery services, grocery delivery services, or fintech services.
[0003] However, different vertical businesses may have their own database schemas for collecting and processing information. In order to protect a specific vertical business using data obtained from N other vertical businesses, N times the data processing may be required. Ultimately, if the platform provides N vertical businesses in total, N×(N-1) data processing may be required to cross-protect different vertical businesses using data from each other's vertical businesses. Due to data processing complexity and / or corresponding storage costs, this may make it difficult for platform providers to monitor users' potential fraud and risky behaviors across different types of on-demand services as a whole.
[0004] Therefore, there is a need to provide a solution for assessing the risk of a user's account for various types of on-demand services. Summary of the invention
[0005] According to various embodiments, a server for evaluating the risk of a user's account for multiple types of on-demand services is provided. The server includes: a memory configured to store a user's behavioral profile for at least one of the multiple types of on-demand services; and a processor configured to assign a user risk score to the user's account, detect the occurrence of an event linked to the user's account for any of the multiple types of on-demand services, adjust the user risk score assigned to the user's account by adding or subtracting a predetermined score based on the event, and evaluate the risk of the user's account for the multiple types of on-demand services based on the adjusted user risk score, wherein the processor is configured to change the predetermined score to be added or subtracted based on the event based on the user's behavioral profile.
[0006] In some implementations, the processor is configured to determine whether the adjusted user risk score is below a predetermined threshold, and if the adjusted user risk score is below the predetermined threshold, trigger the user to perform a predetermined task to continue activating the user's account for multiple types of on-demand services.
[0007] In some implementations, the processor is configured to deactivate the user's account for multiple types of on-demand services if the scheduled task is not performed within a predetermined time.
[0008] In some implementations, the processor is configured to adjust a user risk score assigned to an account of the user by adding a predetermined score corresponding to the task if the predetermined task is performed within the predetermined time.
[0009] In some implementations, the processor is configured to create an event score table indicating a predetermined score corresponding to each of the plurality of events.
[0010] In some implementations, the processor is configured to use machine learning to update the predetermined score corresponding to each of the plurality of events of the event score table.
[0011] In some embodiments, the processor is configured to receive a request for a transaction from a user and decide whether to process the transaction and / or a priority for processing the transaction based on the adjusted user risk score.
[0012] In some implementations, the user's behavioral profile includes a history of one or more events performed by the user for at least one of a plurality of types of on-demand services.
[0013] According to various embodiments, a method for evaluating the risk of a user's account for multiple types of on-demand services is provided, the method comprising: assigning a user risk score to the user's account; detecting the occurrence of an event linked to the user's account for any of the multiple types of on-demand services; adjusting the user risk score assigned to the user's account by adding or subtracting a predetermined score based on the event; and evaluating the risk of the user's account for the multiple types of on-demand services based on the adjusted user risk score, wherein the predetermined score to be added or subtracted based on the event varies based on the user's behavioral profile for at least one of the multiple types of on-demand services.
[0014] In some embodiments, the method further includes: determining whether the adjusted user risk score is below a predetermined threshold; and if the adjusted user risk score is below the predetermined threshold, triggering the user to perform a predetermined task to continue activating the user's account for multiple types of on-demand services.
[0015] In some implementations, the method further includes deactivating the user's account for multiple types of on-demand services if the scheduled task is not performed within a predetermined time.
[0016] In some implementations, the method further includes: if the predetermined task is performed within the predetermined time, adjusting the user risk score assigned to the account of the user by adding a predetermined score corresponding to the task.
[0017] In some implementations, the method further includes creating an event score table indicating a predetermined score corresponding to each of the plurality of events.
[0018] In some implementations, the method further includes using machine learning to update a predetermined score corresponding to each of the plurality of events of the event score table.
[0019] In some embodiments, the method further includes: receiving a transaction request from a user; and determining whether to process the transaction and / or a priority for processing the transaction based on the adjusted user risk score.
[0020] In some implementations, the user's behavioral profile includes a history of one or more events performed by the user for at least one of a plurality of types of on-demand services.
[0021] According to various embodiments, there is provided a data processing device configured to execute the method of any one of the above embodiments.
[0022] According to various embodiments, a computer program element is provided, comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of the above embodiments.
[0023] According to various embodiments, a computer readable medium is provided, including program instructions, which, when executed by one or more processors, cause the one or more processors to perform any one of the methods in the above embodiments. The computer readable medium may include a non-transitory computer readable medium. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] The invention will be better understood with reference to the detailed description when considered in conjunction with the non-limiting examples and accompanying drawings, in which:
[0025] - Figure 1 The infrastructure of a system including a server that assesses the risk of a user's account for multiple types of on-demand services is shown in accordance with various embodiments.
[0026] - Figure 2 A block diagram of a server that assesses the risk of a user's account for various types of on-demand services is shown in accordance with various embodiments.
[0027] - Figure 3 A flow chart illustrating a method of assessing the risk of a user's account for various types of on-demand services in accordance with various embodiments.
[0028] - Figure 4 An exemplary event score table is shown in accordance with various implementations.
[0029] - Figure 5 An exemplary flow chart of a method of assessing the risk of a user's account for various types of on-demand services in accordance with various embodiments is shown.
[0030] - Figure 6 A block diagram of a server that assesses the risk of a user's account for various types of on-demand services is shown in accordance with various embodiments. DETAILED DESCRIPTION
[0031] The following detailed description refers to the accompanying drawings, which illustrate the specific details and embodiments of the present disclosure in a diagrammatic manner. The detailed description of these embodiments is sufficient to enable those skilled in the art to implement the present disclosure. Other embodiments may also be utilized and structural and logical changes may be made thereto without departing from the scope of the present disclosure. The various embodiments are not necessarily mutually exclusive, as some embodiments may be combined with one or more other embodiments to form new embodiments.
[0032] Embodiments described in the context of one of the server and the method are also valid for the other server and the method. Similarly, embodiments described in the context of the server are also valid for the method, and vice versa.
[0033] Features described in the context of one embodiment may be correspondingly applicable to the same or similar features in other embodiments. Features described in the context of one embodiment may be correspondingly applicable to other embodiments, even if not explicitly described in these other embodiments. In addition, additions and / or combinations and / or alternatives as described for features in the context of one embodiment may be correspondingly applicable to the same or similar features in other embodiments.
[0034] In the context of various embodiments, the articles “a,” “an,” and “the” used with respect to features or elements include reference to one or more features or elements.
[0035] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.
[0036] Throughout the description, the term "module" may be understood as an application specific integrated circuit (ASIC), an electronic circuit, a combinational logic circuit, a field programmable gate array (FPGA), a processor that executes code, other suitable hardware components that provide the described functionality, or any combination thereof. The term "module" may include a memory that stores code executed by a processor.
[0037] Hereinafter, embodiments will be described in detail.
[0038] Figure 1 The infrastructure of a system 200 including a server 100 for assessing the risk of an account of a user 160 for multiple types of on-demand services is shown according to various embodiments.
[0039] like Figure 1 As shown in , system 200 may include, but is not limited to, server 100 , database system 140 , computing device 161 , one or more external devices 171 , 172 , 173 , 174 , and network 180 .
[0040] In some embodiments, the on-demand service may be a service that allows the user 160 to satisfy the user's needs via instant access to goods and / or services. The platform provider may provide multiple types of on-demand services (also referred to as "different vertical businesses"), such as transportation services, food delivery services, grocery delivery services, or fintech services, via a single platform operated by the server 100. The user 160 may use a single user account (also referred to as "the user's account") to enjoy multiple types of on-demand services via a single platform operated by the server 100.
[0041] In some embodiments, the network 180 may include, but is not limited to, a local area network (LAN), a wide area network (WAN), a global area network (GAN), or any combination thereof. The network 180 may provide wired communication, wireless communication, or a combination of wired and wireless communication between the server 100 and the computing device 161 and between the server 100 and one or more external devices 171, 172, 173, 174.
[0042] In some embodiments, computing device 161 may be connected to server 100 via network 180. In some embodiments, computing device 161 may be arranged to communicate data or signals with server 100 via network 180. In some embodiments, computing device 161 may include, but is not limited to, at least one of the following: a mobile phone, a tablet computer, a laptop computer, a desktop computer, a head-mounted display, and a smart watch. In some embodiments, computing device 161 may belong to user 160. Although not shown, in some embodiments, system 200 may also include multiple computing devices, each of which belongs to multiple users. In some embodiments, user 160 and multiple users may be customers requesting on-demand services (e.g., transportation services).
[0043] In some embodiments, computing device 161 may include a location sensor. In some embodiments, the location sensor may communicate with at least one of a global positioning satellite (GPS) server, a network server, and a Wi-Fi server to detect the location of computing device 161. In some embodiments, computing device 161 may generate information about the location of computing device 161.
[0044] In some embodiments, computing device 161 may have a software application installed thereon (also referred to as a "user application") that may allow user 160 to make requests for on-demand services provided by a service provider. In some embodiments, user 160 may log in using the user's account and request on-demand services using a user interface provided by the software application. In some embodiments, the software application may allow payment for on-demand services via server 100 and / or via one or more payment processing servers (not shown).
[0045] In some embodiments, for example, the server 100 implemented by a server computer may include a communication interface 110, a processor 120, and a memory 130 (as will be referred to in Figure 2 described).
[0046] In some implementations, server 100 may communicate with computing device 161 via network 180. In some implementations, computing device 161 may receive a request for an on-demand service from user 160. Computing device 161 may send the request to server 100 via network 180. In some implementations, computing device 161 may send information about the location of computing device 161 to server 100 via network 180.
[0047] In some embodiments, the system 200 may also include a database 150. In some embodiments, the database 150 may be part of a database system 140 that may be external to the server 100. The server 100 may communicate with the database 150. In some other embodiments, although not shown, the database 150 may be implemented locally in the memory 130 of the server 100.
[0048] In some embodiments, one or more external devices 171, 172, 173, 174 belong to a service provider that provides an on-demand service. For example, a first external device 171 may belong to a transportation service provider to provide transportation services, a second external device 172 may belong to a food service provider to provide food delivery services, a third external device 173 may belong to a market service provider to provide grocery delivery services, and a fourth external device 174 may belong to a fintech service provider to provide fintech services such as payment services. It is understood that the types of on-demand services are not limited thereto. It is understood that for each type of on-demand service, there may be multiple external devices, each corresponding to multiple service providers.
[0049] In some implementations, the server 100 may communicate with one or more external devices 171, 172, 173, 174 via a network 180. One or more of the external devices 171, 172, 173, 174 may have installed thereon a service provider application (also referred to as a "service provider application") that allows its service provider to receive, accept, and fulfill requests for on-demand services from the computing device 161. Requests for on-demand services may be received at the server 100 and distributed to the one or more external devices 171, 172, 173, 174 based on various considerations, such as the type of service provided by the service provider, the ability of the service provider to fulfill the request, proximity to the user 160, etc.
[0050] In some embodiments, the server 100 may receive a request for an on-demand service and information about the location of the computing device 161, and then determine which type of on-demand service is requested by the user 160. For example, if the user 160 requests a transportation service, the server 100 may communicate with the first external device 171 to provide the transportation service to the user 160. As another example, if the user 160 requests a food delivery service, the server 100 may communicate with the second external device 172 to provide the food delivery service to the user 160.
[0051] Figure 2 A block diagram of a server 100 is shown for assessing the risk of an account of a user 160 for various types of on-demand services in accordance with various embodiments.
[0052] like Figure 2 As shown in , a server 100 implemented by, for example, a server computer may include a communication interface 110 , a processor 120 , and a memory 130 .
[0053] In some embodiments, the memory 130 (also referred to as a "database") can temporarily or permanently store input data and / or output data. In some embodiments, the memory 130 can store data that allows the server 100 to perform the method 300 (as described in reference to Figure 3 In some embodiments, the program code may be embedded in a software development kit (SDK). The memory 130 may include an internal memory and / or an external memory of the server 100. The external memory may include, but is not limited to, an external storage medium such as a memory card, a flash drive, and a network memory.
[0054] In some embodiments, the memory 130 may store a behavior profile of the user 160 for at least one of the multiple types of on-demand services. In some embodiments, the behavior profile of the user 160 may include a history of one or more events performed by the user 160 for at least one of the multiple types of on-demand services. For example, the behavior profile of the user 160 may include information about whether there are any overdue payments / non-payments for one or more on-demand services previously provided to the user 160. In some other embodiments, the behavior profile of the user 160 may be stored in the database 150, such as Figure 1 As shown in , the processor 120 can obtain the behavior profile of the user 160 from the database 150.
[0055] In some embodiments, the communication interface 110 may allow one or more computing devices (including the computing device 161) to communicate with the processor 120 of the server 100 via the network 180, such as Figure 1 In some embodiments, Figure 1 As shown in , computing device 161 may belong to user 160 who wants to request an on-demand service. In some implementations, communication interface 110 may send signals to and / or receive signals from computing device 161 via network 180.
[0056] In some embodiments, the communication interface 110 may allow one or more external devices 171, 172, 173, 174 (e.g., a transportation service provider device 171, a food service provider device 172, a marketplace service provider device 173, and a fintech service provider device 174) to communicate with the processor 120 of the server 100 via a network 180, such as Figure 1 In some implementations, the communication interface 110 may send signals to and / or receive signals from one or more external devices 171 , 172 , 173 , 174 via the network 180 .
[0057] In some implementations, communication interface 110 may receive a request for an on-demand service from computing device 161 via network 180. Communication interface 110 may then send the request for the on-demand service to processor 120.
[0058] In some implementations, communication interface 110 may also receive information about the location of computing device 161 from computing device 161 via network 180. Communication interface 110 may then send the information about the location of computing device 161 to processor 120.
[0059] The processor 120 may include, but is not limited to, a microprocessor, an analog circuit, a digital circuit, a mixed signal circuit, a logic circuit, an integrated circuit, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any combination thereof. Any other type of implementation of the corresponding functions described in further detail below may also be understood as the processor 120.
[0060] In some embodiments, the processor 120 may be connected to the communication interface 110. In some embodiments, the processor 120 may be arranged to be in data or signal communication with the communication interface 110 to receive a request for an on-demand service and information about the location of the computing device 161.
[0061] In some embodiments, the processor 120 may assign a user risk score to the account of the user 160. In some embodiments, each user of the plurality of users may initially be given a user risk score. The user risk score may be added and subtracted based on each event (as described below).
[0062] In some embodiments, the user risk score of each user may represent the risk that each user poses to the platform provider and / or service provider. Each user may have their own user risk score. For example, the user risk score of user 160 may represent the possibility that user 160 will commit fraud. As an example, the user risk score of user 160 may represent the possibility that user 160 will not pay the on-demand service provided by the service provider via the platform. For ease of explanation, throughout the description, a user 160 with a high user risk score means that user 160 is less risky, and vice versa. Although not described herein, it is understood that in some other embodiments, a user 160 with a low user risk score means that user 160 is less risky, and vice versa.
[0063] In some embodiments, the processor 120 may assign the same user risk score, such as "100", to each account of the plurality of users. An initial score (also referred to as a "starting score") may be given to each of the plurality of users. In some other embodiments, the processor 120 may divide the plurality of users into two or more groups and assign different user risk scores to each group. For example, the processor 120 may divide the plurality of users into two or more groups based on behavioral profiles, and assign a high user risk score to a group with a good behavioral profile, and assign a low user risk score to a group with a bad behavioral profile. As an example, the processor 120 may convert the behavioral profile of each user into a value or rating for grouping.
[0064] In some embodiments, the processor 120 may detect the occurrence of an event linked to the account of the user 160 for any of a plurality of types of on-demand services. In some embodiments, the processor 120 may detect a category of events, and detect events under the category of events. In some embodiments, the category of events may include, but is not limited to, logging into a software application using the account of the user 160, payment for an on-demand service, requesting (booking) for an on-demand service, and completing receipt of an on-demand service. In some embodiments, events under the category of logging into a software application may include, but are not limited to, detecting a risky IP (Internet Protocol) address (e.g., an IP address owned by a data center indicating a risk of a cluster of devices), and detecting that the computing device 161 is shared with other users. In some embodiments, events under the category of payment may include, but are not limited to, successful authentication of the user 160, failed authentication of the user 160, and detecting that a credit card registered by the user 160 is shared with other users. In some embodiments, events under the category of booking may include, but are not limited to, detecting that the same driver was previously assigned to the user 160.
[0065] In some implementations, the processor 120 may adjust the user risk score assigned to the account of the user 160 by adding or subtracting a predetermined score based on an event. For example, if the user 160 logs into the software application and the processor 120 detects that the IP address of the user 160 is a risky IP address, the processor 120 may subtract a predetermined score (e.g., "2") from the user risk score (e.g., "100"). As another example, if the user 160 makes a request for a transportation service and the processor 120 detects that the user 160 previously attempted too frequent reservations that were subsequently canceled before a driver was assigned to the user 160, the processor 120 may subtract a predetermined score (e.g., "20") from the adjusted user risk score (e.g., "98", which is calculated by subtracting "2" from "100"). As another example, if the user 160 successfully authenticates the user 160, the processor 120 may add a predetermined score (e.g., "15") to the adjusted user risk score (e.g., "78") (calculated by subtracting "20" from "98").
[0066] In some embodiments, the processor 120 may change the predetermined score to be added or subtracted based on the event based on the user's behavioral profile. In some embodiments, the predetermined score to be added or subtracted may vary between users based on the user's behavioral profile even for the same type of event. For example, if user 160 has previously conducted multiple successful transactions using user 160's account, processor 120 may consider user 160 to be a low-risk user, and the predetermined score to be added may be higher than the default predetermined score to be added and the predetermined score to be subtracted may be lower than the default predetermined score to be subtracted. As another example, if user 160 has previously attempted too frequent reservations that were subsequently canceled before a driver was assigned to user 160, processor 120 may consider user 160 to be a high-risk user, and the predetermined score to be added may be lower than the default predetermined score to be added and the predetermined score to be subtracted may be higher than the default predetermined score to be subtracted.
[0067] In some other embodiments, even for the same type of event, the predetermined score to be added or subtracted may vary between users based on their behavioral profiles and other external circumstances. In some embodiments, the other external circumstances may be changes in attributes linked to them. For example, if processor 120 detects that an IP address that user 160 normally uses is now being abused by a fraudster, the user risk score of user 160 may also be affected.
[0068] In some embodiments, the user's behavior profile may include a history of one or more events performed by each user for at least one of a plurality of types of on-demand services. For example, if user 160 requests a transportation service, processor 120 may consider a history of one or more events performed by user 160 for a food delivery service and a market delivery service.
[0069] In some implementations, processor 120 may create an event score table (e.g., combining Figure 4 In some embodiments, when user 160 registers the software application, an event score table may be generated. In some embodiments, the generated event score table may include a default predetermined score corresponding to each of the plurality of events.
[0070] In some embodiments, the processor 120 may use machine learning to update the predetermined score corresponding to each of the multiple events of the event score table. In some embodiments, the predetermined score to be added or subtracted may be calculated by a machine learning model. In some embodiments, the processor 120 may receive input data related to multiple variables. In some embodiments, the processor 120 may input the input data to the machine learning model. In some embodiments, the machine learning model may be trained to output event metrics based on the values of multiple variables. In some embodiments, the processor 120 may update the predetermined score corresponding to each of the multiple events based on the event metrics. In some embodiments, the input data of the machine learning model may be a constantly changing list, but the main one may be the same features used for score calculation. For longer historical events, the user's score change event sequence or the user's reaction to the prediction may also be used as label data for machine learning model training. The machine learning score may be used as supplementary information to improve prediction performance (e.g., if the difference between the machine learning score and the predetermined score is large (e.g., higher than a predetermined value), the user is not blocked).
[0071] In some embodiments, processor 120 may assess the risk of user 160's account for multiple types of on-demand services based on the adjusted user risk score. In some embodiments, processor 120 may assess the risk of user 160 for multiple types of on-demand services provided by a platform provider via a single platform operated by server 100, including but not limited to transportation services, food delivery services, grocery delivery services, or fintech services.
[0072] In some embodiments, the processor 120 may determine whether the adjusted user risk score is below a predetermined threshold. In some embodiments, if the adjusted user risk score is below the predetermined threshold, the processor 120 may then trigger the user 160 to perform a predetermined task to continue activating the account of the user 160 for various types of on-demand services. In some embodiments, when the adjusted user risk score is below the predetermined threshold, a predetermined task, such as a corresponding verification / action, may be triggered to mitigate the risk of the user 160. For example, if the adjusted user risk score is below "60", the processor 120 may trigger the user 160 to log in to the software application again.
[0073] In some embodiments, the processor 120 may set multiple predetermined thresholds, such as a first predetermined threshold and a second predetermined threshold, and trigger the user 160 to perform different tasks based on the adjusted user risk score. In some embodiments, multiple levels of predetermined thresholds may be set so that the processor 120 may trigger the user 160 to perform different tasks for further verification or risk mitigation. For example, if the adjusted user risk score is below "60", the processor 120 may trigger the user 160 to log in to the software application again. As another example, if the adjusted user risk score is below "55", the processor 120 may trigger the user 160 to perform multi-factor authentication, such as two-factor authentication.
[0074] In some embodiments, if the user 160 successfully performs the predetermined task, the processor 120 may continue to activate the account of the user 160 for multiple types of on-demand services. In some embodiments, if the predetermined task is performed, the processor 120 may adjust the user risk score assigned to the account of the user 160 by adding a predetermined score corresponding to the task. For example, if the user 160 successfully performs the predetermined task within a predetermined time, the processor 120 may add the predetermined score to the user risk score. As an example, if the user 160 correctly responds to the authentication request, the processor 120 may add a predetermined score (e.g., "15") corresponding to the authentication event to the user risk score. In some other embodiments, if the user 160 successfully performs the predetermined task within a predetermined time, the processor 120 may continue to activate the account of the user 160 for multiple types of on-demand services and / or add the predetermined score to the user risk score.
[0075] In some other implementations, if the user 160 resolves the negative impact, such as paying an outstanding balance for an on-demand service, the processor 120 may add a predetermined score corresponding to the payment event to the user risk score.
[0076] In some other implementations, upon a successful transaction, the processor 120 may add a predetermined score corresponding to the event of the successful transaction to the user risk score.
[0077] In some embodiments, if the scheduled task is not performed within a predetermined time, the processor 120 can deactivate the account of the user 160 for multiple types of on-demand services. In some embodiments, if the user does not perform the scheduled task or does not attempt to perform the scheduled task, the processor 120 can deactivate the account of the user 160 for multiple types of on-demand services provided by the platform provider via a single platform operated by the server 100, including but not limited to transportation services, food delivery services, grocery delivery services, or fintech services.
[0078] In some other embodiments, if the predetermined task is not performed within the predetermined time, the processor 120 may deactivate the account of the user 160 for at least one of the multiple types of on-demand services, for example, based on the adjusted user risk score. For example, if the adjusted user risk score is below a third predetermined threshold, the processor 120 may deactivate the account of the user 160 for the fintech service, but still continue to activate the account of the user 160 for other types of on-demand services. As another example, if the adjusted user risk score is below a fourth predetermined threshold that is less than the third predetermined threshold, the processor 120 may deactivate the account of the user 160 for the fintech service, the food delivery service, and the grocery delivery service, but still continue to activate the account of the user 160 for the transportation service. In some embodiments, the processor 120 may require the user 160 to perform authentication of the user 160 to reactivate the account of the user 160 for the multiple types of on-demand services.
[0079] In some embodiments, the processor 120 may receive a request for a transaction from the user 160 and decide whether to process the transaction and / or the priority of processing the transaction based on the adjusted user risk score. In some embodiments, if the processor 120 receives a request for a transaction from the user 160, the processor 120 may check the user risk score and decide whether to process the transaction based on the adjusted user risk score. For example, if the user 160 requests to redeem a reward for payment for an on-demand service and the user risk score is below a fifth predetermined threshold, such as "50", the processor 120 may refuse to redeem the reward. In some other embodiments, if the processor 120 receives a request for a transaction from the user 160, the processor 120 may check the user risk score and decide the priority of processing the transaction based on the adjusted user risk score. For example, if the user 160 requests a food delivery service and the user risk score is below a sixth predetermined threshold, such as "40", the processor 120 may give a low priority to the allocation of the food delivery service requested by the user 160.
[0080] As described above, traditionally, for fraud risks generated in different vertical businesses, data silos are created by default, and therefore all captured data may not be unified together to generate a global risk indicator for the user 160. Instead of processing user activities and transactions from one vertical business and converting the data for use in risk assessment by another vertical business, the server 100 according to various embodiments can continuously track and evaluate user activities and transactions throughout his / her user's daily journey at a single platform.
[0081] Figure 3A flow chart of a method 300 for assessing the risk of a user's account for multiple types of on-demand services according to various implementations is shown. According to various implementations, a method 300 for assessing the risk of a user's account for multiple types of on-demand services may be provided.
[0082] In some implementations, method 300 may include step 301 of assigning a user risk score to an account of a user.
[0083] In some implementations, method 300 may include step 302 of detecting an occurrence of an event linked to an account of a user for any of a plurality of types of on-demand services.
[0084] In some implementations, method 300 may include step 303 of adjusting a user risk score assigned to an account of the user by adding or subtracting a predetermined score based on the event.
[0085] In some implementations, method 300 may include step 304 of evaluating the risk of the user's account for multiple types of on-demand services based on the adjusted user risk score.
[0086] In some implementations, in step 303, the predetermined score to be added or subtracted based on the event varies based on a behavior profile of the user with respect to at least one of the plurality of types of on-demand services.
[0087] Figure 4 An exemplary event score table 400 is shown in accordance with various implementations.
[0088] like Figure 4 As shown in , the event score table may indicate a predetermined score corresponding to each of a plurality of events under a corresponding category of events. In some implementations, the categories of events may include, but are not limited to, logging into a software application using an account of user 160, payment for an on-demand service, and a request (booking) for an on-demand service.
[0089] In some implementations, events under the category of logging into a software application may include, but are not limited to, detecting risky IP (Internet Protocol) addresses (e.g., IP addresses owned by a data center that indicate risk to a cluster of devices), and detecting that computing device 161 is shared with other users. For example, for an event of detecting a risky IP address, "2" may be assigned as a predetermined score to be subtracted. As another example, for an event of detecting that computing device 161 is shared with other users, "10" may be assigned as a predetermined score to be subtracted.
[0090] In some embodiments, events under the payment category may include, but are not limited to, successful authentication of user 160, failed authentication of user 160, and detection that a credit card registered by user 160 is shared with other users. For example, "15" may be assigned as a predetermined score to be added for an event of successful authentication, and "15" may be assigned as a predetermined score to be subtracted for an event of failed authentication. As another example, "10" may be assigned as a predetermined score to be subtracted for an event of detecting that a credit card of user 160 is shared with other users.
[0091] In some embodiments, events under the subscription category may include, but are not limited to, detecting that the same driver was previously assigned to the user 160. For example, an assignment of "10" may be used as a predetermined score to be subtracted for events where an assignment of the same driver is detected.
[0092] Although not shown, in some embodiments, the category of the event and the plurality of events may be updated. In some embodiments, machine learning may be used to update the predetermined score corresponding to each of the plurality of events in the event score table 400 (e.g., reference Figure 2 described).
[0093] Figure 5 An exemplary flow diagram of a method 500 for assessing the risk of an account of a user 160 for multiple types of on-demand services is shown in accordance with various implementations.
[0094] In some implementations, exemplary method 500 may include step 501 of user 160 registering a software application. In step 501, user 160 may be assigned a user risk score of "100".
[0095] In some implementations, exemplary method 500 may include step 502 of user 160 logging into the software application. In step 502, if it is detected that the user's IP address is a risky IP address (e.g., an IP address owned by a data center that indicates risk to a fleet of devices), a predetermined score of "2" may be subtracted from the user's risk score of "100" and the user's risk score may be adjusted to "98."
[0096] In some implementations, exemplary method 500 may include step 503 of user 160 initiating a first ride through a request for a transportation service.
[0097] In some embodiments, the exemplary method 500 may include a step 504 of detecting that the user 160 has previously attempted to make a reservation too frequently, and then canceling the reservation before a driver is assigned to the user 160. In step 504, the predetermined score of "20" may be subtracted from the adjusted user risk score of "98," and the user risk score may be adjusted to "78." Additionally, in step 504, the user 160 may be requested to perform a predetermined task, such as authentication. In some embodiments, the request for authentication may include a request for authorization and capture (also referred to as "authorization capture"). In some embodiments, the request for authorization and capture may include a request to authorize the user's 160 payment method (e.g., a credit card) to ensure that it is valid and / or that sufficient funds are available.
[0098] In some implementations, exemplary method 500 may include step 505 where user 160 may perform authentication (e.g., transaction event). In step 505, if user 160 successfully performs authentication, a predetermined score of "15" may be added to the adjusted user risk score of "78", and the user risk score may be adjusted to "93".
[0099] In some embodiments, exemplary method 500 may include step 506 of detecting that the same driver was previously assigned to user 160. In step 506, a predetermined score of "10" may be subtracted from the adjusted user risk score of "93," and the user risk score may be adjusted to "83."
[0100] In some implementations, exemplary method 500 may include step 507 where user 160 attempts to pay for the transportation service. In step 507, if the payment is declined, a predetermined score of "50" may be subtracted from the adjusted user risk score of "83" and the user risk score may be adjusted to "33."
[0101] In some implementations, exemplary method 500 may include step 508 of user 160 attempting to pay for transportation services by redeeming a reward after disabling cashless payment. In step 508, when the adjusted user risk score is "33" which is lower than a predetermined threshold of "50", the request to redeem the reward may be denied.
[0102] In some implementations, the exemplary method 500 may include a step 509 in which the user 160 logs into the software application. In step 509, when the adjusted user risk score "33" is below a predetermined threshold "60", the user 160 may be requested to perform a predetermined task, such as multi-factor authentication. As an example, the multi-factor authentication may include two-step authentication.
[0103] In some implementations, exemplary method 500 may include step 510 of user 160 performing selfie authentication by taking a selfie of user 160. In step 510, when the adjusted user risk score "33" is lower than a predetermined threshold "55", user 160 may be requested to perform a predetermined task, such as multi-factor authentication. As an example, multi-factor authentication may include two-step authentication.
[0104] In some embodiments, the exemplary method 500 may include a step 511 where the user 160 requests a pre-ride food service. In some embodiments, the pre-ride food service may include an inspection after the user 160 places a food delivery order but before a driver is assigned to pick up the order. In step 511, since the adjusted user risk score "33" is below the predetermined threshold "50", the user 160 may be offered a predetermined transaction method, such as cash-only payment for the food delivery order.
[0105] In some embodiments, the exemplary method 500 may include a step 512 in which the user 160 requests pre-assignment of food service. In some embodiments, pre-assignment of food service may include a check performed when the processor 120 of the system 100 attempts to assign an order to a driver candidate. In step 512, when the adjusted user risk score "33" is below the predetermined threshold "40", the user 160 may be given a low priority for assigning a food delivery order.
[0106] In some implementations, exemplary method 500 may include step 513 of completing receipt of an on-demand service (e.g., a food delivery order). In step 513, a predetermined score of "10" may be added to the adjusted user risk score of "33," and the user risk score may be adjusted to "43."
[0107] In some implementations, exemplary method 500 may include step 514 of user 160 paying the unpaid balance of the transportation service. In step 514, the predetermined score "20" may be added to the adjusted user risk score "43", and the user risk score may be adjusted to "63".
[0108] Figure 6 A block diagram of a server 600 for assessing the risk of a user's account for various types of on-demand services is shown in accordance with various embodiments.
[0109] In some embodiments, the server 600 can receive tickets and / or upgrades from the user 602 as feedback tags. The tickets and / or upgrades from the user 602 can be used to optimize the predetermined scores for each different event in the event score table. In some embodiments, the event score table can be configured by a human (e.g., a person from a platform provider) via an event configuration portal 603 and / or by a machine learning model 604 (e.g., a reference Figure 2 as described).
[0110] In some embodiments, the action platform 601 may receive input data from multiple events 605, including but not limited to transaction events, clickstream events, and booking events, event stream modules (e.g., TIE stream modules 606) containing event data from different vertical businesses, security modules 607, and accounts 608 of users 602, such as IDs. In some embodiments, as described above, the action platform 601 may receive input data from event configuration portals 603 and machine learning models 604. In some embodiments, the action platform 601 may receive input data from an anti-fraud module 610. In some embodiments, the action platform 601 may optimize the predetermined scores for each different event of the event score table and transmit the optimized scores to a user score storage system 609. In this way, the predetermined scores may be updated / adjusted based on at least user events. In some embodiments, the action platform 601 may receive different events from external streams to update the predetermined scores in real time. For example, the external stream may include a Kafka stream, which is a client library for building applications in which input data and output data are stored in a Kafka cluster.
[0111] According to conventional techniques, different vertical businesses 611, 612, 613, 614 may have user risk scores for each corresponding vertical business obtained, for example, from each corresponding event 615, 616, 617, 618. In some embodiments, the anti-fraud module 610 may obtain each user risk score in real time as an additional source for the overall risk assessment of the user. In some embodiments, the anti-fraud module 610 may provide each user risk score provided from different vertical businesses 611, 612, 613, 614 to the action platform 601. This may improve prediction resilience when dependent services (which provide data for risk assessment) fail to return data on time.
[0112] Although the disclosed contents have been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the scope of the present invention shall be subject to the appended claims, and all changes within the meaning and equivalent range of the claims shall be included within the scope of the present invention.
Claims
1. A server for assessing the risk of a user's account for multiple types of on-demand services, the server comprising: a memory configured to store a behavior profile of the user for at least one of the plurality of types of on-demand services; as well as a processor configured to assign a user risk score to the account of the user, detect an occurrence of an event linked to the account of the user for any of the plurality of types of on-demand services, adjust the user risk score assigned to the account of the user by adding or subtracting a predetermined score based on the event, and evaluate the risk of the account of the user for the plurality of types of on-demand services based on the adjusted user risk score, Wherein the processor is configured to change the predetermined score to be added or subtracted based on the event based on the behavioral profile of the user.
2. The server according to claim 1, wherein: The processor is configured to determine whether the adjusted user risk score is below a predetermined threshold, and if the adjusted user risk score is below the predetermined threshold, trigger the user to perform a predetermined task to continue activating the user's account for the multiple types of on-demand services.
3. The server according to claim 2, wherein: The processor is configured to deactivate the account of the user for the plurality of types of on-demand services if the predetermined task is not performed within a predetermined time.
4. The server according to claim 2, wherein: The processor is configured to adjust the user risk score assigned to the account of the user by adding the predetermined score corresponding to the task if the predetermined task is performed within a predetermined time.
5. The server according to any one of claims 1 to 4, wherein: The processor is configured to create an event score table indicating the predetermined score corresponding to each of a plurality of events.
6. The server according to claim 5, wherein: The processor is configured to update the predetermined score corresponding to each of the plurality of events in the event score table using machine learning.
7. The server according to any one of claims 1 to 6, wherein: The processor is configured to receive a request for a transaction from the user, and decide whether to process the transaction and / or a priority for processing the transaction based on the adjusted user risk score.
8. The server according to any one of claims 1 to 7, wherein: The behavioral profile of the user includes a history of one or more events performed by the user for at least one of the plurality of types of on-demand services.
9. A method for assessing the risk of a user's account for multiple types of on-demand services, the method comprising: assigning a user risk score to the account of the user; detecting an occurrence of an event linked to the account of the user for any of the plurality of types of on-demand services; adjusting the user risk score assigned to the account of the user by adding or subtracting a predetermined score based on the event; as well as assessing the risk of the account of the user for the multiple types of on-demand services based on the adjusted user risk score, The predetermined score added or subtracted based on the event varies based on a behavior profile of the user with respect to at least one of the multiple types of on-demand services.
10. The method according to claim 9, further comprising: determining whether the adjusted user risk score is below a predetermined threshold; as well as If the adjusted user risk score is lower than the predetermined threshold, the user is triggered to perform a predetermined task to continue activating the user's account for the multiple types of on-demand services.
11. The method according to claim 10, further comprising: If the predetermined task is not performed within a predetermined time, the account of the user is deactivated for the plurality of types of on-demand services.
12. The method according to claim 10, further comprising: If the predetermined task is performed within a predetermined time, the user risk score assigned to the account of the user is adjusted by adding the predetermined score corresponding to the task.
13. The method according to any one of claims 9 to 12, further comprising: An event score table indicating the predetermined score corresponding to each of the plurality of events is created.
14. The method according to claim 13, further comprising: The predetermined score corresponding to each of the plurality of events in the event score table is updated using machine learning.
15. The method according to any one of claims 9 to 14, further comprising: receiving a request for a transaction from the user; as well as Whether to process the transaction and / or the priority of processing the transaction are determined based on the adjusted user risk score.
16. The method according to any one of claims 9 to 16, wherein: The behavioral profile of the user includes a history of one or more events performed by the user for at least one of the plurality of types of on-demand services.
17. A data processing device configured to execute the method according to any one of claims 9 to 16.
18. A computer readable medium comprising program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 9 to 16.
