Zero-code integration of risk control methods and systems based on Spring Boot starter dependency injection

Abstract

The application discloses a zero-code integration risk control method and system based on SpringBoot starter dependency injection, and the method comprises the following steps: configuring a rule set on a risk control server and pushing the rule set to a configuration management center; establishing and maintaining a dynamic mapping relationship between a business interface URI and the risk control rule set in the configuration management center; a risk control client component is integrated in a business system, the component is automatically loaded and initialized when the business system starts, and the dynamic mapping relationship is acquired and cached from the configuration management center; the built-in interceptor is used for intercepting before processing a business request, the dynamic mapping relationship in the local cache is automatically queried, if the current business request interface exists in the mapping relationship, a risk verification request is automatically initiated to the risk control server, and whether the business request is released is determined according to the returned result. The application realizes the decoupling of the risk control capability and the business system, and the change and expansion of the risk control rule can be completed without modifying the code of the business system.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a zero-code integrated risk control method and system based on Spring Boot starter dependency injection. Background Technology

[0002] In existing technologies, business systems typically integrate risk control capabilities using a real-time invocation scheme. Specifically, business systems can embed risk control verification logic into their business processes by introducing a risk control SDK and explicitly calling its provided API interfaces, or by intercepting at the gateway layer, or by manually configuring AOP (Aspect-Oriented Programming) interceptors, filters, etc.

[0003] However, this integration method has significant limitations. First, the business system development team must study the calling specifications or API interface definitions of the risk control SDK and write the corresponding integration code, which introduces additional development workload and learning costs. More importantly, the business system needs to establish and maintain the static calling relationship between its business interfaces and the risk control rule set within its code through hard coding. When the risk control strategy changes, requiring the addition of risk control to new business interfaces or adjustments to the correspondence between existing interfaces and risk control rules, the business system's source code must be modified, and a series of processes such as retesting, repackaging, and deployment must be carried out.

[0004] This tightly coupled integration model results in the evolution of business systems and risk control systems being intertwined. Even minor changes or expansions to risk control logic can trigger a redeployment of the business system, increasing operational complexity and impacting the continuity of online business and the agility of the risk control system itself. Therefore, there is a strong demand in existing technologies for a solution that can decouple changes in business systems and risk control logic, thereby avoiding frequent development and deployment of business systems due to updates to risk control strategies. Summary of the Invention

[0005] In view of the above problems, this application provides a zero-code integrated risk control technical solution based on Spring Boot starter dependency injection, so as to solve how to achieve flexible, dynamic binding and real-time effect of risk control rules and business interfaces without modifying business system code and restarting deployment.

[0006] To achieve the above objectives, in a first aspect, this application provides a zero-code integrated risk control method based on Spring Boot starter dependency injection, the method comprising the following steps:

[0007] S1: Configure a risk control rule set in the risk control server, wherein the risk control rule set includes rule identifiers and version information;

[0008] S2: Push the set of risk control rules to the configuration management center;

[0009] S3: In the configuration management center, a dynamic mapping relationship is established and maintained between the unified resource identifier of the business system interface and the risk control rule set, taking the business system identifier as the dimension;

[0010] S4: The risk control client component is integrated by the business system by introducing a pre-built SpringBoot starter dependency, in a zero-code manner;

[0011] S5: The risk control client component automatically completes configuration loading and initialization when the business system starts;

[0012] S6: Obtain the dynamic mapping relationship from the configuration management center through the risk control client component, specifically including: the configuration management center actively pushes update information to the risk control client component when the rule changes, and / or the risk control client component periodically initiates a pull request to the configuration management center to obtain update information;

[0013] S7: The obtained dynamic mapping relationship is cached locally in the business system through the risk control client component;

[0014] S8: The interceptor built into the risk control client component intercepts the business request before it enters the business logic processing. It automatically judges the dynamic mapping relationship by querying the local cache. When it is determined that the Uniform Resource Identifier of the business interface corresponding to the business request exists in the dynamic mapping relationship, it automatically sends a risk verification request to the risk control server according to the dynamic mapping relationship, and decides whether to allow the business request to continue to execute the subsequent business logic based on the returned verification result.

[0015] Furthermore, the risk control client component is integrated into the business system in a zero-code manner by introducing a pre-built Spring Boot starter dependency, specifically including:

[0016] In the configuration file of the business system, the authentication and connection configuration with the configuration management center is completed through the business system identifier;

[0017] The Spring Boot starter dependency automatically creates and configures the configuration management, rule acquisition, and request interception modules of the risk control client component when the business system starts, and automatically registers the built-in interceptors into the web request processing flow of the business system.

[0018] Furthermore, in step S8, when initiating a risk verification request to the risk control server, the method further includes:

[0019] Extract predefined business parameters from the currently intercepted business request;

[0020] The business parameters are encapsulated in the risk verification request and sent to the risk control server, so that the risk control server can make a risk judgment in combination with the corresponding risk control rules.

[0021] Furthermore, in step S8, determining whether to allow the business request to continue executing subsequent business logic based on the returned verification result specifically includes:

[0022] When the verification result indicates that there is a risk, the interceptor directly returns an error response to the client, interrupting the subsequent process of the business request;

[0023] When the verification result is no risk, the business request is allowed to continue executing subsequent business logic.

[0024] Furthermore, the dynamic mapping relationship is cached locally in the business system as a local cache with an expiration time, and the method further includes:

[0025] When the cache expires or an update notification is received from the configuration management center, step S6 is re-executed to obtain the dynamic mapping relationship from the configuration management center to update the local cache.

[0026] Furthermore, the method also includes:

[0027] Configure a canary release strategy for the risk control rule set, the canary release strategy including the target rule version and traffic routing rules based on user identifier, device identifier or network address;

[0028] In step S8, when the business system initiates a risk verification request to the risk control server, it extracts the corresponding user identifier, device identifier, or network address from the context of the current business request as a traffic identifier, and carries the traffic identifier in the risk verification request.

[0029] The risk control server receives the risk verification request, parses the traffic identifier, and matches it according to the traffic routing rules in the canary release strategy. If the match is successful, the target rule version is applied for risk verification; if the match fails, the default version of the risk control rule set is applied for risk verification.

[0030] Furthermore, the risk control rule set includes one or more risk rules marked as lightweight, and step S7 specifically includes:

[0031] The risk control client component caches the dynamic mapping relationship from the configuration management center, and simultaneously caches the judgment logic of the lightweight risk rule.

[0032] In step S8, the specific steps for automatically initiating a risk verification request to the risk control server based on the dynamic mapping relationship include:

[0033] After intercepting the current business request, the judgment logic of the lightweight risk rule related to the current business request is loaded and executed first.

[0034] If a deterministic risk verification result can be obtained based on the judgment logic of the lightweight risk rule, then a decision is made on whether to allow the business request to continue to be executed based on the result.

[0035] If a deterministic risk verification result cannot be obtained based on the judgment logic of the lightweight risk rules, then a risk verification request is sent to the risk control server.

[0036] Furthermore, the method also includes:

[0037] Generate a globally unique tracking identifier for pending business requests;

[0038] In step S8, when the business system initiates a risk verification request to the risk control server, it carries the tracking identifier in the risk verification request.

