Information verification methods, server-side equipment, and storage media

Abstract

This application discloses an information verification method, apparatus, electronic device, and readable storage medium, belonging to the field of data processing technology. The method includes: receiving a transaction request sent by a terminal device; responding to the transaction request by obtaining first communication status data of the terminal device; and verifying the compliance of the transaction request based on the first communication status data to obtain a verification result. That is, after receiving a transaction request sent by the terminal device, the server can perform transaction compliance verification. During the verification process, the communication status of the terminal device is used for verification, specifically the first communication status data associated with the terminal device, to achieve transaction legality verification, thereby improving the accuracy of transaction legality verification.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an information verification method, server-side equipment, and storage medium. Background Technology

[0002] In recent years, cases of violations have emerged one after another. However, due to increasingly sophisticated methods of violation and the public's weak ability to identify them, the trend of violations has not yet been effectively curbed. Violations in the financial and credit sectors are particularly prominent. For example, completing financial transactions illegally through telecommunications, i.e., illegal transactions, will result in financial losses for users, while also posing significant public relations risks and asset losses to companies. Therefore, it is necessary to identify, or verify, the compliance of transactions to reduce financial losses.

[0003] Currently, a common method used in transaction compliance verification is to identify violations by installing third-party application services. For example, when a third-party application service is enabled, the non-whitelist of the third-party application service can be written into the terminal device system. When a call comes in, the terminal device can match the incoming call number with the non-whitelist to identify whether the incoming call number is a violation number. If the match is successful, the incoming call number can be considered a violation number, i.e., an non-compliant number, and a warning message or blocking of the ringing can be given.

[0004] However, the above-mentioned method of verifying transaction compliance through non-whitelist matching is prone to missing violating numbers during the verification process due to the limited number of non-whitelists or their untimely updates, resulting in low accuracy of transaction compliance verification. Summary of the Invention

[0005] This application provides an information verification method, server-side device, and storage medium to address the problem of poor accuracy in compliance verification.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows:

[0007] In a first aspect, embodiments of this application provide an information verification method applied to a server-side device, the method comprising:

[0008] Receive a transaction request sent by a terminal device, the transaction request being used to request the server device to perform a transaction;

[0009] In response to the transaction request, the terminal device obtains first communication status data, which is fed back to the server device by the terminal device before sending the transaction request;

[0010] Based on the first communication status data, the transaction request is verified to determine whether it is compliant, and the verification result of the transaction request is obtained.

[0011] As can be seen from the embodiments of this application, transaction compliance verification can be performed after receiving the transaction request sent by the terminal device. The situation of conducting transaction operations while communicating during the entire transaction process is rare. In such a scenario, it is more likely that violators will induce users to operate transaction services through communication. Therefore, in the transaction compliance verification process of this application, verification is no longer performed through non-whitelist matching. Instead, the transaction compliance verification is performed by using the communication status of the terminal device before sending the transaction request after receiving the transaction request. That is, the transaction compliance verification is performed by using the first communication status data associated with the terminal device to improve the accuracy of transaction compliance verification.

[0012] Secondly, embodiments of this application also provide an information verification device, applied to a server-side device, comprising:

[0013] The first receiving module is used to receive a transaction request sent by the terminal device, the transaction request being used to request the server device to perform a transaction.

[0014] The first acquisition module is used to acquire first communication status data of the terminal device in response to the transaction request. The first communication status data is fed back to the server device by the terminal device before sending the transaction request.

[0015] The verification module is used to verify whether the transaction request is compliant based on the first communication status data, and to obtain the verification result of the transaction request.

[0016] Thirdly, embodiments of this application also provide a server device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the above-described information verification method.

[0017] Sixthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the above-described information verification method. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is one of the flowcharts of an information verification method provided in the embodiments of this application;

[0020] Figure 2 This is a second flowchart of an information verification method provided in an embodiment of this application;

[0021] Figure 3 This is the third flowchart of an information verification method provided in the embodiments of this application;

[0022] Figure 4 This is a flowchart of communication status data acquisition in an information verification method provided in this application embodiment;

[0023] Figure 5 This is a schematic diagram of the structure of an information verification device provided in an embodiment of this application;

[0024] Figure 6 This is a schematic diagram of the structure of a server device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] See Figure 1 , Figure 1 This is a flowchart of an information verification method provided in an embodiment of this application. This method can be applied to server-side devices, such as... Figure 1 As shown, it includes the following steps:

[0027] Step 101: Receive a transaction request sent by the terminal device. The transaction request is used to request the server device to perform a transaction.

[0028] Step 102: In response to the transaction request, obtain the first communication status data of the terminal device. The first communication status data is the data that the terminal device sends back to the server device before sending the transaction request.

[0029] Step 103: Verify whether the transaction request is compliant based on the first communication status data, and obtain the verification result of the transaction request.

