Commercial tenant evaluation rule model updating method and device, equipment and medium

Abstract

The embodiment of the invention discloses a merchant evaluation rule model updating method and device, equipment and a medium, and the method comprises the steps: determining a rule configuration file corresponding to a rule editing operation in response to the rule editing operation of at least one rule configuration item of at least one dimension of a merchant evaluation rule model, the merchant evaluation rule model is used for performing admission or shutdown judgment on merchant attribute information of at least one to-be-evaluated merchant, and determining target continuation state information of the corresponding to-be-evaluated merchant; and performing model updating processing on the merchant evaluation rule model based on the rule configuration file to obtain the target merchant evaluation rule model, thereby realizing efficient, safe and flexible updating of the merchant evaluation rule model, and providing reliable guarantee for timeliness and accuracy of business decision.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus, device, and medium for updating a merchant evaluation rule model. Background Technology

[0002] With the rapid development of information technology, basic data collection capabilities have significantly improved, effectively ensuring the integrity and accuracy of data such as merchant information and transaction information. Simultaneously, transaction control measures are constantly being enriched, providing more multi-dimensional references for merchant management. Against this backdrop, traditional merchant evaluation methods relying on manual experience are no longer sufficient to adapt to the frequent changes in the market environment and the dynamic adjustments to management rules. There is an urgent need to construct a flexible and efficient merchant evaluation system through technological means to automate and standardize merchant entry, exit, and daily maintenance.

[0003] Currently, some companies have embedded merchant risk assessment rules into their systems through procedural means, using machine control to replace manual judgment and thus reduce inconsistencies caused by subjective factors. This system automates the analysis of merchant data through preset logic and outputs risk levels, achieving initial standardization of the assessment process.

[0004] However, rule changes for the aforementioned merchant evaluation methods rely on manual adjustments by developers, requiring frequent communication between business personnel and the technical team, resulting in slow response times and low efficiency. Furthermore, the dynamic changes in management requirements and the lag in rule iteration further constrain the timeliness and accuracy of merchant evaluations. Therefore, the existing merchant evaluation rule change process suffers from inefficiency due to strong development dependency and insufficient timeliness caused by delayed rule updates. Summary of the Invention

[0005] This invention provides a method, apparatus, device, and medium for updating a merchant evaluation rule model, so as to achieve efficient, secure, and flexible updates to the merchant evaluation rule model, and provide reliable assurance for the timeliness and accuracy of business decisions.

[0006] In a first aspect, embodiments of the present invention provide a method for updating a merchant evaluation rule model, the method comprising:

[0007] In response to a rule editing operation for at least one rule configuration item of at least one dimension of a merchant evaluation rule model, a rule configuration file corresponding to the rule editing operation is determined; wherein, the merchant evaluation rule model is used to determine the admission or shutdown of merchant attribute information of at least one merchant to be evaluated, and to determine the target survival status information of the corresponding merchant to be evaluated.

[0008] The merchant evaluation rule model is updated based on the rule configuration file to obtain the target merchant evaluation rule model.

[0009] Secondly, embodiments of the present invention also provide a merchant evaluation rule model update device, the device comprising:

[0010] The rule file generation module is used to respond to a rule editing operation for at least one rule configuration item of at least one dimension of the merchant evaluation rule model, and determine the rule configuration file corresponding to the rule editing operation; wherein, the merchant evaluation rule model is used to make an admission or shutdown judgment on the merchant attribute information of at least one merchant to be evaluated, and determine the target survival status information of the corresponding merchant to be evaluated.

[0011] The rule model update module is used to update the merchant evaluation rule model based on the rule configuration file to obtain the target merchant evaluation rule model.

[0012] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising:

[0013] One or more processors;

[0014] A storage device for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement a merchant evaluation rule model update method as described in any embodiment of the present invention.

[0015] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a merchant evaluation rule model update method as described in any of the embodiments of the present invention.

[0016] The technical solution of this invention, in response to a rule editing operation on at least one rule configuration item of at least one dimension of a merchant evaluation rule model, determines a rule configuration file corresponding to the rule editing operation. The merchant evaluation rule model is used to determine the admission or closure of at least one merchant's attribute information, and to determine the target survival status information of the corresponding merchant. Based on the rule configuration file, the merchant evaluation rule model is updated to obtain the target merchant evaluation rule model. The technical solution provided in this embodiment allows business personnel to flexibly adjust the rule configuration items of preset dimensions directly through rule editing operations, automatically generating rule configuration files and completing model updates. This significantly reduces technical communication costs and improves the response speed of rule iteration. Simultaneously, the real-time model update mechanism ensures that the merchant evaluation rule model can quickly adapt to dynamic changes in management requirements, solving the timeliness problem caused by the lag in rule updates in traditional methods. This improves the efficiency of merchant admission or closure determination while further enhancing the accuracy and business adaptability of risk assessment, achieving standardization, intelligence, and agility throughout the entire merchant evaluation process. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of exemplary embodiments of the present invention, the accompanying drawings used in describing the embodiments are briefly introduced below. Obviously, the accompanying drawings described are only a portion of the drawings of the embodiments to be described in this invention, and not all of the drawings. For those skilled in the art, other drawings can be obtained from these drawings without any creative effort.

[0018] Figure 1 This is a flowchart illustrating a merchant evaluation rule model update method provided in an embodiment of the present invention.

[0019] Figure 2 This is a flowchart illustrating another merchant evaluation rule model update method provided in an embodiment of the present invention;

