Risk detection method, device and equipment of transaction log, storage medium and program product

Abstract

The application provides a transaction log risk detection method and device, equipment, a storage medium and a program product, which can be applied to the field of artificial intelligence technology. The method comprises the following steps: acquiring a plurality of transaction records in a same target session window in a transaction log, and extracting a plurality of feature fields in each transaction record, wherein the plurality of feature fields comprise a record time field; determining the time sequence characteristics of each transaction record in the target session window according to the record time field of each transaction record; determining a global feature vector of the plurality of transaction records according to the plurality of feature fields and the plurality of time sequence characteristics corresponding to the plurality of transaction records; and detecting the risk level of the transaction log according to the global feature vector.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and specifically to a risk detection method, apparatus, device, storage medium, and program product for transaction logs. Background Technology

[0002] With the widespread adoption of internet services, web servers have become the core entry point for enterprise information systems. Web server logs, as records of server operational status, contain rich information such as user behavior, access patterns, system response status, and request sequences, making them an important data source for detecting abnormal behavior. However, traditional rule-based attack detection methods (such as regular expressions and blacklisted Internet Protocol (IP) addresses) have the following problems.

[0003] First, traditional methods for detecting abnormal behavior rely on a single field, making it difficult to capture abnormal patterns involving combinations of multiple fields. Second, they cannot distinguish between normal high traffic (such as promotional activities) and malicious attacks, leading to wasted resources and a high false positive rate. Third, they ignore the contextual relationships of transaction requests, only able to identify individual requests. They cannot identify attacks such as continuous malicious requests or abnormal Uniform Resource Locator (URL) redirects, resulting in insufficient ability to identify covert attacks, such as multi-step Structured Query Language (SCL) injection attacks. Fourth, reliance on manual monitoring of logs or offline batch processing leads to slow response times and makes it difficult to automate attack blocking. In financial scenarios, abnormal behavior detection needs to be completed within a very short time; traditional detection methods cannot meet real-time requirements due to computational complexity. Summary of the Invention

[0004] In view of the above problems, embodiments of this application provide a method, apparatus, device, storage medium, and program product for risk detection of transaction logs. This solves the problem of low accuracy in existing abnormal behavior detection methods.

[0005] According to a first aspect of this application, a risk detection method for transaction logs is provided, comprising: acquiring multiple transaction records within the same target session window in the transaction log, and extracting multiple feature fields from each transaction record, the multiple feature fields including a recording time field; determining the temporal characteristics of each transaction record in the target session window based on the recording time field of each transaction record; determining a global feature vector of the multiple transaction records based on the multiple feature fields and the multiple temporal characteristics corresponding to the multiple transaction records; and detecting the risk level of the transaction logs based on the global feature vector.

[0006] According to an embodiment of this application, determining a global feature vector for multiple transaction records based on multiple feature fields and multiple time-series features corresponding to multiple transaction records includes: dividing the multiple feature fields into multiple feature types; processing the multiple feature fields according to the multiple feature types to obtain multiple field feature vectors corresponding to the multiple feature fields; generating an initial feature vector corresponding to each transaction record based on the multiple field feature vectors corresponding to each transaction record; and generating a global feature vector corresponding to multiple transaction records based on the initial feature vector and time-series features corresponding to each transaction record.

[0007] According to embodiments of this application, the feature types include numerical features, category features, and text features; multiple feature fields are processed according to multiple feature types to obtain multiple field feature vectors corresponding to multiple feature fields, including: standardizing numerical features to obtain numerical feature vectors; performing one-hot encoding on category features to obtain category feature vectors; and performing word segmentation and embedding on text features to obtain text feature vectors.

[0008] According to an embodiment of this application, a global feature vector corresponding to multiple transaction records is generated based on the initial feature vector and temporal features corresponding to each transaction record. This includes: converting the temporal features into embeddable temporal feature vectors; fusing the initial feature vector and temporal feature vector corresponding to each transaction record to obtain a fused feature sequence corresponding to multiple transaction records; and inserting a preset global aggregation vector into the initial position of the fused feature sequence to obtain a global feature vector corresponding to multiple transaction records.

[0009] According to an embodiment of this application, detecting the risk level of a transaction log based on a global feature vector includes: mapping the global feature vector to a preset numerical range to obtain a risk detection score corresponding to the target session window; and determining the risk level of the transaction log based on the risk detection score of the target session window.

[0010] According to an embodiment of this application, determining the risk level of a transaction log based on the risk detection score of a target session window includes: obtaining multiple historical risk detection scores corresponding to multiple historical session windows within a preset time period; generating a dynamic threshold range for the target session window based on the multiple historical risk detection scores; and determining the risk level of the transaction log based on the risk detection score of the target session window and the dynamic threshold range.

[0011] According to an embodiment of this application, generating a dynamic threshold range based on multiple historical risk detection scores includes: identifying the distribution type of the multiple historical risk detection scores, wherein the distribution type includes normal distribution and non-normal distribution; if the distribution type is normal, determining the dynamic threshold range based on the target mean and target variance of the multiple historical risk detection scores; if the distribution type is non-normal, determining the dynamic threshold range based on the target quantile of the multiple historical risk detection scores.

[0012] According to a second aspect of this application, a risk detection device for transaction logs is provided, comprising: an extraction module, configured to acquire multiple transaction records within the same target session window in the transaction log, and extract multiple feature fields from each transaction record, the multiple feature fields including a recording time field; a first determination module, configured to determine the temporal characteristics of each transaction record in the target session window based on the recording time field of each transaction record; a second determination module, configured to determine a global feature vector of the multiple transaction records based on the multiple feature fields and the multiple temporal characteristics corresponding to the multiple transaction records; and a detection module, configured to detect the risk level of the transaction logs based on the global feature vector.

[0013] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0014] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0015] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0016] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0017] Figure 1 The illustration shows an application scenario of a risk detection method, apparatus, device, medium, and program product for transaction logs according to embodiments of this application.

[0018] Figure 2 A flowchart illustrating a risk detection method for transaction logs according to an embodiment of this application is shown schematically.

[0019] Figure 3A schematic diagram of a modified converter model according to an embodiment of this application is shown.

[0020] Figure 4 This schematic diagram illustrates the structure of the pre-normalization layer according to an embodiment of the present application;