[0030] The aforementioned terminal devices include, but are not limited to, mobile phones, tablets, laptops, handheld computers, in-vehicle terminals, wearable devices, and pedometers.

[0031] It should be noted that the communication state in this embodiment may include a telephone call state or a voice state through a communication application. A telephone call state refers to a call made via telephone number dialing, and the communication application is an application with voice communication capabilities, such as, but not limited to, conferencing software applications and instant messaging applications. A transaction request can be understood as a request to perform a transaction, specifically used to request the server device to perform a transaction. For example, a transaction request may include a first account, a second account, and resource transfer information (e.g., a target quantity of resources). The transaction request can be used to request the server device to transfer a target quantity of resources from the first account to the second account. In this embodiment, the aforementioned resources may include, but are not limited to, funds, points, coupons, etc.

[0032] In general, it's rare for users to communicate simultaneously (e.g., make phone calls or use communication applications for voice calls) while performing transaction operations. Such scenarios are highly likely to be instances where malicious actors use communication methods to induce users to perform transaction operations. Therefore, in this embodiment, when the server device receives a transaction request from the terminal device, it can obtain the terminal device's first communication status data and use this data to verify transaction compliance, i.e., perform transaction identification and determine the transaction request compliance verification result.

[0033] Terminal devices can collect communication status data and report it to a server device for storage. In one example, the server device is configured with a database to store the communication status data associated with the terminal devices; that is, the database includes the communication status data associated with the terminal devices. Before sending a transaction request, the terminal device can send first communication status data to the server device. In other words, the first communication status data is fed back to the server device before the terminal device sends the transaction request. The server can store the received first communication status data in its database. After receiving a transaction request, the server device can retrieve the terminal device's first communication status data from the database. For example, the first communication status data can be communication status data within a preset time period; that is, the first communication status data within the preset time period can be retrieved and used to perform transaction compliance verification to determine the verification result.

[0034] In one example, the end time of the preset time period can be the time when the transaction request is received (i.e., the time when the server device receives the transaction request), the duration of the preset time period is the preset duration, and the sum of the start time of the preset time period and the preset duration is the end time. That is, after receiving the transaction request, the communication status data within the preset duration before the terminal device sends the transaction request can be read from the database.

[0035] In this embodiment, after receiving a transaction request from the terminal device, transaction compliance verification can be performed. The scenario of simultaneously communicating and performing transaction operations during the entire transaction process is rare, as this is more likely due to perpetrators inducing users to perform transaction operations through communication. Therefore, in this application's transaction compliance verification process, verification is no longer performed using a non-whitelist matching method. Instead, transaction compliance verification is performed using the communication status data of the terminal device prior to sending the transaction request after receiving the transaction request. That is, transaction compliance verification is achieved using the first communication status data associated with the terminal device, which improves the accuracy of transaction compliance verification.

[0036] In one embodiment, the first communication status data includes multiple communication status data, which are collected by the terminal device in response to multiple operation events. The operation events are used to trigger the terminal device to collect communication status data.

[0037] Based on the first communication status data, the transaction request is verified to determine its compliance, and the verification result is obtained, including:

[0038] Based on multiple communication status data, a target event sequence is determined from multiple operation events, wherein the communication status data associated with each operation event in the target event sequence indicates that the terminal device is in communication;

[0039] Based on the number of events in the target event sequence and the total number of events in multiple operation events, the compliance of the transaction request is verified, and the verification result is obtained.

[0040] It can be understood that multiple communication status data are associated one-to-one with multiple operation events; that is, each piece of communication status data is associated with one operation event, and the operation events associated with each piece of communication status data are different. The operation events are used to trigger the terminal device to collect communication status data. Each time the terminal device detects an operation event, it triggers the collection of communication status data, obtaining one piece of communication status data. In other words, multiple pieces of communication status data are collected by the terminal device in response to multiple operation events. In one example, before obtaining the first piece of communication status data from the terminal device in response to a transaction request, the server can receive and store multiple pieces of communication status data collected in response to multiple operation events from the terminal device for subsequent retrieval. After receiving the transaction request, the server device can retrieve these multiple pieces of communication status data from the stored communication status data in response to the transaction request.

[0041] For example, the operation event can be an event that manipulates controls on the page of the first application that is launched, or a page jump event, etc. The first application can be an application with transaction functionality (e.g., a financial application) or an application capable of triggering transaction functionality, etc. Furthermore, it should be noted that multiple operation events have a corresponding temporal order, and the aforementioned transaction request can be a transaction request generated in response to the last operation event among the ordered multiple operation events. For example, the start time of the aforementioned preset time period can be the time of the earliest operation event among the multiple operation events.