[0020] Figure 3 A schematic diagram of the system architecture for updating the merchant evaluation rule model;

[0021] Figure 4 This is a schematic diagram of the structure of a merchant evaluation rule model update device provided in an embodiment of the present invention;

[0022] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0023] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0024] Example 1

[0025] Figure 1 This is a flowchart illustrating a merchant evaluation rule model update method provided in an embodiment of the present invention. This embodiment can be applied to any situation where it is necessary to dynamically adjust the merchant evaluation rule model and influence merchant admission or closure decisions in real time. The method can be executed by a merchant evaluation rule model update device, which can be implemented in the form of software and / or hardware. The hardware can be an electronic device, such as a mobile terminal, PC, or server.

[0026] like Figure 1 As shown, the merchant evaluation rule model update method includes:

[0027] S110, In response to a rule editing operation for at least one rule configuration item of at least one dimension of the merchant evaluation rule model, determine the rule configuration file corresponding to the rule editing operation.

[0028] In this embodiment, the merchant evaluation rule model is an automated decision-making system based on configurable rules. The merchant evaluation rule model is used to determine the admission or closure of at least one merchant's attribute information, thereby determining the target survival status information of the merchant to be evaluated. Here, the merchant to be evaluated refers to the merchant entity currently requiring automated review. Merchant attribute information refers to a structured data set used to describe and characterize the merchant's basic characteristics, operating status, and compliance status. Serving as the input basis for the merchant evaluation rule model, its essence is a quantifiable indicator reflecting the multidimensional status of the merchant. Admission determination refers to the process of systematically reviewing the merchant's qualifications through preset evaluation rules to determine whether they meet the requirements for conducting business cooperation or entering a specific business scope. This determination process is based on a comprehensive analysis of the merchant attribute information, using the logical conditions set in the merchant evaluation rule model for automated decision-making, ultimately generating a binary conclusion on whether the merchant is allowed to enter the platform, obtain service permissions, or conduct specific business. It is a pre-control link in the merchant management system. The shutdown determination refers to a systematic review of the continued operating qualifications of existing merchants based on preset evaluation rules. By analyzing the degree of matching between their real-time attribute information and the rule model, it automatically decides whether to terminate the merchant's business permissions or cooperative relationship. This determination mechanism, as a dynamic monitoring link in the merchant management system, aims to identify merchants who do not meet the conditions for continued operation in a timely manner through quantitative evaluation, and trigger corresponding business restrictions or exit processes, thereby achieving risk control and quality management for the merchant group. Target survival status information refers to the final decision result output after the merchant evaluation rule model is calculated, used to clearly define the legal operating status of the merchant to be evaluated within the business system.

[0029] Optionally, merchant attribute information should include at least the following: information on related parties, creditworthiness, business operations, transaction performance, negative records, customer reviews, location, main business, and enterprise category. Related party information refers to the identity and relationship data of natural persons or entities with legal or business connections to the merchant being evaluated, including but not limited to structured information such as identity documents, qualifications, backgrounds, and relationship networks of key related parties such as shareholders, legal representatives, actual controllers, and senior executives. Creditworthiness information refers to various officially certified data and historical credit records used to assess the merchant's credit level and ability to fulfill obligations, including but not limited to credit ratings from credit reporting agencies, past performance, and debt repayment records—core indicators reflecting the merchant's credit value. Business operations information refers to core indicator data reflecting the merchant's current operational status and business health, including but not limited to factors reflecting its sustainable operating capacity such as enterprise asset size, cash flow, employee structure, equipment configuration, and supply chain relationships. Transaction performance information refers to a core data set reflecting the characteristics and quality of the merchant's transaction behavior in business activities, including dynamic indicators such as transaction frequency, scale, stability, and compliance. Negative record information refers to historical data records of negative behaviors or violations related to merchants, including but not limited to blacklist records, administrative penalties, legal proceedings, contract breaches, complaints, and disputes, reflecting negative information about their compliance and integrity. Customer evaluation information refers to the collection of feedback data provided by the merchant's service recipients regarding the quality of their products or services, including satisfaction ratings, complaint content, and evaluation content, reflecting multi-dimensional indicators of market acceptance. Location information refers to geographical location data used to identify and define the merchant's legal registered address and actual business premises, including but not limited to spatial attributes such as administrative division codes, economic region classifications, and geographic coordinates. Main business information refers to standardized data used to describe the merchant's core business activities and business model, including key characteristics reflecting its commercial essence such as industry classification, service / product type, and business form. Enterprise category information refers to core classification data used to identify and distinguish the merchant's legal organizational form and the nature of its business entity, including but not limited to standardized indicators reflecting the fundamental attributes of the enterprise such as business registration type, capital structure, and equity structure characteristics.

[0030] In this context, "at least one dimension" refers to the smallest selectable unit among the multiple configurable evaluation directions in the merchant evaluation rule model, representing the technical capability to support multi-faceted and modular adjustments to merchant evaluation standards. Specifically, "at least one dimension" includes a localization rule configuration dimension, an enterprise category rule configuration dimension, and a business category rule configuration dimension. The localization rule configuration dimension refers to the set of configurable rules in the merchant evaluation rule model specifically designed for the characteristics of different geographical regions. Its core function is to allow differentiated setting of merchant admission or closure criteria based on factors such as policy requirements, economic characteristics, or risk preferences in different regions. The enterprise category rule configuration dimension refers to the set of configurable rules in the merchant evaluation rule model designed for the characteristics of different enterprise types. Its core function is to differentiated setting of merchant admission or closure criteria based on organizational characteristics such as enterprise ownership, capital structure, and industry attributes. The business category rule configuration dimension refers to the set of configurable rules in the merchant evaluation rule model designed for the characteristics of different business types. Its core function is to differentiated setting of admission or closure criteria based on the specific product or service characteristics, industry attributes, and business model of the merchant.

