Data management system, data management method, electronic device, and storage medium

Abstract

The invention discloses a data management system, a data management method, electronic equipment and a storage medium. The data management system comprises a data pre-check module which is used for carrying out risk pre-check on the cross-domain payment data based on a data level and an access rule by adopting a decision tree model in a data access stage, and generating an access strategy for executing the cross-domain payment data; and the federated traceability module is used for performing full-cycle anomaly monitoring on the cross-domain payment data based on the operation log of the cross-domain payment data by adopting a federated learning model in a data interaction stage, and feeding back an anomaly monitoring result to the data pre-detection module so as to trigger optimization and adjustment of the access rule. According to the data management system, double-track assessment of beforehand pre-check and afterward traceability is adopted, risk management of cross-domain payment data is comprehensively and effectively achieved, and the data security requirement is met.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security, and in particular to a data management system, a data management method, an electronic device and a storage medium. BACKGROUND

[0002] Under the background of rapid development of Internet technology, cross-regional data interaction presents an explosive growth trend, which poses a serious challenge to the security and reliability of cross-regional data interaction mode. The current main defects are as follows: 1) Lack of data full life cycle monitoring. The current system cannot realize end-to-end monitoring of the data full link, resulting in frequent data security vulnerabilities; 2) Insufficient regional rule adaptability. The differentiated regulatory rules between regions lack a dynamic adjustment mechanism and cannot adapt to the rapid change needs of cross-regional business scenarios; 3) Weak collaborative traceability. There are data island phenomena between cross-regional terminals, and it is difficult to realize global tracking and collaborative traceability of risk events.

[0003] Therefore, it is an urgent need to build a new data management system to ensure the security and reliability of cross-regional data interaction. SUMMARY

[0004] The purpose of the present application is to provide a data management system, a data management method, an electronic device and a storage medium, which at least solve one of the above technical problems to some extent.

[0005] To achieve the above purpose, the first aspect of the present application provides a data management system, comprising: a data pre-checking module, configured to use a decision tree model to perform risk pre-checking on cross-regional payment data based on data levels and access rules in a data access stage, and generate an access strategy for executing the cross-regional payment data; a federal traceability module, configured to use a federal learning model to perform abnormal monitoring on the cross-regional payment data based on operation logs of the cross-regional payment data in a data interaction stage, and feed back the abnormal monitoring result to the data pre-checking module to trigger optimization adjustment of the access rules.

[0006] According to an embodiment of the present application, the data pre-checking module comprises: a grading unit configured to determine a corresponding data level based on data characteristics of cross-regional payment data; a decision unit configured to use a decision tree model to match a corresponding access rule based on the data level, to output a decision instruction for the cross-regional payment data, and to execute access decisions including allowing access and early warning processing based on the decision instruction.

[0007] According to an embodiment of the present application, the hierarchical unit is configured to determine the corresponding data level based on the data features of the cross-domain payment data, including: parsing the data content of the cross-domain payment data, and extracting the data features of the cross-domain payment data, wherein the data features include data type, impact range and compliance constraints; obtaining a weighted score of the data features, and dividing the corresponding data level based on the weighted score and a preset threshold.

[0008] According to an embodiment of the present application, the decision unit is configured to match the corresponding access rule based on the data level by using a decision tree model, to output a decision instruction for the cross-domain payment data, including: taking the data level as a root node and the access rule as a leaf node, to construct a decision path of the decision tree model; and binding the leaf node to a corresponding decision instruction, to output the corresponding decision instruction when the cross-domain payment data passes through the decision path to reach the leaf node.

[0009] According to an embodiment of the present application, the data pre-checking module further includes an arbitration unit configured to execute the access rule corresponding to the highest priority based on the divided priority when there is a conflict between the access rules of different regions.

