Risk monitoring method, device, equipment, medium and program product
Patent Information
- Application Number
- CN202610858982.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-15
- Publication Date
- 2026-10-16
AI Technical Summary
现有的风险监测方法依赖于单模态数据进行风险监测模型训练,并采用简单的集中式建模方式,导致了数据孤岛以及数据风险的问题,所训练出来的模型也因为数据模态单一而出现信息损失,预测不准的问题
Smart Images

Figure CN122926151A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of artificial intelligence and can be used in the field of fintech or other fields, and more specifically to a risk monitoring method, device, equipment, medium and program product. Background Technology
[0002] The financial industry faces increasingly complex and systemic risk challenges. Existing risk monitoring methods rely on single-modal data for risk monitoring model training and employ a simple centralized modeling approach, leading to data silos and data risks. The trained models also suffer from information loss and inaccurate predictions due to the limited data modality. Summary of the Invention
[0003] In view of the above problems, embodiments of this application provide a risk monitoring method, apparatus, device, medium, and program product.
[0004] According to a first aspect of this application, a risk monitoring method is provided. The method includes: acquiring first multimodal feature data, wherein the first multimodal feature data is obtained based on the access behavior of a first user and includes features extracted from data of multiple data types; inputting the first multimodal data features into a trained fusion decision model and obtaining a risk score output by the fusion decision model; processing the first user's access according to a preset action in the risk level to which the risk score belongs; wherein the fusion decision model includes multiple branch models and a fusion mechanism for the decision results of the multiple branch models; the fusion decision model is trained using federated learning, wherein the fusion decision model is deployed on the server side of the federated learning and a small model is distilled from the fusion decision model, and the small model is deployed on each client side of the federated learning. According to an embodiment of this application, the process of training the fusion decision model through federated learning includes: each client training the small model using at least one local second multimodal feature data, and uploading parameters to the server after training, wherein the second multimodal feature data is obtained based on the access behavior of a second user; the server updating the small model by aggregating the parameters uploaded by each client to obtain a global small model; the server updating the fusion decision model using bidirectional knowledge distillation of the global small model and the fusion decision model; and after one round of updating of the fusion decision model, the server sending the parameters of the global small model to each client.
[0005] According to an embodiment of this application, during the federated learning training process, sparse ternary quantization is used to compress and transmit data between the client and the server.
[0006] According to an embodiment of this application, the small model adopts the same architecture as one of the plurality of branch models.
[0007] According to an embodiment of this application, obtaining the first multimodal feature data includes: collecting encrypted feature data from multiple data sources to obtain an encrypted feature dataset, wherein the encrypted feature data is obtained by the multiple data sources extracting and encrypting the original behavioral data stored by each of them according to a unified encrypted feature extraction method; dividing the encrypted feature dataset according to the user dimension to form an encrypted feature subset for each user; and concatenating the features in the encrypted feature subset of the first user to form the first multimodal feature data.
[0008] According to an embodiment of this application, the encrypted feature extraction method includes: determining the feature extraction method and encryption method according to the data type of the original behavioral data and a preset correspondence; extracting features from the original behavioral data according to the feature extraction method, and then encrypting the extracted features according to the encryption method; wherein the feature extraction method and encryption method are different for different data types in the correspondence.
[0009] According to an embodiment of this application, processing the access of the first user according to the preset handling action in the risk level to which the risk score belongs includes: when the preset handling action in the risk level to which the risk score belongs needs to process plaintext data related to the first user, the handling action is executed within the secure enclave.
[0010] According to a second aspect of the embodiments of this application, a risk monitoring device is provided. The device includes: an acquisition module, a scoring module, and a processing module. The acquisition module is used to acquire first multimodal feature data; wherein the first multimodal feature data is obtained based on the access behavior of a first user and includes features extracted from data of multiple data types. The scoring module is used to input the first multimodal data features into a trained fusion decision model and acquire a risk score output by the fusion decision model; wherein the fusion decision model includes multiple branch models and a fusion mechanism for the decision results of the multiple branch models, the fusion decision model is trained using federated learning, wherein the fusion decision model is deployed on the server side of the federated learning and a small model is distilled from the fusion decision model, and the small model is deployed on each client side of the federated learning. The processing module is used to process the first user's access according to a preset processing action in the risk level to which the risk score belongs.
[0011] 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.
[0012] 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.
[0013] 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
[0014] 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:
[0015] Figure 1 The illustrations depict application scenarios of risk monitoring methods, apparatus, devices, media, and program products according to embodiments of this application.
[0016] Figure 2 A flowchart illustrating a risk monitoring method according to an embodiment of this application is shown schematically;
[0017] Figure 3 This illustration shows a flowchart of a risk monitoring method according to an embodiment of the present application, in which a fusion decision model is trained through federated learning.
[0018] Figure 4 This illustration schematically shows a flowchart of obtaining first multimodal feature data in a risk monitoring method according to an embodiment of this application;
[0019] Figure 5 The flowchart illustrating the implementation of an encryption feature extraction method in one embodiment of this application is shown in the schematic diagram.
[0020] Figure 6 A flowchart illustrating another embodiment of the risk monitoring method of this application is shown schematically;
[0021] Figure 7 This schematic diagram illustrates the structure of a risk monitoring device according to an embodiment of the present application;
[0022] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing the risk monitoring method according to embodiments of this application. Detailed Implementation
[0023] 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.
[0024] 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.
[0025] 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.
[0026] As used in this paper, the term "model" refers to a system that learns the relationship between inputs and outputs from training data, enabling it to generate corresponding outputs for a given input after training. 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.
[0027] 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.
[0028] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.
[0029] This application provides a risk monitoring method, apparatus, device, medium, and program product. This application can be applied to privacy-preserving collaborative analysis of multi-source heterogeneous data (such as transaction logs, network traffic, and operational behaviors in a banking system). It solves the core challenge of cross-institutional data privacy sharing through federated learning and addresses the issue of fully mining the value of heterogeneous data through multimodal approaches. By combining these two approaches, cross-institutional multimodal data collaborative modeling is achieved under strict privacy protection, thereby breaking through the limitations of a single institutional perspective and improving the intelligent monitoring capability for systemic risks.
[0030] Figure 1 The illustration shows an application scenario diagram of the risk monitoring method, apparatus, device, medium, and program product according to embodiments of this application.
[0031] like Figure 1 As shown, the application scenario 100 according to the embodiments of this application may include a first user terminal 101, a second user terminal 102, a third user terminal 103, a central server 104, and multiple branch servers 105.
[0032] Users can use the first user terminal 101, the second user terminal 102, and the third user terminal 103 to interact with the central server 104 via the network to receive or send information, etc.
[0033] The central server 104 can also communicate with multiple branch servers 105 to exchange information and data. In some embodiments, the central server 104 may be a server deployed at the bank headquarters, and the branch servers 105 may be servers deployed at various branches.
[0034] According to some embodiments of this application, the central server 104 may be deployed with a fusion decision model. This fusion decision model can monitor the user behavior of users accessing the central server using the first user terminal 101, the second user terminal 102, and the third user terminal 103 to determine if any risks exist. The central server 104 may be an independent 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, etc.
[0035] The fusion decision model can be trained and then deployed to the central server 104, or it can be trained on the central server 104 and used for risk monitoring in the application phase after training. Specifically, in one embodiment, the central server 104 and multiple branch servers 105 can constitute a federated learning framework to perform federated training on the fusion decision model. According to embodiments of this application, knowledge distillation can be supported in the federated learning framework.
[0036] It should be noted that the risk monitoring method provided in this application embodiment can generally be executed by the central server 104. Accordingly, the risk monitoring device provided in this application embodiment can generally be set in the central server 104.
[0037] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.
[0038] It should be noted that the risk monitoring method and apparatus determined in the embodiments of this application can be used in the field of fintech, or in any field other than fintech. This application does not limit the application field.
[0039] The following is passed Figures 2-6 The risk monitoring methods of various embodiments of this application will be described in detail.
[0040] Figure 2 A flowchart illustrating a risk monitoring method according to an embodiment of this application is shown. Figure 2 As shown, the method 200 may include steps S210 to S230.
[0041] In step S210, first multimodal feature data is obtained; wherein the first multimodal feature data is obtained based on the access behavior of the first user; the first multimodal feature data may include features extracted from data of multiple data types.
[0042] These various data types can be categorized based on how the data is formed and recorded, such as transaction logs, network traffic, and operational behavior; or they can be categorized based on the data storage format, such as text (customer feedback, news), images (certificates, tickets), and even voice (customer service recordings). It should be noted that this application will obtain user authorization before using and analyzing user behavior-related data, and the use and analysis of user behavior-related data will only proceed after obtaining user authorization.
[0043] In step S220, the first multimodal data features are input into the trained fusion decision model, and the risk score output by the fusion decision model is obtained.
[0044] The fusion decision model includes multiple branch models and a fusion mechanism for the decision results of these multiple branch models. The model architectures of the different branch models are different.
[0045] Specifically, the first type of multimodal data feature can be the feature of data from multiple data sources and multiple data types, which can provide a more comprehensive characterization of user behavior and enable the model to gain a more comprehensive understanding of user behavior. Among them, multimodal learning studies how to enable machine learning models to understand and process information from multiple different sources or forms (modalities). "Modality" refers to different forms of data representation or perception channels. Common modalities include: text (such as reports, news, social media, customer service dialogue records, contracts), images (such as ID photos, surveillance footage, scanned documents, charts), voice / audio (such as customer service call recordings, meeting recordings), video (such as surveillance video, which can be regarded as a combination of image + time series + audio), structured data (such as transaction records, account information, credit records, market data tables), time series data (such as stock price fluctuations, changes in transaction frequency), and graph data (such as customer relationship networks, inter-institutional fund transfer networks).
[0046] Accordingly, the multiple branch models in the fusion decision model can be selected from those that excel at processing data of different modalities. Then, the decision results of different branch models are fused through a weighting mechanism (such as an attention mechanism) to improve the ability to analyze multimodal data. For example, in one embodiment, the fusion decision model can be an Attention-CNN-LSTM fusion model. One branch model can adopt a convolutional neural network (CNN) architecture model (e.g., a one-dimensional convolutional neural network 1D-CNN model), which is good at local feature extraction. Another branch model can adopt a long-short-term memory neural network (LSTM) architecture model (e.g., a bidirectional long short-term memory network BiLSTM model), which is good at sequence modeling and can capture long-term dependency information. Then, the decision results of the two are fused through an attention mechanism.
[0047] In step S230, the access of the first user is processed according to the preset handling action in the risk level to which the risk score belongs.
[0048] For example, risk management strategies can be preset as shown in Table 1 below, where thresholds and corresponding actions are preset for different risk levels. In step S230, the risk level can be determined based on the risk score output by the fusion decision-making model and the thresholds in the risk management strategy, and then the corresponding action for that risk level can be taken.
[0049] Table 1, Risk Management Strategies:
[0050]
[0051] According to some embodiments of this application, the fusion decision model is trained using federated learning. The fusion decision model is deployed on the server side of the federated learning process, and a smaller model is distilled from the fusion decision model. This smaller model is then deployed on each client side of the federated learning process. In this way, during federated learning, the server and clients only need to exchange parameters for the smaller model, while the server can update the fusion decision model through bidirectional knowledge distillation between the smaller model and the fusion decision model.
[0052] In one embodiment, the process of training a fusion decision model using federated learning can be as follows: Figure 3 As shown. Specifically, according to an embodiment of this application, the process of training a fusion decision model through federated learning may include steps S310 to S340.
[0053] In step S310, each client trains the small model using at least one local second multimodal feature data, and uploads the parameters to the server after training, wherein the second multimodal feature data is obtained based on the access behavior of the second user.
[0054] In step S320, the server updates the small model by aggregating the parameters uploaded by each client to obtain the global small model.
[0055] When aggregating parameters on the server side, a weighted average algorithm can be used.
[0056] In one embodiment, weights can be dynamically assigned based on the trustworthiness of each client. For example, a client's trustworthiness *w* can be obtained through its log integrity and security rating, such as *w = α * log integrity + β * security rating*, where α and β are hyperparameters, for example, α = 0.7 and β = 0.3. Then, after calculating the trustworthiness *w* of each client, normalization is performed to obtain the weights of each client when the aggregation parameters are applied. Client weights determined in this way can be dynamically adjusted as the client's trustworthiness changes (such as changes in log integrity or security rating), improving the flexibility and adaptability of model training.
[0057] In step S330, the server updates the fusion decision model using bidirectional knowledge distillation between the global small model and the fusion decision model. During bidirectional knowledge distillation, the server can use a public, unlabeled auxiliary dataset as a bridge to allow the aggregated global small model and the fusion large model to teach each other. This allows the fusion large model to absorb domain knowledge from various clients from the global small model, while also further improving the generalization ability of the small model.
[0058] In step S340, after the fusion decision model has been updated once, the server sends the parameters of the global small model to each client.
[0059] In this way, on the one hand, the security of local training data of each client is effectively guaranteed because the client does not need to transmit local training data to the outside world during the federated learning process; on the other hand, the range of training data that the fusion decision model can learn is greatly expanded, and the generalization ability and accuracy of the fusion decision model are improved; furthermore, the client and the server only exchange parameters of small models, which can effectively reduce the amount of data transmitted during the federated learning process, and the client only deploys small models, which effectively reduces the deployment pressure of each client.
[0060] Taking application scenario 100 as an example, the central server 104 acts as the server-side of federated learning, and the branch servers 105 act as the clients. The central server 104 not only deploys the fusion decision model but also distills a smaller model from it. This smaller model is then distributed to multiple branch servers 105. Each branch server 105 learns from local training data using the smaller model. The parameters of the smaller models are then sent back to the central server 104. The central server 104 aggregates the parameters, updates the smaller model, and then uses the bidirectional knowledge distillation between the updated smaller model and the fusion decision model to update the fusion decision model. This process is repeated to continuously train the fusion decision model. After one round of parameter aggregation and bidirectional distillation, the central server 104 obtains a fusion decision model that incorporates the knowledge from multiple branch servers 105, as well as a more refined global smaller model. Then, by simply distributing the latest parameters of the global smaller model, the next round of iterative training can begin.
[0061] The fusion decision-making model trained in this way can overcome the data limitations of a single node and improve the model's ability to comprehensively recognize risks. Specifically, if the fusion decision-making model is trained solely on data from the central server 104, it will suffer from limited perspective, inability to capture systemic risk transmission and related risks across institutions and markets, and difficulty in identifying long-tail risks (such as the inability of data from a single institution to cover low-frequency but high-loss new and complex risk patterns), leading to serious lag and one-sidedness in risk warnings. However, by incorporating data from various branches into the model, the data scope can be expanded, and the range and depth of data across various modalities can be increased.
[0062] Furthermore, the federated learning framework incorporates knowledge distillation, taking into account the performance differences between different branches. This allows branch servers 105 to participate in federated training through small models, significantly reducing computational resource consumption compared to the central server 104. It also takes into account the performance differences between different branches and can adapt to problems such as varying equipment performance in different branches (e.g., some branches have outdated equipment).
[0063] In some embodiments, sparse ternary quantization can be used to compress and transmit data between the client and the server during the federated learning training process. For example, in step S310, each client performs sparse ternary quantization compression before uploading model parameters. Similarly, in step S340, when the server sends the updated global small model parameters to the client, it can also perform sparse ternary quantization compression before sending them. This can significantly reduce communication overhead and effectively improve communication efficiency.
[0064] In one embodiment, the small model can be a simplified architecture of the fusion decision model. For example, if the fusion decision model is an Attention-CNN-LSTM fusion model, the small model adopts a lightweight model combining 1D-CNN and GRU, where GRU stands for Gated Recurrent Unit, which is a simplified version of LSTM.
[0065] In another embodiment, the small model can be heterogeneously distilled from the fusion decision model. For example, the small model may adopt the same architecture as one of the multiple branch models of the fusion decision model. This creates an architectural correlation between the small model and the fusion decision model, which can improve the distillation performance to some extent. Specifically, in heterogeneous distillation, when the student model (the small model in this paper) and a part of the teacher model (the fusion decision model in this paper) share the same inductive bias, the distillation performance is better than choosing an architecture that does not share any bias. When the fusion decision model is an Attention-CNN-LSTM fusion model, the small model is preferably a CNN model because sharing the "feature extraction method" (the capability of the CNN model) is easier to transfer than sharing the "sequence modeling method" (the capability of the LSTM model).
[0066] Figure 4 The illustration shows a flowchart of step S210, acquiring first multimodal feature data, in a risk monitoring method according to an embodiment of this application. For example... Figure 4 As shown, step S210 may include steps S211 to S213.
[0067] In step S211, encrypted feature data is collected from multiple data sources to obtain an encrypted feature dataset. This encrypted feature data is obtained by extracting and encrypting the original behavioral data stored by each of the multiple data sources using a unified encrypted feature extraction method. By employing a unified encrypted feature extraction method, differences in data sources can be ignored after collection, and unified processing can be performed on the encrypted data.
[0068] In one embodiment, the raw behavioral data stored in different data sources may have different data types, or a single data source may store data of one or more data types. Accordingly, the unified encrypted feature extraction method can be as follows: Figure 5 As shown, it includes steps S501 to S502.
[0069] In step S501, the feature extraction method and encryption method are determined according to the data type of the original behavioral data and the preset correspondence.
[0070] In step S502, features are extracted from the original behavioral data according to the described feature extraction method, and then the extracted features are encrypted according to the described encryption method. The feature extraction and encryption methods differ for different data types in the above correspondence, as shown in Table 2.
[0071] Table 2 illustrates the feature extraction methods and encryption methods corresponding to different data types in an embodiment of this application.
[0072] Table 2. Feature extraction and encryption methods for different data types
[0073]
[0074] When extracting encrypted feature data according to Table 2, for raw behavioral data, the feature extraction method and encryption method can be selected based on the data type. First, features are extracted from plaintext according to the feature extraction method, and then encrypted before being provided externally. For example, for transaction logs, key features can be extracted through dynamic rule matching, and then encrypted using a combination of the SM4 encryption engine and Cipher Block Chaining (CBC) mode. As another example, for network traffic, if the network traffic itself is encrypted, features can be extracted through encrypted stream structured query statement syntax tree parsing. Specifically, encrypted structured query statements are first extracted from the encrypted network traffic, then decrypted, and transformed into a structured expression of an "abstract syntax tree," forming a structured feature vector. This vector is then encrypted using a combination of TLS 1.3 and key encapsulation. For yet another example, for operational behavior, a series of related operations can be identified through sensitive operation chain detection. These related operations can then be converted into ciphertext through homomorphic encryption before being output. Sensitive operation chain detection is a security technique that identifies whether these key operations constitute a complete attack chain; unauthorized access -> export is a typical scenario.
[0075] Next, in step S212, the encrypted feature dataset is divided according to the user dimension, forming a subset of encrypted features for each user. For example, in the encrypted feature extraction method, the extracted user identification information (such as IP address, user ID, etc.) can be encrypted using a predetermined encryption conversion method and represented using characters of a specific length. In this way, for each encrypted feature data, it is possible to distinguish whether it represents the same user based on the string at the corresponding position. This allows the encrypted features of the same user to be determined without exposing user information.
[0076] In step S213, the features in the encrypted feature subset of the first user are concatenated to form the first multimodal feature data. Here is an example of feature concatenation; an operation behavior feature encoding (encrypted state) feature_vector can be represented as follows:
[0077] feature_vector=[HE_Encrypt(Flag('after_hours_access')),SM4_Encrypt(Count('sensitive_operation')),FHE_Encrypt(Duration('data_export'))]
[0078] HE_Encrypt(Flag('after_hours_access')) is the encrypted feature data obtained by converting the non-working hours access feature through homomorphic encryption (HE), where the feature is represented by 23 bits (i.e., the feature bits are 23).
[0079] SM4_Encrypt(Count('sensitive_operation')) is the encrypted feature data obtained by converting the sensitive operation extracted from the transaction log using the SM4 encryption engine, where the feature is represented by 41 bits (i.e., feature bit 41).
[0080] FHE_Encrypt(Duration('data_export')) first determines the data export duration in the unauthorized export scenario through sensitive operation chain detection, and then encrypts the data export duration using Fully Homomorphic Encryption (FHE) to obtain encrypted feature data, which is represented by 57 bits (i.e. feature bit 57).
[0081] As can be seen, the embodiments of this application can perform encrypted feature correlation analysis on different data sources and data types in an encrypted state, forming a user's multimodal feature data for model input. In this way, each data source does not need to expose the plaintext of user data, but only provides data after feature extraction and encryption. Subsequent modeling analysis can then be performed on the encrypted feature data, further improving data security during risk monitoring and reducing unnecessary exposure of user data and sensitive information. It can be understood that when the first multimodal feature data input during the application stage of the fusion decision model is encrypted, the second multimodal feature data used in the federated training process is also encrypted, extracted and constructed in the same way as the first multimodal feature data. Thus, during federated learning, data isolation and security can be achieved between data sources on different servers, further reducing the risk of user data exposure.
[0082] In one embodiment, when the model input data is encrypted, in step S230 above, if the preset action in the risk level to which the risk score belongs requires processing plaintext data related to the first user (e.g., restricting user permissions requires determining user identity, freezing user accounts requires locating user accounts), the action is executed within a Software Guard Extensions (SGX). For example, in Table 1, when the risk level to which the risk score belongs is high-risk, the first user's account needs to be frozen. In this case, it is necessary to obtain the first user's account information in plaintext. The action is then executed within the SGX, including decrypting the first user's encrypted feature data to obtain the first user's plaintext information, then calling the bank's core system API to locate the first user's account and performing the freezing operation. After processing, the data is encrypted and logged in the audit log. This hardware-level security response ensures that the plaintext of user data remains completely invisible to the outside world, further protecting the security of user data.
[0083] Figure 6 A flowchart illustrating another embodiment of the risk monitoring method 600 of this application is shown.
[0084] like Figure 6 As shown, the method 600 can utilize the fusion decision model 601 to process multimodal features (transaction features, network features, and operational features) and output risk scores to risk management strategies.
[0085] The fusion decision model can include three parts: a 1D-CNN branch, an LSTM branch, and an attention mechanism. Transaction features, network features, and operational features are fused through the feature fusion layer of the fusion decision model 601, then processed by the 1D-CNN branch and the LSTM branch respectively. Finally, the attention mechanism weights the decision results of the 1D-CNN branch and the LSTM branch to output the final risk score. In one embodiment, the transaction features, network features, and operational features can be encrypted features, with their respective encryption methods being the same as those in the previous examples, and they can be concatenated according to predetermined rules (such as preset bit length and reserved positions). Thus, the fusion decision model 601 performs modeling and analysis based on encrypted features.
[0086] In one embodiment, method 600 can be used for credit card risk detection. The specific process is as follows: First, multi-source data is collected. Assume the collected data includes: transaction logs showing user X making 5 transactions totaling 4999 yuan within 10 minutes (at different merchants); network traffic showing transaction requests initiated from the same IP address; and user behavior showing frequent changes to the registered mobile phone number. Then, the collected features are provided to the fusion decision model 601 for risk decision-making. Assume the model outputs a risk score of 0.95, triggering high-risk handling. At this point, the following can be executed in the secure enclave SGX environment: freezing the account and generating an audit report. For example, the SGX environment executes "UPDATE acc_table SET status='frozen' WHERE user_id='X';" to freeze the account.
[0087] In another embodiment, method 600 can be used for distributed denial-of-service attack protection. First, multimodal collaborative analysis is performed. For example, if a network layer synchronized flood attack with a traffic surge of 300% is detected; system layer CPU utilization is >95% for 120 seconds; and application layer transaction failure rate rises to 45%, decision analysis is conducted through the fusion decision model 601. Assuming an output risk score of 0.88, the automatic activation of traffic scrubbing equipment is triggered.
[0088] This application embodiment can use a fusion decision model to monitor the risks of user access behavior. The fusion decision model can integrate model branches of different architectures, has multimodal feature modeling capabilities, and has a more comprehensive understanding of risks, thereby enabling risk assessment by combining multimodal data.
[0089] Furthermore, this fusion decision model is trained using federated learning, which supports knowledge distillation, meaning that lightweight small models can be deployed on the federated learning client to participate in training. Additionally, in some embodiments, when analyzing user access behavior, each data source only provides data after encrypted feature extraction from the original user behavior data. The predictive analysis of the fusion decision model is based on the encrypted feature data, thereby minimizing the exposure of user-related plaintext data and enhancing data security.
[0090] In addition, in some embodiments, the fusion decision model uses encrypted features as input data in both the application and training phases, which can further reduce the exposure of user data and improve data security.
[0091] Based on the above-described risk monitoring method, embodiments of this application also provide a risk monitoring device. The following will combine... Figure 7 The device is described in detail.
[0092] Figure 7 The diagram illustrates the structure of a risk monitoring device 1000 according to an embodiment of this application.
[0093] like Figure 7 As shown, the risk monitoring device 1000 in this embodiment includes an acquisition module 1010, a scoring module 1020, a processing module 1030, and a federated learning module 1040.
[0094] The acquisition module 1010 is used to acquire first multimodal feature data; wherein the first multimodal feature data is obtained based on the access behavior of the first user. In one embodiment, the acquisition module 1010 may be used to execute step S210 described above, which will not be repeated here.
[0095] The scoring module 1020 is used to input the first multimodal data features into the trained fusion decision model and obtain the risk score output by the fusion decision model. The fusion decision model includes multiple branch models and a fusion mechanism for the decision results of the multiple branch models. The fusion decision model is trained using federated learning. In one embodiment, the scoring module 1020 can be used to execute step S220 described above, which will not be repeated here.
[0096] The processing module 1030 is used to process the access of the first user according to the preset processing action in the risk level to which the risk score belongs. In one embodiment, the processing module 1030 can be used to execute the step S230 described above, which will not be repeated here.
[0097] The federated learning module 1040 is used to train the fusion decision model through federated learning. The fusion decision model is deployed on the server side of the federated learning, and a small model is heterogeneously distilled from the fusion decision model. The small model is then deployed on each client side of the federated learning. Specifically, the federated learning module 1040 is used for: each client training the small model using at least one local second multimodal feature data, and uploading parameters to the server after training, wherein the second multimodal feature data is obtained based on the access behavior of a second user; the server updating the small model by aggregating the parameters uploaded by each client to obtain a global small model; the server updating the fusion decision model using bidirectional knowledge distillation of the global small model and the fusion decision model; and after one round of updates to the fusion decision model, the server distributing the parameters of the global small model to each client. In one embodiment, the federated learning module 1040 can execute steps S310 to S340 as described above.
[0098] According to embodiments of this application, any multiple modules among the acquisition module 1010, scoring module 1020, processing module 1030, and federated learning module 1040 can be merged 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 acquisition module 1010, scoring module 1020, processing module 1030, and federated learning module 1040 can be at least partially implemented as hardware circuitry, such as field-programmable gate arrays, programmable logic arrays, systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits, or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the acquisition module 1010, scoring module 1020, disposal module 1030, and federated learning module 1040 may be implemented at least partially as a computer program module that can perform corresponding functions when the computer program module is run.
[0099] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing the risk monitoring method according to embodiments of this application.
[0100] like Figure 8As shown, an electronic device 1200 according to an embodiment of this application includes a processor 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory 1202 or a program loaded from a storage portion 1208 into a random access memory 1203. The processor 1201 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 1201 may also include onboard memory for caching purposes. The processor 1201 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.
[0101] Random access memory 1203 stores various programs and data required for the operation of electronic device 1200. Processor 1201, read-only memory 1202, and random access memory 1203 are interconnected via bus 1204. Processor 1201 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 1202 and / or random access memory 1203. It should be noted that the programs may also be stored in one or more memories other than read-only memory 1202 and random access memory 1203. Processor 1201 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.
[0102] According to embodiments of this application, the electronic device 1200 may further include an input / output interface 1205, which is also connected to the bus 1204. The electronic device 1200 may also include one or more of the following components connected to the input / output interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card, such as a local area network card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the input / output interface 1205 as needed. A removable medium 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1210 as needed so that computer programs read from it can be installed into the storage section 1208 as needed.
[0103] 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.
[0104] 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 1202, and / or random access memory 1203, and / or one or more memories other than read-only memory 1202 and random access memory 1203 described above.
[0105] 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.
[0106] 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 1209, and / or installed from the removable medium 1211. 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.
[0107] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by processor 1201, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.
[0108] 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).
[0109] 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.
[0110] 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 monitoring method, characterized in that, The method includes: Acquire first multimodal feature data; wherein the first multimodal feature data is obtained based on the access behavior of the first user and includes features extracted from data of multiple data types; The first multimodal data features are input into the trained fusion decision model, and the risk score output by the fusion decision model is obtained. The first user's access is processed according to the preset handling actions in the risk level to which the risk score belongs; The fusion decision model includes multiple branch models and a fusion mechanism for the decision results of the multiple branch models; the fusion decision model is trained using federated learning, wherein the fusion decision model is deployed on the server side of the federated learning and a small model is distilled from the fusion decision model, and the small model is deployed on each client side of the federated learning.
2. The method according to claim 1, characterized in that, The process of training the fusion decision model through federated learning includes: Each client trains the small model using at least one local second multimodal feature data, and uploads the parameters to the server after training. The second multimodal feature data is obtained based on the access behavior of the second user. The server updates the small model by aggregating the parameters uploaded by each client, thus obtaining a global small model; The server uses bidirectional knowledge distillation of the global small model and the fusion decision model to update the fusion decision model; and After the fusion decision model completes one round of updates, the server sends the parameters of the global mini-model to each client.
3. The method according to claim 2, characterized in that, During the federated learning training process, the client and the server use sparse ternary quantization to compress and transmit data.
4. The method according to claim 1, wherein, The smaller model adopts the same architecture as one of the multiple branch models.
5. The method according to claim 1, characterized in that, The acquisition of the first multimodal feature data includes: Encrypted feature data is collected from multiple data sources to obtain an encrypted feature dataset. The encrypted feature data is obtained by extracting and encrypting the original behavioral data stored by the multiple data sources according to a unified encrypted feature extraction method. The encrypted feature dataset is divided according to the user dimension to form a subset of encrypted features for each user; The features in the encrypted feature subset of the first user are concatenated to form the first multimodal feature data.
6. The method according to claim 5, characterized in that, The encryption feature extraction method includes: Based on the data type of the original behavioral data, the feature extraction method and encryption method are determined according to the preset correspondence. Features are extracted from the original behavioral data according to the described feature extraction method, and then the extracted features are encrypted and transformed according to the described encryption method. The feature extraction and encryption methods for different data types in the correspondence are different.
7. The method according to claim 5, characterized in that, The process of handling the first user's access according to the preset action in the risk level to which the risk score belongs includes: When the preset action in the risk level to which the risk score belongs requires processing plaintext data related to the first user, the action is executed within the secure enclave.
8. A risk monitoring device, characterized in that, The device includes: The acquisition module is used to acquire first multimodal feature data; wherein the first multimodal feature data is obtained based on the access behavior of the first user and includes features extracted from data of multiple data types; The scoring module is used to input the first multimodal data features into the trained fusion decision model and obtain the risk score output by the fusion decision model; The processing module is used to process the first user's access according to the preset processing actions in the risk level to which the risk score belongs; The fusion decision model includes multiple branch models and a fusion mechanism for the decision results of the multiple branch models. The fusion decision model is trained using federated learning. The fusion decision model is deployed on the server side of the federated learning and a small model is distilled from the fusion decision model. The small model is deployed on each client side of the federated learning.
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.