[0031] At least one rule configuration item refers to the smallest adjustable rule unit in any dimension of the merchant evaluation rule model, representing the ability to modify evaluation criteria with fine granularity. Specifically, at least one rule configuration item can include various specific judgment conditions and parameter settings, such as: overdue number threshold (e.g., triggering shutdown after 3 consecutive overdue payments), entry amount threshold (e.g., single transaction limit of 50,000 yuan), risk score range (e.g., automatic rejection below 60 points), operating period requirement (e.g., requiring establishment for at least 2 years), regional risk level (e.g., raising review standards for high-risk areas), industry restriction list (e.g., prohibiting entry into specific industries), customer satisfaction minimum (e.g., requiring review for scores below 4 stars), etc. These configuration items, as the smallest adjustable unit of the rule model, allow for independent parameterization of evaluation criteria for different dimensions, thereby achieving refined control of merchant evaluation strategies.

[0032] Rule editing refers to the interactive process by which users modify, add, or delete configuration items for specific dimensions in the merchant evaluation rule model. Essentially, it involves dynamically adjusting evaluation rules through a standardized user interface or API. The rule configuration file is a set of rule change instructions stored in a structured data format; it is essentially a machine-readable document carrying the results of rule editing operations. This file records the modified rule configuration items and their corresponding parameters for specific dimensions according to predefined syntax. Serving as an intermediary between business requirements and system implementation, it provides standardized and versioned policy update guidelines for the merchant evaluation rule model, ensuring that the model can accurately parse and execute the latest evaluation logic.

[0033] Specifically, a visual interactive interface can provide hierarchical display of dimension navigation and rule configuration items. When a user triggers a rule editing operation on a specific rule parameter in the interface, the operation event can be captured in real time, and the modified dimension, configuration item, and new parameter value can be parsed out. Subsequently, the modified content can be checked for compliance. If it passes the compliance check, a JSON / XML format rule configuration file containing metadata such as version identifier, operation timestamp, and modification details can be automatically generated. Finally, the rule configuration file is persistently stored in the rule version repository. Optionally, after persistently storing the rule configuration file in the rule version repository, a configuration update notification mechanism can also be triggered to provide atomic strategy change units for subsequent model hot updates.

[0034] For example, when a business user selects the "Micro and Small Enterprises" category under "Enterprise Category Rule Configuration Dimension" in the visual interactive interface, adjusts the data content under its "Access Registered Capital Threshold" rule configuration item from 500,000 yuan to 300,000 yuan, and clicks save: In response to this rule editing operation, the system first records the dimension path involved in the operation ( / Enterprise Category / Micro and Small Enterprises / Access Rules), the rule configuration item (Registered Capital Threshold), and the new and old parameter values ​​(500,000 → 300,000); then it verifies the legality of the value range (e.g., confirming that 300,000 ≥ the system minimum limit of 200,000), and upon successful verification, generates an operation ID (OP_20231125_001) and an effective date (2023-12-01). 00:00:00), modify the detailed JSON-formatted rule configuration file ({"dimension":"enterprise_type","category":"SME","field":"registered_capital","old_value":500000,"new_value":300000}); finally, store the rule configuration file in the rule version repository (e.g., / config / enterprise_type / version_12.json), and simultaneously trigger the configuration update message queue to notify the rule engine service to load the new configuration.

[0035] S120. Based on the rule configuration file, update the merchant evaluation rule model to obtain the target merchant evaluation rule model.

[0036] Among them, the target merchant evaluation rule model refers to the final effective version of the evaluation model generated after the rule configuration file has been updated. It integrates the latest modified rule configuration items with the original evaluation logic to form a rule engine instance with the best current judgment capability.

[0037] Specifically, the process involves reading the rule configuration file to extract the dimension path to be modified, configuration item identifiers, and new parameter values. Then, the rule engine locates the target rule node in memory, uses a double-buffering mechanism to first create a copy of the rule tree, atomically updates the specified parameters of the merchant evaluation rule model within the copy, and simultaneously retains a snapshot of the old version. Finally, the version controller marks the updated rule tree as the new version model and synchronizes it to the distributed computing nodes. After ensuring successful loading on all nodes, traffic is atomically switched to the new model (the old version model enters a pending recycling state). This process yields the target merchant evaluation rule model. This target merchant evaluation rule model, as the final product of the rule configuration change, dynamically loads the updated judgment parameters and business logic to achieve real-time and accurate evaluation of merchant attribute information and outputs a survival status decision that meets the latest management requirements. It serves as the core execution carrier connecting rule configuration updates and merchant status determination.

