Methods, devices, electronic equipment, and storage media for assessing transaction risk decisions

Abstract

This application discloses an assessment method, apparatus, electronic device, and storage medium for transaction risk decision-making. The method utilizes a distributed computing framework to process full historical transaction context snapshots, achieving efficient processing on a data scale of hundreds of billions while ensuring the fidelity of time-series logic. It also automatically outputs multi-dimensional assessment indicators and comprehensive scores, providing zero-business-risk, low-cost, and highly reliable data support for strategy iteration. This effectively solves the core defects of traditional solutions, such as asset synchronization lag, limited assessment scale, and poor result fidelity.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of computers, and in particular to an assessment method, apparatus, electronic device, and storage medium for transaction risk decision making. Background Technology

[0002] With the rapid development of fintech and e-commerce, the scale of online transactions is growing exponentially, making transaction risk control crucial for ensuring business security and stability. To effectively identify and intercept risky transactions such as fraud and money laundering, various financial institutions and platforms commonly employ digital decision-making assets comprised of risk strategies, rules, and models for real-time risk decision-making. To ensure the effectiveness and security of these decision-making assets before deployment, thorough testing and evaluation are necessary. While traditional online A / B testing or canary releases can reflect real-world effects, they suffer from high business risks, long cycles, and high costs. Therefore, utilizing offline big data platforms for simulation evaluation based on historical transaction data has become an important supplement and pre-verification method.

[0003] Existing technologies involve randomly sampling a small number of historical transaction samples from a data warehouse and using tools such as SQL or Spark to execute new strategies or rules to be evaluated in batches. The core drawback is that sampling leads to a lack of complete contextual information at the decision-making moment, and random sampling disrupts the inherent time-series relationships of the transaction data, resulting in severe distortion of feature calculations that rely on time-series logic. Furthermore, this approach has a limited evaluation scale and struggles to cover long-tail risk patterns. Summary of the Invention

[0004] In view of this, embodiments of this application provide at least one method, apparatus, electronic device, and storage medium for assessing transaction risk decisions.

[0005] The technical solution of this application embodiment is implemented as follows: On the one hand, embodiments of this application provide a method for assessing transaction risk decisions, the method comprising: Listen for page configuration change events in the production configuration center, trigger the asset synchronization service through the message queue, pull the asset configuration from the production configuration center, serialize the asset configuration into a preset format file, and store it in the asset storage area of ​​the distributed file system. Historical transaction data is read from the data warehouse, the historical transaction data is converted into a context snapshot, and the context snapshot is stored in an offline data table in columnar storage format; The preset format file is loaded from the asset storage area of ​​the distributed file system, and the preset format file is deserialized to obtain a rule engine object and a model object. The rule engine object and the model object are encapsulated into custom functions of the distributed computing framework, and the custom functions are dynamically registered to the distributed computing cluster. Based on the context snapshot in the offline data table, the custom function is invoked to execute decision logic on the context snapshot and generate an evaluation result; Based on the evaluation results, multiple evaluation indicators are calculated, a comprehensive score is generated based on the evaluation indicators, and the evaluation results and the comprehensive score are output to the management and control layer for display.

[0006] On the other hand, embodiments of this application provide an assessment apparatus for transaction risk decision-making, the method comprising: The processing module is used to listen for page configuration change events in the production configuration center, trigger the asset synchronization service through the message queue, pull the asset configuration from the production configuration center, serialize the asset configuration into a preset format file, and store it in the asset storage area of ​​the distributed file system. Historical transaction data is read from the data warehouse, the historical transaction data is converted into a context snapshot, and the context snapshot is stored in an offline data table in columnar storage format; The preset format file is loaded from the asset storage area of ​​the distributed file system, and the preset format file is deserialized to obtain a rule engine object and a model object. The rule engine object and the model object are encapsulated into custom functions of the distributed computing framework, and the custom functions are dynamically registered to the distributed computing cluster. The evaluation module is used to call the custom function to perform decision logic on the context snapshot based on the context snapshot in the offline data table and generate an evaluation result; Based on the evaluation results, multiple evaluation indicators are calculated, a comprehensive score is generated based on the evaluation indicators, and the evaluation results and the comprehensive score are output to the management and control layer for display.

[0007] In another aspect, embodiments of this application provide a computer device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-mentioned assessment method for transaction risk decision-making.

[0008] In another aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described method for assessing transaction risk decisions.

[0009] In another aspect, embodiments of this application provide a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device executes some or all of the steps in the assessment method for implementing the above-mentioned transaction risk decision.

[0010] In another aspect, embodiments of this application provide a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-mentioned assessment method for transaction risk decision-making.

[0011] This application embodiment utilizes a distributed computing framework to process full historical transaction context snapshots, achieving efficient processing on a data scale of hundreds of billions while ensuring the fidelity of time sequence logic. It also automatically outputs multi-dimensional evaluation indicators and comprehensive scores, providing zero business risk, low cost, and high reliability data support for strategy iteration. This effectively solves the core defects of traditional solutions in terms of asset synchronization lag, limited evaluation scale, and poor result fidelity.