[0021] Figure 5 This diagram schematically illustrates the architecture of a multi-module interconnected security protection system according to an embodiment of this application.

[0022] Figure 6 This schematic diagram illustrates a structural block diagram of a risk detection device for transaction logs according to an embodiment of this application;

[0023] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a risk detection method for transaction logs according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] As used in this paper, the term "model" refers to a model that learns the relationship between inputs and outputs from training data, enabling it to generate corresponding outputs for a given input after training. Model generation can be based on machine learning techniques. Deep learning is a machine learning algorithm that processes inputs and provides corresponding outputs using multiple layers of processing units. A neural network model is an example of a deep learning-based model. In this paper, "model" may also be referred to as a "machine learning model," "learning model," "machine learning network," or "learning network," and these terms are used interchangeably.

[0028] It's important to note that the term "neural network" can refer to a machine learning network based on deep learning. A neural network processes input and provides corresponding output, typically consisting of an input layer, an output layer, and one or more hidden layers between them. Neural networks used in deep learning applications often include many hidden layers, increasing the network's depth. The layers of a neural network are connected sequentially, so that the output of the previous layer serves as the input to the next layer. The input layer receives the input to the neural network, while the output layer's output becomes the final output. Each layer of a neural network includes one or more nodes (also called processing nodes or neurons), each processing the input from the layer above.

[0029] It should be understood that machine learning generally includes three phases: training, testing, and application (also known as inference). In the training phase, a given model is trained using a large amount of training data, iteratively updating parameter values ​​until the model can consistently generate inferences that meet the expected goals from the training data. Through training, the model can be considered to have learned the relationship between inputs and outputs (also known as the input-output mapping) from the training data. The parameter values ​​of the trained model are determined. In the testing phase, test inputs are applied to the trained model to test whether it can provide the correct output, thus determining the model's performance. In the application phase, the model can be used to process actual inputs based on the trained parameter values ​​to determine the corresponding output.

[0030] In one or more embodiments described herein, the term "large model" can refer to a deep learning model with a large number of model parameters, which can include hundreds of millions, tens of billions, hundreds of billions, trillions, or even tens of trillions of model parameters. Large models can also be called foundational models or basic models. They are pre-trained using large-scale unlabeled corpora to produce pre-trained models with hundreds of millions of parameters. Such models can adapt to a wide range of downstream tasks and have good generalization ability, such as large language models and multimodal pre-trained models. It should be understood that in practical applications, large models only require a small number of samples to fine-tune the pre-trained model before being applied to different tasks. Large models can be widely used in natural language processing, computer vision, and other fields. Specifically, they can be applied to computer vision tasks such as visual question answering, image captioning, and image generation, as well as natural language processing tasks such as text-based sentiment classification, text summarization, and machine translation. Major application scenarios for large models can include digital assistants, intelligent robots, search, online education, office software, e-commerce, and intelligent design.

[0031] Risk detection methods, devices, equipment, storage media, and program products for transaction logs involve the application of large models in fintech scenarios.

[0032] Figure 1 The diagram illustrates an application scenario of the risk detection method for transaction logs according to an embodiment of this application.

[0033] like Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a database 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the database 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101 and the second terminal device 102 to interact with the server 105 and / or the database 103 through the network 104 to receive or send information, etc.

[0034] The first terminal device 101 and the second terminal device 102 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal device. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this application embodiment does not limit the form of the target application, including but not limited to applications, mini-programs, etc., installed on the terminal device, and can also be in web page form.

[0035] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101 and the second terminal device 102 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data. The server can be a backend server for the aforementioned target application, used to provide backend services to the clients of the target application.

[0036] Database 103 is a professional storage system for storing and managing data. It can store various types of data related to the target application, such as user account information, business transaction records, and content resource data. It supports structured, semi-structured, or unstructured data storage and has management capabilities such as data creation, deletion, modification, querying, backup, and recovery. In this application scenario, database 103 can be connected to server 105 via a communication link. Server 105 can retrieve the required data from database 103 for processing based on requests from the first terminal device 101 and the second terminal device 102. It can also synchronously store new data generated by the operations of the first terminal device 101 and the second terminal device 102 into database 103, thereby achieving data persistence and efficient retrieval.

[0037] It should be noted that the risk detection method for transaction logs provided in this application embodiment can generally be executed by server 105 and / or first terminal device 101 and second terminal device 102. Accordingly, the risk detection device for transaction logs provided in this application embodiment can generally be set in server 105 and / or first terminal device 101 and second terminal device 102.

[0038] It should be understood that Figure 1 The number of terminal devices, networks, databases, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, databases, and servers can be included.

[0039] Figure 2 A flowchart illustrating a risk detection method for transaction logs according to an embodiment of this application is shown schematically. Figure 2 As shown, the risk detection method 200 for transaction logs according to an embodiment of this application may include steps S210 to S240.

[0040] In step S210, multiple transaction records within the same target session window in the transaction log are obtained, and multiple feature fields are extracted from each transaction record, including the record time field;

[0041] In step S220, the temporal characteristics of each transaction record in the target session window are determined based on the record time field of each transaction record;

[0042] In step S230, a global feature vector for multiple transaction records is determined based on multiple feature fields and multiple time-series features corresponding to multiple transaction records.

[0043] In step S240, the risk level of the transaction log is detected based on the global feature vector.

[0044] In embodiments of this application, user consent or authorization can be obtained before acquiring user information. For example, a request to acquire user information can be sent to the user before step S210. If the user consents or authorizes the acquisition of user information, step S210 is executed.

[0045] For example, a web server's transaction log records the request information for each transaction, typically in the form of Hypertext Transfer Protocol (HTTP) requests. Since a single request cannot fully reflect the complete picture of user behavior, this embodiment employs a session window mechanism to group multiple transaction records of the same user (identified by their Internet Protocol (IP) address) within the same target session window during the testing period. The testing period can be flexibly set according to the business scenario, for example, 30 seconds. A testing period that is too short will lose the complete attack chain, while a period that is too long will introduce excessive noise.