[0038] Based on the above example, when business personnel adjust the "entry-level registered capital threshold" for micro and small enterprises from 500,000 to 300,000 in the interface and submit it, a rule configuration file (such as sme_config_update.json) containing change details is first generated. Then, the rule engine service creates a copy of the current model in memory, accurately locates the "Enterprise Category Rule Configuration Dimension → Micro and Small Enterprises → Entry Conditions" node, and updates the registered capital threshold parameter to 300,000 through atomic operations, while retaining the version snapshot of the original 500,000 threshold. After the update is completed, the syntax verification and simulation test of the new rule are automatically executed. After the verification is passed, the updated model is immediately marked as version v2.1 and synchronized to all service nodes. Finally, the switch between the old and new models is completed without the business being aware of it through the hot deployment mechanism. At this time, the newly created "Target Merchant Evaluation Rule Model" has changed the judgment standard for the registered capital of micro and small enterprises to 300,000, while the original model enters the waiting state for recycling. The entire update process is completed within 300 milliseconds and ensures zero service interruption.

[0039] Based on the above example, the admission determination process of the target merchant evaluation rule model includes: in response to a business admission request for a merchant to be evaluated, obtaining the merchant attribute information corresponding to the merchant to be evaluated; and making an admission determination based on the merchant attribute information according to the target merchant evaluation rule model to determine the admission result or approval process result corresponding to the merchant to be evaluated.

[0040] The business access request refers to a formal application initiated by a merchant or its affiliates to the evaluation system, an interactive instruction aimed at obtaining specific business permissions or service qualifications. This request, acting as the starting signal for the merchant evaluation process, contains the unique identifier of the merchant to be evaluated and the required business type code. After being transmitted to the evaluation system through a standardized interface, it activates the target merchant evaluation rule model's multi-dimensional automated review process of the merchant's qualifications, ultimately generating a definitive judgment result such as granting access, transferring to manual approval, or rejecting access. The access result refers to the final decision conclusion generated by the target merchant evaluation rule model after automated analysis of the merchant's attribute information; it is an authoritative judgment on whether the merchant meets the business access conditions. This access result can clearly identify the merchant's access status (e.g., approved / rejected), the scope of grantable business permissions, and the validity period, etc., in structured data form. The approval process result refers to the intermediate conclusion generated when the merchant evaluation rule model determines that the merchant's attribute information cannot fully meet the automated decision-making conditions, resulting in manual intervention.

[0041] Specifically, when a merchant's business access application is received, a data acquisition process is automatically triggered to extract the merchant's full-dimensional merchant attribute information from the associated database and input it into the target merchant evaluation rule model in a structured manner. Furthermore, the target merchant evaluation rule model performs multi-level verification and weighted calculation on each attribute data through pre-configured rule logic, and finally outputs the access approval result, access rejection result, or approval process result.

[0042] Based on the above example, the shutdown determination process of the target merchant evaluation rule model includes: periodically acquiring the current merchant attribute information corresponding to at least one approved merchant based on a preset timed task; for each approved merchant, determining the shutdown based on the current merchant attribute information of the target merchant evaluation rule model, and determining the shutdown instruction information corresponding to the corresponding approved merchant.

[0043] Among them, the preset scheduled task refers to a programmed work process that is automatically executed according to a pre-configured time period and trigger conditions. In the merchant assessment scenario, this task serves as a technical carrier for dynamic supervision. It automatically activates the merchant data collection and rule judgment process at a fixed frequency, such as daily / weekly, ensuring that the continuous risk assessment of approved merchants is not affected by human intervention. This guarantees the timeliness and full coverage of shutdown decisions, forming a normalized technical guarantee for merchant lifecycle management. An approved merchant refers to a merchant entity that has successfully obtained business operation qualifications through initial assessment and is currently in a normal service state. Current merchant attribute information refers to the dynamic set of operational data of approved merchants updated in real time within the latest assessment cycle, reflecting the merchant's latest operational status and risk characteristics. Shutdown instruction information refers to the business disposal instructions generated by the target merchant assessment rule model after periodically reviewing approved merchants. Shutdown instruction information clearly identifies whether a merchant meets the continuous operation standards in the form of structured data, including core elements such as the shutdown recommendation level (e.g., immediate shutdown, rectification within a time limit, continuous observation), specific violation indicators, and judgment basis.

[0044] Specifically, periodic merchant assessment tasks can be initiated through pre-configured timed triggers. First, the current merchant attribute information of approved merchants is obtained in real time from the data source to form the basis for the current assessment. Then, the target merchant assessment rule model is called to perform full-dimensional rule matching and risk calculation on the current merchant attribute information of each merchant. Finally, a decision output containing structured data such as the shutdown recommendation level and risk factor list is generated, and an executable shutdown instruction is formed, thereby realizing intelligent and normalized supervision of the merchant's continued operation qualification.

[0045] The technical solution of this invention, in response to a rule editing operation on at least one rule configuration item of at least one dimension of a merchant evaluation rule model, determines a rule configuration file corresponding to the rule editing operation. The merchant evaluation rule model is used to determine the admission or closure of at least one merchant's attribute information, and to determine the target survival status information of the corresponding merchant. Based on the rule configuration file, the merchant evaluation rule model is updated to obtain the target merchant evaluation rule model. The technical solution provided in this embodiment allows business personnel to flexibly adjust the rule configuration items of preset dimensions directly through rule editing operations, automatically generating rule configuration files and completing model updates. This significantly reduces technical communication costs and improves the response speed of rule iteration. Simultaneously, the real-time model update mechanism ensures that the merchant evaluation rule model can quickly adapt to dynamic changes in management requirements, solving the timeliness problem caused by the lag in rule updates in traditional methods. This improves the efficiency of merchant admission or closure determination while further enhancing the accuracy and business adaptability of risk assessment, achieving standardization, intelligence, and agility throughout the entire merchant evaluation process.