[0042] For example, launching the first application and logging in triggers a login event, which in turn triggers communication status data collection. This data is then collected and sent to the server device for storage. Similarly, navigating to page Y1 in response to the login event triggers a page transition event, again triggering communication status data collection. Clicking on control K1 on page Y1 triggers a similar event, again collecting and sending communication status data to the server device. Likewise, clicking on control K2 on page Y2 triggers the same event, again collecting and sending communication status data to the server device for storage. In response to an operation on control K2, the user navigates to page Y3. This page navigation event triggers communication status data collection, which is then collected and sent to the server for storage. Similarly, clicking on a transaction control on page Y3 triggers communication status data collection, which is also sent to the server for storage. Additionally, clicking on a transaction control can generate a transaction request, which is also sent to the server.

[0043] In this embodiment, the communication status data corresponding to the operation event indicates that the terminal device is currently in communication when the operation event is detected. During the transaction process, the more events that correspond to the communication status data indicating that the terminal device is in communication, the lower the probability of the transaction being compliant. Thus, by using multiple communication status data, the target event sequence that corresponds to the communication status data indicating that the terminal device is in communication can be determined from multiple operation events. The number of events in the target event sequence and the total number of events in multiple operation events can be used to verify the transaction compliance, thereby improving the accuracy of the obtained transaction compliance verification results.

[0044] In one embodiment, each piece of communication status data includes a first status attribute value and a second status attribute value.

[0045] In the communication status data corresponding to any event in the target event sequence, the first status attribute value indicates that the microphone and audio functions are being used, and the second status attribute value indicates that the terminal device is in the process of speaking.

[0046] It should be noted that "using microphone and audio functions" can also be understood as the microphone and audio functions being in use. In this embodiment, the communication state can be a telephone call or a voice state through a communication application. Each communication state data entry includes a first state attribute value and a second state attribute value. When the first state attribute value indicates that the microphone and audio functions are being used, and the second state attribute value indicates that the terminal device is in a voice call, it means that the terminal device is communicating. The operation event corresponding to this communication state data can be used as an event in the target event sequence.

[0047] In this embodiment, two state attribute values ​​can be used to determine whether the terminal device is in communication, thereby improving the accuracy of determining the terminal device's communication status. The target event sequence is the operation events representing the terminal device's communication status determined from multiple operation events, thus improving the accuracy of the determined target event sequence. Subsequently, transaction compliance verification is performed based on the number of events in the target event sequence and the total number of events in the multiple operation events, thereby improving the accuracy of transaction compliance verification.

[0048] In one embodiment, the compliance of a transaction request is verified based on the number of events in the target event sequence and the total number of events in multiple operation events, resulting in a verification result, including:

[0049] If the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to a preset threshold, a first verification result is obtained, indicating that the transaction request is non-compliant.

[0050] The higher the ratio of the number of events in the target event sequence to the total number of events, the greater the proportion of events indicating that the terminal device is in communication among multiple operational events, and the lower the likelihood of transaction compliance. Therefore, if the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to a preset threshold, the transaction can be determined to be non-compliant, resulting in the first verification result indicating that the transaction request is non-compliant. It should be noted that the preset threshold can be pre-set based on historical experience or according to actual needs.

[0051] In this embodiment, by comparing the ratio of the number of events in the target event sequence to the total number of events with a preset threshold, if the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to the preset threshold, the transaction can be determined to be compliant, and a first verification result indicating that the transaction request is non-compliant can be obtained, thereby improving the accuracy of transaction compliance verification.

[0052] In one embodiment, the compliance of a transaction request is verified based on the number of events in the target event sequence and the total number of events in multiple operation events, resulting in a verification result, including:

[0053] If the ratio of the number of events in the target event sequence to the total number of events is less than a preset threshold, a second verification result is obtained, which indicates that the transaction request is compliant.

[0054] The smaller the ratio of the number of events in the target event sequence to the total number of events, the smaller the proportion of events in which the corresponding communication status data indicates that the terminal device is in communication among multiple operation events, and the higher the probability of transaction compliance. Therefore, in this embodiment, by comparing the ratio of the number of events in the target event sequence to the total number of events with a preset threshold, if the ratio of the number of events in the target event sequence to the total number of events is less than the preset threshold, the transaction can be determined to be compliant, and a second verification result indicating that the transaction request is compliant can be obtained, thereby improving the accuracy of transaction compliance verification.

[0055] In one embodiment, after verifying the compliance of a transaction request based on first communication state data and obtaining the verification result of the transaction request, the process includes:

[0056] If the verification result indicates that the transaction request is non-compliant, a transaction result indicating transaction failure is sent to the terminal device; or

[0057] If the verification result indicates that the transaction request is compliant, the transaction behavior corresponding to the transaction request is executed, and after the transaction behavior is completed, a transaction result indicating that the transaction was successful is sent to the terminal device.

[0058] If the verification result indicates that the transaction request is non-compliant, it can be understood that the transaction risk is high. The server-side device can intercept, block, or stop the transaction and send a transaction failure result to the terminal device to notify the user that the transaction has failed. If the verification result indicates that the transaction is compliant, it can be understood that the transaction risk is low. The server-side device can execute the transaction and send a successful transaction result to the terminal device to notify the user that the transaction has succeeded.