[0012] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0014] Figure 1 A schematic diagram illustrating the implementation process of a transaction risk decision assessment method provided in this application embodiment; Figure 2 A schematic diagram of the architecture of an assessment system for transaction risk decision-making provided in an embodiment of this application; Figure 3 A flowchart illustrating an asset synchronization adaptation page configuration method provided in this application embodiment; Figure 4 This is a schematic diagram illustrating the implementation process of an asset synchronization technology provided in an embodiment of this application; Figure 5 A flowchart illustrating a historical data batch processing and evaluation mechanism provided for an embodiment of this application; Figure 6 A schematic diagram of the composition structure of an assessment device for transaction risk decision-making provided in an embodiment of this application; Figure 7 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0017] The terms “first / second / third” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first / second / third” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0019] This application provides a method for assessing transaction risk decisions, which can be executed by a processor of a computer device. The computer device can refer to a server, laptop computer, tablet computer, desktop computer, smart TV, set-top box, mobile device (such as a mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or other similar computer equipment. Figure 1 A schematic diagram illustrating the implementation process of a transaction risk decision assessment method provided in this application embodiment is shown below. Figure 1 As shown, the method includes: Step 101: Listen for page configuration change events in the production configuration center, trigger the asset synchronization service through the message queue, pull the asset configuration from the production configuration center, serialize the asset configuration into a preset format file, and store it in the asset storage area of ​​the distributed file system.

[0020] In this embodiment, the production configuration center is a software system that centrally manages the operating parameters of the online system, used to store and publish configuration information for digital assets such as risk strategies, rules, and models. A message queue is middleware software that supports asynchronous communication, used to reliably transmit events or data between different system components. The asset synchronization service is an independent software service program responsible for executing the synchronization task of asset configuration. Asset configuration refers to the specific parameters and logical definitions of digital assets such as risk strategies, rules, and models. Serialization is the process of converting data structures or object states in memory into a specific format that can be stored or transmitted. A preset format file refers to a file with a specific structure and conventions formed after serialization, such as a JSON file. A distributed file system is a software system that supports storing and managing files on multiple computers, providing high throughput and fault tolerance. The asset storage area is a logical storage directory in the distributed file system, specifically used to store asset configuration files synchronized from the production environment.

[0021] The system continuously monitors page configuration changes via an event listening module deployed in the production configuration center. When a configuration change occurs, the listening module generates an event containing a configuration identifier and version information. The system then sends this event to a designated message queue. The asset synchronization service, acting as a consumer of the message queue, receives and parses the triggering event in real time. Subsequently, the asset synchronization service retrieves the complete asset configuration data corresponding to the event by calling the application programming interface provided by the production configuration center. The system serializes the retrieved asset configuration data according to a predefined JSON format specification, generating a structured configuration file. Finally, the system writes this configuration file to a pre-allocated asset storage directory in the distributed file system, completing the synchronized storage of the assets.

[0022] Step 102: Read historical transaction data from the data warehouse, convert the historical transaction data into a context snapshot, and store the context snapshot in an offline data table in columnar storage format.

[0023] In this embodiment, the data warehouse is a subject-oriented, integrated, relatively stable collection of data reflecting historical changes, used to support management decisions. Historical transaction data refers to all completed transaction records and related ancillary information that occurred in the production system in the past. A context snapshot refers to a data set that can completely reconstruct the environmental state required for the decision at the precise moment the risk decision occurred, including account status, device fingerprints, time-series characteristics, etc. Columnar storage format is a data storage method that organizes and compresses data by column rather than by row, making it particularly suitable for large-scale data analysis scenarios. Offline data tables are structured data tables stored in an offline big data platform for subsequent batch calculations.

[0024] Based on the requirements of the evaluation task, the system batch-reads historical transaction raw data within a specified time range from the data warehouse. For each historical transaction record read, the system extracts its complete context information at the time of decision-making, including the real-time status of the user account, the instantaneous value of the device fingerprint, and the feature sequence arranged in strict chronological order. The system organizes and encapsulates this extracted context information according to a predefined schema structure, forming an independent context snapshot data unit. The system uses a columnar storage format as the storage medium and writes all generated context snapshot data to one or more data tables on an offline big data platform. This offline data table typically employs a secondary partitioning strategy based on transaction date and user identifier to optimize subsequent query performance.

[0025] Step 103: Load the preset format file from the asset storage area of ​​the distributed file system, deserialize the preset format file to obtain a rule engine object and a model object, encapsulate the rule engine object and the model object into a custom function of the distributed computing framework, and dynamically register the custom function with the distributed computing cluster.

[0026] In this embodiment, deserialization is the reverse process of serialization, which converts a stored or transmitted file in a specific format back into a data structure or object in memory. A rule engine object refers to a software object instantiated in memory that can execute specific business rule logic. A model object refers to a trained machine learning model instance loaded in memory, capable of predictive inference. A distributed computing framework is a software framework for writing and running applications capable of handling massive amounts of data; it automatically handles task scheduling, fault tolerance, and resource management on computer clusters. Custom functions are an extension mechanism provided by the distributed computing framework, allowing users to write custom business logic code that can be executed in parallel within the cluster. A distributed computing cluster is a collection of multiple computers connected via a network, collaborating to complete large-scale computing tasks.

[0027] When initiating the evaluation computation task, the system first locates and loads the latest preset format configuration file from the asset storage area of ​​the distributed file system. The system then calls the deserialization component to parse the contents of this JSON configuration file and, based on the rule description language and model parameters defined within, reconstructs in memory rule engine objects and machine learning model objects that are completely consistent with the production environment logic. The system then encapsulates these instantiated rule engine and model objects into User-Defined Functions (UDFs) conforming to the distributed computing framework specification. This encapsulation process ensures that the UDFs' input / output interfaces are compatible with the framework. Subsequently, the system dynamically registers these newly created UDFs with the cluster manager in the Driver program of the distributed computing cluster, enabling all Executor nodes in the cluster to recognize and call these functions without restarting the entire Spark job.

[0028] Step 104: Based on the context snapshot in the offline data table, call the custom function to execute decision logic on the context snapshot and generate an evaluation result.

[0029] In this embodiment, decision logic refers to the computational process of applying a series of predefined rules and models based on the input context information, ultimately outputting a risk decision result. The evaluation result is the output generated after invoking the decision logic, and typically includes information such as the risk decision label, risk score, and list of triggered rules for each transaction.

[0030] The system launches a computation job on a distributed computing cluster. The core of this job is to process context snapshot data from offline data tables. The Executor node of the computation job reads the partitioned context snapshot data from storage. For each context snapshot record, the Executor calls a previously registered custom function. Inside the custom function, the system takes the context snapshot as input and passes it to the loaded rule engine object and model object. The rule engine object executes the configured rule set, and the model object performs feature calculation and predictive inference. The two work together to simulate the real-time decision-making process in a production environment. The system collects the output of all context snapshots after processing by the decision logic, including decision actions, risk scores, rule hit details, etc., and summarizes these results into a structured evaluation result dataset.

[0031] Step 105: Calculate evaluation indicators for multiple dimensions based on the evaluation results, generate a comprehensive score based on the evaluation indicators, and output the evaluation results and the comprehensive score to the control layer for display.

[0032] In this embodiment, the evaluation metrics are quantitative standards for measuring the performance of decision-making assets from different perspectives, such as decision change rate, false positive rate, false negative rate, latency, and stability. The comprehensive score is a single value calculated by weighted aggregation of multiple evaluation metrics, used to comprehensively evaluate the quality of the decision-making asset. The control layer is a software platform or interface that provides system monitoring, task management, and result visualization.

[0033] The system performs statistical analysis on the generated evaluation result dataset. Based on predefined formulas, the system calculates multiple evaluation indicators across various dimensions, such as decision change rate, false alarm rate, feature calculation fidelity, and processing latency. Following a pre-defined weighting model, the system weights and sums the calculated evaluation indicators to generate a comprehensive score. This comprehensive score provides an overall quantitative evaluation of the performance of the decision-making assets. The system persistently stores detailed evaluation result data, values ​​of each evaluation indicator, and the final comprehensive score in a database or file. Simultaneously, the system sends this result data to the visualization module at the management level via an application programming interface (API) or push notification. Upon receiving the data, the management level displays it in charts and tables on a web interface or in reports for risk strategy personnel to analyze and make decisions.

[0034] This application embodiment utilizes a distributed computing framework to process full historical transaction context snapshots, achieving efficient processing on a data scale of hundreds of billions while ensuring the fidelity of time sequence logic. It also automatically outputs multi-dimensional evaluation indicators and comprehensive scores, providing zero business risk, low cost, and high reliability data support for strategy iteration. This effectively solves the core defects of traditional solutions in terms of asset synchronization lag, limited evaluation scale, and poor result fidelity.

[0035] Optionally, step 101 includes: Step 1011: Deploy an event listener in the production configuration center. When a page configuration release operation occurs in the production configuration center, capture the configuration change event through the event listener. The configuration change event includes configuration identifier, version number and timestamp information.

[0036] In this embodiment, the production configuration center is a software system for centrally managing and publishing configurations related to risk decisions. An event listener is a program component deployed within the production configuration center to monitor the occurrence of specific operations within the system. A page configuration publishing operation refers to the process by which a user modifies configurations through a graphical interface and executes the publishing, making the new configuration effective in the production environment. A configuration change event is a data structure generated by the event listener after capturing a page configuration publishing operation, used to record key information about this change.

[0037] The system deploys an event listener component within the production configuration center. This listener continuously monitors the operation logs or internal event bus of the production configuration center. When a user modifies risk policies, rules, or model parameters through the graphical interface and executes a release operation, the event listener immediately captures this operation. Subsequently, the event listener generates a configuration change event object, which contains a unique identifier of the configuration involved in this release, the version number of the new version, and the timestamp of the release operation.

[0038] Step 1012: The configuration change event is sent to a designated topic in the message queue. The asset synchronization service subscribes to the designated topic and, upon receiving the configuration change event, initiates a configuration retrieval request to the production configuration center through the application programming interface based on the configuration identifier and the version number.

[0039] In this embodiment, a message queue is a middleware system that supports asynchronous communication, used to transfer messages between different services or applications. A designated topic is a logical channel within the message queue used to categorize messages; producers send messages to specific topics, and consumers subscribe to those topics to receive messages. The asset synchronization service is an independently running background service specifically responsible for synchronizing configuration data from the production environment to an offline big data platform. The application programming interface (API) is a set of predefined functions or protocols that allow the asset synchronization service to programmatically request data from the production configuration center.

[0040] The system sends the configuration change event generated in step 1011 as a message to a specific topic in a predefined message queue. The asset synchronization service, as a subscriber to this topic, continuously listens for new messages. Upon receiving this configuration change event message containing the configuration identifier and version number, the asset synchronization service immediately initiates a request to the production configuration center to retrieve the specific configuration content by calling the application programming interface provided by the production configuration center, based on the configuration identifier and version number in the message.

[0041] Step 1013: Receive asset configuration data returned by the production configuration center. The asset configuration data is structured text format data, which includes rule expression text, model weight parameters, and feature calculation formulas.

[0042] In this embodiment, asset allocation data refers to the specific configuration content obtained from the production configuration center for risk decision-making. Structured text format data is text data organized according to specific grammatical rules and easily parsed by machines, such as JSON or XML format. Rule expression text is risk judgment logic written in a domain-specific language. Model weight parameters are a set of numerical parameters within a machine learning model that determine its predictive behavior. Feature calculation formulas are mathematical or logical expressions used to calculate risk feature values ​​from raw data.

[0043] After receiving a configuration retrieval request from the asset synchronization service via the application programming interface, the production configuration center retrieves the corresponding complete configuration content based on the configuration identifier and version number in the request. The system receives a response from the production configuration center, which contains the asset configuration data. This data is organized in a structured text format, explicitly including the logical description of risk rules, the weight parameter values ​​of the machine learning model, and the specific formula definitions used to calculate risk characteristics.

[0044] Step 1014: Calculate the integrity verification value of the asset configuration data, compare the integrity verification value with the source verification value provided by the production configuration center, and if the comparison results are consistent, serialize the asset configuration data into the preset format file, construct a storage path according to the asset type, version number and synchronization timestamp, and write the preset format file into the asset storage area of ​​the distributed file system.

[0045] In this embodiment, the integrity check value is a fixed-length unique string calculated by applying a specific hash algorithm to the data content, used to verify whether the data has been tampered with or damaged during transmission or storage. The source check value is the integrity check value calculated and provided by the data provider for the original data. The preset format file refers to the standard file format agreed upon by the offline big data platform for storing asset configurations. The asset storage area of ​​the distributed file system is a storage directory in the offline big data platform specifically used to store various configuration files synchronized from the production environment.

[0046] The system applies a hash algorithm to the complete content of the received asset configuration data to calculate an integrity check value. Simultaneously, the system retrieves the source check value of the configuration data from the metadata provided by the production configuration center. The system compares the calculated integrity check value with the source check value. If the two values ​​match exactly, the asset configuration data is confirmed to be complete and error-free during transmission. The system serializes this structured text data and saves it as a preset format file agreed upon by the offline platform. Based on the asset type, version number, and timestamp of this synchronization, the system generates a unique storage path according to predefined rules. The system writes the generated preset format file to the corresponding path in the asset storage area specified in the distributed file system.

[0047] This application embodiment ensures timely synchronization through event-driven triggering and message queue decoupling; guarantees the accuracy of data acquisition through API retrieval; eliminates the risk of data inconsistency through integrity verification mechanism; and finally stores the configuration in a versioned and structured manner on a distributed file system, providing an accurate and reliable asset foundation for subsequent large-scale, high-fidelity risk decision assessment in an offline environment that is completely consistent with the production environment.

[0048] Optionally, step 102 includes: Step 1021: Filter historical transaction data to be evaluated from the data warehouse according to time range. The historical transaction data includes transaction identifier, user identifier, transaction timestamp, transaction amount, transaction channel, and account snapshot information at the time of the transaction.

[0049] In this embodiment, a data warehouse is a system for centrally storing and managing structured historical data from different data sources to support analytical reporting and decision-making. A time range refers to a specific period of time defined by a start time and an end time. Historical transaction data refers to a collection of transaction-related information that has occurred and been recorded within a certain past period. A transaction identifier is a string or number that uniquely identifies a specific transaction. A user identifier is a string or number that uniquely identifies a user. A transaction timestamp is a numerical value that records the specific date and time a transaction occurred. The transaction amount is the monetary value involved in the transaction. The transaction channel refers to the method or platform used by the user to complete the transaction, such as a mobile application, a web page, or a physical store. Account snapshot information refers to the instantaneous record of the user account status associated with the transaction at the moment the transaction occurred.

[0050] The system reads data from the data warehouse. Based on preset evaluation requirements, the system determines a specific time range as a filtering condition. The system performs data query operations in the data warehouse, using this time range as the filtering condition, to select all transaction records whose timestamps fall within this time range from the database tables storing transaction records. These selected records constitute the historical transaction dataset to be evaluated, where each record contains fields such as transaction identifier, user identifier, transaction timestamp, transaction amount, transaction channel, and account snapshot information at the time the transaction occurred.

[0051] Step 1022: For each historical transaction data, collect the complete context information required for the decision-making moment from multiple data sources. The complete context information includes account balance, account registration duration, historical transaction frequency, device fingerprint identifier, number of historically associated accounts of the device, and behavioral sequence characteristics within a preset time window.

[0052] In this embodiment, the data source refers to a storage system or service that provides raw data, such as a user database, device information database, or behavior log system. The decision moment refers to the specific point in time when the risk decision-making system assesses and judges the risk of a transaction. Complete context information refers to the complete set of relevant data that the decision engine needs to refer to for accurate judgment when making risk decisions. Account balance refers to the amount of funds available in a user's account at the time of the transaction. Account registration duration refers to the length of time elapsed from the creation of the user account to the time of the transaction. Historical transaction frequency refers to the number of times a user has conducted transactions within a specific historical time period. Device fingerprint identifier refers to a string generated by collecting device hardware and software characteristics to uniquely identify a user's device. Number of historically associated accounts for a device refers to the number of different user accounts that the device fingerprint has been associated with historically. Preset time window refers to a predefined fixed time period for statistical analysis. Behavioral sequence characteristics refer to a quantitative representation of a series of user actions performed in chronological order within the preset time window.

[0053] The system iterates through each filtered historical transaction record. For each transaction record, the system initiates data query requests to multiple different data sources based on its transaction identifier, user identifier, transaction timestamp, and other information. The system collects the account balance and account registration duration at the time of the transaction from the user account database. The system calculates the frequency of the user's historical transactions within a specific time period before the transaction from the transaction history database. The system collects the device fingerprint identifier of the device that initiated the transaction from the device fingerprint service and queries the total number of accounts historically associated with that device. The system extracts all operation logs of the user within a preset time window before the transaction from the user behavior log system and calculates a behavioral sequence feature vector. The system summarizes all collected information to form the complete set of contextual information required for the decision-making process of this transaction.

[0054] Step 1023: The collected complete context information is structured and organized to form a context snapshot record in key-value pair format. The context snapshot record retains all fields of the original transaction data and attaches a serialized representation of the complete context information.

[0055] In this application embodiment, structured organization refers to arranging and combining data according to predetermined formats and rules, giving it a clear hierarchy and relationships. Key-value pair format is a data representation where each data item consists of a unique key and a corresponding value. A context snapshot record refers to a complete data record formed by packaging a transaction and all its associated context information. A field is a basic data unit in a data record, used to store a specific type of information. Serialization representation refers to the process of converting a data structure or object state into a format that can be stored or transmitted.

[0056] The system formats the complete context information collected for each transaction. First, it creates a new data structure, preserving all fields of the original historical transaction data (such as transaction identifier, amount, timestamp, etc.). Then, it serializes the collected complete context information (such as account balance, device fingerprint, etc.), for example, by converting it into a JSON string. Finally, the system uses this serialized string as a new, additional field, combining it with the original transaction fields to form a record in a unified key-value pair format. This newly generated record is the context snapshot record for that transaction.

[0057] Step 1024: The context snapshot record is partitioned into two levels, and the partitioned context snapshot record is written into the offline data table using a columnar storage format.

[0058] In this embodiment, two-level partitioning is a data management technique that refers to the physical division and organization of data according to two levels of partition keys. Columnar storage format is a data storage method that organizes and compresses data by column rather than by row, suitable for analytical queries. Offline data tables refer to structured data tables created in an offline big data platform for storing batch processing data.

[0059] The system partitions all generated context snapshot records. First, it partitions by transaction date, grouping data from the same day into the same directory. Then, within each date partition, it partitions by user identifier, grouping data from the same user together. After partitioning, the system uses a columnar storage format to write all partitioned context snapshot records to a designated table on the offline big data platform. This table is specifically used to store this structured snapshot data for efficient retrieval by subsequent batch evaluation tasks.

[0060] The embodiments of this application can accurately filter target data from massive historical data and efficiently and completely reconstruct the panoramic information of each transaction decision, forming a structured snapshot. Through two-level partitioning and columnar storage technology, the system persists these snapshot data in a highly optimized manner, thereby establishing a data foundation with high fidelity, high query efficiency, and strong scalability for subsequent offline risk assessment. This ensures that the assessment process can be based on complete contextual information consistent with the production environment, guaranteeing the accuracy and reliability of the assessment results.

[0061] Optionally, step 103 includes: Step 1031: When the distributed computing task starts, read the latest version of the preset format file from the asset storage area of ​​the distributed file system. The preset format file contains a rule configuration section, a model configuration section, and a feature configuration section.

[0062] In this embodiment, a distributed computing task refers to a computing job running on a cluster of multiple computers, used for parallel processing of large-scale data. A distributed file system is a file system that allows data to be stored and accessed on multiple computers, providing high fault tolerance and high throughput. An asset storage area is a logical partition in a distributed file system specifically used to store specific data. A preset format file is a data file with predefined structure and syntax rules, used to store configuration information.

[0063] When the system initiates a distributed computing task, it sends a read request to the distributed file system. The target path of this request points to a pre-formatted file identified as the latest version within the asset storage area. The system reads the entire contents of this file into memory to prepare data for subsequent parsing operations. The file contents are identified by the system as containing three logical segments: rule configuration, model configuration, and feature configuration.

[0064] Step 1032: Invoke the deserializer corresponding to the preset format file to parse the rule configuration segment into a rule object that can be executed by the rule engine. The rule object contains conditional expressions and action definitions. Parse the model configuration segment into a model object that can be loaded by the machine learning framework. The model object contains model structure and model weight parameters.

[0065] In this application embodiment, a deserialization parser is a computer program component whose function is to convert data read from a storage medium and encoded in a specific format back into the original data structure or object in computer memory. A rule engine is a software system used to execute business rules, which are typically expressed in an "if-then" form. A rule object is a data structure in memory that a rule engine uses to represent and manipulate one or more rules. A machine learning framework is a software environment that provides the tools and libraries needed to build, train, and deploy machine learning models. A model object is a data structure in memory that a machine learning framework uses to represent a specific machine learning model, containing the model's computation graph, layer definitions, and parameters.

[0066] The system calls the matching deserializer based on the type of the preset format file. This parser first processes the rule configuration section, parsing the text-based conditional expressions and action definitions according to predefined syntax rules and constructing rule objects that the rule engine can directly load and execute. Next, the parser processes the model configuration section, parsing the model structure description and weight parameter data according to the model framework requirements and constructing model objects that the machine learning framework can directly load and run.

[0067] Step 1033: Create a custom function encapsulation class for the distributed computing framework, and inject the rule object and the model object into the internal execution logic of the custom function encapsulation class so that the custom function encapsulation class provides a unified evaluation interface to the outside world.

[0068] In this embodiment, the distributed computing framework is a software framework used to simplify the process of developing and running distributed data processing programs on computer clusters. A custom function encapsulation class is a class written by the developer based on specific business logic, inheriting or implementing a specific interface of the distributed computing framework, used to extend the framework's native functionality. The evaluation interface refers to the method signature exposed by the custom function that can be called by the distributed computing framework, used to receive input data and return processing results.

[0069] The system instantiates a custom function encapsulation class. During the initialization of this class, the generated rule object and model object are injected as dependencies into the class's internal member variables. The system implements the specific execution logic within this class, which calls the injected rule object to perform rule judgments and the injected model object to perform prediction calculations. Finally, this class provides a unified function call interface that accepts a single transaction or a batch of transaction data as input and returns the risk assessment result after processing by the rules and model.

[0070] Step 1034: Using the reflection mechanism of the distributed computing framework, the custom function encapsulation class is registered in the function registry of all execution nodes in the distributed computing cluster. After registration, a preset smoke test case is executed to verify the availability and correctness of the custom function encapsulation class.

[0071] In this embodiment, reflection is a capability provided by programming languages, allowing programs to inspect, invoke, or modify their own structure and behavior at runtime. A distributed computing cluster is a collection of interconnected computing nodes that jointly execute computing tasks. An execution node is the computer in the cluster that actually runs the computing task process. A function registry is a data structure maintained by the distributed computing framework on each execution node, used to record the mapping relationship between all available function names and their implementation classes. Smoke test cases are a set of simple and rapid tests used to verify whether the basic functions of the system are working correctly.

[0072] The system utilizes the reflection mechanism provided by the distributed computing framework to obtain information about the encapsulated class of the created custom function. Through the framework's API, the system registers the custom function with the function registry of all execution nodes in the cluster, assigning it a unique function name. After registration, the system automatically executes pre-written smoke test cases, which use test data to call the newly registered function. The system verifies whether the function call is successful and whether the output meets expectations, thereby confirming the usability and logical correctness of the custom function.

[0073] This application embodiment ensures that the decision logic used in the offline evaluation environment is synchronized with the production environment within minutes, eliminating evaluation distortion caused by inconsistent asset versions. By encapsulating assets as distributed custom functions and registering them to the cluster, it achieves efficient, parallel, and high-fidelity batch risk evaluation of massive historical transaction data, supports rapid verification of data scales of hundreds of billions, and the entire process does not require restarting the computing task, thus improving evaluation efficiency and flexibility.

[0074] Optionally, step 104 includes: Step 1041: Read the context snapshots in batches from the offline data table according to the partition order, and distribute the context snapshots to multiple execution nodes for parallel processing through a distributed computing framework.

[0075] In this embodiment, an offline data table refers to a collection of historical transaction data stored in an offline big data platform for evaluation. The data is organized in a structured form and typically physically partitioned based on a specific partition key. A context snapshot refers to a structured data record captured and stored at the moment of a transaction decision, containing all the information needed for risk decision-making, such as account status, device fingerprints, and time-series characteristics. Partition order refers to the logical order of data reading according to the predefined partition keys of the data table. A distributed computing framework refers to a software framework used for parallel processing of large-scale datasets on a computer cluster. An execution node refers to a physical or logical computing unit in a distributed computing cluster that actually performs the computing tasks.

[0076] The system first reads context snapshot data of specified partitions sequentially from offline data tables according to a predefined data partitioning strategy. Then, the system calls the job scheduler of the distributed computing framework to divide the read batch of context snapshot data into multiple data shards based on principles such as data locality. These data shards are distributed to different execution nodes in the cluster, with each execution node responsible for processing its assigned portion of the context snapshot data, thereby achieving parallel data processing and improving overall processing throughput.

[0077] Step 1042: On each execution node, obtain a locally cached custom function instance. The custom function instance is loaded from the asset storage area of ​​the distributed file system and deserialized to obtain a rule engine object and a model object.

[0078] In this embodiment, an execution node refers to a physical or logical computing unit in a distributed computing cluster that actually performs computing tasks. A local cache refers to a high-speed storage area located in the execution node's memory or local disk, used to temporarily store frequently accessed data or objects to reduce remote access latency. A custom function instance refers to a running instance of an executable code unit defined and encapsulated by a user within the distributed computing framework, containing specific business logic. The asset storage area of ​​the distributed file system refers to a dedicated storage directory opened on the distributed file system, used to store serialized policy rules and model asset files synchronized from the production environment. Deserialization refers to the process of converting a serialized data stream in a specific format stored in the file system back into an object in memory that can be directly called by the program.

[0079] When each execution node starts a computation task, the system first checks its local cache for a valid, available custom function instance. If it doesn't exist or the cache is expired, the system reads the latest serialized asset file from a specified asset storage path in the distributed file system. Next, the system uses predefined deserialization logic to parse and reconstruct these file contents into in-memory rule engine objects and machine learning model objects. Finally, the system injects these initialized objects into a custom function instance and caches this instance locally on the execution node for subsequent repeated calls, avoiding reloading assets for each computation.

[0080] Step 1043: Pass the context snapshot as an input parameter to the custom function instance. The custom function instance then sequentially calls the rule engine object to match the rule conditions and calls the model object to predict and calculate the input features to obtain the risk decision result.

[0081] In this embodiment, input parameters refer to data passed to a function or method for processing. A custom function instance refers to a running instance of an executable code unit defined by the user and encapsulating specific business logic within a distributed computing framework. A rule engine object refers to a software component instance encapsulating rule matching logic, capable of executing a series of predefined business rules based on input factual data. Rule conditions refer to logical expressions or Boolean conditions defined in the risk strategy for determining whether a transaction is risky. A model object refers to a software component instance encapsulating a machine learning prediction algorithm, capable of outputting prediction results based on the input feature vector. Input features refer to a set of numerical or categorical variables that, after preprocessing, are used as model input. The risk decision result refers to the final risk assessment conclusion given for the current transaction after comprehensive judgment by rules and the model.

[0082] The system passes each context snapshot record assigned to the current execution node as input to the loaded custom function instance. Internally, this custom function instance executes according to a predefined decision-making process: First, it calls its held rule engine object to convert the data in the context snapshot into facts recognizable by the rule engine, then drives the rule engine to match and evaluate all loaded rule conditions. Next, based on the rule engine's output, it may need to further call its held model object. The system inputs the feature vectors extracted or calculated from the context snapshot into the model object for forward inference calculations to obtain a predicted score or category. Finally, the custom function instance combines the rule matching results and model prediction results to generate a final risk decision result according to predefined decision logic.

[0083] Step 1044: Record the rule node identifiers, model node identifiers, and intermediate calculation results of each node during the generation of the risk decision result. Then, encapsulate the risk decision result and the intermediate calculation results in a structured manner according to the decision path format to form the evaluation result.

[0084] In this embodiment, the risk decision result refers to the final risk assessment conclusion given for the current transaction after comprehensive judgment by rules and models. The generation process refers to a series of calculation and logical judgment steps performed internally by the system from the input context snapshot to the output final decision result. The rule node identifier refers to the code or name that uniquely identifies a triggered or evaluated business rule in the decision path. The model node identifier refers to the code or name that uniquely identifies a invoked machine learning model in the decision path. Intermediate calculation results refer to the stage results output by each rule node and model node before the final decision result is generated, such as the matching status of a rule, the matched rule ID, and the original prediction score output by the model. The decision path format refers to a predefined structured data format used to systematically organize and record all aspects and results involved in a decision. Structured encapsulation refers to the process of combining multiple data fields into a complete data record according to a specific data pattern or protocol. The evaluation result refers to a complete output record containing the final decision and its detailed decision path information, used for subsequent analysis and evaluation.

[0085] While generating risk decision results through custom function instances, the system simultaneously tracks and records key information throughout the entire computational pipeline. This includes recording the unique identifier of each triggered or executed rule, the unique identifier of the invoked model, and their respective intermediate computation results. Subsequently, the system assembles and encapsulates this discrete recorded information according to a pre-designed decision path data structure. The system outputs a structured evaluation result record, which not only contains the final risk decision result but also fully includes the details of the decision chain leading to that result, providing a complete data foundation for subsequent decision analysis, effect evaluation, and root cause identification.

[0086] This application embodiment ensures that the rules and model assets used in the evaluation are synchronized and completely consistent with the production environment in real time through the UDF hot loading mechanism. It also reproduces the decision logic execution process that is exactly the same as that in the production environment on the distributed nodes, ensuring the time-series fidelity and accuracy of the evaluation results. Furthermore, it generates decision path information rich in detail, supporting in-depth evaluation analysis and automated root cause localization.

[0087] Optionally, step 1042 includes: Step 10421: When the execution node starts, a connection is established with the distributed file system, the preset format file is read from the asset storage area, and the preset format file is deserialized into a rule engine object and a model object, which are then stored in the local memory cache of the execution node.

[0088] In this embodiment, the execution node is a process or container instance within a distributed computing framework responsible for executing specific computing tasks. A distributed file system is a software system that stores file data across multiple physical servers and provides a unified access interface over a network. An asset storage area is a directory or partition within the distributed file system specifically used to store decision assets. A preset format file is a file that serializes and stores decision asset configurations according to a specific structure. A rule engine object is a program object in computer memory that executes rule logic, generated by deserializing a preset format file. A model object is a machine learning model program object in computer memory that executes prediction or classification tasks, generated by deserializing a preset format file. A local memory cache is a memory area allocated within the execution node process for temporarily storing frequently accessed data to reduce external I / O overhead.

[0089] During the startup process of the execution node, the system invokes the network connection module to establish a communication connection with the specified distributed file system. After establishing the connection, the system locates the asset storage area according to a predefined path and reads the preset format files stored in that area. The system then invokes the deserialization module to parse and reconstruct the file content into rule engine objects and model objects in memory, according to the definition of the preset format files. Finally, the system stores these initialized objects in the local memory cache of the execution node process for direct use in subsequent risk decision calculations.

[0090] Step 10422: Set a version identifier field in the local memory cache of the execution node, periodically check the version update status of the preset format files in the asset storage area, and when a version update is detected, reload the preset format files from the asset storage area and update the rule engine object and model object in the local memory cache area. The detection period for the version update status is a preset time interval.

[0091] In this embodiment, the version identifier field is a data item stored in the local memory cache, used to record the asset version information corresponding to the current cached object. Version update status refers to the version status of the preset format file in the asset storage area relative to the object in the local memory cache. The preset time interval is a fixed duration parameter configured by the system, used to control the frequency of version checks.

[0092] When storing rule engine objects and model objects in the local memory cache, the system simultaneously sets a version identifier field to record their version information. The system starts a background scheduled task that runs periodically at preset time intervals. Each time this scheduled task is triggered, it reconnects to the distributed file system, checks the metadata of the preset format files in the asset storage area, and compares it with the information recorded in the version identifier field of the local memory cache. When the system detects an update in the file version in the asset storage area, it triggers the asset update process. The system rereads the latest preset format file from the asset storage area, performs deserialization again to generate new rule engine objects and model objects, replaces the old objects in the local memory cache with these new objects, and updates the version identifier field.

[0093] Step 10423: After updating the rule engine object and model object in the local memory cache, perform availability verification on the updated rule engine object and model object. If the availability verification passes, switch the subsequent context snapshot to the updated rule engine object and model object for processing.

[0094] In this embodiment, availability verification is a series of tests to check whether the updated rule engine object and model object can function correctly, such as checking configuration syntax, model loading integrity, and performing simple inference. A context snapshot is a data record that stores all relevant state information at the moment of a transaction decision.

[0095] After updating objects in the local memory cache, the system does not immediately use the new objects to process business data. First, the system calls the validation module to perform availability validation on the updated rule engine and model objects. The validation module uses a set of predefined test cases or simulated data to drive these objects, checking whether their logic execution throws exceptions and whether the output conforms to the expected format. If the validation module returns a successful validation result, the system performs a switching operation, routing subsequent context snapshot data from the data source that requires risk decision assessment to the updated rule engine and model objects for processing. If validation fails, the system continues to use the old, validated, and usable objects to process data and logs errors.

[0096] This application embodiment can quickly initialize assets when the execution node starts. Through a periodic polling mechanism, it ensures that the assets used in the offline environment are synchronized with the production environment within minutes, effectively solving the problems of asset version lag and mismatch. Furthermore, through the updated availability verification and secure switching mechanism, it ensures the stability of the evaluation process and the credibility of the results, enabling the offline evaluation to truly reflect the effect of the latest production strategy on the full historical data. This achieves transaction risk decision evaluation with zero business risk, high efficiency, and high fidelity.

[0097] Optionally, step 105 includes: Step 1051: Extract risk decision results from the assessment results, compare the risk decision results with preset real result labels, and calculate the decision consistency rate index through a distributed aggregation function.

[0098] In this embodiment, the risk decision result refers to the judgment conclusion output by the offline big data platform regarding the existence of risk in each transaction after executing risk strategies, rules, or models synchronized from the production environment and calculating historical transaction data. The true result label refers to a pre-defined, verified label representing the true risk status of each historical transaction, such as a "normal transaction" or "fraudulent transaction" label derived from post-event manual review or long-term business verification, serving as a benchmark for evaluating the accuracy of the offline decision result. The decision consistency rate index is a numerical indicator used for quantitative evaluation, calculated as the percentage of historical transactions whose risk decision results output by the offline system are consistent with the pre-defined true result labels, out of the total number of historical transactions evaluated.

[0099] The system extracts the risk decision result field, calculated by a custom function, from the dataset generated during the evaluation process. The system then compares each extracted risk decision result with the pre-stored true result label field in the dataset. By calling aggregation functions provided by the distributed computing framework, the system counts the number of transactions whose decision results match the true labels in parallel across the cluster, and calculates this number with the total number of transactions to arrive at a decision consistency rate metric. This metric reflects the degree to which the offline evaluation system's decision logic aligns with the expected or historical facts of the production environment.

[0100] Step 1052: Extract case detection identifiers from the risk decision results from the assessment results, compare the case detection identifiers with preset real case labels, and calculate the fraud detection rate index through a distributed aggregation function.

[0101] In this embodiment, the case detection identifier refers to a marker in the risk decision result specifically used to identify whether a transaction has been determined by the system to be a "case" requiring key attention or handling. For example, when the decision result is "reject" or "requires manual review," the corresponding case detection identifier may be set to "true" or "1," indicating that the transaction has been detected by the system as a potential risk case. The real case label refers to a label pre-marked on historical transaction data, representing whether it is indeed a real risk case requiring handling, serving as a benchmark for evaluating the accuracy of the system's case detection. The fraud detection rate indicator is a numerical indicator used for quantitative evaluation, calculated as the percentage of real fraud cases correctly detected by the offline system out of the total number of real fraud cases. This indicator focuses on measuring the system's ability to capture high-risk events.

[0102] The system further analyzes the risk decision results from the evaluation results, extracting a specific identifier field indicating whether a case has been detected. The system then compares this case detection identifier with pre-stored real case tags in the dataset. Using a distributed aggregation function, the system counts the number of transactions where both the case detection identifier and the real case tag are "true," and then calculates this number against the total number of transactions with a "true" real case tag, ultimately yielding a fraud detection rate metric. This metric is specifically used to evaluate the system's sensitivity in identifying high-risk factors such as fraud.

[0103] Step 1053: Collect processing delay data from each execution node when executing the custom function in the distributed computing framework, and calculate the quantile of the processing delay data through a distributed aggregation function to obtain the processing delay quantile index.

[0104] In this embodiment, the distributed computing framework refers to a software framework used for large-scale parallel data processing, specifically Spark in this invention. It consists of a master node and multiple execution nodes, working together to complete the computational tasks. An execution node is a worker process or container in the distributed computing framework that actually executes the computational tasks, responsible for running the computational logic on its assigned data shard. Processing latency data refers to the time spent executing the custom function encapsulating the risk strategy or model on each execution node, typically in milliseconds, reflecting the time consumed by a single decision call. The processing latency quantile index refers to the quantile value obtained by statistically calculating all collected processing latency data.

[0105] During the execution of distributed computing tasks, the system collects performance tracking data recorded by each execution node when executing custom functions, i.e., the latency required to process each transaction. The system aggregates the processing latency data reported by all execution nodes. The system then calculates the quantiles of the full processing latency data using a distributed aggregation function. The resulting processing latency quantile index reflects the execution efficiency of the evaluation task in a distributed environment; a higher quantile indicates better stability of the system's processing capacity and fewer extremely slow requests.

[0106] Step 1054: Based on the decision consistency rate index, the fraud detection rate index, and the processing delay quantile index, perform a weighted summation according to preset weight coefficients to generate the comprehensive score, and display the evaluation results, the comprehensive score, and the indicators of each dimension through a visualization interface.

[0107] In this embodiment, the weighting coefficient refers to the pre-assigned proportional value to each evaluation indicator based on its business importance, used to reflect the relative importance of different indicators in the comprehensive score calculation. The comprehensive score is a single value obtained through weighted calculation, comprehensively reflecting the overall performance of the offline evaluation system across multiple dimensions such as accuracy, risk capture capability, and performance efficiency. The visualization interface refers to a graphical user interface used to display the evaluation results, comprehensive score, and indicators of each dimension in intuitive forms such as charts and dashboards, facilitating user understanding and analysis.

[0108] The system calculates a comprehensive score by weighting and summing the decision consistency rate obtained in step 1051, the fraud detection rate obtained in step 1052, and the processing delay quantile obtained in step 1053, based on preset weighting coefficients. The system then displays the detailed evaluation results, the calculated comprehensive score, and the indicator values ​​for each dimension on a visual interface by calling front-end services or reporting tools. The display format may include score cards, trend charts, detailed tables, etc., thus completing a full closed loop from data calculation to conclusion presentation.

[0109] This application's embodiments utilize parallel computing to efficiently calculate decision consistency rate and fraud detection rate, assessing asset effectiveness from a business accuracy perspective. By collecting distributed performance data and calculating latency quantiles, it evaluates system performance from an execution efficiency perspective. Through weighted fusion, it generates a comprehensive score and visualizes it, providing technical decision-makers with a comprehensive, objective, and efficient evaluation conclusion. This supports their ability to quickly determine the quality of risk-determining assets and the feasibility of online deployment, thereby significantly improving the efficiency of strategy iteration and the scientific nature of decision-making under the premise of zero business risk.

[0110] Optionally, refer to Figure 2The transaction risk decision-making assessment system provided in this application includes: an asset synchronization layer, a data layer, a calculation layer, an assessment layer, and a control layer. Data exchange between these layers occurs through standard interfaces, achieving a loosely coupled and highly cohesive system design.

[0111] The asset synchronization layer is responsible for synchronizing the production environment's strategies, models, and other decision-making assets to the offline big data platform in real time, solving the problems of asset version lag and configuration mismatch in traditional solutions.

[0112] The asset synchronization layer uses the production configuration center as the source of page configuration publishing events, including the rule configuration interface and model management interface; it uses the Kafka asset change topic to implement an asynchronous message queue to carry configuration change events, achieving decoupling and peak shaving; it uses the configuration synchronization service to listen to Kafka messages, pull the complete configuration through the REST API, and serialize and store it in HDFS; and it uses the HDFS asset area to store the versioned policy configuration (JSON) and model files (ONNX / PMML).

[0113] The data layer is responsible for storing all the data required for the evaluation, including historical transaction records, decision logs, context snapshots, and pre-computed features, providing data support for the computing layer.

[0114] The data layer includes: transaction log tables, decision log tables, context snapshots, and feature libraries.

[0115] The computing layer is the system's computing engine, based on the Spark distributed computing framework, which enables parallel processing of large-scale data and dynamic loading and execution of decision assets.

[0116] The computer layer uses Spark Driver to implement the task scheduling center, which is responsible for SQL parsing, task planning, and global aggregation; it uses Executor clusters as distributed computing nodes to perform actual data processing and UDF calls; it uses the rule engine UDF to encapsulate the Drools rule engine, dynamically load JSON configurations to perform rule evaluation; and it uses model prediction UDFs to achieve this.

[0117] The evaluation layer is responsible for summarizing and analyzing the evaluation results, including aligning the old and new decision results, calculating indicators, performing root cause analysis, and generating reports, and outputting the final evaluation conclusions.

[0118] The evaluation layer uses a result alignment engine to obtain JOINs based on the txn_id primary key and compares the new and old decision results; it uses an indicator aggregator to obtain core indicators such as distributed computing accuracy, recall, and latency; it uses a root cause analyzer to automatically locate problem rules when indicators fail to meet the standards; and it uses a report generator to output evaluation reports in HTML / PDF / JSON formats.

[0119] The control layer provides system operation and maintenance management capabilities, including task lifecycle management, asset version control, and system monitoring and alarms, to ensure stable system operation.

[0120] The control layer provides a REST interface through the task management API, supporting the creation, start, stop, and query of evaluation tasks; it manages multiple versions of policies / models through asset version management, supporting version rollback and comparison; and it monitors the system's operating status in real time through monitoring and alarms, triggering alarms when anomalies occur.

[0121] Optionally, refer to Figure 3 The asset synchronization adaptation page configuration methods in this application include: Step 0: By listening to page configuration change events in the production configuration center, and combining REST API retrieval and Kafka message queue, the strategy / model configuration is synchronized to HDFS every minute, and JSON serialization storage and SHA256 verification are used to ensure consistency. Step 1: parse the evaluation task configuration, determine the evaluation time window, and specify the strategy / model asset version; Step 2: Scan the HDFS file list to determine data partitions. Partition pruning reduces data scanning by 98%, and column pruning reduces I / O overhead by 80%. Step 3: Calculate the proportion of features affected by configuration changes through characteristic lineage analysis; Step 3a calculates all 247 basic features, which is suitable for large-scale configuration change scenarios. It involves a large amount of computation but yields complete results. Step 3b involves recalculating only the affected features, while reusing unmodified features from the feature repository, reducing processing time by 60-80%. Step 4: Load the latest configuration from the HDFS asset area, deserialize it into a rule / model object, register it as a SparkUDF function, and update it without restarting the task, achieving the effect within minutes; Step 5: Perform a smoke test to verify the correctness of the UDF configuration syntax and logic; Step 5a: If the verification fails, the task will be terminated immediately, and a detailed error log will be returned. Retrying after configuration correction is supported. Step 6: Start mapPartitions for parallel processing, distribute tasks to 500 Executor nodes, optimize data locality by 90%, and reduce network transmission. Step 7: Use window functions to sort by timestamp, calculate features such as cumulative over the past N hours and sliding window, and the time series fidelity is >95%, consistent with production. Step 8: Call the rule engine UDF to perform rule evaluation, and call the model prediction UDF to perform ML inference, supporting models such as XGBoost / LSTM; Step 9: Based on the txn_id primary key LEFT JOIN, compare the new strategy with the historical production decision results, and optimize JOIN performance using Bloom Filter; Step 10: The Executor pre-calculates local metrics. Combiner mode reduces network transmission, reducing the amount of data transmitted by 95% compared to the original data. Step 11: The Driver summarizes the results from each Executor and calculates global precision, recall, and other metrics, aggregating in MapReduce mode; Step 12: Determine whether the evaluation indicators have reached the preset threshold; Step 12a: When the indicator fails to meet the standard, the problem rule is automatically triggered by differential sampling, and a list of the top 10 problem rules is output. The decision path comparison tree algorithm is used. Step 13: Generate an HTML / PDF / JSON report containing indicator data, visualization charts, root cause analysis results, and recommendations; Step 14: Delete temporary data during the evaluation process, release Executor computing resources, and implement an automated resource reclamation mechanism.

[0122] Optionally, refer to Figure 4 The implementation process of the asset synchronization technology in this application includes: Step S1: The production configuration center generates a change event; Step S2: Kafka asset Topic consumption configuration change message; Step S3: Configure the synchronization service subscription config-change-topic, the consumer group is sync-service-group, and deploy 3 instances; Step S4: Configure the synchronization service to pull the complete JSON configuration via REST API: GET / api / v1 / configs / {config_id}?version={version}; Step S5: The production configuration center returns a complete JSON configuration, including the rule DSL, model parameters, and feature definitions. Step S6: Configure the synchronization service to calculate the SHA256 hash value of the configuration JSON: SHA256(json.dumps(config_json, sort_keys=True)); Step S7, HDFS serialization storage; Step S8: Configure the synchronization service to read the file, recalculate the SHA256 hash, and compare it with the hash value of the source data; In step S9, if the Kafka asset topic verification passes, push the sync-confirm-topic; if it fails, push the sync-error-topic and trigger a retry. Step S10: Spark UDF configuration loading. When the evaluation task starts, the JSON configuration is loaded from HDFS and read as an InputStream. Step S11, Spark UDF deserialization registration; Step S12: Spark UDF change listener periodically checks the HDFS file mtime or listens for Kafka acknowledgment messages, automatically invalidates the cache and reloads it.

[0123] Optionally, refer to Figure 5 The historical data batch processing and evaluation mechanism in this application includes: a data preprocessing stage, an evaluation task execution stage, a parallel computing node stage, and a result aggregation stage.

[0124] The data and processing phase includes: generating real-time transaction data sources through Kafka log streams; collecting and aggregating logs through Flume; providing temporary storage through HDFS raw logs; generating snapshot jobs through Spark Streaming; and implementing columnar storage through Parquet snapshot files.

[0125] The evaluation of the task execution phase includes four optimization projects: partition pruning, column referencing, data sharding, and data locality.

[0126] The parallel computing node stage includes: distributed computing through Task Executor; obtaining user-level time-series features through local feature calculation; implementing rule and model inference through UDF calls; and aggregating local metrics through Combiner pre-aggregation.

[0127] The results aggregation phase includes: data aggregation through Driver Shuffle; comprehensive evaluation through global metric calculation; problem identification through root cause analysis; and output of results through report generation.

[0128] Based on the foregoing embodiments, this application provides an assessment device for transaction risk decision-making. The device includes various units and modules included in each unit, which can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0129] Figure 6 This is a schematic diagram of the composition structure of an assessment device for transaction risk decision-making provided in an embodiment of this application, as shown below. Figure 2 As shown, the assessment device 20 for transaction risk decision-making includes: Processing module 201 is used to listen for page configuration change events in the production configuration center, trigger asset synchronization service through message queue, pull asset configuration from the production configuration center, serialize the asset configuration into a preset format file and store it in the asset storage area of ​​the distributed file system; Historical transaction data is read from the data warehouse, the historical transaction data is converted into a context snapshot, and the context snapshot is stored in an offline data table in columnar storage format; The preset format file is loaded from the asset storage area of ​​the distributed file system, and the preset format file is deserialized to obtain a rule engine object and a model object. The rule engine object and the model object are encapsulated into custom functions of the distributed computing framework, and the custom functions are dynamically registered to the distributed computing cluster. Evaluation module 202 is used to call the custom function to perform decision logic on the context snapshot based on the context snapshot in the offline data table to generate evaluation results; Based on the evaluation results, multiple evaluation indicators are calculated, a comprehensive score is generated based on the evaluation indicators, and the evaluation results and the comprehensive score are output to the management and control layer for display.