[0046] For example, a user initiates 5 HTTP requests within 30 seconds. These 5 transaction records together constitute a target session window. Feature fields extracted from these 5 records include IP address, request time, request frequency, Uniform Resource Locator (URL) path, and response status code. The temporal sequence characteristic of each transaction record within the target session window is its temporal position within the window, obtained from the record time field. After sorting the 5 transaction records chronologically, different temporal positions are obtained for each. The transaction request corresponding to the fifth temporal position appears normal on its own, but when combined with the preceding request sequence—such as a normal access to a product page followed by a tentative addition of single quotes, and then initiating a multi-step structured query language injection attack—the overall sequence exhibits attack characteristics.

[0047] For example, after acquiring multiple feature fields of each transaction record and its temporal features within the target session window, this information needs to be fused into a unified, comprehensive feature representation that can characterize the entire target session window—a global feature vector. This involves fusing the multiple feature fields of each transaction record with its corresponding temporal features, ensuring that each transaction record's features include both its own attribute information and its temporal position within the session. The fused features of all transaction records are then organized chronologically and processed to form a global feature vector that comprehensively characterizes the entire session window. Thus, the global feature vector carries comprehensive information about the entire target session window, including the attribute information of each transaction record and the temporal dependencies of the request sequence. Based on this global feature vector, a detection result representing the level of risk can be mapped—that is, the risk level of the transaction logs that characterizes whether there is a security risk in the current target session window and the degree of that risk.

[0048] For example, risk levels can be divided into multiple levels. Low risk indicates normal transaction behavior with no abnormal characteristics; medium risk indicates suspicious transaction behavior requiring further attention; high risk indicates obvious attack characteristics in the transaction behavior, requiring immediate blocking. Within a target session window, if three transaction records, in chronological order, are a normal visit to the product list page, a normal visit to the product details page, and a submission to the shopping cart, the entire sequence presents a normal shopping behavior pattern of browsing, viewing details, and placing an order. Based on the global feature vector of this session window, the current transaction behavior is determined to be normal, and the risk level is low. However, if the three transaction records are a normal visit to the product list page, a visit to the product details page (the URL path contains single quotes), and a visit to the product details page (the URL path contains malicious multi-step structured query language statements), the entire sequence presents a typical multi-step structured query language injection attack chain of normal browsing, tentative injection, and malicious attack. Based on the global feature vector of this session window, the current transaction behavior is determined to be abnormal, and the risk level is high.

[0049] The above steps, by acquiring multiple transaction records within the same target session window and extracting multiple feature fields, including the record time field, determine the temporal characteristics of each transaction record within the window. This introduces the sequential information between requests, avoiding the deficiency of evaluating each transaction record as an isolated individual while ignoring their temporal relationships. Furthermore, by fusing multiple feature fields from multiple transaction records with the temporal features, a global feature vector capable of comprehensively representing the entire session window is determined. This global feature vector not only includes the attribute information of individual transaction records but also carries the contextual dependencies of the request sequence, avoiding the problem of missed detections due to the inability to capture temporal dependencies and attack chains between requests. Based on this global feature vector, the risk level of the transaction log is detected, achieving a comprehensive risk assessment of multiple transaction records within the same session window. This solves the problem of difficulty in identifying multi-step attacks due to ignoring the contextual relationships of the request sequence, achieving accurate detection of transaction log risks, effectively improving the accuracy of attack identification, and reducing the possibility of false positives and false negatives.

[0050] The risk detection method for transaction logs according to embodiments of this application determines a global feature vector for multiple transaction records based on multiple feature fields and multiple time-series features corresponding to multiple transaction records. This includes: dividing the multiple feature fields into multiple feature types; processing the multiple feature fields according to the multiple feature types to obtain multiple field feature vectors corresponding to the multiple feature fields; generating an initial feature vector for each transaction record based on the multiple field feature vectors corresponding to each transaction record; and generating a global feature vector for multiple transaction records based on the initial feature vector and time-series features corresponding to each transaction record.

[0051] For example, based on the initial feature vector and temporal features corresponding to each transaction record, an input feature sequence for multiple transaction records is constructed. This input feature sequence is then fed into the risk detection model to obtain a global feature vector corresponding to multiple transaction records.

[0052] For example, such as Figure 3 As shown, each transaction record contains multiple feature fields (such as HTTP method, URL path, response status code, etc.). These feature fields have different data types and need to be processed separately before being merged into the initial feature vector corresponding to that transaction record. The field feature vectors include numeric feature vectors, categorical feature vectors, and text feature vectors. The numeric feature vector, categorical feature vector, and text feature vector corresponding to a particular transaction record are concatenated (i.e., sequentially connected into a longer vector) to form the initial feature vector of that transaction record. This initial feature vector simultaneously contains comprehensive information from numeric, categorical, and text features, serving as a unified digital representation of the transaction record's own attributes. Furthermore, each transaction record not only has its own initial feature vector but also temporal features within the target session window. The initial feature vector of each transaction record is combined with its corresponding temporal features, ensuring that each transaction record's features include both its own attribute information and its temporal position information within the session. Then, multiple transaction records within the target session window are arranged sequentially (1st, 2nd, 3rd, etc.) to form the input feature sequence. The sequence is ordered, preserving the temporal dependencies between transaction requests corresponding to transaction records.

[0053] For example, the input feature sequence can be used as input to a risk detection model, which is an improved converter model, to output global feature vectors corresponding to multiple transaction records. The converter model is a deep learning model based on a self-attention mechanism. Through self-attention computation, it can directly capture the dependencies between any two positions in the sequence, regardless of their distance within the sequence. This makes the converter model highly adept at understanding the contextual information of sequence data, placing isolated elements within the overall context for correlation analysis. After the input feature sequence is fed into the improved converter model, it encodes the features of each transaction record in the sequence. Through its self-attention mechanism, the model can capture the temporal dependencies and contextual relationships between transaction records, thereby outputting global feature vectors corresponding to multiple transaction records. For example, the relationship between the second record and the first record, the relationship between the third record and the first and second records, etc. For instance, ... Figure 4As shown, the improved converter model adopts a pre-normalization variant, adding a normalization layer before the multi-head self-attention module and the feedforward neural network, and also introducing a cross-channel attention mechanism to fuse the interactive information of structured features and text features through cross-attention, enabling heterogeneous features to be interactively superimposed.