[0059] In one embodiment, the first communication status data is communication data within a preset time period. When the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to a preset threshold, a first verification result is obtained, including:

[0060] If the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to a preset threshold, multiple screen sharing identifiers of the terminal device within a preset time period are obtained. The multiple screen sharing identifiers are associated with multiple operation events. The screen sharing identifiers are used to indicate whether the screen of the terminal device is in a shared state.

[0061] If the number of screen sharing identifiers with the first preset value is greater than the preset number, a first verification result is obtained. If the screen sharing identifier is the first preset value, it is used to indicate that the screen is in a sharing state.

[0062] It should be noted that the multiple screen sharing identifiers are fed back to the server device by the terminal device before the transaction request is received. This means that each screen sharing identifier is associated with one of the aforementioned operation events, and each screen sharing identifier is associated with a different operation event. Each time the terminal device detects an operation event, it not only triggers the collection of communication status data, obtaining one piece of communication status data, but also triggers the collection of screen sharing identifiers. In other words, the multiple screen sharing identifiers are collected by the terminal device in response to each of the multiple operation events. Furthermore, a screen sharing identifier with a first preset value (e.g., 1) can be used to indicate that the screen is in a shared state, while a screen sharing identifier with a second preset value (e.g., 0) can be used to indicate that the screen is in a non-shared state.

[0063] In this embodiment, preliminary transaction compliance verification can be performed by comparing the ratio of the number of events in the target event sequence to the total number of events with a preset threshold. If the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to the preset threshold, the transaction compliance is considered relatively high. In this case, further verification can be performed using multiple screen sharing identifiers within a preset time period. Specifically, multiple screen sharing identifiers of the terminal device within a preset time period can be obtained first. Verification is performed by comparing the number of identifiers with a first preset value among the multiple screen sharing identifiers with a preset number. If the number of identifiers with the first preset value among the multiple screen sharing identifiers is greater than the preset number, a first verification result is obtained. It is understood that in this embodiment, preliminary verification is first achieved by comparing the ratio of the number of events in the target event sequence to the total number of events with a preset threshold. Then, further verification is achieved by comparing the number of identifiers with the first preset value among multiple screen sharing identifiers with a preset number. When the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to the preset threshold, and the number of identifiers with the first preset value among multiple screen sharing identifiers is greater than the preset number, a first verification result is obtained, which can improve the accuracy of transaction compliance verification.

[0064] In one embodiment, if the number of identifiers with a preset value among multiple screen-sharing identifiers is greater than a preset number, a first verification result is obtained, including:

[0065] If the number of identifiers with preset values ​​among multiple screen sharing identifiers is greater than the preset number, obtain user operation behavior data of the terminal device within a preset time period;

[0066] The first verification result is obtained when abnormal behavior is detected based on user operation behavior data.

[0067] It should be noted that user operation behavior data is fed back to the server device by the terminal device before the transaction request is received.

[0068] During the process of violators inducing users to conduct transactions, users' operational behavior on terminal devices is more prone to abnormalities compared to normal transaction behavior, meaning there is a higher probability of abnormal behavior. In this embodiment, further verification can be performed based on the detection of abnormal behavior using user operation behavior data. Specifically, in this embodiment, preliminary transaction compliance verification can be performed by comparing the ratio of the number of events in the target event sequence to the total number of events with a preset threshold. Then, further verification can be performed by comparing the number of identifiers with a first preset value among multiple screen sharing identifiers with a preset number. Finally, further verification can be performed using user operation behavior data within a preset time period. If the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to the preset threshold, the number of identifiers with the first preset value among multiple screen sharing identifiers is greater than the preset number, and abnormal behavior is detected based on user operation behavior data, a first verification result is obtained, which can improve the accuracy of transaction compliance verification.

[0069] See Figure 2 , Figure 2 This is a flowchart of an information verification method provided in an embodiment of this application. This method can be applied to terminal devices, such as... Figure 2 As shown, it includes the following steps:

[0070] Step 201: Send a transaction request to the server device so that the server device responds to the transaction request, obtains the first communication status data of the terminal device, and verifies whether the transaction request is compliant based on the first communication status data, and obtains the verification result.

[0071] The first communication status data is the data that the terminal device sends back to the server device before sending a transaction request.

[0072] In this embodiment, the terminal device can send a transaction request to the server device so that the server device can perform transaction compliance verification. During the transaction compliance verification process, the communication status of the terminal device is used for verification, that is, the first communication status data before the terminal device sends the transaction request is used to realize transaction compliance verification, so as to improve the accuracy of transaction compliance verification.

[0073] In one embodiment, before sending a transaction request to the server device, the method further includes:

[0074] Upon detecting an operation event, the terminal device collects a communication status data point in response to the operation event and sends the communication status data point to the server device. The operation event is used to trigger the terminal device to collect communication status data, and the operation event is associated with the communication status data point.

[0075] It should be noted that in the terminal device, multiple operation events are performed to generate transaction requests. For each operation event detected, communication status data can be collected to obtain a communication status data associated with that operation event. This collected communication status data associated with the operation event is then reported to the server device. In this way, in response to multiple operation events, multiple communication status data, namely the first communication status data, can be collected and uploaded to the server device. After receiving the transaction request, the server device reads the first communication status data from the terminal device and uses the first communication status data to verify the compliance of the transaction.

[0076] In one example, for each detected operation event, the communication status data collected from the terminal device in response to that operation event may include: after the first application is launched, for each detected operation event, a communication status data piece is collected from the terminal device in response to that operation event. It should be noted that after the terminal device launches the first application, the user can perform multiple operation events within the first application to generate transaction requests. For each detected operation event, communication status data can be collected once, and the collected communication status data is reported to the server device.

[0077] In one embodiment, a communication status data of the terminal device in response to an operation event includes:

[0078] In response to operational events, detect the operating system version of the terminal device;

[0079] Based on the operating system version, determine the communication status data associated with the operation event.

[0080] Different operating system versions of terminal devices may require different methods to determine communication status. In this implementation, the communication status data of the terminal device can be determined based on the operating system version, thereby improving the flexibility of communication status data determination. In one example, the operating system of the terminal device could be iOS.

[0081] In one embodiment, based on the operating system version, determining a piece of communication status data associated with the operation event includes:

[0082] If the operating system version is higher than or equal to the first preset version, retrieve the first state attribute value and the second state attribute value from the audio session AVAudioSession object; or

[0083] If the operating system version is higher than or equal to the second preset version, but lower than the first preset version, the first state attribute value is obtained from the AVAudioSession object, and the first preset value is used as the second state attribute value. The first state attribute value is used to indicate the usage status of the microphone and audio functions, and the second state attribute value is used to indicate the voice status of the terminal device; or

[0084] If the operating system version is lower than the second preset version, the first preset value is used as the first state attribute value, and the first preset value is used as the second state attribute value.

[0085] The first preset version is superior to the second preset version.

[0086] For example, the first preset version could be version 13.0, and the second preset version could be version 8.0. AVAudioSession is a class used by the iOS operating system to manage an application's resource usage of audio hardware devices (microphone, speaker, etc.). An AVAudioSession object can be understood as an instantiation of this class. It's important to note that retrieving the first state attribute value from the AVAudioSession object yields either the second preset value (e.g., 1) or the third preset value (e.g., 0). Retrieving the second state attribute value (e.g., 1852796517 or 1936224884) yields either the fourth or fifth preset value (e.g., 1852992876). In cases where the operating system version is lower than the second preset version, the AVAudioSession object does not include the first and second state attribute values. Instead, the first and second state attribute values ​​are determined by assignment, i.e., the first preset value (e.g., -1) is used as both the first and second state attribute values. When the operating system version is lower than the first preset version but higher than or equal to the second preset version, the AVAudioSession object includes a first state attribute value but does not include a second state attribute value. Thus, the first state attribute value can be obtained from the AVAudioSession object, and the first preset value can be used as the second state attribute value. When the operating system version is higher than or equal to the first preset version, the AVAudioSession object includes both a first state attribute value and a second state attribute value, which can be obtained from the audio session AVAudioSession object.

[0087] In this embodiment, the first state attribute value and the second state attribute value can be obtained in different ways under different operating system versions, thereby realizing the acquisition of communication state data and improving the flexibility of data acquisition.

[0088] In one example, if the first state attribute value is a first preset value, it means that the usage status of the microphone and audio functions is unknown; if the first state attribute value is a second preset value, it means that the microphone and audio functions are in use; if the first state attribute value is a third preset value, it means that the microphone and audio functions are not in use; if the second state attribute value is a first preset value, it means that the voice status is unknown; if the second state attribute value is a fourth preset value, it means that the voice is being spoken; and if the second state attribute value is a fifth preset value, it means that the voice is not being spoken.

[0089] The process of the above method will be specifically described below with a specific embodiment.

[0090] Currently, identifying fraudulent phone numbers by installing and activating third-party application services, and using non-whitelist matching methods, is crucial to prevent users from being scammed. However, increasingly sophisticated fraudulent methods exist, such as changing phone numbers or making calls through communication applications to bypass phone number identification. Furthermore, the limited number and untimely updates of non-whitelists can easily lead to missed detections, resulting in low accuracy in fraud identification. Moreover, requiring the installation and activation of third-party application services is inconvenient for users unfamiliar with the system. To better identify, alert, and intercept fraudulent users, reducing public opinion risks and financial losses, a real-time solution is needed to identify whether a user is experiencing fraud and to intercept their transactions in real time through policy intervention, thereby minimizing asset losses. Based on this, the transaction compliance verification method of this application is proposed.