[0130] Optionally, the processing module 201 is further configured to: An event listener is deployed in the production configuration center. When a page configuration release operation occurs in the production configuration center, the event listener captures the configuration change event, which includes configuration identifier, version number and timestamp information. The configuration change event is sent to a designated topic in the message queue. The asset synchronization service subscribes to the designated topic and, upon receiving the configuration change event, initiates a configuration retrieval request to the production configuration center through the application programming interface based on the configuration identifier and the version number. Receive asset configuration data returned by the production configuration center. The asset configuration data is structured text format data, which includes rule expression text, model weight parameters and feature calculation formulas. Calculate the integrity check value of the asset configuration data, compare the integrity check value with the source check value provided by the production configuration center, and if the comparison results are consistent, serialize the asset configuration data into the preset format file, construct a storage path according to the asset type, version number and synchronization timestamp, and write the preset format file into the asset storage area of ​​the distributed file system.

[0131] Optionally, the processing module 201 is further configured to: Historical transaction data to be evaluated is filtered from the data warehouse according to time range. The historical transaction data includes transaction identifier, user identifier, transaction timestamp, transaction amount, transaction channel, and account snapshot information at the time of the transaction. For each historical transaction data, complete contextual information required for the decision-making moment is collected from multiple data sources. The complete contextual information includes account balance, account registration duration, historical transaction frequency, device fingerprint identifier, number of historically associated accounts of the device, and behavioral sequence characteristics within a preset time window. The collected complete context information is structured and organized to form a context snapshot record in key-value pair format. The context snapshot record retains all fields of the original transaction data and appends a serialized representation of the complete context information. The context snapshot records are partitioned into two levels, and the partitioned context snapshot records are written to the offline data table using a columnar storage format.