[0046] Example 2

[0047] Figure 2 This diagram illustrates a merchant evaluation rule model update method provided in an embodiment of the present invention. Based on the aforementioned embodiments, the specific implementation processes of S110 and S120 are further refined. For detailed implementation methods, please refer to the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0048] like Figure 2 As shown, the method specifically includes the following steps:

[0049] S210. In response to the rule editing operation, determine the identifier of the edited dimension, the unique code of the edited rule configuration item, and the rule editing content entered by the user under the corresponding edited rule configuration item.

[0050] Here, "Editable Dimension" refers to the editable dimension triggered by the user. "Identifier" refers to the unique identification code assigned to each configurable dimension in the merchant evaluation rule model. "Editable Rule Configuration Item" refers to the editable rule configuration item triggered by the user. "Unique Encoding" refers to the globally unique identification symbol assigned to each configurable rule parameter in the merchant evaluation rule model. "Rule Edit Content" refers to the specific modification instructions entered by the user for a particular rule configuration item in the configuration interface.

[0051] Specifically, when a user's editing action on a rule configuration item within a specific dimension is captured on the interactive interface, three key elements are automatically extracted: First, the unique identifier of the edited dimension within the rule architecture is parsed from the dimension navigation path; second, the globally unique code of the edited rule configuration item is obtained from the operation event; and finally, the specific modified value or logical expression entered by the user on the configuration item interface is collected. These three elements together constitute the smallest complete unit of rule change, providing precise operation objects and content basis for subsequent rule verification and configuration file generation, ensuring that each edit is accurately mapped to a specific node in the rule model.

[0052] S220. Locate the rule configuration item to be modified in the rule configuration database based on the identifier of the edited dimension and the unique code of the edited rule configuration item.

[0053] The rule configuration database is a structured data storage system specifically designed to store and manage all dimensions, configuration items, and associated parameters of the merchant evaluation rule model. A rule configuration item to be modified refers to a specific rule parameter unit in the merchant evaluation rule model that is about to be edited. As the direct target of rule changes, it is precisely located in the rule configuration database through dimension identifiers and unique codes.

[0054] In this embodiment, the identifier of the edited dimension is used as a primary index to quickly locate the target dimension node in the rule configuration database. Then, the unique code of the edited rule configuration item is used as a secondary index to accurately retrieve the specific rule configuration item to be modified. This two-layer positioning mechanism achieves millisecond-level response through database index optimization and query optimization techniques, ensuring accurate extraction of the current version data of the target configuration item from the complex rule tree structure. This includes complete metadata such as its parameter definitions, constraints, and dependencies, providing an accurate comparison benchmark for subsequent rule conflict detection. At the same time, it ensures that the positioning process does not affect the normal operation of other rule configuration items.

[0055] S230. Check whether the rule editing content conflicts with the rule logic of the rule configuration item to be modified.

[0056] In this context, rule logic refers to the judgment principles and operational relationships followed by a specific rule configuration item in the merchant evaluation rule model. Essentially, it is an abstract expression of business strategies into computer-executable rules. This logic includes core elements such as mathematical relationships between parameters, Boolean operations for conditional judgments, and operators for threshold comparisons.

[0057] In this embodiment, the compliance verification of newly input rule editing content can be performed in multiple dimensions: first, check whether the syntax structure conforms to the predefined rule expression specification; second, analyze whether the parameter values ​​exceed the threshold range defined by the configuration item; third, determine whether the modified rule has a logical contradiction with the associated configuration item, such as mutual exclusion conditions, circular dependencies, etc.; and finally, verify whether it violates the constraint principles of the upper dimension.

[0058] S240. If not, the rule editing content will be used as the associated content corresponding to the rule configuration item to be modified, and serialized into a rule configuration file according to the preset template, and the rule configuration file will be stored in the target directory.

[0059] The preset template refers to a predefined standardized structural framework for rule configuration files, essentially a formatted conversion specification for business rules into machine-readable configurations. The target directory is a standardized storage path specifically used to store validated rule configuration files. Specifically, if the rule editing content does not conflict with the rule logic of the rule configuration item to be modified, it indicates that the rule editing content has passed conflict detection. Furthermore, a persistent association can be established between the rule editing content and the rule configuration item to be modified, storing the new parameter value or logical expression as the latest valid version of the configuration item. Then, the serialization engine is invoked to convert the dimension identifier, configuration item code, edited content, and related metadata (such as operator and timestamp) into a standardized rule configuration file according to the field structure and data format of the preset template. This rule configuration file can then be stored in the target directory. This process preserves the integrity of the business semantics, generates a machine-readable rule change carrier, provides compliant configuration input for subsequent model hot updates, and ensures that each change is traceable.

[0060] Based on the above embodiments, optionally, if there is a conflict between the rule editing content and the rule logic of the rule configuration item to be modified, an input error message will be generated and the generation of the rule configuration file will be blocked.

[0061] The input error message refers to the standardized error feedback generated when a logical conflict is detected in the rule editing content. Essentially, it is a machine-readable rule validation result. This information records the conflict type (e.g., syntax error, threshold exceeding limits, logical contradiction), conflict location (i.e., dimension / configuration item path), and key diagnostic data such as correction suggestions through a structured data format. This provides a user-friendly error display for the user interface and records detailed troubleshooting clues for the logging system.