[0091] The following parameters are explained:

[0092] NSMutableDictionary: An iOS data structure object, similar to a Map in Java.

[0093] AVAudioSession: A class for iOS system management applications (APPs) to access audio hardware devices (microphones and speakers) resources.

[0094] @available: A method for determining the iOS system version.

[0095] secondaryAudioShouldBeSilencedHint: This attribute identifies whether the application is using the microphone and audio functionality. The first attribute below will be used as an example.

[0096] `promptStyle`: Voice prompt style (1852992876:Normal, 1852796517:None, 1936224884:Short). The second attribute below uses this attribute as an example for explanation. Voice prompt style explanation: Normal: Normal. None: Indicates that another conversation is actively using the microphone for input. Short: Indicates one of the following three states: Siri is active but not recording; voicemail playback is active; or a voice call is active. This attribute field is mainly used to determine whether the microphone is being used in the background of the terminal device during the operation of the business process, that is, whether there is a voice call.

[0097] like Figure 3 As shown, the specific process of the information verification method in this application embodiment is as follows:

[0098] First, the user launches the first application. After launching the first application, a call voice status collection event is triggered in the actual business process, for example, ... Figure 3 The events shown are A, B, C, D, E, F, and G. Specifically, as... Figure 3As shown, when a login operation is performed in the first application, a login operation event (Event A) can be detected, triggering communication status data collection. This data is then collected and reported to the server device, which receives and stores the data. In response to the login operation and redirection to business page Y1, a page redirection event (Event B) can be detected, triggering communication status data collection again. This data is then collected and reported to the server device for storage. Clicking on control K1 in business page Y1 triggers an operation event (Event C), also triggering communication status data collection. This data is then collected and reported to the server device for storage. In response to the operation on control K1 and redirection to business page Y2, a page redirection event (Event D) can be detected, triggering communication status data collection again. This data is then collected and reported to the server device for storage. Clicking on control K2 in business page Y2 triggers an event (Event E) indicating an action on control K2, which in turn triggers communication status data collection. This data is then collected and reported to the server for storage. Responding to the action on control K2 and navigating to business page Y3 triggers a page navigation event (Event F), again triggering communication status data collection. This data is then collected and reported to the server for storage. Clicking on a transaction control in business page Y3 triggers an event (Event G) indicating an action on the transaction control, which in turn triggers communication status data collection. This data is then collected and reported to the server for storage. Furthermore, clicking on the transaction control can generate a transaction request and send it to the server. In other words, a user's action on an actual transaction triggers events A through G, and event G generates a transaction request that is sent to the server. It should be noted that the server stores the collected communication status data received from the terminal device, for example, in a database.

[0099] For each of the above events detected, the terminal device will execute a communication status data acquisition process. The communication status data acquisition process for any event is as follows:

[0100] a: Create an NSMutableDictionary object (denoted as dict) to store the data collected in this event, and then execute b;

[0101] b: Collect communication status data (taking telephone call or voice status data from a communication application as an example), the process is as follows:

[0102] I: Obtain the AVAudioSession object by calling the sharedInstance method of the system AVAudioSession, and then execute II;

[0103] II: Use @available to determine if the current system version is iOS 8.0 or higher. Figure 4 As shown, if yes, the secondaryAudioShouldBeSilencedHint property in the AVAudioSession object is used to obtain whether an application is using the microphone and audio function identifier data. That is, the secondaryAudioShouldBeSilencedHint property in the AVAudioSession object is called to obtain whether an application is using the microphone and audio function identifier, and the identifier is stored in the dict. Then, execute III. Otherwise, the identifier whether an application is using the microphone and audio function is recorded as -1 and stored in the dict.

[0104] III: Use @available to determine if the current system version is iOS 13 or above. If it is, obtain the voice prompt style identifier data through the promptStyle property in the AVAudioSession object and store it in a dict. Otherwise, record the voice prompt style identifier as -1 and store it in a dict.

[0105] Secondly, after receiving the transaction request, the server-side device performs the following steps:

[0106] (1) Count the number of events in the target event sequence:

[0107] Read the first communication status data within a preset time period from the database;

[0108] The number of events corresponding to the first attribute value (secondaryAudioShouldBeSilencedHint attribute value) being equal to 1 and the second attribute value (promptStyle attribute value) being 1852796517 or 1936224884 in the first communication status data read is recorded as x (i.e. the number of events in the target event sequence), and the total number of events in the transaction business process is recorded as y;

[0109] (2) Determine whether x / y is greater than or equal to z:

[0110] If x / y>=z, it indicates that the transaction has a high risk and can be determined to be non-compliant. The server-side device blocks the transaction, obtains a verification result indicating that the transaction request is non-compliant, and returns a transaction result indicating that the transaction has failed to the terminal device. z is a preset threshold.