[0132] Optionally, the processing module 201 is further configured to: When a distributed computing task starts, the latest version of a preset format file is read from the asset storage area of ​​the distributed file system. The preset format file contains a rule configuration section, a model configuration section, and a feature configuration section. The deserializer corresponding to the preset format file is invoked to parse the rule configuration segment into a rule object that can be executed by the rule engine. The rule object contains conditional expressions and action definitions. The model configuration segment is also parsed into a model object that can be loaded by the machine learning framework. The model object contains model structure and model weight parameters. Create a custom function encapsulation class for the distributed computing framework, inject the rule object and the model object into the internal execution logic of the custom function encapsulation class, so that the custom function encapsulation class provides a unified evaluation interface to the outside world; The custom function encapsulation class is registered to the function registry of all execution nodes in the distributed computing cluster using the reflection mechanism of the distributed computing framework. After registration, preset smoke test cases are executed to verify the availability and correctness of the custom function encapsulation class.

[0133] Optionally, the evaluation module 202 is further configured to: The context snapshots are read in batches from the offline data table according to the partition order, and the context snapshots are distributed to multiple execution nodes for parallel processing through a distributed computing framework. On each execution node, a custom function instance is retrieved from the local cache. The custom function instance is loaded from the asset storage area of ​​the distributed file system and deserialized to obtain a rule engine object and a model object. The context snapshot is passed as an input parameter to the custom function instance. The custom function instance then sequentially calls the rule engine object to match the rule conditions and calls the model object to predict and calculate the input features to obtain the risk decision result. Record the rule node identifiers, model node identifiers, and intermediate calculation results of each node during the generation of the risk decision result. Then, encapsulate the risk decision result and the intermediate calculation results in a structured manner according to the decision path format to form the evaluation result.