[0054] The above steps process multiple feature fields of each transaction record separately based on type to obtain multiple field feature vectors, which are then merged into an initial feature vector, achieving a multi-dimensional digital representation of a single transaction record. The initial feature vectors of each transaction record are then combined with their temporal features and arranged sequentially, enabling subsequent processing to distinguish the order of requests and capture dependencies between requests, avoiding the problem of separating multiple requests in an attack chain into independent events. This results in a global feature vector that integrates the feature information and temporal correlation information of all transaction records within the entire target session window. Ultimately, transaction risk detection is elevated from the single transaction record level to the session window level, effectively identifying hidden threats such as multi-step attacks that rely on temporal context.

[0055] According to the risk detection method for transaction logs in this application, the feature types include numerical features, category features, and text features; multiple feature fields are processed according to multiple feature types to obtain multiple field feature vectors corresponding to multiple feature fields, including: standardizing numerical features to obtain numerical feature vectors; performing one-hot encoding on category features to obtain category feature vectors; and performing word segmentation and embedding on text features to obtain text feature vectors.

[0056] For example, such as Figure 3 As shown, the transaction records contain multiple feature fields with different data types and semantic features. Response time is a continuous numerical value, response status code is a discrete category, and URL path is variable-length text. These different types of features cannot be directly mixed, so they need to be divided into structured features (further subdivided into numerical features and categorical features) and text features. Numeric features, such as response time and request frequency, are continuous numerical data and require standardization to eliminate dimensional differences. Categorical features, such as response status codes, are discrete data and require one-hot encoding to achieve a computable representation. Text features, such as URL paths, are unstructured text data and require word segmentation and embedding to capture their semantic information.

[0057] For example, numerical features (such as response time, request frequency, etc.) can be converted into a distribution with a mean of 0 and a standard deviation of 1 to eliminate the dimensional differences between different features. Assuming a transaction record has a response time of 200 milliseconds, and the mean response time of all transactions within the same session window is 150 milliseconds with a standard deviation of 50 milliseconds, the standardized value would be 1.0 (i.e., higher than the mean by one standard deviation). Categorical features (such as response status codes) can be converted into binary vectors. Common status codes include 404 (Not Found) and 500 (Internal Server Error). Assuming the dataset only contains 404 and 500 status codes, 404 would be encoded as (0, 1, 0), and 500 as (0, 0, 1). Textual features (such as URL paths) can be segmented into word units and then converted into numerical vectors using embedding techniques. For example, a URL path segmented into ['products', 'detail', 'id', '1'] can be converted into a numerical vector for each word, and then combined to form the overall vector representation of the URL path. After the above processing, the numerical feature vector, category feature vector, and text feature vector of the transaction record are obtained respectively.

[0058] The above steps, by standardizing the numerical features, eliminate scale differences caused by different units of measurement, avoiding the problem of features with larger numerical ranges dominating features with smaller numerical ranges in subsequent calculations, and enabling the model to fairly utilize each numerical feature. One-hot encoding is performed on categorical features to convert them into a computable numerical form. Word segmentation and embedding are performed on text features, converting them into numerical vectors containing semantic information, ensuring that semantically similar words are close in distance in the vector space. This allows the model to understand the semantic information in the URL path and identify keyword patterns in malicious payloads. Finally, by concatenating the three types of feature vectors into a unified initial feature vector, a multi-dimensional comprehensive representation of a single transaction record is achieved.

[0059] In addition, since the initial feature vector contains complete attribute information of the transaction record and all types of features are presented in a form suitable for model processing, the problem of information loss caused by the inability to process features uniformly or improper processing due to heterogeneous feature types is avoided, thereby ensuring the accuracy and reliability of subsequent risk detection.

[0060] The risk detection method for transaction logs according to embodiments of this application generates global feature vectors corresponding to multiple transaction records based on the initial feature vector and temporal features corresponding to each transaction record. The method includes: converting temporal features into embeddable temporal feature vectors; fusing the initial feature vector and temporal feature vector corresponding to each transaction record to obtain a fused feature sequence corresponding to multiple transaction records; and inserting a preset global aggregation vector into the initial position of the fused feature sequence to obtain global feature vectors corresponding to multiple transaction records.

[0061] For example, after determining the temporal features of each transaction record within the target session window in step S220, these temporal features are represented as discrete position indices (e.g., the 1st, 2nd, and 3rd). However, these discrete indices cannot be directly input into the model for calculation. Therefore, the temporal features need to be processed and converted into embeddable temporal feature vectors. Specifically, learnable positional encoding is used to initialize a learnable embedding vector for each temporal position (the 1st, 2nd, and 3rd), and these vectors are continuously optimized through backpropagation during model training. After training and optimization, each temporal position corresponds to a fixed-length numerical vector, i.e., an embeddable temporal feature vector. This vector carries the temporal position information of the transaction record within the session window and can adaptively adjust according to the training data to better serve the risk detection task.

[0062] Next, as Figure 3 As shown, the initial feature vector and the temporal feature vector are fused. Specifically, this can be done by vector superposition (addition) or vector concatenation (connection) so that the fused feature vector contains both the transaction record's own attribute information and its temporal position information within the session. For example, if a transaction record is the second request in the session window, its fused feature vector will contain both the request time, URL path, and other attribute information of that request, as well as the temporal position information that it is the second request.

[0063] For example, after fusing all transaction records within the target session window as described above, they are arranged sequentially according to time to form a fused feature sequence. This sequence is ordered and fully preserves the temporal dependencies between requests. A preset global aggregation vector is inserted at the beginning of the fused feature sequence to obtain the input feature sequence. The preset global aggregation vector is a Classification Token (CLS) vector. This vector is a learnable special vector that does not correspond to any real transaction record, but its position (at the very beginning of the sequence) allows it to learn about information from all other positions in the sequence through a self-attention mechanism in subsequent model processing. Inputting the input feature sequence into the risk detection model yields global feature vectors corresponding to multiple transaction records.

[0064] The above steps convert discrete temporal positions into embeddable temporal feature vectors through learnable positional encoding, enabling temporal information to participate in model computation. By fusing the initial feature vector with the temporal feature vector, each transaction record's features simultaneously include its own attribute information and temporal position information. By arranging the fused features in temporal order and inserting a preset global aggregation vector at the beginning of the sequence, a complete input feature sequence that can be fed into the model is constructed. This allows the model to capture the temporal dependencies and contextual relationships of the request sequence in subsequent processing, providing a data foundation for generating a global feature vector that integrates information from the entire session window.