[0111] If x / y < z, it indicates that the risk of the transaction is relatively small, and the transaction can be determined to be compliant. A verification result indicating that the transaction request is compliant is obtained. The server device executes the transaction operation, that is, executes the transaction business, and returns a transaction result indicating that the transaction is successful to the terminal device after the transaction is successfully executed.

[0112] (3) The terminal device receives the transaction result returned by the server device, and determines whether the transaction is successful based on the transaction result. If the transaction result indicates that the transaction is successful, the terminal device continues the subsequent business (proceeds to the next step of the business); otherwise, the terminal device prompts that the transaction failed and ends.

[0113] It is extremely rare for a legitimate user to be on a phone call or using a messaging app while operating the entire transaction process. Such a scenario is highly likely to be a trap set by unscrupulous individuals to induce the user to participate in the transaction. Therefore, if the user is shown to be on a call or in a voice conversation at multiple stages, it indicates a high probability that the user has been defrauded, meaning the transaction is likely non-compliant. If the user is on a call or in a voice conversation at only one stage, it means that the user received a legitimate call or voice conversation during the process.

[0114] The core of the technical solution implemented in this application is to trigger communication status data collection at every stage of the user's entire transaction process to determine whether the user is currently on a phone call or using a communication application. When an actual transaction request is invoked, the communication status data is used to verify transaction compliance, assessing whether the user poses a risk of non-compliant transactions, and determining whether to block the transaction based on the verification result. This solves the problem of limited coverage scenarios, allowing application to various transaction scenarios without requiring users to install third-party application services or grant permissions, thus covering a wide range of users. It also eliminates the need for manual maintenance of non-whitelists, avoiding issues of incomplete or delayed updates, thereby reducing maintenance costs. Furthermore, it can identify users suspected of non-compliant transactions in real time, promptly blocking transactions and minimizing asset losses.

[0115] See Figure 5 , Figure 5 This is a structural diagram of the information verification device provided in this application embodiment. The information verification device of this embodiment can be applied to server-side devices, and can implement the details of the information verification method in the embodiment applied to server-side devices described above, achieving the same effect. Figure 5 As shown, the information verification device 500 includes:

[0116] The first receiving module 501 is used to receive a transaction request sent by the terminal device. The transaction request is used to request the server device to perform a transaction.

[0117] The first acquisition module 502 is used to acquire the first communication status data of the terminal device in response to the transaction request. The first communication status data is fed back to the server device by the terminal device before sending the transaction request.

[0118] The verification module 503 is used to verify whether the transaction request is compliant based on the first communication status data, and to obtain the verification result of the transaction request.

[0119] In one embodiment, the first communication status data includes multiple communication status data, which are collected by the terminal device in response to multiple operation events. The operation events are used to trigger the terminal device to collect communication status data.

[0120] Verification module 503 includes:

[0121] The event determination module is used to determine a target event sequence from multiple operation events based on multiple communication status data, wherein the communication status data associated with each operation event in the target event sequence indicates that the terminal device is in communication;

[0122] The verification result determination module is used to verify whether a transaction request is compliant based on the number of events in the target event sequence and the total number of events in multiple operation events, and to obtain the verification result.

[0123] In one embodiment, each piece of communication status data includes a first status attribute value and a second status attribute value.

[0124] In the communication status data corresponding to any event in the target event sequence, the first status attribute value indicates that the microphone and audio functions are being used, and the second status attribute value indicates that the terminal device is in the process of speaking.

[0125] In one embodiment, the verification result determination module is specifically used for:

[0126] If the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to a preset threshold, a first verification result is obtained, indicating that the transaction request is non-compliant.

[0127] In one embodiment, the verification result determination module is specifically used for:

[0128] If the ratio of the number of events in the target event sequence to the total number of events is less than a preset threshold, a second verification result is obtained, which indicates that the transaction request is compliant.

[0129] In one embodiment, the information verification device 500 further includes:

[0130] The first sending module is used to send a transaction result indicating transaction failure to the terminal device if the verification result indicates that the transaction request is non-compliant;

[0131] Alternatively, the information verification device 500 may also include:

[0132] The transaction execution module is used to execute the transaction behavior corresponding to the transaction request if the verification result indicates that the transaction request is compliant;

[0133] The second sending module is used to send a transaction result indicating that the transaction was successful to the terminal device after the transaction is completed.

[0134] In one embodiment, the verification result determination module includes:

[0135] The identifier acquisition module is used to acquire multiple screen sharing identifiers of the terminal device within a preset time period when the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to a preset threshold. The multiple screen sharing identifiers are associated with multiple operation events, and the screen sharing identifiers are used to indicate whether the screen of the terminal device is in a shared state.

[0136] The verification result determination unit is used to obtain a first verification result when the number of identifiers with a first preset value among multiple screen sharing identifiers is greater than a preset number. When the screen sharing identifier is the first preset value, it is used to indicate that the screen is in a sharing state.