[0134] Optionally, the evaluation module 202 is further configured to: When the execution node starts, it establishes a connection with the distributed file system, reads the preset format file from the asset storage area, and deserializes the preset format file into a rule engine object and a model object, which are then stored in the local memory cache of the execution node. A version identifier field is set in the local memory cache of the execution node, and the version update status of the preset format file in the asset storage area is checked periodically. When a version update is detected, the preset format file is reloaded from the asset storage area and the rule engine object and model object in the local memory cache are updated. The detection period for the version update status is a preset time interval. After updating the rule engine object and model object in the local memory cache, an availability verification is performed on the updated rule engine object and model object. If the availability verification passes, subsequent context snapshots are switched to the updated rule engine object and model object for processing.

[0135] Optionally, the evaluation module 202 is further configured to: Risk decision results are extracted from the assessment results, and the risk decision results are compared with preset real result labels. The decision consistency rate index is calculated by using a distributed aggregation function. The case detection identifier is extracted from the risk decision results from the assessment results, and the case detection identifier is compared with the preset real case label. The fraud detection rate index is calculated by using a distributed aggregation function. Processing latency data is collected from each execution node when executing the custom function in the distributed computing framework. The processing latency data is then processed using a distributed aggregation function to calculate the quantiles and obtain the processing latency quantile index. The comprehensive score is generated by weighting and summing the decision consistency rate, fraud detection rate, and processing delay quantile index according to preset weight coefficients. The evaluation results, the comprehensive score, and the indicators of each dimension are then displayed through a visualization interface.