[0065] For example, in one embodiment, numerical features, category features, and text features are processed separately.

[0066] The numerical feature vector is obtained by standardizing the numerical feature data and multiplying it by its weight vector using the following formula:

[0067]

[0068] in, Let j be the numerical feature vector corresponding to the j-th numerical feature of the transaction record. Let be the weight vector of the j-th numerical feature, and Norm be the standardization factor. For the j-th numerical feature, Let be the bias of the j-th numerical feature.

[0069] The category feature vector is obtained by multiplying the category feature data by the weight vector after one-hot encoding using the following formula:

[0070]

[0071] in, This is the category feature vector corresponding to the k-th category feature of the transaction record. Let be the weight vector of the k-th category feature. It is a one-hot encoding. For the k-th category feature, This is the bias of the k-th category feature.

[0072] The following formula is used to perform word segmentation and embedding of text features to generate a text feature vector:

[0073]

[0074] in, Let l be the text feature vector corresponding to the l-th text feature of the transaction record. For word segmentation embedding, This is the l-th text feature.

[0075] Next, using the following formula, a learnable positional embedding method is employed to generate dynamic time-series markers (time-series features) driven by a stochastic process, generating a learnable embedding vector (time-series feature vector) for each transaction request's position in the sequence. The generation formula is:

[0076]

[0077] in, Let be the temporal feature vector of the i-th transaction record among multiple transaction records, where i is the i-th transaction record, and 1≤i≤T, T is an integer greater than or equal to 2, and T is the sequence length of the input feature sequence.

[0078] Then, the temporal feature vector is superimposed on the structured feature vector and the text feature vector to capture the sequential dependencies of the requested sequence and preserve the temporal information of the sequence.

[0079] For the numeric feature vector, each numeric feature vector for each request is added to the corresponding time-series feature vector using the following formula:

[0080]

[0081] in, This is the time-series digital feature vector corresponding to the j-th digital feature vector of the i-th transaction record.

[0082] For the category feature vector, each category feature vector for each request is added to the corresponding time-series feature vector using the following formula:

[0083]

[0084] in, Let be the time-series category feature vector corresponding to the j-th category feature vector of the i-th transaction record.

[0085] For the text feature vector, the text feature vector of each request is added to the corresponding temporal feature vector using the following formula:

[0086]

[0087] in, Let be the time-series text feature vector corresponding to the j-th text feature vector of the i-th transaction record.

[0088] Next, based on the fusion of the above feature vectors, the input feature sequence is constructed using the following formula:

[0089]

[0090] Where T0 is the input feature sequence, stack is the stacking layer, and CLS is the preset global aggregation vector. This is the first time-series numerical feature vector of the first transaction record. This is the second time-series numerical feature vector of the first transaction record; This is the first time-series category feature vector of the first transaction record. This is the second time-series category feature vector of the first transaction record; This is the first time-series text feature vector of the first transaction record. This is the second time-series text feature vector of the first transaction record. This is the last time-series numerical feature vector in the last transaction record. This represents the last time-series category feature vector in the last transaction record. This is the last time-series text feature vector in the last transaction record.

[0091] The risk detection method for transaction logs according to embodiments of this application detects the risk level of transaction logs based on global feature vectors, including: mapping the global feature vectors to a preset numerical range to obtain a risk detection score corresponding to the target session window; and determining the risk level of the transaction logs based on the risk detection score of the target session window.

[0092] For example, the global feature vector is a high-dimensional vector (e.g., 256-dimensional) output by the risk detection model. The values ​​of its dimensions are distributed within the real number range, making it unsuitable for directly representing the level of risk. Therefore, the global feature vector needs to be linearly transformed through a fully connected layer and then mapped to a preset numerical range of 0 to 1 using a sigmoid activation function. This value is the risk detection score for the target session window; the closer the value is to 1, the higher the risk level, and the closer it is to 0, the lower the risk level, thus determining the risk level of the transaction log.

[0093] For example, risk levels can typically be categorized into low, medium, and high risk. A risk detection score between 0 and 0.5 indicates low risk, between 0.5 and 0.7 indicates medium risk, and between 0.7 and 1 indicates high risk. The risk level of the transaction log can be determined based on the specific range in which the risk detection score of the current target session window falls.

[0094] The above steps, by mapping high-dimensional global feature vectors to a preset numerical range, transform high-dimensional features that cannot be directly interpreted into single numerical values ​​with clear probabilistic meanings. This allows for the quantification of risk levels and avoids the situation where the model output is a high-dimensional feature vector that cannot be directly used for risk assessment. Furthermore, by classifying risk levels based on risk detection scores, continuous numerical values ​​are discretized into level labels with clear business semantics, making the assessment results more intuitive and facilitating subsequent decision-making and execution.

[0095] The risk detection method for transaction logs according to embodiments of this application determines the risk level of the transaction logs based on the risk detection score of the target session window, including: obtaining multiple historical risk detection scores corresponding to multiple historical session windows within a preset time period; generating a dynamic threshold range for the target session window based on the multiple historical risk detection scores; and determining the risk level of the transaction logs based on the risk detection score of the target session window and the dynamic threshold range.

[0096] For example, before determining the risk level of the current target session window, it is necessary to obtain the historical risk detection scores corresponding to multiple historical session windows within a preset time period (such as the past 5 minutes or the past 100 session windows). These historical risk detection scores reflect the risk distribution of recent transaction behavior and are the data basis for generating a dynamic threshold range. Since web server traffic patterns change over time (such as traffic differences between weekdays and holidays, and traffic peaks during promotional activities), only by calculating thresholds based on recent historical data can we ensure that the thresholds adapt to current traffic characteristics. After obtaining multiple historical risk detection scores, a dynamic threshold range needs to be generated based on the statistical characteristics of these scores.

[0097] For example, the risk level is determined based on the range of the risk detection score within the dynamic threshold range. If the risk detection score is below the low threshold, it is judged as low risk; if the risk detection score is between the low and high thresholds, it is judged as medium risk; and if the risk detection score is above the high threshold, it is judged as high risk.

[0098] The above steps achieve dynamic adaptation of the threshold to changes in traffic characteristics by acquiring multiple historical risk detection scores within a preset time period and generating a dynamic threshold range based on their statistical distribution. Specifically, by introducing recent historical risk scores, the problem of misclassifying a large number of normal transactions as high-risk during peak traffic periods and missing abnormal transactions during off-peak traffic periods, caused by using a fixed threshold, is avoided, thereby improving the accuracy and robustness of risk level determination.