[0137] In one embodiment, the verification result determination unit includes:

[0138] The behavior data acquisition module is used to acquire user operation behavior data of the terminal device within a preset time period when the number of identifiers with preset values ​​among multiple screen sharing identifiers is greater than the preset number.

[0139] The verification result acquisition unit is used to obtain the first verification result when abnormal behavior is detected based on user operation behavior data.

[0140] The information verification device provided in this application embodiment can realize each process of the information verification method applied to the server device in the above embodiment. The technical features are one-to-one and will not be repeated here to avoid repetition.

[0141] like Figure 6 As shown, this application embodiment also provides a server device 600, including a processor 601 and a memory 602. The memory 602 stores computer programs or instructions that can run on the processor 601. When the computer program or instructions are executed by the processor 601, they implement the various processes of the above-described information verification method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0142] This application also provides a computer-readable storage medium storing a computer program or instructions. When executed by a processor, the computer program or instructions implement the various processes of the above-described information verification method embodiments and achieve the same technical effects. To avoid repetition, further details are omitted here. The computer-readable storage medium may include read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0143] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0144] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause the server device to execute the methods described in the various embodiments of this application.

[0145] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. An information verification method, characterized in that, Applied to server-side devices, the method includes: Receive a transaction request sent by a terminal device, the transaction request being used to request the server device to perform a transaction; In response to the transaction request, the terminal device obtains first communication status data, which is fed back to the server device by the terminal device before sending the transaction request. The first communication status data includes multiple communication status data, which are collected by the terminal device in response to multiple operation events. The operation events are used to trigger the terminal device to collect communication status data. Based on the multiple communication status data, a target event sequence is determined from the multiple operation events, wherein the communication status data associated with each operation event in the target event sequence indicates that the terminal device is in communication; Based on the number of events in the target event sequence and the total number of events in the multiple operation events, the compliance of the transaction request is verified, and the verification result is obtained.

2. The method according to claim 1, characterized in that, Each of the multiple communication status data includes a first status attribute value and a second status attribute value; In the communication status data corresponding to any event in the target event sequence, the first status attribute value indicates that the microphone and audio functions are being used, and the second status attribute value indicates that the terminal device is in the process of speaking.

3. The method according to claim 1, characterized in that, The step of verifying the compliance of the transaction request based on the number of events in the target event sequence and the total number of events in the plurality of operation events, and obtaining the verification result, includes: If the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to a preset threshold, a first verification result is obtained, which indicates that the transaction request is non-compliant.

4. The method according to claim 3, characterized in that, The first communication status data is communication data within a preset time period. The step of obtaining a first verification result when the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to a preset threshold includes: If the ratio of the number of events in the target event sequence to the total number of events is greater than or equal to a preset threshold, multiple screen sharing identifiers of the terminal device within the preset time period are obtained. The multiple screen sharing identifiers are associated with the multiple operation events, and the screen sharing identifiers are used to indicate whether the screen of the terminal device is in a shared state. If the number of screen sharing identifiers that have a first preset value is greater than a preset number, the first verification result is obtained. If the screen sharing identifier has the first preset value, it is used to indicate that the screen is in a sharing state.

5. The method according to claim 4, characterized in that, When the number of identifiers with preset values ​​among the multiple screen sharing identifiers is greater than a preset number, the first verification result is obtained, including: When the number of identifiers with preset values ​​among the multiple screen sharing identifiers is greater than a preset number, the user operation behavior data of the terminal device within the preset time period is obtained. If abnormal behavior is detected based on the user operation behavior data, the first verification result is obtained.

6. The method according to claim 1, characterized in that, The step of verifying the compliance of the transaction request based on the number of events in the target event sequence and the total number of events in the plurality of operation events, and obtaining the verification result, includes: If the ratio of the number of events in the target event sequence to the total number of events is less than a preset threshold, a second verification result is obtained, which indicates that the transaction request is compliant.

7. An information verification device, characterized in that, Applied to server-side equipment, the device includes: The first receiving module is used to receive a transaction request sent by the terminal device, the transaction request being used to request the server device to perform a transaction. The first acquisition module is used to acquire first communication status data of the terminal device in response to the transaction request. The first communication status data is fed back to the server device by the terminal device before sending the transaction request. The first communication status data includes multiple communication status data, which are collected by the terminal device in response to multiple operation events. The operation events are used to trigger the terminal device to collect communication status data. The verification module is used to determine a target event sequence from the multiple operation events based on the multiple communication status data, wherein the communication status data associated with each operation event in the target event sequence indicates that the terminal device is in communication; and to verify whether the transaction request is compliant based on the number of events in the target event sequence and the total number of events in the multiple operation events, thereby obtaining a verification result.

8. A server-side device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the information verification method as described in any one of claims 1-6.

9. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the information verification method as described in any one of claims 1-6.

Images