[0136] This application embodiment utilizes a distributed computing framework to process full historical transaction context snapshots, achieving efficient processing on a data scale of hundreds of billions while ensuring the fidelity of time sequence logic. It also automatically outputs multi-dimensional evaluation indicators and comprehensive scores, providing zero business risk, low cost, and high reliability data support for strategy iteration. This effectively solves the core defects of traditional solutions in terms of asset synchronization lag, limited evaluation scale, and poor result fidelity.

[0137] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0138] It should be noted that, in the embodiments of this application, if the above-mentioned transaction risk decision assessment method is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0139] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0140] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0141] This application provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0142] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0143] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0144] It should be noted that, Figure 7 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this application, such as... Figure 7 As shown, the hardware entity of the computer device 700 includes: one or more processors 701, a communication interface 702, and a memory 703, wherein: Processor 701 typically controls the overall operation of computer device 700.

[0145] Communication interface 702 enables computer devices to communicate with other terminals or servers over a network.

[0146] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 701 and various modules in the computer device 700. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 701, the communication interface 702, and the memory 703 can be performed via bus 704. Only one processor is shown in the figure; each processor 700 includes one or more cores.

[0147] It should be noted that the computer device may include multiple processors 701, and each processor 701 can interact with each other through aggregated communication methods such as all-to-all, all-gather, or all-reduce. The processors 701 may be central processing units (CPUs), graphics processing units (GPUs), embedded neural network processing units (NPUs), tensor processing units (TPUs), data processing units (DPUs), accelerated processing units (APUs), floating-point processing units (FPUs), or application-specific integrated circuits (ASICs). The processors may also be single-core or multi-core processors. The processor may consist of a CPU and hardware chips. The hardware chips may be ASICs, PLDs, or combinations thereof. The PLDs may be complex programmable logic devices (CPLDs), FPGAs, generic array logic (GALs), or any combination thereof. The processor can also be implemented using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs).