[0010] According to an embodiment of the present application, the federal traceability module includes: a collection unit configured to collect the operation log for the entire data life cycle of the cross-domain payment data; a processing unit configured to preprocess the operation log of the cross-domain payment data, extract a feature vector, and encrypt the feature vector by using a homomorphic encryption technology; an aggregation unit configured to align and aggregate the encrypted feature vector to form a global feature set; a detection unit configured to detect an abnormal scenario of the cross-domain payment data based on the global feature set; and an analysis unit configured to perform risk analysis and identification based on the detected abnormal scenario, and obtain an abnormal monitoring result of the cross-domain payment data.

[0011] According to an embodiment of the present application, the detection unit is configured to detect the abnormal scenario of the cross-domain payment data based on the global feature set, including: training the global feature set by using a spatio-temporal graph neural network, constructing a data topology graph, to detect whether there is abnormal data; and when abnormal data is detected, outputting the corresponding abnormal scenario and a risk heat map.

[0012] To achieve the above object, the second aspect of the present application provides a data management method, comprising: in a data access stage, adopting a decision tree model to perform risk pre-checking on the cross-domain payment data based on data levels and access rules, and generating an access strategy for executing the cross-domain payment data; in a data interaction stage, adopting a federated learning model to perform full-cycle anomaly monitoring on the cross-domain payment data based on operation logs of the cross-domain payment data, and feeding back the anomaly monitoring result to the data pre-checking module to trigger optimization adjustment of the access rules.

[0013] To achieve the above object, the third aspect of the present application provides an electronic device, comprising: at least one processor; and a memory communicatively connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the data management method of the second aspect.

[0014] To achieve the above object, the fourth aspect of the present application provides a non-transitory computer readable storage medium storing computer instructions, wherein the computer instructions are used to enable the computer to execute the data management method of the second aspect.

[0015] It can be seen that the present application has the following advantages compared with the prior art: 1) A double-track evaluation system of pre-checking and post-tracing is adopted to comprehensively and effectively manage cross-domain payment data; 2) A dynamic rule iteration optimization mechanism is established to optimize and adjust the access rules based on the abnormal analysis result, and the pre-checking strategy is self-evolved; 3) Data management throughout the entire data life cycle is realized, and the data security requirements are flexibly met.

[0016] Additional aspects and advantages of the present application will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS

[0017] The above and / or additional aspects and advantages of the present application will become apparent and be readily appreciated from the following description, including the appended drawings. Figure 1 is a schematic block diagram of a data management system according to an exemplary embodiment; Figure 2 is a schematic flow chart of a data management method according to an exemplary embodiment.

[0018] Figure 3 is a schematic diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0019] Embodiments of the present application are described below in detail with reference to the accompanying drawings, wherein the same or similar components or components having the same or similar functions are denoted by the same or similar reference numerals throughout the drawings. The embodiments described below by reference to the drawings are exemplary and are intended to explain the present application, and cannot be understood as a limitation of the present application.

[0020] The embodiments of the present application provide a data management system, as shown in the figure, which comprises: a data pre-checking module 110, configured to perform risk pre-checking on the cross-domain payment data based on data levels and access rules in a data access stage by using a decision tree model, and generate an access strategy for executing the cross-domain payment data; a federal traceability module 120, configured to perform abnormality monitoring on the cross-domain payment data in a whole cycle based on operation logs of the cross-domain payment data in a data interaction stage by using a federal learning model, and feed back the abnormality monitoring result to the data pre-checking module to trigger optimization adjustment of the access rules. Figure 1