[0099] The risk detection method for transaction logs according to embodiments of this application generates a dynamic threshold range based on multiple historical risk detection scores, including: identifying the distribution type of the multiple historical risk detection scores, wherein the distribution type includes normal distribution and non-normal distribution; when the distribution type is normal distribution, determining the dynamic threshold range based on the target mean and target variance of the multiple historical risk detection scores; when the distribution type is non-normal distribution, determining the dynamic threshold range based on the target quantile of the multiple historical risk detection scores.

[0100] For example, transaction traffic on a web server exhibits different statistical characteristics at different times. During normal periods, risk scores may be concentrated in low-risk segments, showing an approximately normal distribution. However, during attacks, a large number of high-risk scores appear, causing the distribution to show a significant right skew (the long tail extends to the right). Therefore, it is necessary to first determine the distribution type corresponding to multiple historical risk detection scores. On one hand, the Kolmogorov-Smirnov test is used to determine the deviation of the current distribution from the standard normal distribution. On the other hand, kurtosis-skewness joint analysis is used to determine the distribution shape. When the absolute value of skewness is greater than 1 and kurtosis is greater than 3, the distribution type is determined to be non-normal, and the model is switched to a non-normal distribution such as the gamma distribution; otherwise, it is determined to be a normal distribution.

[0101] For example, when multiple historical risk detection scores follow a normal distribution, their distribution characteristics are determined by the target mean and target variance of these scores. In this case, the three-standard-deviation principle is used to calculate the dynamic threshold range. Specifically, the upper boundary of the dynamic threshold can be set as the target mean plus k times the target standard deviation (k is a preset coefficient that can be dynamically adjusted according to the attack situation; the target standard deviation is obtained from the target variance). Risk scores exceeding this boundary are considered abnormal.

[0102] When multiple historical risk detection scores are not normally distributed, the mean and variance are easily distorted by extreme values, making them unsuitable as the basis for threshold calculation. In this case, a quantile-based method is used to calculate the dynamic threshold range. This involves arranging multiple historical risk detection scores in ascending order, calculating the third quartile (Q3, the value at the 75th percentile), and the interquartile range (IQR). The IQR is the difference between Q3 and the first quartile (Q1). The upper boundary of the dynamic threshold is set to Q3 + 1.5IQR.

[0103] The above steps utilize a dual-modal detection mechanism to determine the distribution type of historical risk detection scores and apply corresponding threshold calculation methods based on whether the distribution is normal or non-normal. This allows the dynamic threshold range to automatically select the appropriate threshold calculation method based on the actual distribution characteristics of historical risk scores. This avoids the problem of normal scores being misjudged as abnormal or abnormal scores being missed due to a mismatch between the threshold calculation method and the data distribution, thereby improving the accuracy of risk level determination and adaptability to different traffic distribution characteristics.

[0104] According to the risk detection method for transaction logs in the embodiments of this application, after detecting the risk level of the transaction logs, the method further includes: executing a corresponding risk blocking strategy based on the risk level of the transaction logs.

[0105] For example, when the risk detection score falls into the range corresponding to the high-risk level (e.g., greater than 0.9), it is judged as a high-risk transaction. A multi-level action decision tree is used to execute hardware-level blocking. Specifically, the Software-Defined Networking (SDN) controller issues open flow table rules to the network switches, instructing the switches to directly discard subsequent data packets that match the rule. This operation is performed at the network layer, directly intercepting malicious traffic at the data link level, preventing it from reaching the web server.

[0106] For example, when the risk detection score falls within the range corresponding to the medium-to-high risk level (e.g., greater than 0.7 and less than or equal to 0.9), an application-layer challenge strategy is activated, generating a cryptographic challenge token and sending it to the client, requiring the client to include a correct response in subsequent requests. This operation is performed at the application layer, distinguishing between genuine users and automated attack tools by verifying whether the client can correctly respond to the challenge.

[0107] For example, when the risk detection score falls within the range corresponding to the medium-risk level (e.g., greater than 0.5 and less than or equal to 0.7), a traffic shaping policy is activated to limit the request rate of that IP address to a preset threshold (e.g., limited to 10 requests per second). This operation controls the request rate, preventing attackers from launching a large number of requests in a short period of time to exhaust server resources, while allowing legitimate users' normal requests to pass through.

[0108] For example, when the risk detection score falls into the range corresponding to the low-risk level (such as less than or equal to 0.5), no blocking operation is performed, and subsequent requests are allowed to pass normally.

[0109] Under high-risk conditions, the above steps involve the SDN controller issuing OpenFlow flow table rules to the switches, directly dropping malicious traffic at the network layer for millisecond-level rapid blocking. Under medium-to-high-risk conditions, application-layer challenge strategies are used to initiate cryptographic challenges, effectively intercepting suspicious requests while reducing false positives on legitimate users. Under medium-risk conditions, traffic shaping strategies limit request rates, mitigating the impact of attacks while ensuring normal business access. Thus, while effectively blocking malicious attacks, the continuity of normal business operations is maximized, achieving a balance between security protection and business availability.

[0110] According to the risk detection method for transaction logs in this application, the risk detection model is trained in the following manner: obtaining a training sample set, wherein the training sample set includes multiple historical session window samples, each of the multiple historical session window samples carrying a risk label; inputting each historical session window sample into the risk detection model to be trained to obtain a predicted risk score corresponding to each historical session window sample; adjusting the parameters of the risk detection model to be trained based on the predicted risk score and risk label corresponding to each historical session window sample to obtain a trained risk detection model.

[0111] For example, risk labels are used to mark whether a sample is a normal transaction or an abnormal transaction (such as multi-step structured query language injection, web crawler attacks, etc.), and are labeled by domain experts based on historical attack records and manual review results. The data structure of each historical session window sample is consistent with the target session window obtained in step S210, containing multiple transaction records within the window. Each transaction record contains multiple feature fields, and the temporal characteristics of each transaction record within the corresponding session window have been determined.