[0039] After receiving the risk verification request, the risk control server associates the risk logs and rule hit records generated during the internal processing with the received tracking identifier.

[0040] After the business request is processed based on the verification result, by querying the tracking identifier, the complete decision-making link information from the business system to the risk control server can be obtained and displayed. The complete decision-making link information includes at least: the context information of the business request, the time when the risk verification request was initiated, the verification result returned by the risk control server, and the specific risk control rule and its decision logic that triggered the verification result.

[0041] Furthermore, the method includes:

[0042] The risk control server generates a decision credential, which encapsulates at least the following: the risk control rule identifier on which the verification result is based, the input feature data fingerprint, and the verification result.

[0043] The cryptographic hash value of the decision credential is recorded in an immutable storage medium;

[0044] Based on the risk control rule identifier and input feature data fingerprint encapsulated in the decision credential, in a verification environment independent of the risk control server, a simulation verification result is recalculated and output by calling the corresponding risk control rule logic.

[0045] The simulation verification results recalculated based on the decision credentials are compared with the original verification results encapsulated in the decision credentials to achieve auditing of the historical decision-making process.

[0046] In a second aspect, this application provides a zero-code integrated risk control system based on Spring Boot starter dependency injection, the system being used to execute the method described in the first aspect of this application, the system comprising:

[0047] A risk control server is configured to store and configure a set of risk control rules, the set of risk control rules including rule identifiers and version information;

[0048] The configuration management center is connected to the risk control server to receive and store the risk control rule set pushed from the risk control server, and to establish and maintain a dynamic mapping relationship between the unified resource identifier of the business system interface and the risk control rule set, with the business system identifier as the dimension.

[0049] The business system integrates a risk control client component that is injected with zero coding by introducing a pre-built Spring Boot starter dependency; wherein, the risk control client component further includes:

[0050] The configuration loading and initialization module is used to automatically complete configuration loading and initialization when the business system starts.

[0051] The mapping relationship management module is used to obtain and update the dynamic mapping relationship from the configuration management center, and cache the dynamic mapping relationship locally in the business system; wherein, the methods of obtaining updates include: receiving proactive push from the configuration management center when rules change, and / or periodically initiating pull requests to the configuration management center;

[0052] The request interception and judgment module has a built-in interceptor, which is used to intercept business requests before they enter the business logic processing, and automatically judges them by querying the dynamic mapping relationship in the local cache.

[0053] The risk verification execution module is used to automatically initiate a risk verification request to the risk control server based on the dynamic mapping relationship when the request interception and judgment module determines that the Uniform Resource Identifier of the business interface corresponding to the business request exists in the dynamic mapping relationship, and decide whether to allow the business request to continue to execute subsequent business logic based on the returned verification result.

[0054] Unlike existing technologies, the above-mentioned technical solution involves a zero-code integrated risk control method and system based on Spring Boot starter dependency injection. This method includes: configuring a rule set on the risk control server and pushing it to a configuration management center; establishing and maintaining a dynamic mapping relationship between business interface URIs and the risk control rule set in the configuration management center; the business system integrating a risk control client component in a zero-code manner, which is automatically loaded and initialized when the business system starts, obtaining and caching the dynamic mapping relationship from the configuration management center; and using its built-in interceptor, intercepting business requests before processing, automatically querying the dynamic mapping relationship in the local cache, and if the current business request interface exists in the mapping relationship, automatically initiating a risk verification request to the risk control server, and deciding whether to allow the business request based on the returned result. This application decouples risk control capabilities from the business system, so that changes and extensions to risk control rules do not require code modification and redeployment in the business system.

[0055] The above description of the invention is merely an overview of the technical solution of this application. In order to enable those skilled in the art to better understand the technical solution of this application and to implement it based on the description and drawings, and to make the above-mentioned objectives and other objectives, features and advantages of this application easier to understand, the following description is provided in conjunction with the specific embodiments and drawings of this application. Attached Figure Description

[0056] The accompanying drawings are only used to illustrate the principles, implementation methods, applications, features, and effects of specific embodiments of this application and other related content, and should not be considered as limitations on this application.

[0057] In the accompanying drawings of the instruction manual:

[0058] Figure 1 This is a flowchart of the zero-code integrated risk control method based on Spring Boot starter dependency injection as described in the first exemplary embodiment of this application;

[0059] Figure 2 This is a flowchart illustrating the zero-code integrated risk control method based on Spring Boot starter dependency injection as described in the second exemplary embodiment of this application;

[0060] Figure 3 This is a flowchart of the zero-code integrated risk control method based on Spring Boot starter dependency injection as described in the third exemplary embodiment of this application;

[0061] Figure 4 This is a flowchart of the zero-code integrated risk control method based on Spring Boot starter dependency injection as described in the fourth exemplary embodiment of this application;

[0062] Figure 5 This is a flowchart of the zero-code integrated risk control method based on Spring Boot starter dependency injection as described in the fifth exemplary embodiment of this application;

[0063] Figure 6 This is a flowchart of the zero-code integrated risk control method based on Spring Boot starter dependency injection as described in the sixth exemplary embodiment of this application;

[0064] Figure 7 This is a flowchart of the zero-code integrated risk control method based on Spring Boot starter dependency injection as described in the seventh exemplary embodiment of this application;

[0065] Figure 8 This is a flowchart of the zero-code integrated risk control method based on Spring Boot starter dependency injection as described in the eighth exemplary embodiment of this application;

[0066] Figure 9 This is a schematic diagram of an electronic device according to an exemplary embodiment of this application;

[0067] The reference numerals used in the above figures are explained as follows:

[0068] 10. Risk control server;

[0069] 20. Configuration Management Center;

[0070] 30. Business systems;

[0071] 301. Risk control client component;

[0072] 3011. Configuration loading and initialization module;

[0073] 3012. Mapping Relationship Management Module;

[0074] 3013. Request interception and judgment module;

[0075] 3014. Risk Verification Execution Module. Detailed Implementation

[0076] To illustrate the possible application scenarios, technical principles, implementable specific solutions, and achievable objectives and effects of this application in detail, the following description, in conjunction with the listed specific embodiments and accompanying drawings, provides a detailed explanation. The embodiments described herein are merely illustrative of the technical solutions of this application and are therefore intended to limit the scope of protection of this application.

[0077] like Figure 1 As shown, in a first aspect, this application provides a zero-code integrated risk control method based on Spring Boot starter dependency injection, the method comprising the following steps:

[0078] S1: Configure a risk control rule set in the risk control server, wherein the risk control rule set includes rule identifiers and version information;

[0079] S2: Push the set of risk control rules to the configuration management center;

[0080] S3: In the configuration management center, a dynamic mapping relationship is established and maintained between the unified resource identifier of the business system interface and the risk control rule set, taking the business system identifier as the dimension;

[0081] S4: The risk control client component is integrated by the business system by introducing a pre-built SpringBoot starter dependency, in a zero-code manner;

[0082] S5: The risk control client component automatically completes configuration loading and initialization when the business system starts;

[0083] S6: Obtain the dynamic mapping relationship from the configuration management center through the risk control client component, specifically including: the configuration management center actively pushes update information to the risk control client component when the rule changes, and / or the risk control client component periodically initiates a pull request to the configuration management center to obtain update information;