[0148] The communication interface 702 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0149] Memory 703 can be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 703 can also be volatile memory, which can be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM), direct rambus DRAM (DRDRAM), and rambus DRAM.

[0150] The 704 bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc.

[0151] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

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

[0153] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0154] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0155] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0156] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0157] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0158] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for assessing transaction risk decisions, characterized in that, The method includes: Listen for page configuration change events in the production configuration center, trigger the asset synchronization service through the message queue, pull the asset configuration from the production configuration center, serialize the asset configuration into a preset format file, and store it in the asset storage area of ​​the distributed file system. Historical transaction data is read from the data warehouse, the historical transaction data is converted into a context snapshot, and the context snapshot is stored in an offline data table in columnar storage format; The preset format file is loaded from the asset storage area of ​​the distributed file system, and the preset format file is deserialized to obtain a rule engine object and a model object. The rule engine object and the model object are encapsulated into custom functions of the distributed computing framework, and the custom functions are dynamically registered to the distributed computing cluster. Based on the context snapshot in the offline data table, the custom function is invoked to execute decision logic on the context snapshot and generate an evaluation result; Based on the evaluation results, multiple evaluation indicators are calculated, a comprehensive score is generated based on the evaluation indicators, and the evaluation results and the comprehensive score are output to the management and control layer for display.