[0021] For example, the data management system of the embodiments of the present application adopts a double-track architecture of risk pre-checking and traceability analysis to manage data for cross-domain payment scenarios. The data pre-checking module 110 needs to determine which interaction strategy to execute on the data based on the access rules corresponding to the data level of the cross-domain payment data. For example, if the cross-domain payment data needs to be transmitted from region A to region B, the embodiments of the present application first need to know the data level of the data and the access rules corresponding to the data in region A and region B. If the data meets the compliance transmission rules of region A and the receiving identification rules of region B at the same time, the data is allowed to be transmitted from region A to region B, if not, a warning is triggered, the data transmission is prevented, or the data is further manually verified to further determine whether to perform cross-domain transmission, etc. The federal traceability module 120 needs to perform risk monitoring on the transmission of the cross-domain payment data in the whole life cycle after the data is transmitted across regions. At the same time, the data management system of the embodiments of the present application also adopts a real-time feedback mechanism, the federal traceability module 120 can feed back the abnormality analysis situation to the data pre-checking module 110 in real time, and then the data pre-checking module 110 can adjust and optimize the corresponding rules of the multi-region rule library according to the risk analysis situation. For example, when the federal traceability module detects an abnormal violation scenario, it can perform in-depth analysis on the abnormal situation, such as analyzing the risk type, risk level, etc. of the abnormal situation, and can evaluate the influence range of the abnormal situation, and also provide optimization improvement strategies based on the analysis and evaluation situation, so that the federal traceability module 120 generates a complete analysis report based on the analysis and evaluation result and the optimization improvement strategy, and feeds back the report to the data pre-checking module 110.

[0022] ​It can be seen that the data management system of the embodiment of the present application can ensure the security and reliability of cross-domain payment before data interaction on the one hand, meet the compliance requirements of cross-domain, on the other hand, can trace and analyze the potential risks of data in data transmission, and can also be based on risk analysis to optimize and adjust by itself, effectively realize the comprehensive risk monitoring of data in each stage.

[0023] In a preferred embodiment, the data pre-checking module comprises: a grading unit configured to determine a corresponding data level based on data features of the cross-domain payment data; a decision unit configured to match a corresponding access rule based on the data level by using a decision tree model, to output a decision instruction for the cross-domain payment data, and to perform access decision including access permission and early warning processing based on the decision instruction.

[0024] More preferably, the grading unit is configured to determine a corresponding data level based on data features of the cross-domain payment data, comprising: analyzing data content of the cross-domain payment data, and extracting data features of the cross-domain payment data, wherein the data features include data type, influence range and compliance constraint; obtaining a weighted score of the data features, and dividing a corresponding data level based on the weighted score and a preset threshold.

[0025] For example, the grading unit can extract data features by analyzing key fields included in the cross-domain payment data through natural language processing. The data type represents the transaction nature of the cross-domain payment data, such as cross-domain transfer, cryptocurrency payment, etc. The influence range represents the number of regions involved in the transaction, the amount of money, the size of the user group, etc. The compliance constraint represents whether it meets the regulatory requirements. After extracting the corresponding data features, the grading unit further assigns corresponding weights to different data features according to the business risk priority, so as to obtain the score value of the data features by weighted calculation. Further, the grading unit determines the data level based on the preset threshold and the corresponding relationship between the level. In addition, the preset threshold and the corresponding relationship between the level and the assigned weight can be adjusted flexibly according to actual application. For example, the weight of the compliance constraint needs to be improved accordingly if a certain region strengthens the supervision of cryptocurrency.

[0026] It can be seen that the grading unit in the embodiment of the present application converts complex cross-domain payment data into explicit risk levels by quantifying features, dynamic weighting and threshold comparison, provides accurate input for subsequent risk control actions, and supports flexible adjustment to adapt to regulatory changes.

[0027] More preferably, the decision unit is configured to match the corresponding access rule based on the data level using a decision tree model to output a decision instruction for the cross-domain payment data, comprising: taking the data level as a root node and taking the access rule as a leaf node to construct a decision path of the decision tree model; and binding the leaf node to a corresponding decision instruction to output a corresponding decision instruction when the cross-domain payment data passes through the decision path to the leaf node.

[0028] For example, after determining the data level, the decision unit can match the corresponding access rule of the cross-domain payment data by identifying the key information of the data. For example, the embodiment of the present application sets the corresponding access rule for each data level in advance. For example, in the transmission scenario, the data processor shall not, in principle, use Internet email, instant messaging, online file transmission, interactive information service or exchange and transmission of data items above the third level through mobile media, except as necessary to perform statutory duties or statutory obligations. If necessary, the data processor should unify and clarify the transmission demand scenario, the necessity of supporting such a scenario, and the risk prevention measures that should be taken.