[0112] For example, initially, the parameters of the risk detection model to be trained are randomly initialized, resulting in a difference between the predicted score and the true risk label. A loss function is calculated based on the difference between the predicted risk score and the risk label for each historical session window sample. This loss function quantifies the degree of deviation between the model's prediction and the true label. By minimizing this loss function, the parameters of the risk detection model to be trained (including the weight matrices and bias terms of each layer of the transformational encoder) are progressively updated using the backpropagation algorithm. After multiple rounds of iterative training, when the model's prediction accuracy reaches a preset standard, a trained risk detection model is obtained, which can be used for risk detection in the target session window.

[0113] The above steps, by constructing a training set containing labeled samples, enable the model to extract differentiated feature patterns between normal and aggressive behaviors from historical data. By comparing the model's predictions with the true labels and adjusting the model parameters using error backpropagation, the model gradually optimizes its internal representation capabilities. This allows it to accurately output risk detection scores for new target session windows, providing a reliable scoring basis for determining the risk level of transaction logs.

[0114] According to the risk detection method for transaction logs in this application embodiment, before inputting each historical session window sample into the risk detection model to be trained, the method further includes: extracting multiple feature fields corresponding to each transaction request record from each historical session window sample, and determining the temporal features corresponding to each transaction request record; constructing a historical input feature sequence corresponding to each historical session window sample based on the multiple feature fields and temporal features corresponding to each historical session window sample; and using the historical input feature sequence corresponding to each historical session window sample as the input to the risk detection model to be trained.

[0115] For example, from each historical session window sample, multiple feature fields (including at least the record time field) corresponding to each transaction record are extracted, and the temporal features of each transaction record in that historical session window are determined based on the record time field. Based on the multiple feature fields and temporal features corresponding to each historical session window sample, a historical input feature sequence corresponding to that historical session window sample is constructed. The historical input feature sequence corresponding to each historical session window sample is then used as input to the risk detection model to be trained for model training.

[0116] The above steps ensure that the feature patterns learned by the model during training can be directly applied to actual detection scenarios, avoiding problems such as the model being unable to correctly parse the input or the detection performance degrading due to inconsistencies between the training data and detection data formats. This ensures that the trained model can accurately detect risks in the target session window.

[0117] For example, in one embodiment, such as Figure 5 As shown, this application also provides a network security protection system based on multi-module linkage, including:

[0118] The real-time log acquisition device includes a log access unit 511, which establishes a communication connection with the server through a streaming data processing interface to capture the raw access log stream in real time; a parsing and processing unit 512, which has a built-in regular expression matching engine and a JavaScript object representation parser, to convert unstructured logs into structured log data containing fields such as IP address, request path, status code, and timestamp; and a data distribution unit 513, which transmits the structured log data to the intelligent risk decision-making device in real time through a high-speed data bus.

[0119] The intelligent risk decision-making device includes a risk analysis model loading unit 521, which stores an anomaly detection model (the aforementioned risk detection model) trained by machine learning. The model is trained based on historical attack data and can generate multi-dimensional feature vectors. The dynamic rule matching unit 522 integrates a configurable threshold rule library, which includes request frequency thresholds, sensitive path access rules, and abnormal status code combination rules. The comprehensive decision-making unit 523 generates a blocking instruction set that includes blocking level, target IP, and effective duration.

[0120] The network blocking execution device includes an instruction parsing unit 531, which converts the blocking instruction set into control protocol instructions recognizable by the target network device; a multi-protocol adaptation unit 532, which supports at least one of the following methods: iptables instruction interface, application programming interface (API) gateway's representational state transition interface, or SDN controller southbound interface; and a real-time blocking unit 533, which issues dynamic access control list (ACL) policies to the firewall / API gateway based on a priority queue to achieve millisecond-level abnormal request interception.

[0121] Among them, the real-time log collection device, the intelligent risk decision-making device, and the network blocking execution device form a closed-loop processing link through a distributed message middleware.

[0122] Based on the above-described risk detection method for transaction logs, embodiments of this application also provide a risk detection device for transaction logs. The following will combine... Figure 6 The device is described in detail.

[0123] Figure 6 The diagram illustrates the structure of a risk detection device for transaction logs according to an embodiment of this application.

[0124] like Figure 6 As shown, the risk detection device 600 for transaction logs in this embodiment includes an extraction module 610, a first determination module 620, a second determination module 630, and a detection module 640.

[0125] The extraction module 610 is used to obtain multiple transaction records within the same target session window in the transaction log, and extract multiple feature fields from each transaction record, including a record time field. In one embodiment, the extraction module 610 can be used to perform step S210 described above, which will not be repeated here.

[0126] The first determining module 620 is used to determine the temporal characteristics of each transaction record in the target session window based on the recording time field of each transaction record. In one embodiment, the first determining module 620 can be used to execute the step S220 described above, which will not be repeated here.

[0127] The second determining module 630 is used to determine the global feature vector of multiple transaction records based on multiple feature fields and multiple time-series features corresponding to the multiple transaction records. In one embodiment, the second determining module 630 can be used to execute step S230 described above, which will not be repeated here.

[0128] The detection module 640 is used to detect the risk level of transaction logs based on global feature vectors. In one embodiment, the detection module 640 can be used to perform step S240 described above, which will not be repeated here.

[0129] According to an embodiment of this application, the second determining module 630 is further configured to divide multiple feature fields into multiple feature types; process the multiple feature fields according to the multiple feature types to obtain multiple field feature vectors corresponding to the multiple feature fields; generate an initial feature vector corresponding to each transaction record based on the multiple field feature vectors corresponding to each transaction record; and generate a global feature vector corresponding to multiple transaction records based on the initial feature vectors corresponding to each transaction record and the time sequence features.

[0130] According to embodiments of this application, the feature types include numerical features, category features, and text features; the second determining module 630 is further configured to standardize the numerical features to obtain a numerical feature vector; perform one-hot encoding on the category features to obtain a category feature vector; and perform word segmentation and embedding on the text features to obtain a text feature vector.

[0131] According to an embodiment of this application, the second determining module 630 is further configured to convert the time-series features into an embeddable time-series feature vector; fuse the initial feature vector and the time-series feature vector corresponding to each transaction record to obtain a fused feature sequence corresponding to multiple transaction records; and insert a preset global aggregation vector into the initial position of the fused feature sequence to obtain a global feature vector corresponding to multiple transaction records.