[0084] S7: The obtained dynamic mapping relationship is cached locally in the business system through the risk control client component;

[0085] S8: The interceptor built into the risk control client component intercepts the business request before it enters the business logic processing. It automatically judges the dynamic mapping relationship by querying the local cache. When it is determined that the Uniform Resource Identifier of the business interface corresponding to the business request exists in the dynamic mapping relationship, it automatically sends a risk verification request to the risk control server according to the dynamic mapping relationship, and decides whether to allow the business request to continue to execute the subsequent business logic based on the returned verification result.

[0086] In this embodiment, SpringBoot starter refers to a wrapper module in the SpringBoot ecosystem used to simplify dependency management and component integration. Through the auto-configuration mechanism, after the business system introduces the dependency, the component initialization and function integration can be completed without manually writing a lot of configuration code.

[0087] The risk control server (i.e., the risk control server system) is the core server-side device that stores, manages, and executes risk control rules. It is responsible for receiving risk verification requests initiated by business systems, determining the risk level of the request based on a preset set of rules, and returning the verification results.

[0088] The rule identifier (ruleId) is a unique identifier assigned to each risk control rule, used to accurately locate a specific rule. Combined with version information, it enables multi-version management and iteration of rules, avoiding rule confusion.

[0089] The configuration management center is an intermediate service used for centralized storage and management of risk control rule sets and mapping relationships. It supports proactive push of rule changes and proactive retrieval by business systems, ensuring the consistency of rules and mapping relationships in a distributed environment.

[0090] The business system identifier (appId) is a unique identifier assigned to each business system. It is used to distinguish the rule mapping relationship between different business systems in the configuration management center. When there are multiple versions of a business system (such as canary release), the unique version can be located by "appId + version".

[0091] A Uniform Resource Identifier (URI) is a unique access path for each business interface in a business system, such as " / api / user / login". This application establishes a mapping relationship between URIs and a set of risk control rules to achieve precise risk control and interception of requests to specific interfaces.

[0092] The risk control client component (i.e., the risk control client component) is integrated into the business system. It is responsible for interacting with the configuration management center and the risk control server system, and executing functional modules such as rule retrieval, caching, request interception, and risk verification initiation. Zero-code integration is achieved through Spring Boot starter injection.

[0093] An interceptor is a built-in AOP (Aspect-Oriented Programming) functional module in the risk control client component. It can trigger an interception operation before a business request enters the business logic processing, thus avoiding intrusive development of the business system.

[0094] In step S1, the risk control server creates and sorts risk control rules based on market operation needs (such as anti-fraud and authorization verification) and product security strategies. Each rule must be assigned a unique ruleId, and version information (version) must be assigned to the rule set. For example, for the "user login interface," rules such as "password error count exceeded" and "abnormal IP login" can be configured, combined to form a rule set and marked as "ruleId=LOGIN_001, version=V1.0". The configuration of the rule set provides a basis for subsequent accurate risk control.

[0095] In step S2, the risk control server pushes the configured rule set to the configuration management center according to the dimension of "ruleId + version". The core principle of this step is to achieve unified management of the rule set through centralized storage, avoiding the synchronization difficulties caused by rules being stored separately in various business systems, and laying the foundation for subsequent rule sharing among multiple business systems. For example, the risk control server pushes the "LOGIN_001-V1.0" rule set to the designated storage node of the configuration management center via the HTTP protocol, ensuring that the configuration management center obtains the latest rules in real time.

[0096] In step S3, within the configuration management center, a dynamic mapping relationship is established between the business system's interface URI and the risk control rule set, using the business system's appId as the dimension. This mapping relationship includes information such as "appId, URI, ruleId, version, and business parameters," and supports dynamic adjustments via manual or automated tools (e.g., adding URI mappings or switching rule versions). For example, for "appId=USER_SYSTEM (user business system)," the mapping relationship is configured as follows: "uri= / api / user / login → ruleId=LOGIN_001, version=V1.0," ensuring that login interface requests for this business system can be associated with the corresponding risk control rule set. The principle behind this step is to achieve precise risk control coverage for specific business interfaces through "URI-rule" mapping, avoiding resource waste caused by indiscriminate interception.

[0097] In step S4, the business system can complete the zero-code integration of the risk control client component by including the pre-built SpringBootstarter dependency (such as "com.example:risk-control-starter:1.0.0") in the Maven / Gradle configuration file. The principle behind this is the automatic configuration mechanism of SpringBoot starters: the starter internally encapsulates the bean definition and configuration class of the risk control client (such as RiskClientAutoConfiguration). After the business system includes the dependency, the Spring container automatically scans and loads these configurations when it starts, completing the initialization of the risk control client without requiring business developers to write additional code, achieving a zero-code integration effect of "introducing the dependency is integration".

[0098] In step S5, the risk control client component automatically performs configuration loading and initialization operations when the business system starts. Specifically, this includes reading preset parameters such as "configuration management center address, risk control server address, appId, version, communication protocol (HTTP / RPC / WebSocket), and account password authentication information" from the business system configuration file (such as application.yml), and completing the communication protocol agreement and identity authentication preparation with the configuration management center and the risk control client component.

[0099] In step S6, the risk control client component obtains the mapping relationship from the configuration management center through a dual mechanism of "active push + periodic pull" to ensure the real-time nature of the mapping relationship:

[0100] The proactive push process is as follows: When the configuration management center detects a change in the mapping relationship corresponding to a certain appId (such as adding a URI mapping or modifying the ruleId), it will proactively push the update information to the risk control Client component of the business system corresponding to that appId based on the service registration / discovery mechanism. For example, after the configuration management center modifies the mapping rule of " / api / user / login" of "USER_SYSTEM" to "ruleId=LOGIN_002, version=V2.0", it will immediately push the update notification to all risk control Client components of business systems that integrate that appId.

[0101] The periodic fetching process is as follows: The risk control Client component has a built-in scheduled task (e.g., executed every 10 minutes) that periodically sends a fetch request to the configuration management center to obtain the latest mapping relationship corresponding to the current appId. After fetching, the risk control Client component compares the timestamps of the mapping relationships: if the timestamp of the fetched mapping relationship is not later than the timestamp of the local cache, the update is discarded; if the timestamp is updated, subsequent cache update operations are performed. The principle of the dual mechanism is: proactive push ensures the real-time nature of changes, periodic fetching avoids omissions caused by push failures, and dual guarantees the consistency of mapping relationships.

[0102] In step S7, the risk control Client component caches the obtained dynamic mapping relationship locally in the business system (e.g., using Redis local caching or Caffeine caching). During caching, atomicity of updates must be guaranteed (e.g., using CAS operations or distributed locks) to avoid inconsistencies in cached data caused by concurrent updates from multiple threads. For example, the risk control Client component caches " / api / user / login→{LOGIN_002,V2.0,username / password parameters,2025-07-25 10:00:00}" locally. Subsequent interception requests can directly query the local cache without needing to request the configuration management center each time, significantly improving interception and judgment efficiency.

[0103] In step S8, when a user initiates a business request (such as accessing " / api / user / login"), the AOP interceptor built into the risk control Client component triggers interception before the request enters the business logic (such as user login processing code) and performs the following operations:

[0104] Mapping relationship query: The interceptor extracts the URI (such as " / api / user / login") from the request, queries the local cached mapping relationship, and determines whether the URI exists in the mapping table.

[0105] Risk verification request initiation: If a mapping relationship exists between URIs, the risk control Client component automatically extracts predefined business parameters (such as username and login IP) from the request, encapsulates the risk verification request (containing "appId, uri, ruleId, version, and business parameters") according to the protocol (such as HTTP) in the mapping relationship, and sends it to the risk control server.

[0106] Verification Result Processing: After receiving the request, the risk control server matches the ruleId with the version and performs risk assessment on the business parameters (e.g., checking if the IP is on a blacklist, or if the password error count has exceeded the limit), and returns the result of "Pass / Reject / Requires Secondary Verification" to the risk control client component. The risk control client component determines the request path based on the result: if pass, the request is allowed to proceed to the business logic; if rejected, an error response is returned directly (e.g., "The account has an abnormal login risk, please verify your mobile number"); if secondary verification is required, an additional verification process (e.g., SMS verification code) is triggered, interrupting the subsequent business request process until verification is completed.

[0107] The above solution allows business systems to integrate the risk control client component simply by adding the Spring Boot starter dependency, eliminating the need to write SDK calls or AOP configuration code. This solves the problem of existing technologies requiring extensive SDK / API specification study and development, thus shortening the integration cycle. The push-pull mechanism (including proactive push and periodic pull) of the configuration management center enables dynamic adjustments to mapping relationships and rules, taking effect without restarting the business system. This addresses the issue of existing technologies requiring development and deployment of new interfaces / rules, impacting online business, and improves the availability of the risk control system. Based on the mapping relationship between URIs and rule sets, only requests to interfaces requiring risk control are intercepted, avoiding resource waste caused by indiscriminate interception. Simultaneously, local caching of mapping relationships reduces the number of interactions with the configuration management center, lowering request latency.

[0108] In some embodiments, such as Figure 2 As shown, the risk control client component is integrated into the business system in a zero-code manner by introducing a pre-built Spring Boot starter dependency, specifically including:

[0109] S201: In the configuration file of the business system, the authentication and connection configuration with the configuration management center is completed through the business system identifier;

[0110] S202: The Spring Boot starter dependency automatically creates and configures the configuration management, rule acquisition, and request interception function modules of the risk control client component when the business system starts, and automatically registers the built-in interceptors into the web request processing flow of the business system.

[0111] In this embodiment, the configuration file refers to the file used in the business system to store basic configuration parameters. Common formats include YAML (such as application.yml) and Properties (such as application.properties). In this application, it is used to store key parameters for interaction between the business system and the configuration management center.

[0112] Authentication and connection configuration refers to a set of parameters that ensure secure communication between the business system and the configuration management center. These parameters include the configuration management center address, the business system appId, identity authentication information (such as account password, token), and communication protocols (such as HTTPS), and are used to verify the legitimacy of the business system's identity and establish a stable connection.

[0113] Web request processing flow refers to the standardized process by which a business system receives and processes HTTP / Web requests. It typically includes "request reception → filter processing → interceptor processing → business logic execution → response return". This application registers the risk control interceptor to the "interceptor processing" stage of this flow to achieve request interception.

[0114] When the business system starts, the Spring container scans the auto-configuration classes (such as RiskClientAutoConfiguration) in the imported risk control Spring Boot starter. This class is recognized as a configuration class through the @Configuration annotation, and internally, it automatically creates the core functional module bean of the risk control Client component through the @Bean annotation. This module includes:

[0115] The configuration management module Bean is used to read the "authentication and connection configuration" in the configuration file, generate a configuration object (such as ConfigCenterConfig) for communication with the configuration management center, and ensure that the communication parameters are correct.

[0116] The rule retrieval module Bean is used to create components (such as RuleFetcher) responsible for pulling mapping relationships from the configuration management center. It has a built-in scheduled task thread pool to implement the function of periodic retrieval.

[0117] Request interception module bean: Create an AOP-based risk control interceptor (such as RiskInterceptor), and register the interceptor to the web request processing flow of the business system through Spring MVC's InterceptorRegistry. At the same time, configure the interception path as " / **" (i.e., intercept all web requests) to ensure that all business requests will be judged by the risk control interceptor.

[0118] The principle behind this step is Spring Boot's auto-configuration mechanism: the starter specifies the full path of the auto-configuration class through the META-INF / spring / org.springframework.boot.autoconfigure.AutoConfiguration.imports file. When the Spring container starts, it will automatically load the class and execute the Bean creation logic. The business system does not need to manually create Beans, achieving the zero-code effect of component initialization through dependency import.

[0119] The auto-configuration class of the risk control Client component integrates the WebMvcConfigurer interface and overrides the addInterceptors method to register risk control interceptors with the business system's Web request processing flow. This step leverages Spring MVC's interceptor registration mechanism, replacing traditional XML configuration with code-based configuration to achieve automatic interceptor registration. This avoids the business system manually writing interceptor registration code, further reducing integration costs.

[0120] Business systems only need to modify configuration files; no code for Bean creation or interceptor registration is required. Even non-professional risk control developers can complete the integration, resolving the issue of existing technologies requiring expertise in AOP and Spring configuration for risk control integration. By using Spring Boot starters to pre-define configuration formats and parameter paths, issues such as parameter reading failures and connection exceptions caused by custom configuration formats in business systems are avoided, improving the integration success rate. Interceptors are automatically registered to the web request flow through configuration, eliminating the need for business systems to modify their existing interceptor chains or request processing logic, thus ensuring the stability of the original business system functionality.

[0121] In some embodiments, such as Figure 3 As shown, in step S8, when initiating a risk verification request to the risk control server, the method further includes:

[0122] Step S301: Extract predefined business parameters from the currently intercepted business request;

[0123] Step S302: Encapsulate the business parameters in the risk verification request and send them to the risk control server so that the risk control server can make a risk judgment in conjunction with the corresponding risk control rules.

[0124] In this embodiment, the predefined business parameters refer to the key business data that are pre-specified for risk control judgment when establishing the mapping relationship in the configuration management center, such as "username, login IP, device ID" of the "user login interface", and "order amount, payment method" of the "order payment interface". These parameters are the core input data for the risk control server system to judge risk.

[0125] Risk verification request encapsulation refers to the process of assembling information such as "business parameters, appId, uri, ruleId, version" into a request data packet according to a preset format (such as JSON, ProtoBuf). The encapsulated data packet must conform to the interface protocol of the risk control server system (such as the JSON body of an HTTP POST request) to ensure that the risk control server system can correctly parse and extract key information.

[0126] When establishing the dynamic mapping relationship in step S3, the configuration management center needs to synchronously record the "predefined business parameters" corresponding to each URI. For example, for the mapping relationship of "uri= / api / user / login, ruleId=LOGIN_001", the configuration management center needs to mark the business parameters to be extracted for this URI as "username, loginIp, deviceId". This configuration information will be pushed to the risk control Client component along with the mapping relationship and stored in the local cached mapping table to provide a basis for subsequent parameter extraction.