[0029] The decision tree model selects the optimal split feature through information gain or Gini index and forms a tree-shaped rule path. In the cross-domain payment scenario, the data level is set as the root node of the decision tree as the initial classification basis. For example, L3-level data indicates a higher risk and needs to be prioritized into a strict review branch. This design ensures that data of different risk levels are diverted from the root node to form the initial screening logic. Each leaf node is directly associated with a specific access rule (such as blocking transactions or enhancing verification) and represents the final decision instruction. For example: when the cross-domain payment data flows through the decision path to the leaf node, if the condition of "L4-level data + involving prohibited areas" is met, the "block transactions and report to the regulator" instruction is triggered. The rule binding of the leaf node is realized through the final judgment of the feature attributes (such as transaction amount, merchant blacklist), ensuring that the output instruction strictly matches the data level. Further, the decision unit constructs a decision path generation mechanism. For example, the path from the root node to the leaf node is generated by a recursive division process. The root node is initially divided according to the data level (such as L1 / L2 / L3 / L4). The internal nodes are further divided according to additional attributes (such as transaction amount, user authentication status). The end point of the path (leaf node) executes the pre-defined rule to form a complete logic chain of "data level-feature judgment-disposal action". In addition, the cross-domain payment data can also dynamically match the branch conditions according to the real-time attributes when it flows through the decision path.

[0030] It can be seen that the decision unit of the embodiment of the application accurately associates the data level with the access rule through the tree structure, generates a dynamic decision path by recursive division, and realizes the automation of risk disposal and compliance by algorithm optimization, and is suitable for high requirement scenarios such as cross-domain payment.

[0031] In addition, the data pre-checking module can also record pre-checking logs, for example, the timestamp, data type, monitoring result and exception handling of each pre-checking operation. The pre-checking result is bound to the access rule version to ensure traceability. Furthermore, the data pre-checking module can periodically analyze the recorded pre-checking logs, for example, cluster analysis of exception handling or statistics of high-frequency rules, and can further associate the pre-checking exception data with regional rules, industry standards, vulnerability libraries and the like, so as to update the corresponding access rules.

[0032] In a preferred embodiment, the data pre-checking module further comprises an arbitration unit for executing the access rule corresponding to the highest priority based on the divided priority when the access rules of different regions conflict.

[0033] For example, the arbitration unit in the data pre-checking module is responsible for priority sorting of multiple access rules, for example, setting rules related to high-risk scenarios such as cross-domain sanctions as the highest priority to ensure that critical risk control logic is executed first. When there is a logical conflict between access rules in different regions (such as domestic and overseas), the arbitration unit selects the highest level rule based on the preset priority level. For example, the priority of compliance check for overseas transactions is higher than that of automatic release rules for domestic transactions, triggering a blocking operation. The arbitration unit in the embodiment of the application can define the priority of access rules by using a rule weight matrix. Furthermore, by detecting the intersection condition of multi-region rules (such as triggering domestic release and overseas blocking at the same time) through a rule engine, the arbitration unit automatically selects the rule with higher weight based on the weight coefficient.

[0034] It can be seen that the arbitration unit in the embodiment of the application guarantees the consistency of decision-making under a complex rule system through priority division and conflict resolution mechanism, and the dynamic weight adjustment capability further improves the adaptability of the risk control system to multi-region and multi-regulation scenarios.

[0035] In a preferred embodiment, the federal traceability module comprises: a collection unit for collecting the operation log for the entire data life cycle of the cross-domain payment data; a processing unit for preprocessing the operation log of the cross-domain payment data, extracting a feature vector, and encrypting the feature vector using homomorphic encryption technology; an aggregation unit for aligning and aggregating the encrypted feature vector to form a global feature set; a detection unit for detecting abnormal scenarios of the cross-domain payment data based on the global feature set; and an analysis unit for risk analysis and identification based on the detected abnormal scenarios, and obtaining abnormal monitoring results of the cross-domain payment data.