[0132] According to an embodiment of this application, the detection module 640 is further configured to map the global feature vector to a preset numerical range to obtain a risk detection score corresponding to the target session window; and determine the risk level of the transaction log based on the risk detection score of the target session window.

[0133] According to an embodiment of this application, the detection module 640 is further configured to obtain multiple historical risk detection scores corresponding to multiple historical session windows within a preset time period; generate a dynamic threshold range for the target session window based on the multiple historical risk detection scores; and determine the risk level of the transaction log based on the risk detection score and the dynamic threshold range of the target session window.

[0134] According to an embodiment of this application, the detection module 640 is further configured to identify the distribution type of multiple historical risk detection scores, wherein the distribution type includes normal distribution and non-normal distribution; when the distribution type is normal distribution, a dynamic threshold range is determined based on the target mean and target variance of the multiple historical risk detection scores; when the distribution type is non-normal distribution, a dynamic threshold range is determined based on the target quantile of the multiple historical risk detection scores.

[0135] According to embodiments of this application, any plurality of modules among the extraction module 610, the first determining module 620, the second determining module 630, and the detection module 640 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the extraction module 610, the first determining module 620, the second determining module 630, and the detection module 640 can be at least partially implemented as a hardware circuit, such as a field-programmable gate array, a programmable logic array, a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit, or any other reasonable means of integrating or packaging the circuit, or implemented in software, hardware, or firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the extraction module 610, the first determining module 620, the second determining module 630, and the detection module 640 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0136] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a risk detection method for transaction logs according to an embodiment of this application.

[0137] like Figure 7As shown, an electronic device 700 according to an embodiment of this application includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory 702 or a program loaded from a storage portion 708 into a random access memory 703. The processor 701 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 701 may also include onboard memory for caching purposes. The processor 701 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0138] Random access memory 703 stores various programs and data required for the operation of electronic device 700. Processor 701, read-only memory 702, and random access memory 703 are interconnected via bus 704. Processor 701 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 702 and / or random access memory 703. It should be noted that the programs may also be stored in one or more memories other than read-only memory 702 and random access memory 703. Processor 701 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0139] According to embodiments of this application, the electronic device 700 may further include an input / output interface 705, which is also connected to a bus 704. The electronic device 700 may also include one or more of the following components connected to the input / output interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card, such as a local area network card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0140] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0141] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 702, and / or random access memory 703, and / or one or more memories other than read-only memory 702 and random access memory 703 described above.

[0142] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0143] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 709, and / or installed from a removable medium 711. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0144] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by processor 701, it performs the functions defined in the system of embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0145] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0147] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A risk detection method for transaction logs, characterized in that, The method includes: Retrieve multiple transaction records within the same target session window from the transaction log, and extract multiple feature fields from each transaction record, including the record time field; Based on the recording time field of each transaction record, determine the temporal characteristics of each transaction record in the target session window; Based on the multiple feature fields corresponding to the multiple transaction records and the multiple time-series features, a global feature vector for the multiple transaction records is determined; The risk level of the transaction log is detected based on the global feature vector.

2. The risk detection method for transaction logs according to claim 1, characterized in that, Based on multiple feature fields and multiple time-series features corresponding to the multiple transaction records, a global feature vector for the multiple transaction records is determined, including: The multiple feature fields are divided into multiple feature types; The multiple feature fields are processed according to the multiple feature types to obtain multiple field feature vectors corresponding to the multiple feature fields; Based on the multiple field feature vectors corresponding to each transaction record, an initial feature vector corresponding to each transaction record is generated; Based on the initial feature vector corresponding to each transaction record and the temporal features, a global feature vector corresponding to the multiple transaction records is generated.

3. The risk detection method for transaction logs according to claim 2, characterized in that, The feature types include numerical features, category features, and text features; The multiple feature fields are processed according to the multiple feature types to obtain multiple field feature vectors corresponding to the multiple feature fields, including: The digital features are standardized to obtain a digital feature vector; The category features are one-hot encoded to obtain the category feature vector; The text features are segmented and embedded to obtain a text feature vector.

4. The risk detection method for transaction logs according to claim 2, characterized in that, Based on the initial feature vector corresponding to each transaction record and the temporal features, a global feature vector corresponding to the multiple transaction records is generated, including: The temporal features are converted into embeddable temporal feature vectors; The initial feature vector and the temporal feature vector corresponding to each transaction record are fused to obtain the fused feature sequence corresponding to the multiple transaction records; A preset global aggregation vector is inserted into the initial position of the fused feature sequence to obtain the global feature vector corresponding to the multiple transaction records.

5. The risk detection method for transaction logs according to claim 1, characterized in that, Based on the global feature vector, the risk level of the transaction log is detected, including: The global feature vector is mapped to a preset numerical range to obtain the risk detection score corresponding to the target session window; The risk level of the transaction log is determined based on the risk detection score of the target session window.

6. The risk detection method for transaction logs according to claim 5, characterized in that, Based on the risk detection score of the target session window, the risk level of the transaction log is determined, including: Obtain multiple historical risk detection scores corresponding to multiple historical session windows within a preset time period; Based on the multiple historical risk detection scores, a dynamic threshold range for the target session window is generated; The risk level of the transaction log is determined based on the risk detection score of the target session window and the dynamic threshold range.

7. The risk detection method for transaction logs according to claim 6, characterized in that, Based on the multiple historical risk detection scores, a dynamic threshold range is generated, including: Identify the distribution type of the multiple historical risk detection scores, wherein the distribution type includes normal distribution and non-normal distribution; When the distribution type is a normal distribution, the dynamic threshold range is determined based on the target mean and target variance of the multiple historical risk detection scores; When the distribution type is non-normal, the dynamic threshold range is determined based on the target quantiles of the multiple historical risk detection scores.

8. A risk detection device for transaction logs, characterized in that, The device includes: The extraction module is used to obtain multiple transaction records within the same target session window in the transaction log, and extract multiple feature fields from each transaction record, including the record time field; The first determining module is used to determine the temporal characteristics of each transaction record in the target session window based on the recording time field of each transaction record; The second determining module is used to determine the global feature vector of the multiple transaction records based on the multiple feature fields corresponding to the multiple transaction records and the multiple time-series features; The detection module is used to detect the risk level of the transaction log based on the global feature vector.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images