[0127] When the interceptor of the risk control Client component intercepts a business request, it first queries the local cached mapping table for the list of "predefined business parameters" corresponding to the current URI, and then extracts these parameters from the request using a request parsing tool (such as ServletRequestUtils in Spring MVC). For example:

[0128] If the request is an HTTP POST (JSON format), the interceptor extracts the values ​​of the "username", "loginIp", and "deviceId" fields by parsing the JSON request body.

[0129] If the request is an HTTP GET (URL parameter), the interceptor extracts the corresponding parameter values ​​by parsing the URL query string (such as "?username=test&loginIp=192.168.1.1").

[0130] If a predefined parameter is missing (e.g., the request does not include "deviceId"), the interceptor can handle it according to a preset strategy: such as marking it as "parameter missing" and passing this information into the risk verification request. The risk control server system then determines whether this affects the risk assessment (if a non-critical parameter is missing, the assessment can continue; if a critical parameter is missing, "request parameters are incomplete" is returned directly). The principle behind this step is to ensure that the risk control server system obtains sufficient data for assessment through "predefined parameters + targeted extraction," thus avoiding misjudgments or omissions in risk control due to missing parameters.

[0131] After extracting the business parameters, the interceptor encapsulates the risk verification request according to the protocol format agreed upon by the risk control server system. For example, if the communication protocol is HTTP, the request is encapsulated as a POST request body in JSON format. After encapsulation, the risk control client component sends the request to the specified interface of the risk control server system (e.g., "http: / / risk-server:8080 / api / risk / verify") via a preset communication protocol (such as HTTP). The principle behind this step is to ensure that the risk control server system can quickly parse the key information in the request by standardizing the request format, thereby improving the efficiency of risk verification. At the same time, the addition of a timestamp can prevent the request from being maliciously replayed, ensuring communication security.

[0132] The above solution ensures that the risk control server obtains key data that matches the rules by predefining business parameters, avoiding judgment bias caused by parameter redundancy or missing parameters. Furthermore, through a unified request format and protocol adaptation, the risk control client component can communicate with risk control server systems of different versions and architectures (such as simultaneously adapting to HTTP-based and RPC-based risk control server systems), improving system compatibility.

[0133] In some embodiments, in step S8, determining whether to allow the business request to continue executing subsequent business logic based on the returned verification result specifically includes: when the verification result indicates a risk, the interceptor directly returns an error response to the client, interrupting the subsequent process of the business request; when the verification result indicates no risk, the business request is allowed to continue executing subsequent business logic.

[0134] When the verification result is high-risk (e.g., "IP is on the blacklist," "Password incorrect attempts exceeded 10 times"), the interceptor of the risk control Client component directly constructs an error response and returns information to the client via Spring MVC's ResponseEntity or HttpServletResponse, while simultaneously interrupting the subsequent flow of the business request (preventing the request from being passed to the business logic layer). For example, returning an HTTP 403 status code or lower response body to the client. The principle behind this step is "risk pre-interception," which directly blocks high-risk requests before they enter the business logic, preventing risky requests from posing security threats to the business system (such as account theft or malicious order placement), while guiding the user through clear error messages, thus balancing security and user experience.

[0135] When the verification result is risk-free (e.g., "login IP is a frequently used IP, password is correct and not exceeded"), the interceptor of the risk control Client component will remove the block, allowing the request to continue flowing to the business logic layer of the business system (e.g., calling the login method of UserService to perform login verification). Subsequent processes will be executed according to the original logic of the business system (e.g., generating a login token and returning a login success response). The principle of this step is "quickly allowing risk-free requests," avoiding unnecessary interception delays and ensuring the normal processing efficiency of the business system.

[0136] If the verification result is medium risk (e.g., "login IP is a new device IP, but username and password are correct"), the risk control Client component can trigger a secondary verification process (e.g., SMS verification code, facial recognition) based on a preset strategy. The specific process is as follows: the risk control Client component returns a "secondary verification required" response to the client, guiding the user to complete the verification; after the client submits the verification information (e.g., SMS verification code), the risk control Client component sends the verification information and the original business parameters to the risk control Server system again for risk verification; the risk control Server system verifies the secondary verification result. If it passes, it is determined to be "no risk" and the request is allowed; if it fails, it is determined to be "high risk" and an error response is returned.

[0137] The above solution employs a tiered strategy of "high-risk interception, no-risk access, and medium-risk secondary verification" to prevent high-risk requests from threatening system security while ensuring the normal processing of no-risk requests. At the same time, secondary verification reduces the impact of misjudgments on user experience.

[0138] In some embodiments, the dynamic mapping relationship is cached locally in the business system as a local cache with an expiration time. The method further includes: when the cache expires or an update notification is received from the configuration management center, step S6 is re-executed to obtain the dynamic mapping relationship from the configuration management center to update the local cache.

[0139] In this embodiment, a local cache with an expiration time refers to setting an automatic expiration time (e.g., 30 minutes) for cached data when the dynamic mapping relationship is stored locally in the business system. When the cache reaches its expiration time, it is automatically marked as expired and an update mechanism is triggered. Common implementation methods include Caffeine caching (based on Java local caching) and Redis local caching (an in-memory database with an expiration time).

[0140] When the risk control client component retrieves the mapping relationship, the mapping relationship data packet will carry a timestamp generated by the configuration management center (such as "updateTime=1690272000000"). The risk control client component compares this timestamp with the timestamp of the locally cached mapping relationship:

[0141] If the fetched timestamp is less than or equal to the local timestamp: this means the local cache is up-to-date, and the fetched mapping relationship should be discarded;

[0142] If the retrieved timestamp is greater than the local timestamp, it means the mapping relationship has been updated, and a cache update operation should be performed.

[0143] The local cache mapping table is updated using an atomic operation of "updating the temporary cache first, then switching the reference". For example, when using ConcurrentHashMap as the cache container, a new HashMap is created to store the latest mapping relationship during the update. Then, the cache reference is pointed to the new HashMap through CAS (Compare and Swap) operation. This avoids the inconsistency problem of "partial mapping relationship updated and partial not updated" when multiple threads update concurrently, and ensures the integrity of cached data when interception judgment.

[0144] In some embodiments, the business system can specify the communication protocol with the risk control server system and configuration management center in the configuration file. In addition to HTTP, it also supports protocols such as RPC (e.g., Dubbo, gRPC) and WebSocket. For example, when configuring "risk.client.protocol=GRPC", the risk control client component will automatically use the GRPC protocol to encapsulate requests and parse responses, adapting to high-performance, low-latency risk control scenarios (such as high-frequency trading interface risk control). The configuration file can also specify communication parameters such as "connection timeout, number of retries, and data serialization method".