[0036] For example, the collection unit collects operation logs for the entire life cycle (creation, circulation, storage, and destruction) of cross-domain payment data, covering key behaviors such as data access, modification, and transmission. For example, API call records in the data transmission stage, SFTP file transmission logs, cloud storage access logs in the data storage stage, encryption state change events, and third-party server interface call records in the data sharing stage can be collected, thereby providing a complete and full-chain data basis for subsequent heritage analysis. The processing unit can preliminarily clean the collected operation logs, remove redundant information, and extract feature vectors of the cross-domain payment data, such as data attributes, compliance labels, and timestamps. After extracting the feature vectors, the processing unit encrypts the feature vectors using homomorphic encryption technology to realize data availability in the ciphertext state and avoid plaintext disclosure risks. The aggregation unit can align the public feature dimensions of the encrypted cross-domain payment data through encrypted data matching technology to eliminate the influence of data islands. Then, the encrypted dispersed feature vectors are combined into a global feature set. The detection unit detects abnormal scenarios based on the global feature set through a machine learning model. The analysis unit traces abnormal nodes based on the abnormal scenarios and generates disposal suggestions to output an abnormal analysis report.

[0037] It can be seen that the federal traceability module of the embodiment of the present application realizes cross-domain payment risk joint defense and control under the premise of protecting data sovereignty through federated learning and privacy computing technology, and realizes global traceability of abnormal risk events.

[0038] More preferably, the detection unit is configured to detect abnormal scenarios of the cross-domain payment data based on the global feature set, including: training the global feature set using a spatio-temporal graph neural network, constructing a data topology graph, and detecting whether there is abnormal data; and when abnormal data is detected, outputting a corresponding abnormal scenario and a risk heat map.

[0039] For example, the detection unit dynamically models complex associations in the transaction network by integrating global features of cross-domain payment data (such as transaction amount, geographic location, time series, user behavior, etc.) using a spatio-temporal graph neural network (ST-GNN) and identifying abnormal scenarios. Among them, the cross-domain payment data is modeled as a topological graph structure, such as setting the node as the transaction subject (user, merchant, bank account, etc.), the edge as the transaction relationship (such as the transfer path, transaction frequency), and the node / edge feature as the amount, timestamp, IP address, device fingerprint, etc. The spatial dimension is used to capture the geographic location association (such as whether the transaction parties cross the sanctioned countries). The time dimension is used to analyze the transaction sequence pattern (such as whether the high-frequency transfer in a short time is consistent with the historical behavior). The neural network model aggregates neighbor information through a graph convolution network (GCN) and learns time dependence by combining a long short-term memory network (LSTM) to achieve spatio-temporal joint modeling. Further, the neural network model outputs the abnormal probability of each node / edge (such as judging the degree of deviation from the normal mode through reconstruction error or attention weight). For example, the first large transaction of an account with a high-risk area account is marked as abnormal if the spatio-temporal features differ significantly from the historical pattern. The detection unit can also map the abnormal probability to a visual risk heat map, where the heat map can display the risk distribution according to dimensions such as geographic area, time window, entity association, etc. The heat map visually presents the risk focus through color depth (such as red representing high risk), so as to support quick positioning of risk points.

[0040] It can be seen that the detection unit of the embodiment of the present application models the dynamic association of the transaction network through the spatio-temporal graph neural network, and realizes the explainability analysis of the abnormal scenario in combination with the risk heat map, thereby providing precise and visual decision support for cross-domain payment risk control.

[0041] Correspondingly, based on the same inventive concept, the embodiment of the present application provides a data management method, as shown in Figure 2 The data management method comprises: In step S210, a decision tree model is used to perform risk pre-checking on the cross-domain payment data based on data levels and access rules in the data access stage, and an access strategy for the cross-domain payment data is generated; In step S220, a federated learning model is used to perform abnormal monitoring on the cross-domain payment data based on the operation log of the cross-domain payment data in the data interaction stage, and the abnormal monitoring result is fed back to the data pre-checking module to trigger optimization adjustment of the access rule.