[0062] In this embodiment, when a logical contradiction is detected between the user's input rule modification and the existing rule system, a security protection mechanism can be triggered immediately. Specifically, the mechanism can be implemented by: first, generating an input exception prompt message containing details of the specific conflict, clearly indicating the type and location of the violation; at the same time, interrupting the current rule configuration file generation process to prevent inconsistent rule changes from entering the production environment, and rolling back the temporary operations performed at the transaction level to ensure that the rule database maintains its complete state before editing.

[0063] S250. When the preset file loading conditions are met, load the rule configuration file from the target directory.

[0064] The preset file loading conditions refer to a predefined set of criteria for determining whether to load and execute the rule configuration file. Specifically, the preset file loading conditions include: when the rule configuration file is generated, or when a scheduled task is triggered.

[0065] In this embodiment, a dual-trigger mechanism for loading rule configuration files is established. Specifically: First, a listening service monitors change events in the target directory in real time. When a new rule configuration file is detected, the loading process is immediately triggered, ensuring immediate effect of rule changes. Second, relying on a time-scheduling engine, the target directory is actively scanned and batch loading tasks are executed according to a pre-configured periodic plan, such as at midnight daily. These two approaches, combining event-driven and time-driven methods, satisfy both the business's real-time requirements and ensure centralized processing capabilities during periods of low load. Furthermore, atomic operations ensure the integrity and consistency of the loading process, representing an intelligent scheduling strategy that balances business agility and system stability.

[0066] S260. Based on the rule configuration file, the rule determination execution script of the merchant evaluation rule model stored therein is hot-deployed and updated to obtain the target merchant evaluation rule model.

[0067] Among them, the rule judgment execution script refers to the executable code unit in the merchant evaluation rule model used to implement specific judgment logic.

[0068] In this embodiment, after loading the rule configuration file, the rule configuration file is first parsed to extract the changed content, and the script content that needs to be modified is located by version comparison. Then, a double buffering mechanism is adopted to create an independent running instance of the new version rule script in memory, and seamlessly replace the old version after initialization verification. Finally, a target merchant evaluation rule model integrating the latest rules is formed. This model inherits the running state and data context of the original model to ensure the continuity of the evaluation service and realize the safe and smooth transition of business rules.

[0069] The following example illustrates the merchant evaluation rule model update method provided in this embodiment of the invention. Figure 3 A schematic diagram of the system architecture for updating the merchant evaluation rule model. (Example) Figure 3As shown, in response to a rule editing operation, the step of determining the rule configuration file can be executed by the rule engine management module. When the rule engine management module receives a rule editing operation, it can determine the identifier of the edited dimension, the unique code of the edited rule configuration item, and the user-inputted rule editing content under the corresponding edited rule configuration item. Then, based on the identifier of the edited dimension and the unique code of the edited rule configuration item, it locates the rule configuration item to be modified in the rule configuration database. Further, if it is determined that the rule editing content does not conflict with the rule logic of the rule configuration item to be modified, the rule editing content is used as the associated content corresponding to the rule configuration item to be modified, and serialized into a rule configuration file according to a preset template, and stored in the target directory. The update step of the merchant evaluation rule model can be executed by the merchant rule engine module. When the merchant rule engine module detects the generation of a rule configuration file, or triggers a scheduled task, it loads the rule configuration file from the target directory. Then, based on the rule configuration file, it performs a hot deployment update of the rule judgment execution script of the stored merchant evaluation rule model to obtain the target merchant evaluation rule model. During the process of updating the merchant evaluation rule model in the merchant rule engine module, the merchant information module can send merchant attribute information to the merchant rule engine module in a predetermined format via HTTP / TCP or other means. The merchant rule engine module can then determine the target existence status information corresponding to at least one merchant to be evaluated in real time through the merchant evaluation rule model.

[0070] The technical solution of this invention, when determining the rule configuration file corresponding to the rule editing operation, responds to the rule editing operation by determining the identifier of the edited dimension, the unique code of the edited rule configuration item, and the rule editing content input by the user under the corresponding edited rule configuration item; based on the identifier of the edited dimension and the unique code of the edited rule configuration item, it locates the rule configuration item to be modified in the rule configuration database; it checks whether the rule editing content conflicts with the rule logic of the rule configuration item to be modified; if not, it uses the rule editing content as the associated content corresponding to the rule configuration item to be modified, and serializes it into a rule configuration file according to a preset template. The technical solution provided in this embodiment significantly improves the accuracy and traceability of rule changes through the dual positioning mechanism of structured identifiers and unique codes, effectively avoiding configuration errors that may be caused by manual intervention; at the same time, the serialization processing based on the preset template not only ensures the standardization of the configuration file, but also greatly reduces the cost of manual operation through automated processes, while the pre-emptive rule logic conflict check eliminates the system risks caused by rule contradictions from the source, thereby achieving efficient, secure, and flexible updates of the merchant evaluation rule model as a whole, providing a reliable guarantee for the timeliness and accuracy of business decisions. When updating the merchant evaluation rule model, if a preset file loading condition is detected, a rule configuration file is loaded from the target directory. The preset file loading conditions include: detecting the generation of a rule configuration file, or triggering a scheduled task. Based on the rule configuration file, the rule judgment execution script of the stored merchant evaluation rule model is hot-deployed and updated to obtain the target merchant evaluation rule model. The technical solution provided in this embodiment, through an intelligent file loading condition monitoring mechanism, achieves a flexible combination of real-time response to rule changes and scheduled batch processing. This satisfies the need for rapid iteration of business rules while ensuring stable system operation during off-peak periods. The use of hot deployment technology for uninterrupted updates significantly improves service continuity and availability, avoiding business interruptions caused by traditional restart methods. Furthermore, version management and atomic operations ensure the security and reliability of the update process, enabling the merchant evaluation system to maintain the timeliness and accuracy of the rule engine without affecting existing business operations, providing strong technical support for the refined operation of merchant management.