[0145] In some embodiments, after a user initiates a business request, the business system will first perform its own "authentication verification" (such as verifying whether the user's token is valid and whether it has access to the interface) and "parameter compliance verification" (such as verifying whether the parameter format is correct and whether it meets the length / range restrictions). Only when both verifications pass will the interceptor of the risk control Client component intercept the request.

[0146] If authentication fails (e.g., the token expires), the business system directly returns an "unauthorized" response; if parameter compliance verification fails (e.g., "username length is less than 6 characters"), it returns a "parameter error" response, eliminating the need to enter the risk control interception stage, reducing invalid risk control judgments, and improving request processing efficiency.

[0147] In some embodiments, besides Spring Boot starter integration, the risk control Client component can also be integrated in other ways, as follows:

[0148] SPI (Service Provider Interface) Integration: For business systems that are not based on Spring Boot architecture (such as traditional Spring MVC systems), the risk control client component can be integrated through the SPI mechanism. Specifically, the business system configures the service implementation class of the risk control client component in the "META-INF / services" directory. When the system starts, the class is loaded through ServiceLoader to complete the initialization and functional integration of the risk control client component, thus achieving the same low-code integration effect.

[0149] KMM (Kotlin Multiplatform Mobile) Integration: For mobile business systems (such as Android and iOS apps), risk control client components can be integrated via KMM. KMM allows the core logic of cross-platform risk control client components to be written in Kotlin, compiled into an aar package for Android and a framework package for iOS. After the mobile app imports the corresponding package, integration can be completed with simple configuration, enabling risk control interception of mobile business requests (such as risk control of payment interfaces within the app).

[0150] In some embodiments, such as Figure 4 As shown, the method further includes:

[0151] S401: Configure a canary release strategy for the risk control rule set, wherein the canary release strategy includes a target rule version and traffic routing rules based on user identifier, device identifier, or network address;

[0152] S402: In step S8, when the business system initiates a risk verification request to the risk control server, it extracts the corresponding user identifier, device identifier, or network address from the context of the current business request as a traffic identifier, and carries the traffic identifier in the risk verification request.

[0153] S403: The risk control server receives the risk verification request, parses the traffic identifier, and matches it according to the traffic routing rules in the canary release strategy;

[0154] After step S403, you can proceed to step S404: if the match is successful, apply the target rule version for risk verification; or proceed to step S405: if the match fails, apply the default version of the risk control rule set for risk verification.

[0155] In this embodiment, the canary release strategy is a phased release of new rule versions. It routes a portion of traffic to the new rule version for verification, while the remaining traffic uses the old version, reducing the risk of a full release. Traffic identifiers are unique identifiers used to distinguish different users / devices, such as user ID (userId), device serial number (deviceId), and IP address (ipAddress), serving as the basis for traffic routing decisions. The default version is the currently stable version in the risk control rule set; when traffic does not match a canary routing rule, this version is used by default for risk verification.

[0156] The above solution utilizes a canary release approach, ensuring that new rules only affect a portion of traffic. If issues are discovered, a quick rollback to the default version can be initiated, avoiding systemic risks associated with a full release (such as mistakenly blocking legitimate requests). Furthermore, canary traffic can be precisely filtered by user, device, network, and other dimensions (e.g., releasing new rules only to internal test accounts), facilitating the collection of targeted feedback for rule optimization.

[0157] In some embodiments, such as Figure 5 As shown, the risk control rule set includes one or more risk rules marked as lightweight. Step S7 specifically includes:

[0158] S501: The risk control client component caches the dynamic mapping relationship from the configuration management center, and simultaneously caches the judgment logic of the lightweight risk rule;

[0159] In step S8, the specific steps for automatically initiating a risk verification request to the risk control server based on the dynamic mapping relationship include:

[0160] S502: After intercepting the current business request, prioritize loading and executing the judgment logic of the lightweight risk rule related to the current business request;

[0161] After step S502, we can proceed to step S503: If a deterministic risk verification result can be obtained based on the judgment logic of the lightweight risk rule, then we decide whether to allow the business request to continue to be executed based on the result.

[0162] After step S502, you can proceed to step S504: If a deterministic risk verification result cannot be obtained based on the judgment logic of the lightweight risk rule, then a risk verification request is sent to the risk control server.

[0163] In this embodiment, lightweight risk rules refer to risk rules that are logically simple, have few dependent parameters, and can be executed locally, such as "password length must be ≥6 characters" and "request frequency ≤10 times / minute". These are typically stored as scripts (such as Groovy or JavaScript) or serialized objects and can be directly parsed and executed by the risk control client component. A deterministic risk verification result refers to a result where the lightweight rule can clearly determine "no risk" or "high risk" without relying on the complex calculations of the risk control server system (e.g., "password length = 5 characters" can be directly determined as high risk). A non-deterministic result refers to a result where the lightweight rule cannot completely determine the risk (e.g., "request frequency = 8 times / minute" requires further judgment based on complex data such as user historical behavior), necessitating a request to the risk control server system.

[0164] When obtaining the dynamic mapping relationship in step S6, the risk control Client component synchronously pulls the rule judgment logic marked as "lightweight" (such as the Groovy script "return password.length()>= 6") from the configuration management center and caches it locally along with the dynamic mapping relationship (step S7). The cache structure is expanded to "uri→{ruleId, lightweight rule script, ...}".

[0165] After intercepting the request in step S8, the risk control Client component processes it as follows: extracting parameters and executing local rules, specifically extracting lightweight rule-dependent parameters (such as "password") from the request and executing locally cached rule scripts through a built-in script engine (such as GroovyScriptEngine); if the script returns "explicitly rejected" (e.g., insufficient password length), it is directly judged as high-risk and returns an error response without calling the risk control Server system for further judgment; if the script returns "explicitly approved" (e.g., password length is compliant and request frequency is normal), the request is directly allowed; if the script returns "further verification required" (e.g., parameters are compliant but the IP is a new address), the original logic of step S8 is executed, and a risk verification request is initiated to the risk control Server system.

[0166] In this embodiment, lightweight rules complement the complex rules of the risk control server system (such as judgments based on user profiles and blacklists): lightweight rules handle simple, high-frequency basic checks, while server-side rules of the risk control server system handle complex, low-frequency deep checks. For example, local rules can quickly block obvious risks such as "empty password" and "exceeding request frequency limits"; server-side rules can combine data such as the user's historical login location and device fingerprint to determine whether "a new IP login is a case of account theft".

[0167] The above solution reduces invalid server requests (such as those with incorrect basic parameters) by executing lightweight rules locally, thus improving the efficiency of the risk control server system in handling complex requests. Even when the network connection between the business system and the risk control server system is interrupted, the local lightweight rules can still execute basic risk interception (such as preventing logins with empty passwords), ensuring basic system security.

[0168] In some embodiments, such as Figure 6 As shown, the method further includes:

[0169] S601: Generate a globally unique tracking identifier for pending business requests;

[0170] S602: In step S8, when the business system initiates a risk verification request to the risk control server, it carries the tracking identifier in the risk verification request;

[0171] S603: After receiving the risk verification request, the risk control server associates the risk log and rule hit record generated during the internal processing of the risk control server with the received tracking identifier.

[0172] S604: After processing the business request based on the verification result, by querying the tracking identifier, the complete decision-making link information from the business system to the risk control server can be obtained and displayed.

[0173] In this embodiment, the globally unique trace identifier (traceId) refers to a unique string (such as a UUID) generated for each business request, which runs through the entire process of the business system and the risk control server system, and is used to associate logs and records at each stage. Risk logs and rule hit records refer to logs generated by the risk control server system when processing verification requests, including "received request time, executed rule ID, rule judgment logic, intermediate results," etc., which, when associated with the traceId, allow for tracing the complete decision-making process. The complete decision-making chain information includes at least: the context information of the business request, the time when the risk verification request was initiated, the verification result returned by the risk control server, and the specific risk control rule and its decision logic that triggered the verification result.

[0174] The above solution uses traceId to link logs from the business system and the risk control server system, enabling rapid identification of the cause of risk control anomalies (such as whether a "false block" is due to incorrect rule configuration or parameter extraction), thus solving the problems of "fragmented logs and difficulty in investigation" in traditional distributed systems. Complete decision-making chain information can serve as auditing evidence, meeting the regulatory requirements for traceable risk control decisions in industries such as finance and e-commerce. By analyzing the "rule hit records" in the chain information, frequently triggered rules and misjudged rules can be identified, providing data support for rule optimization (such as adjusting the judgment threshold of the "IP anomaly" rule).

[0175] In some embodiments, such as Figure 7 As shown, the method includes:

[0176] S701: The risk control server generates a decision credential, which encapsulates at least the following: the risk control rule identifier on which the verification result is based, the input feature data fingerprint, and the verification result;

[0177] S702: Record the cryptographic hash value of the decision credential in an immutable storage medium;

[0178] S703: Based on the risk control rule identifier and input feature data fingerprint encapsulated in the decision credential, in a verification environment independent of the risk control server, a simulation verification result is recalculated and output by calling the corresponding risk control rule logic;

[0179] S704: Compare the simulation verification result recalculated based on the decision voucher with the original verification result encapsulated in the decision voucher to achieve auditing of the historical decision-making process.

[0180] In this embodiment, the decision credential is a structured data generated by the risk control server that records key information of a single risk verification. It is the core basis for tracing and verifying the risk control decision-making process and includes three core elements: risk control rule identifier, input feature data fingerprint, and verification result.

[0181] Cryptographic hash values ​​are fixed-length strings obtained by encrypting decision credentials using cryptographic hash algorithms (such as SHA-256). They are irreversible and unique, and can be used to verify the integrity of credentials and prevent the leakage of original data.

[0182] Immutable storage media refers to storage systems that possess the characteristic of data immutability, such as blockchain (which ensures that data cannot be tampered with through a distributed node consensus mechanism) and trusted databases with timestamps (such as storage systems that support WORM features).

[0183] An independent verification environment refers to a system environment that is physically isolated from and logically independent of the risk control server. It contains a logical copy of the risk control rules consistent with the production environment and is used to simulate and verify historical decision-making processes.

[0184] Simulation verification results refer to the risk verification results recalculated based on decision credentials in an independent verification environment. These results are used to compare with the original verification results to verify the accuracy and compliance of historical decisions.

[0185] The aforementioned solution achieves complete traceability of historical risk control decisions through decision credentials and tamper-proof evidence storage, meeting the regulatory audit requirements of industries such as finance and payment. By combining cryptographic hashing with blockchain evidence storage, the integrity and authenticity of decision credentials are ensured, solving the problem of tampering in traditional log storage. Through a verification environment independent of the risk control server, the audit results are prevented from being affected by changes in production environment rules or data, objectively verifying the accuracy of historical decisions and providing authoritative evidence for dispute resolution (such as user complaints).

[0186] like Figure 8 As shown, in some embodiments, the method includes:

[0187] S10: Complete the risk control rule configuration in the risk control server system.

[0188] S20: Push rule sets to the configuration / registration center.

[0189] S30: The configuration / registration center can perform mapping configuration operations between service URI and risk control rule set based on the service's appId and risk control rule set ruleId. The configured mapping relationship includes information such as interface URI mapping, business parameters, and version.

[0190] S40: When the risk control rule set configuration is actively changed, the rule set can be pushed to the business system.

[0191] S50 initialization risk control client component configuration.

[0192] In this embodiment, the risk control Client component configuration includes authentication and connection information such as the addresses, account passwords, etc., of the configuration management center, configuration registration center, and risk control Server system. Initialization configuration prepares for subsequent communication with the configuration management center and risk control Server system. The specific steps are: integrating the risk control Client component into the business system, such as through Spring Boot Starter, using the SPI method to achieve automatic loading of basic configurations, or integrating the risk control component based on the Kotlin Multiplatform Mobile (KMM) method for mobile devices. Communication between the risk control Client component and the configuration management center and risk control Server system is completed simply through dependency injection. Basic communication information and protocols can be specified in the business system, such as the business service appId, service version, and the protocol used (HTTP, RPC, WebSocket, etc.). The agreed-upon work with the configuration management center and risk control server is completed through the basic configuration information.

[0193] S60: Based on the configuration of S50, actively pulls the rule set information from the configuration management center.

[0194] S70: The cache rule set contains information such as interface URI mapping, business parameters, and version.

[0195] S80: Users call the business system and complete authentication and parameter verification.

[0196] S90: The risk control client component AOP intercepts and judges requests.

[0197] S100: Risk control rule set in AOP query cache.

[0198] S110: Determine if the requested URI is in the mapping.

[0199] S120: Invoke the risk control service.

[0200] S130: The risk control server system verifies the risk level of this request.

[0201] S140: The risk control server system returns the verification results to the business system.

[0202] S150: Display the results of risk verification or handling to the user.

[0203] S160: If the risk detection is passed, proceed with the subsequent business.

[0204] In the second aspect, such as Figure 9As shown, this application provides a zero-code integrated risk control system based on Spring Boot starter dependency injection. The system is used to execute the method described in the first aspect of this application, and the system includes:

[0205] Risk control server 10 is configured to store and configure a set of risk control rules, the set of risk control rules including rule identifiers and version information;

[0206] Configuration management center 20 is communicatively connected to risk control server 10, and is used to receive and store risk control rule set pushed from risk control server, and establish and maintain dynamic mapping relationship between unified resource identifier of business system interface and risk control rule set with business system identifier as dimension;

[0207] Business system 30 integrates a risk control client component 301 that is injected with zero coding by introducing a pre-built Spring Boot starter dependency; wherein, the risk control client component 301 further includes:

[0208] The configuration loading and initialization module 3011 is used to automatically complete the configuration loading and initialization when the business system starts.

[0209] The mapping relationship management module 3012 is used to obtain and update the dynamic mapping relationship from the configuration management center, and cache the dynamic mapping relationship locally in the business system; wherein, the methods of obtaining updates include: receiving active push from the configuration management center when the rules change, and / or periodically initiating pull requests to the configuration management center;

[0210] The request interception and judgment module 3013 has a built-in interceptor, which is used to intercept business requests before they enter business logic processing, and to make automatic judgments by querying the dynamic mapping relationship in the local cache.

[0211] The risk verification execution module 3014 is used to automatically initiate a risk verification request to the risk control server according to the dynamic mapping relationship when the request interception and judgment module determines that the unified resource identifier of the business interface corresponding to the business request exists in the dynamic mapping relationship, and decide whether to allow the business request to continue to execute subsequent business logic based on the returned verification result.

[0212] Finally, it should be noted that although the above embodiments have been described in the text and drawings of this application, this should not limit the scope of patent protection of this application. Any technical solutions that are based on the essential concept of this application and utilize the content described in the text and drawings of this application, resulting in equivalent structural or procedural substitutions or modifications, as well as the direct or indirect application of the technical solutions of the above embodiments to other related technical fields, are all included within the scope of patent protection of this application.

Claims

1. A zero-code integrated risk control method based on Spring Boot starter dependency injection, characterized in that, The method includes the following steps: S1: Configure a risk control rule set in the risk control server, wherein the risk control rule set includes rule identifiers and version information; S2: Push the set of risk control rules to the configuration management center; S3: In the configuration management center, a dynamic mapping relationship is established and maintained between the unified resource identifier of the business system interface and the risk control rule set, taking the business system identifier as the dimension; S4: The risk control client component is integrated by the business system by introducing a pre-built SpringBoot starter dependency, in a zero-code manner; S5: The risk control client component automatically completes configuration loading and initialization when the business system starts; S6: Obtain the dynamic mapping relationship from the configuration management center through the risk control client component, specifically including: the configuration management center actively pushes update information to the risk control client component when the rule changes, and / or the risk control client component periodically initiates a pull request to the configuration management center to obtain update information; S7: The obtained dynamic mapping relationship is cached locally in the business system through the risk control client component; S8: The interceptor built into the risk control client component intercepts the business request before it enters the business logic processing. It automatically judges the dynamic mapping relationship by querying the local cache. When it is determined that the Uniform Resource Identifier of the business interface corresponding to the business request exists in the dynamic mapping relationship, it automatically sends a risk verification request to the risk control server according to the dynamic mapping relationship, and decides whether to allow the business request to continue to execute the subsequent business logic based on the returned verification result. The risk control rule set includes one or more risk rules marked as lightweight. Step S7 specifically includes: The risk control client component caches the dynamic mapping relationship from the configuration management center, and simultaneously caches the judgment logic of the lightweight risk rule. In step S8, the specific steps for automatically initiating a risk verification request to the risk control server based on the dynamic mapping relationship include: After intercepting the current business request, the judgment logic of the lightweight risk rule related to the current business request is loaded and executed first. If a deterministic risk verification result can be obtained based on the judgment logic of the lightweight risk rule, then a decision is made on whether to allow the business request to continue to be executed based on the result, and the step of initiating a risk verification request to the risk control server is no longer executed. If a deterministic risk verification result cannot be obtained based on the judgment logic of the lightweight risk rules, then a risk verification request is sent to the risk control server. The method includes: The risk control server generates a decision credential, which encapsulates at least the following: the risk control rule identifier on which the verification result is based, the input feature data fingerprint, and the verification result. The cryptographic hash value of the decision credential is recorded in an immutable storage medium; Based on the risk control rule identifier and input feature data fingerprint encapsulated in the decision credential, in a verification environment independent of the risk control server, a simulation verification result is recalculated and output by calling the corresponding risk control rule logic. The simulation verification results recalculated based on the decision credentials are compared with the original verification results encapsulated in the decision credentials to achieve auditing of the historical decision-making process. The method further includes: Generate a globally unique tracking identifier for pending business requests; In step S8, when the business system initiates a risk verification request to the risk control server, it carries the tracking identifier in the risk verification request. After receiving the risk verification request, the risk control server associates the risk logs and rule hit records generated during the internal processing with the received tracking identifier. After the business request is processed based on the verification result, by querying the tracking identifier, the complete decision-making link information from the business system to the risk control server can be obtained and displayed. The complete decision-making link information includes at least: the context information of the business request, the time when the risk verification request was initiated, the verification result returned by the risk control server, and the specific risk control rule and its decision logic that triggered the verification result.

2. The zero-code integrated risk control method based on Spring Boot starter dependency injection as described in claim 1, characterized in that, The risk control client component is integrated into the business system in a zero-code manner by introducing a pre-built Spring Boot starter dependency, specifically including: In the configuration file of the business system, the authentication and connection configuration with the configuration management center is completed through the business system identifier; The Spring Boot starter dependency automatically creates and configures the configuration management, rule acquisition, and request interception modules of the risk control client component when the business system starts, and automatically registers the built-in interceptors into the web request processing flow of the business system.

3. The zero-code integrated risk control method based on Spring Boot starter dependency injection as described in claim 1, characterized in that, In step S8, when initiating a risk verification request to the risk control server, the method further includes: Extract predefined business parameters from the currently intercepted business request; The business parameters are encapsulated in the risk verification request and sent to the risk control server, so that the risk control server can make a risk judgment in combination with the corresponding risk control rules.

4. The zero-code integrated risk control method based on Spring Boot starter dependency injection as described in claim 1 or 3, characterized in that, In step S8, the decision on whether to allow the business request to continue executing subsequent business logic based on the returned verification result specifically includes: When the verification result indicates that there is a risk, the interceptor directly returns an error response to the client, interrupting the subsequent process of the business request; When the verification result is no risk, the business request is allowed to continue executing subsequent business logic.

5. The zero-code integrated risk control method based on Spring Boot starter dependency injection as described in claim 1, characterized in that, The dynamic mapping relationship is cached locally in the business system as a local cache with an expiration time. The method further includes: When the cache expires or an update notification is received from the configuration management center, step S6 is re-executed to obtain the dynamic mapping relationship from the configuration management center to update the local cache.

6. The zero-code integrated risk control method based on Spring Boot starter dependency injection as described in claim 1, characterized in that, The method further includes: Configure a canary release strategy for the risk control rule set, the canary release strategy including the target rule version and traffic routing rules based on user identifier, device identifier or network address; In step S8, when the business system initiates a risk verification request to the risk control server, it extracts the corresponding user identifier, device identifier, or network address from the context of the current business request as a traffic identifier, and carries the traffic identifier in the risk verification request. The risk control server receives the risk verification request, parses the traffic identifier, and matches it according to the traffic routing rules in the canary release strategy. If the match is successful, the target rule version is applied for risk verification; if the match fails, the default version of the risk control rule set is applied for risk verification.

7. A zero-code integrated risk control system based on Spring Boot starter dependency injection, characterized in that, The system is used to perform the method as described in any one of claims 1 to 6, the system comprising: A risk control server is configured to store and configure a set of risk control rules, the set of risk control rules including rule identifiers and version information; The configuration management center is connected to the risk control server to receive and store the risk control rule set pushed from the risk control server, and to establish and maintain a dynamic mapping relationship between the unified resource identifier of the business system interface and the risk control rule set, with the business system identifier as the dimension. The business system integrates a risk control client component that is injected with zero coding by introducing a pre-built Spring Boot starter dependency; wherein, the risk control client component further includes: The configuration loading and initialization module is used to automatically complete configuration loading and initialization when the business system starts. The mapping relationship management module is used to obtain and update the dynamic mapping relationship from the configuration management center, and cache the dynamic mapping relationship locally in the business system; wherein, the methods of obtaining updates include: receiving proactive push from the configuration management center when rules change, and / or periodically initiating pull requests to the configuration management center; The request interception and judgment module has a built-in interceptor, which is used to intercept business requests before they enter the business logic processing, and automatically judges them by querying the dynamic mapping relationship in the local cache. The risk verification execution module is used to automatically initiate a risk verification request to the risk control server based on the dynamic mapping relationship when the request interception and judgment module determines that the Uniform Resource Identifier of the business interface corresponding to the business request exists in the dynamic mapping relationship, and decide whether to allow the business request to continue to execute subsequent business logic based on the returned verification result.

Images