[0042] More implementation details and beneficial effects of the embodiment of the present application can be referred to the above-mentioned embodiments of the data management system, and will not be described in detail here.

[0043] Correspondingly, the embodiment of the present application also provides an electronic device, as shown in Figure 3The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of the present invention. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0044] like Figure 3 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0045] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0046] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention provide a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 309, or installed from a storage device 308, or installed from a ROM 302. When the computer program is executed by a processing device 301, it performs the functions defined in the methods of the embodiments of the present invention.

[0047] It should be noted that the computer-readable medium in the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium may, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination of the above. More specific examples of the computer-readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus or device. In the present application, the computer-readable signal medium can include a data signal carried in a baseband or as a part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take many forms, including but not limited to, an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium that can send, propagate or transmit the program for use by or in connection with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to, wire, cable, RF (radio frequency), etc., or any suitable combination of the above.

[0048] In some embodiments, the client, server, or both can communicate using any current known or future developed network protocol, such as HTTP (HyperText Transfer Protocol), and can be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks ("LANs"), wide area networks ("WANs"), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any current known or future developed networks.

[0049] The above computer-readable medium can be contained in the above electronic device; or can exist separately without being assembled into the electronic device.

[0050] The computer readable medium carries one or more programs, when the one or more programs are executed by the electronic device, cause the electronic device to: in a data access stage, adopt a decision tree model to perform risk pre-checking on the cross-domain payment data based on a data level and an access rule, and generate an execution of an access strategy for the cross-domain payment data; and in a data interaction stage, adopt a federated learning model to perform full-cycle anomaly monitoring on the cross-domain payment data based on an operation log of the cross-domain payment data, and feed back an anomaly monitoring result to the data pre-checking module to trigger an optimized adjustment of the access rule.

[0051] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0052] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0053] The units described in the embodiments of the present application can be implemented by software, or by hardware. In some cases, the name of a unit does not constitute a limitation on the unit itself. For example, a first obtaining unit can also be described as a unit that obtains at least two Internet protocol addresses.

[0054] The functions described above can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system on a chip (SOCs), complex programmable logic devices (CPLDs), etc.

[0055] In the context of the present application, a machine-readable medium can be a tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium will include one or more lines of electrical connections, portable computer disks, hard disk drives, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), optical fibers, portable compact disc read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0056] The above description is merely exemplary of the application and the application of the principles of the application. It is to be understood that modifications can be made in the embodiments described without departing from the spirit of the application, and the scope of the application should be limited only as specified in the appended claims. For example, the features of the various embodiments described above can be combined with one another in any combination.

[0057] Moreover, while operations are depicted in a particular, sequential order, this should not be understood as requiring or implying that such operations are performed in the order illustrated. Rather, many of the operations will potentially be performed in parallel, or in a different order than illustrated. In addition, while a particular implementation is discussed, this should not be understood as requiring or implying that all or even any of the implementations are consistent among all embodiments.

[0058] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

[0059] Accordingly, the present application provides a non-transitory computer readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to perform the identity authentication method or the data transmission method described in the above embodiments.

[0060] The flow and block diagrams in the drawings show architectural, functional, and operational architectures of possible implementations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow and block diagrams can represent a module, a segment, or a portion of code that comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations thereof, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or combinations of hardware and software.

[0061] The units described in the embodiments of the present application can be implemented by software, or by hardware. In some cases, the name of the unit does not constitute a limitation on the unit itself.

[0062] The functionality described above can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0063] In the context of the present application, a machine-readable medium can be a tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium will include one or more of: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0064] The above description is only a preferred embodiment of the present application and a description of the technical principles of the application. It should be understood by those skilled in the art that the disclosed scope of the present application is not limited to the technical solutions formed by the specific combinations of the above technical features, and should also cover other technical solutions formed by the combinations of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the technical solutions formed by the mutual replacement of the above features and the technical features disclosed in the present application (but not limited to) having similar functions.