[0071] Example 3

[0072] Figure 4 This is a schematic diagram of a merchant evaluation rule model update device provided in an embodiment of the present invention. The device includes: a rule file generation module 310 and a rule model update module 320.

[0073] The rule file generation module 310 is used to determine the rule configuration file corresponding to the rule editing operation in response to a rule editing operation for at least one rule configuration item of at least one dimension of the merchant evaluation rule model; wherein the merchant evaluation rule model is used to determine the admission or closure of at least one merchant's attribute information to determine the target survival status information of the merchant to be evaluated.

[0074] The rule model update module 320 is used to update the merchant evaluation rule model based on the rule configuration file to obtain the target merchant evaluation rule model.

[0075] The technical solution of this invention, in response to a rule editing operation on at least one rule configuration item of at least one dimension of a merchant evaluation rule model, determines a rule configuration file corresponding to the rule editing operation. The merchant evaluation rule model is used to determine the admission or closure of at least one merchant's attribute information, and to determine the target survival status information of the corresponding merchant. Based on the rule configuration file, the merchant evaluation rule model is updated to obtain the target merchant evaluation rule model. The technical solution provided in this embodiment allows business personnel to flexibly adjust the rule configuration items of preset dimensions directly through rule editing operations, automatically generating rule configuration files and completing model updates. This significantly reduces technical communication costs and improves the response speed of rule iteration. Simultaneously, the real-time model update mechanism ensures that the merchant evaluation rule model can quickly adapt to dynamic changes in management requirements, solving the timeliness problem caused by the lag in rule updates in traditional methods. This improves the efficiency of merchant admission or closure determination while further enhancing the accuracy and business adaptability of risk assessment, achieving standardization, intelligence, and agility throughout the entire merchant evaluation process.

[0076] Based on the above-mentioned device, optionally, the at least one dimension includes a localization rule configuration dimension, an enterprise category rule configuration dimension, and a business category rule configuration dimension; the merchant attribute information includes at least: enterprise related person information, credit qualification information, operating status information, transaction performance information, bad record information, customer evaluation information, location information, main business information, and enterprise category information.

[0077] Based on the above-mentioned apparatus, optionally, the rule file generation module 310 includes:

[0078] An information determination unit is used to determine, in response to the rule editing operation, the identifier of the edited dimension, the unique code of the edited rule configuration item, and the rule editing content input by the user under the corresponding edited rule configuration item;

[0079] The configuration item locating unit is used to locate the rule configuration item to be modified in the rule configuration database based on the identifier of the edited dimension and the unique code of the edited rule configuration item;

[0080] A logic conflict detection unit is used to check whether the rule editing content conflicts with the rule logic of the rule configuration item to be modified;

[0081] The rule file generation unit is used to, if not, associate the rule editing content with the configuration item to be modified, serialize it into a rule configuration file according to a preset template, and store the rule configuration file in the target directory.

[0082] Based on the above-mentioned device, optionally, the rule file generation module 310 is further configured to generate an input error message and block the generation of the rule configuration file if the rule editing content conflicts with the rule logic of the rule configuration item to be modified.

[0083] Based on the above-mentioned device, optionally, the rule model update module 320 includes:

[0084] The configuration file loading unit is used to load the rule configuration file from the target directory when a preset file loading condition is detected; wherein the preset file loading condition includes: when the generation of the rule configuration file is detected, or when a scheduled task is triggered;

[0085] The rule model update unit is used to perform hot deployment updates of the rule determination execution script of the merchant evaluation rule model stored in the rule configuration file to obtain the target merchant evaluation rule model.

[0086] Based on the above-mentioned device, optionally, the merchant evaluation rule model update device is further configured to, in response to a business access request for a merchant to be evaluated, obtain merchant attribute information corresponding to the merchant to be evaluated; and make an access determination on the merchant attribute information based on the target merchant evaluation rule model to determine the access result or approval process result corresponding to the merchant to be evaluated.

[0087] Based on the above-mentioned device, optionally, the merchant evaluation rule model update device is also used to periodically acquire the current merchant attribute information corresponding to at least one approved merchant based on a preset timed task; for each approved merchant, the device performs a shutdown determination on the current merchant attribute information based on the target merchant evaluation rule model, and determines the shutdown instruction information corresponding to the corresponding approved merchant.

[0088] The merchant evaluation rule model update device provided in this embodiment of the invention can execute the merchant evaluation rule model update method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0089] It is worth noting that the various units and modules included in the above system are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the protection scope of the embodiments of the present invention.

[0090] Example 4

[0091] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Figure 5 The electronic device 40 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0092] like Figure 5 As shown, electronic device 40 is represented in the form of a general-purpose computing device. The components of electronic device 40 may include, but are not limited to: one or more processors or processing units 401, system memory 402, and bus 403 connecting different system components (including system memory 402 and processing unit 401).

[0093] Bus 403 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0094] Electronic device 40 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 40, including volatile and non-volatile media, removable and non-removable media.