2. The method according to claim 1, characterized in that, The process of monitoring page configuration change events in the production configuration center, triggering asset synchronization service via message queue, retrieving asset configuration from the production configuration center, serializing the asset configuration into a preset format file, and storing it in the asset storage area of ​​the distributed file system includes: An event listener is deployed in the production configuration center. When a page configuration release operation occurs in the production configuration center, the event listener captures the configuration change event, which includes configuration identifier, version number and timestamp information. The configuration change event is sent to a designated topic in the message queue. The asset synchronization service subscribes to the designated topic and, upon receiving the configuration change event, initiates a configuration retrieval request to the production configuration center through the application programming interface based on the configuration identifier and the version number. Receive asset configuration data returned by the production configuration center. The asset configuration data is structured text format data, which includes rule expression text, model weight parameters and feature calculation formulas. Calculate the integrity check value of the asset configuration data, compare the integrity check value with the source check value provided by the production configuration center, and if the comparison results are consistent, serialize the asset configuration data into the preset format file, construct a storage path according to the asset type, version number and synchronization timestamp, and write the preset format file into the asset storage area of ​​the distributed file system.

3. The method according to claim 1, characterized in that, The step of reading historical transaction data from the data warehouse, converting the historical transaction data into a context snapshot, and storing the context snapshot in an offline data table in columnar storage format includes: Historical transaction data to be evaluated is filtered from the data warehouse according to time range. The historical transaction data includes transaction identifier, user identifier, transaction timestamp, transaction amount, transaction channel, and account snapshot information at the time of the transaction. For each historical transaction data, complete contextual information required for the decision-making moment is collected from multiple data sources. The complete contextual information includes account balance, account registration duration, historical transaction frequency, device fingerprint identifier, number of historically associated accounts of the device, and behavioral sequence characteristics within a preset time window. The collected complete context information is structured and organized to form a context snapshot record in key-value pair format. The context snapshot record retains all fields of the original transaction data and appends a serialized representation of the complete context information. The context snapshot records are partitioned into two levels, and the partitioned context snapshot records are written to the offline data table using a columnar storage format.

4. The method according to claim 1, characterized in that, The steps include loading the preset format file from the asset storage area of ​​the distributed file system, deserializing the preset format file to obtain a rule engine object and a model object, encapsulating the rule engine object and the model object into custom functions of the distributed computing framework, and dynamically registering the custom functions with the distributed computing cluster. When a distributed computing task starts, the latest version of a preset format file is read from the asset storage area of ​​the distributed file system. The preset format file contains a rule configuration section, a model configuration section, and a feature configuration section. The deserializer corresponding to the preset format file is invoked to parse the rule configuration segment into a rule object that can be executed by the rule engine. The rule object contains conditional expressions and action definitions. The model configuration segment is also parsed into a model object that can be loaded by the machine learning framework. The model object contains model structure and model weight parameters. Create a custom function encapsulation class for the distributed computing framework, inject the rule object and the model object into the internal execution logic of the custom function encapsulation class, so that the custom function encapsulation class provides a unified evaluation interface to the outside world; The custom function encapsulation class is registered to the function registry of all execution nodes in the distributed computing cluster using the reflection mechanism of the distributed computing framework. After registration, preset smoke test cases are executed to verify the availability and correctness of the custom function encapsulation class.

5. The method according to claim 1, characterized in that, The step of calling the custom function to execute decision logic on the context snapshot based on the offline data table and generating an evaluation result includes: The context snapshots are read in batches from the offline data table according to the partition order, and the context snapshots are distributed to multiple execution nodes for parallel processing through a distributed computing framework. On each execution node, a custom function instance is retrieved from the local cache. The custom function instance is loaded from the asset storage area of ​​the distributed file system and deserialized to obtain a rule engine object and a model object. The context snapshot is passed as an input parameter to the custom function instance. The custom function instance then sequentially calls the rule engine object to match the rule conditions and calls the model object to predict and calculate the input features to obtain the risk decision result. Record the rule node identifiers, model node identifiers, and intermediate calculation results of each node during the generation of the risk decision result. Then, encapsulate the risk decision result and the intermediate calculation results in a structured manner according to the decision path format to form the evaluation result.

6. The method according to claim 5, characterized in that, On each execution node, a locally cached custom function instance is obtained. This custom function instance is loaded from the asset storage area of ​​the distributed file system and deserialized to obtain a rule engine object and a model object, including: When the execution node starts, it establishes a connection with the distributed file system, reads the preset format file from the asset storage area, and deserializes the preset format file into a rule engine object and a model object, which are then stored in the local memory cache of the execution node. A version identifier field is set in the local memory cache of the execution node, and the version update status of the preset format file in the asset storage area is checked periodically. When a version update is detected, the preset format file is reloaded from the asset storage area and the rule engine object and model object in the local memory cache are updated. The detection period for the version update status is a preset time interval. After updating the rule engine object and model object in the local memory cache, an availability verification is performed on the updated rule engine object and model object. If the availability verification passes, subsequent context snapshots are switched to the updated rule engine object and model object for processing.

7. The method according to claim 1, characterized in that, The process of calculating multiple evaluation indicators based on the evaluation results, generating a comprehensive score based on the evaluation indicators, and outputting the evaluation results and the comprehensive score to the management layer for display includes: Risk decision results are extracted from the assessment results, and the risk decision results are compared with preset real result labels. The decision consistency rate index is calculated by using a distributed aggregation function. The case detection identifier is extracted from the risk decision results from the assessment results, and the case detection identifier is compared with the preset real case label. The fraud detection rate index is calculated by using a distributed aggregation function. Processing latency data is collected from each execution node when executing the custom function in the distributed computing framework. The processing latency data is then processed using a distributed aggregation function to calculate the quantiles and obtain the processing latency quantile index. The comprehensive score is generated by weighting and summing the decision consistency rate, fraud detection rate, and processing delay quantile index according to preset weight coefficients. The evaluation results, the comprehensive score, and the indicators of each dimension are then displayed through a visualization interface.

8. An assessment device for transaction risk decision-making, characterized in that, The device includes: The processing module is used to listen for page configuration change events in the production configuration center, trigger the asset synchronization service through the message queue, pull the asset configuration from the production configuration center, serialize the asset configuration into a preset format file, and store it in the asset storage area of ​​the distributed file system. Historical transaction data is read from the data warehouse, the historical transaction data is converted into a context snapshot, and the context snapshot is stored in an offline data table in columnar storage format; The preset format file is loaded from the asset storage area of ​​the distributed file system, and the preset format file is deserialized to obtain a rule engine object and a model object. The rule engine object and the model object are encapsulated into custom functions of the distributed computing framework, and the custom functions are dynamically registered to the distributed computing cluster. The evaluation module is used to call the custom function to perform decision logic on the context snapshot based on the context snapshot in the offline data table and generate an evaluation result; Based on the evaluation results, multiple evaluation indicators are calculated, a comprehensive score is generated based on the evaluation indicators, and the evaluation results and the comprehensive score are output to the management and control layer for display.

9. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the assessment method for transaction risk decision-making according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps in the assessment method for transaction risk decision-making as described in any one of claims 1 to 7.

Images