[0065] Moreover, while operations can be depicted in a particular, serial order, this should not be understood as requiring or implying that such operations be performed in the order illustrated, or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing can be advantageous. Likewise, while specific implementations are discussed, these should not be understood to suggest a limitation of the scope of the present application. In separate embodiments, certain features can be combined. Conversely, where specific embodiments are discussed, various features can be used alone or in any combination.

[0066] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A data management system, characterized in that, include: The data pre-inspection module is used to perform risk pre-inspection on cross-domain payment data based on data level and access rules using a decision tree model during the data access phase, and to execute access strategies for the cross-domain payment data. The federated tracing module is used to perform full-cycle anomaly monitoring of the cross-domain payment data based on the operation logs of the cross-domain payment data using a federated learning model during the data interaction phase, and to feed back the anomaly monitoring results to the data pre-inspection module to trigger the optimization and adjustment of the admission rules.

2. The data management system according to claim 1, characterized in that, The data pre-inspection module includes: The hierarchical unit is used to determine the corresponding data level based on the data characteristics of cross-domain payment data; The decision unit is used to use a decision tree model to match the corresponding access rules based on the data level, so as to output a decision instruction for the cross-domain payment data, and to execute an access decision including allowing access and warning processing based on the decision instruction.

3. The data management system according to claim 2, characterized in that, The grading unit is used to determine the corresponding data level based on the data characteristics of the cross-domain payment data, including: The data content of the cross-domain payment data is analyzed, and the data characteristics of the cross-domain payment data are extracted, wherein the data characteristics include data type, scope of influence and / or compliance constraints. Obtain the weighted score of the data features, and classify the corresponding data levels based on the weighted score and a preset threshold.

4. The data management system according to claim 2, characterized in that, The decision unit is used to employ a decision tree model to match the corresponding admission rules based on the data level, and output decision instructions for the cross-domain payment data, including: The decision path of the decision tree model is constructed by using the data level as the root node and the admission rule as the leaf node. The leaf node is bound to a corresponding decision instruction so that when the cross-domain payment data reaches the leaf node through the decision path, the corresponding decision instruction is output.

5. The data management system according to claim 1, characterized in that, The data pre-inspection module also includes: The arbitration unit is used to execute the highest priority admission rule when there are conflicts in the admission rules of different regions.

6. The data management system according to claim 1, characterized in that, The federal tracing module includes: The data collection unit is used to collect the operation logs throughout the entire data lifecycle of the cross-domain payment data. The processing unit is used to preprocess the operation logs of the cross-domain payment data, extract feature vectors, and encrypt the feature vectors using homomorphic encryption technology. The aggregation unit is used to align and aggregate the encrypted feature vectors to form a global feature set; The detection unit is used to detect abnormal scenarios in the cross-domain payment data based on the global feature set. The analysis unit is used to perform risk analysis and identification based on detected abnormal scenarios, and to obtain the abnormal monitoring results of the cross-domain payment data.

7. The data management system according to claim 6, characterized in that, The detection unit is used to detect abnormal scenarios in the cross-domain payment data based on the global feature set, including: The global feature set is trained using a spatiotemporal graph neural network to construct a data topology graph in order to detect whether there is abnormal data. When abnormal data is detected, the corresponding abnormal scenario and risk heatmap are output.

8. A data management method, characterized in that, include: During the data access phase, a decision tree model is used to perform risk pre-detection on cross-domain payment data based on data level and access rules, and generate an access strategy for the cross-domain payment data. During the data interaction phase, a federated learning model is used to perform full-cycle anomaly monitoring of the cross-domain payment data based on the operation logs of the cross-domain payment data, and the anomaly monitoring results are fed back to the data pre-inspection module to trigger the optimization and adjustment of the admission rules.

9. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the data management method as described in claim 8.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the data management method as described in claim 8.

Images