[0095] System memory 402 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 404 and / or cache memory 405. Electronic device 40 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 406 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 403 via one or more data media interfaces. Memory 402 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0096] A program / utility 408 having a set (at least one) of program modules 407 may be stored, for example, in memory 402. Such program modules 407 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 407 typically perform the functions and / or methods described in the embodiments of the present invention.

[0097] Electronic device 40 can also communicate with one or more external devices 409 (e.g., keyboard, pointing device, display 810, etc.), and with one or more devices that enable a user to interact with electronic device 40, and / or with any device that enables electronic device 40 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 411. Furthermore, electronic device 40 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 412. As shown, network adapter 412 communicates with other modules of electronic device 40 via bus 403. It should be understood that, although... Figure 5 Not shown, other hardware and / or software modules may be used in conjunction with electronic device 40, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0098] The processing unit 401 executes various functional applications and page processing by running programs stored in the system memory 402, such as implementing the merchant evaluation rule model update method provided in the embodiments of the present invention.

[0099] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via I / O interface 411, or installed from storage system 406. When the computer program is executed by processing unit 401, it performs the functions defined in the methods of the embodiments of the present invention.

[0100] Example 5

[0101] This invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a merchant evaluation rule model update method, including:

[0102] In response to a rule editing operation for at least one rule configuration item of at least one dimension of a merchant evaluation rule model, a rule configuration file corresponding to the rule editing operation is determined; wherein, the merchant evaluation rule model is used to determine the admission or shutdown of merchant attribute information of at least one merchant to be evaluated, and to determine the target survival status information of the corresponding merchant to be evaluated.

[0103] The merchant evaluation rule model is updated based on the rule configuration file to obtain the target merchant evaluation rule model.

[0104] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0105] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0106] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0107] Computer program code for performing the operations of embodiments of the present invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0108] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for updating a merchant evaluation rule model, characterized in that, include: In response to a rule editing operation for at least one rule configuration item of at least one dimension of a merchant evaluation rule model, a rule configuration file corresponding to the rule editing operation is determined; wherein, the merchant evaluation rule model is used to determine the admission or shutdown of merchant attribute information of at least one merchant to be evaluated, and to determine the target survival status information of the corresponding merchant to be evaluated. The merchant evaluation rule model is updated based on the rule configuration file to obtain the target merchant evaluation rule model.

2. The method according to claim 1, characterized in that, The at least one dimension includes the localization rule configuration dimension, the enterprise category rule configuration dimension, and the business category rule configuration dimension; The merchant attribute information includes at least: information on related parties of the enterprise, credit qualification information, business status information, transaction performance information, negative record information, customer evaluation information, location information, main business information, and enterprise category information.

3. The method according to claim 1, characterized in that, The step of responding to a rule editing operation for at least one rule configuration item of at least one dimension of a merchant evaluation rule model, and determining a rule configuration file corresponding to the rule editing operation, includes: In response to the rule editing operation, determine the identifier of the edited dimension, the unique code of the edited rule configuration item, and the rule editing content entered by the user under the corresponding edited rule configuration item; Based on the identifier of the edited dimension and the unique code of the edited rule configuration item, locate the rule configuration item to be modified in the rule configuration database; Check whether the rule editing content conflicts with the rule logic of the rule configuration item to be modified; If not, the rule editing content is used as the associated content corresponding to the rule configuration item to be modified, and serialized into a rule configuration file according to a preset template, and the rule configuration file is stored in the target directory.

4. The method according to claim 3, characterized in that, Also includes: If the rule editing content conflicts with the rule logic of the rule configuration item to be modified, an input error message will be generated, and the generation of the rule configuration file will be blocked.

5. The method according to claim 1, characterized in that, The step of updating the merchant evaluation rule model based on the rule configuration file to obtain the target merchant evaluation rule model includes: When a preset file loading condition is detected, the rule configuration file is loaded from the target directory; wherein, the preset file loading condition includes: when the generation of the rule configuration file is detected, or when a scheduled task is triggered; Based on the rule configuration file, the rule determination execution script of the merchant evaluation rule model stored therein is hot-deployed and updated to obtain the target merchant evaluation rule model.

6. The method according to claim 1, characterized in that, The admission determination process of the target merchant evaluation rule model includes: In response to a business access request for a merchant to be evaluated, obtain the merchant attribute information corresponding to the merchant to be evaluated; Based on the target merchant evaluation rule model, the merchant attribute information is used to determine the admission result or approval process result corresponding to the merchant to be evaluated.

7. The method according to claim 1, characterized in that, The shutdown determination process of the target merchant evaluation rule model includes: Based on a preset scheduled task, periodically obtain the current merchant attribute information corresponding to at least one approved merchant; For each of the approved merchants, the current merchant attribute information is used to determine whether to close down based on the target merchant evaluation rule model, and the closure instruction information corresponding to the corresponding approved merchant is determined.

8. A merchant evaluation rule model updating device, characterized in that, The device includes: The rule file generation module is used to respond to a rule editing operation for at least one rule configuration item of at least one dimension of the merchant evaluation rule model, and determine the rule configuration file corresponding to the rule editing operation; wherein, the merchant evaluation rule model is used to make an admission or shutdown judgment on the merchant attribute information of at least one merchant to be evaluated, and determine the target survival status information of the corresponding merchant to be evaluated. The rule model update module is used to update the merchant evaluation rule model based on the rule configuration file to obtain the target merchant evaluation rule model.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the merchant assessment rule model update method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the merchant evaluation rule model update method according to any one of claims 1-7.

Images