Decision engine and method based on risk control strategy

Abstract

The invention discloses a risk control strategy-based decision engine and method, and relates to the technical field of financial risk control, and the decision engine comprises a strategy warehouse module, a mapping service module, an execution engine module, a data management module, a version rollback module, a security scale module, and a monitoring alarm module. According to the invention, function decoupling is realized through collaborative design of the seven modules, and the modules interact through a unified interface, support strategy dynamic loading, gray release, distributed parallel execution, version governance and security compliance capabilities, and ensure high cohesion and low coupling of the system; through unique strategy version management, intelligent mapping and gray release, plug-in parallel execution, multi-version consistency view, block chain audit rollback, security compliance management and control, intelligent monitoring and other technical innovations, a complex, dynamic and high-concurrency risk control business scene is effectively supported; the security, the flexibility, the expandability and the auditing performance of the decision engine are remarkably improved, and the technical advancement and the industry creativity are high.

Description

Technical Field

[0001] This invention relates to the field of financial risk control technology, and in particular to a decision engine and method based on risk control strategies. Background Technology

[0002] Financial-grade risk control technology is a core branch of fintech, focusing on identifying, assessing and managing risks in financial business through real-time, highly reliable technical means. Its core objectives are to ensure transaction security, prevent fraud, reduce the probability of credit default, and meet stringent financial regulatory requirements.

[0003] The published patent, CN115018624A, describes a decision engine and method based on risk control strategies. The method includes: a strategy scheduling module acquiring a request message to be decided, parsing the request message to obtain parsed variables, determining a target strategy file based on the parsed variables, generating a calling instruction based on the target strategy file, and sending the calling instruction to a file calling module; the file calling module receiving the calling instruction and sending the target strategy file to a decision processing module based on the calling instruction; the decision processing module receiving the target strategy file, performing decision processing based on the target strategy file and the parsed variables to obtain a result variable, and sending the result variable to the strategy scheduling module; and the strategy scheduling module receiving the result variable and determining the decision result of the request message based on the result variable. Each module in the decision engine handles its own work, segmenting the decision process, which facilitates deployment and reduces the difficulty of modification.

[0004] The aforementioned patents have the following drawbacks: they rely solely on product number as the single dimension for mapping strategy files, making them unsuitable for multi-dimensional routing scenarios such as channels, regions, and real-time risk control indicators; they lack a hot update mechanism, resulting in long strategy deployment cycles; they use sequential call rules units without resolving node dependencies, making it impossible to achieve DAG parallel scheduling; they suffer from high latency under high concurrency; they cannot dynamically handle traffic peaks; strategy versions require a full switch, leading to a high risk of failure; they cannot quickly restore to a historical stable version when problems occur; they do not record operations, making operations untraceable; external variables are directly passed, potentially leading to concurrent dirty reads; and they cannot meet the high concurrency, second-level iteration, and stringent regulatory requirements of internet finance businesses. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a decision engine and method based on risk control strategies.

[0006] To achieve the above objectives, this invention adopts the following technical solution: a risk control strategy-based decision engine, including a strategy repository module, a mapping service module, an execution engine module, a data management module, a version rollback module, a security compliance module, and a monitoring and alarm module. The strategy repository module stores strategy files, rule scripts, and metadata with version numbers, and supports Git / API dual-channel commits, branch management, and secure signatures. The mapping service module dynamically matches the target strategy version based on multi-dimensional context such as product number, channel, region, and real-time risk control indicators using a consistent hashing and conditional routing algorithm. The execution engine module consists of a multi-node rule execution container and supports the integration of DMN, Drools, Groovy, Python, SparkUDF, and RESTfulML services. The system comprises several modules: a component-based execution unit that enables parallel execution of independent nodes through DAG parsing; a data management module that generates versioned snapshots of external variables when decision requests arrive, combined with a two-phase cache invalidation strategy to ensure read-write consistency; a version rollback module that records the policy release pipeline, traces back execution records, and supports one-click rollback to any historical stable version; a security and compliance module that includes policy package integrity verification, fine-grained RBAC, audit logs, encrypted transmission, and support for national cryptographic algorithms; and a monitoring and alarm module that collects metrics such as TPS, P99 latency, rule hit rate, and number of abnormal retries, and triggers alarms based on AI anomaly detection. These modules are decoupled from each other and interact through a unified interface to achieve dynamic policy loading, canary release, distributed parallel execution, version governance, and security and compliance risk control decision-making functions.

[0007] As a further description of the above technical solution: The policy repository module supports fast retrieval by version number, branch, and tag. It implements mandatory signature verification when policy files are added to the repository and pushes change events to the monitoring and alarm module.

[0008] As a further description of the above technical solution: The mapping service module includes a rule dimension splitting unit, a canary release unit, and a configuration hot update unit. The rule dimension splitting unit is used to split multi-dimensional routing conditions into cacheable prefix tree indexes. The canary release unit is used to allocate canary traffic according to users, proportions, or feature values. The configuration hot update unit is used to refresh the mapping cache without interrupting the service. The traffic allocation methods of the canary release unit include directed routing by user ID, traffic splitting by percentage, and allocation of differentiated policy versions based on real-time metrics.

[0009] As a further description of the above technical solution: The execution engine module includes a DAG parser, a parallel scheduler, an exception handling unit, and a resource elastic scaling unit. The DAG parser is used to parse the dependencies described in the policy file into a directed acyclic graph. The parallel scheduler dynamically allocates tasks to execution nodes based on the topology sorting result. The exception handling unit provides replay, circuit breaking, and degradation policies. The resource elastic scaling unit automatically expands and shrinks based on queue length and CPU / memory metrics. The parallel scheduler allocates independent execution nodes to independent container nodes for synchronous execution and asynchronously schedules dependent execution nodes according to the data flow order.

[0010] As a further description of the above technical solution: The data management module employs a timestamp-based multi-version concurrency control strategy to generate a consistent view for each decision request.

[0011] As a further description of the above technical solution: The version rollback module utilizes the immutable ledger of the blockchain to record and publish pipeline information, thereby achieving traceability.

[0012] As a further description of the above technical solution: The security and compliance module provides a unified encrypted channel encapsulation library based on TLS, which negotiates SM2 / SM4 / SMTLS1.1 by default and supports fine-grained RBAC access control down to policy version, environment, and operation level.

[0013] As a further description of the above technical solution: The monitoring and alarm module asynchronously collects system operation indicators through a lightweight probe, identifies abnormal fluctuations in performance indicators through a built-in AI anomaly detection engine, and triggers security alarms in real time for signature anomaly events reported by the policy repository module.

[0014] As a further description of the above technical solution: A method for applying to a risk control strategy-based decision engine includes the following steps: S.1. Receive decision requests containing product number, request channel, user region, and real-time risk control indicators; S.2 The mapping service module determines the target policy version by combining consistent hashing with conditional routing algorithm, and allocates requests according to the preset traffic ratio in the canary release scenario. The canary release divides the traffic of requests based on user granularity, traffic ratio or custom feature value. S.3. Call the policy repository module to retrieve the policy file of the target policy version; S.4 The execution engine module uses a DAG resolver to resolve policy dependencies and allocates independent nodes to the rule execution container for parallel execution according to the parallel scheduler. The rule execution container supports the execution units of DMN, Drools, Groovy, Python, SparkUDF and RESTful machine learning services in a pluggable manner, and can be hot-swapped and expanded without restarting the service. S.5 The data management module generates a snapshot version number for the request and provides a consistent view, and all execution nodes access the data based on the same snapshot version number; S.6. If an exception occurs during execution, the exception handling unit selects a replay, circuit breaker, or degradation strategy and notifies the monitoring and alarm module to record the number of exception retries. The circuit breaker protection avoids the avalanche effect when the fault node suspends receiving new tasks and automatically resumes task reception after the fault is recovered. S.7. Aggregate the results of each execution node to form a single decision output and return it to the caller; S.8 The version rollback module records the execution summary based on the blockchain ledger, and supports one-click rollback to a historical stable version when necessary; S.9 The security and compliance module audits the entire operation and transmits data through an encrypted channel.

[0015] The present invention has the following beneficial effects: 1. In this invention, functional decoupling is first achieved through the collaborative design of the strategy repository module, mapping service module, execution engine module, data management module, version rollback module, security compliance module, and monitoring and alarm module. Each module interacts through a unified interface, supporting dynamic policy loading, canary release, distributed parallel execution, version governance, and security compliance capabilities, ensuring high cohesion and low coupling of the system. Through unique policy version management, intelligent mapping and canary release, plug-in parallel execution, multi-version consistent view, blockchain audit rollback, security compliance control, and intelligent monitoring, this invention effectively supports complex, dynamic, and high-concurrency risk control business scenarios, significantly improving the security, flexibility, scalability, and auditability of the decision engine, demonstrating strong technological advancement and industry innovation.

[0016] 2. This invention supports dual-channel strategy submission via Git and API. The Git channel retains a complete commit log for auditing, while the API channel adapts to automated pipelines, ensuring seamless integration of strategy changes into the development process. All strategy files are forcibly appended with version numbers and digital signatures, and signature integrity is verified upon storage to prevent tampering. It supports fast retrieval by version number, branch, and tag, and pushes change events to the monitoring and alarm module. Based on consistent hashing combined with conditional routing algorithms, it dynamically matches the target strategy version according to multi-dimensional context such as product number, channel, region, and real-time risk control indicators. Rule-dimensional splitting units construct cacheable prefix tree indexes to reduce query latency. The canary release unit allocates canary traffic based on user granularity, traffic ratio, or feature values. It supports user ID-based targeted routing, percentage-based traffic splitting, and differentiated allocation of policy versions based on real-time metrics, enabling smooth deployment and rollback. A DAG resolver parses policy dependencies into a directed acyclic graph, identifying input-output dependencies between nodes. A parallel scheduler, based on topology sorting results, assigns independent nodes to independent rule execution containers for synchronous execution, while dependent nodes are scheduled asynchronously according to data flow. The rule execution containers support execution units for DMN, Drools, Groovy, Python, SparkUDF, and RESTful machine learning services in a pluggable manner, supporting hot-swappable expansion. Resource elastic scaling units automatically expand and shrink container nodes based on queue length and CPU / memory metrics, ensuring high concurrency throughput.

[0017] 3. In this invention, a timestamped versioned snapshot is generated for each decision request. A consistent view is generated by combining this with a timestamped multi-version concurrency control strategy. A two-stage cache invalidation strategy is employed: in stage one, local cached historical versions are proactively invalidated before variable updates; in stage two, the metadata table is broadcast to other nodes after the update, ensuring global consistency of cross-node reads and writes and avoiding concurrent dirty reads. The immutable ledger of the blockchain is used to record pipeline information, enabling traceable operations. One-click rollback to any historical stable version is supported, and the target strategy file is automatically loaded and activated. The merging process automatically detects version conflicts, generates conflict reports, and generates a unique semantic version number through an approval process, providing policy package integrity verification. It supports verification, fine-grained RBAC, audit logs, encrypted transmission, and national cryptographic algorithms. Based on asymmetric encryption, it verifies signatures. Fine-grained RBAC controls policy versions, environments, and operation level permissions. Audit logs record and archive key operations. By default, it enables encrypted transmission using national cryptographic algorithms such as SM2 / SM4 / SMTLS1.1 to ensure data security and compliance. It asynchronously collects metrics such as TPS, P99 latency, rule hit rate, and number of abnormal retries through lightweight probes. The AI ​​anomaly detection engine identifies performance fluctuations and rule hit rate deviations based on time-series models, triggering tiered alarms. It receives signature anomaly events from the policy repository module and matching failure events from the mapping service module, enabling real-time monitoring of security and configuration risks. Attached Figure Description

[0018] Figure 1 This is a diagram of the engine architecture of the present invention; Figure 2 This is a flowchart of the engine operation process of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Reference Figure 1-2 This invention provides an embodiment of a risk control strategy-based decision engine, comprising a strategy repository module, a mapping service module, an execution engine module, a data management module, a version rollback module, a security compliance module, and a monitoring and alarm module. The strategy repository module stores strategy files, rule scripts, and metadata with version numbers, and supports Git / API dual-channel commits, branch management, and secure signatures. The mapping service module dynamically matches target strategy versions based on multi-dimensional context including product number, channel, region, and real-time risk control metrics using a consistent hashing and conditional routing algorithm. The execution engine module consists of a multi-node rule execution container and supports pluggable execution of DMN, Drools, Groovy, Python, SparkUDF, and RESTfulML services. The system comprises several modules: a unit that enables parallel execution of independent nodes through DAG parsing; a data management module that generates versioned snapshots of external variables when decision requests arrive, and a two-phase cache invalidation strategy to ensure read-write consistency; a version rollback module that records the policy release pipeline, backtracks execution records, and supports one-click rollback to any historical stable version; a security and compliance module that includes policy package integrity verification, fine-grained RBAC, audit logs, encrypted transmission, and support for national cryptographic algorithms; and a monitoring and alarm module that collects metrics such as TPS, P99 latency, rule hit rate, and number of abnormal retries, and triggers alarms based on AI anomaly detection. These modules are decoupled from each other and interact through a unified interface to achieve dynamic policy loading, canary release, distributed parallel execution, version governance, and security and compliance risk control decision-making functions.

[0021] The policy repository module supports fast retrieval by version number, branch, and tag. It implements mandatory signature verification when policy files are added to the repository and pushes change events to the monitoring and alarm module.

[0022] The mapping service module includes a rule dimension splitting unit, a canary release unit, and a configuration hot update unit. The rule dimension splitting unit is used to split multi-dimensional routing conditions into cacheable prefix tree indexes. The canary release unit is used to allocate canary traffic according to users, proportions, or feature values. The configuration hot update unit is used to refresh the mapping cache without interrupting the service. The traffic allocation methods of the canary release unit include directed routing by user ID, traffic splitting by percentage, and allocation of differentiated policy versions based on real-time metrics.

[0023] The execution engine module includes a DAG parser, a parallel scheduler, an exception handling unit, and a resource elastic scaling unit. The DAG parser is used to parse the dependencies described in the policy file into a directed acyclic graph. The parallel scheduler dynamically allocates tasks to execution nodes based on the topology sorting result. The exception handling unit provides replay, circuit breaking, and degradation policies. The resource elastic scaling unit automatically expands and shrinks based on queue length and CPU / memory metrics. The parallel scheduler allocates independent execution nodes to independent container nodes for synchronous execution and asynchronously schedules dependent execution nodes according to the data flow order.

[0024] The data management module employs a timestamp-based multi-version concurrency control strategy to generate a consistent view for each decision request.

[0025] The version rollback module utilizes the immutable ledger of the blockchain to record and publish pipeline information, thereby achieving traceability.

[0026] The security and compliance module provides a unified encrypted channel encapsulation library based on TLS, which negotiates SM2 / SM4 / SMTLS1.1 by default and supports fine-grained RBAC access control down to policy version, environment, and operation level.

[0027] The monitoring and alarm module asynchronously collects system operation indicators through a lightweight probe, identifies abnormal fluctuations in performance indicators through a built-in AI anomaly detection engine, and triggers security alarms in real time for signature anomaly events reported by the policy repository module.

[0028] A method for applying to a risk control strategy-based decision engine includes the following steps: S.1. Receive decision requests containing product number, request channel, user region, and real-time risk control indicators; S.2 The mapping service module determines the target policy version by combining consistent hashing with conditional routing algorithm, and allocates requests according to the preset traffic ratio in the canary release scenario. The canary release divides the traffic of requests based on user granularity, traffic ratio or custom feature value. S.3. Call the policy repository module to retrieve the policy file of the target policy version; S.4 The execution engine module uses a DAG resolver to resolve policy dependencies and allocates independent nodes to the rule execution container for parallel execution according to the parallel scheduler. The rule execution container supports the execution units of DMN, Drools, Groovy, Python, SparkUDF and RESTful machine learning services in a pluggable manner, and can be hot-swapped and expanded without restarting the service. S.5 The data management module generates a snapshot version number for the request and provides a consistent view, and all execution nodes access the data based on the same snapshot version number; S.6. If an exception occurs during execution, the exception handling unit selects a replay, circuit breaker, or degradation strategy and notifies the monitoring and alarm module to record the number of exception retries. The circuit breaker protection avoids the avalanche effect when the fault node suspends receiving new tasks and automatically resumes task reception after the fault is recovered. S.7. Aggregate the results of each execution node to form a single decision output and return it to the caller; S.8 The version rollback module records the execution summary based on the blockchain ledger, and supports one-click rollback to a historical stable version when necessary; S.9 The security and compliance module audits the entire operation and transmits data through an encrypted channel.

[0029] The strategy repository module centrally stores all strategy files, rule scripts, and their associated metadata, including author, commit time, and policy scope. All stored objects are forcibly appended with version numbers, ensuring that different versions do not overwrite each other. This guarantees that each strategy file has an independent and traceable version record for every modification. Version numbers follow the semantic conventions of major, minor, and revision numbers, supporting precise retrieval by version range. Two strategy submission methods are provided: a Git channel allows developers to submit strategy changes via Git operations, fully preserving the Commit Log for auditing; and an API channel provides standardized interfaces for automated pipelines, supporting direct uploads of strategy packages by CI / CD tools. Both channels share the same storage platform, ensuring consistency of strategy content and metadata. This dual-channel design balances development habits with automated integration needs, allowing seamless integration of strategy changes into existing development processes. Multiple long-term or short-term branches can be created within the repository to isolate different product lines, gray-scale environments, or experimental functions, supporting independent development and testing. It supports merging strategy differences on demand and generating new version numbers, but merging approvals or releasing strategies still falls under the version rollback module. The version structure based on storage enables multi-branch isolation capabilities, supporting the creation of feature branches for independent development. For release and testing, and to isolate different product lines, gray-scale environments, or experiments, the main branch only accepts policy versions that have passed quality verification. Policy differences are merged between branches as needed to generate new version numbers, but the merging approval or release of policies still falls under the version rollback module. The merging process automatically detects version conflicts. During the file entry stage, mandatory signature verification is implemented for all policy files and rule scripts entered into the database. Based on a secure signature mechanism, an asymmetric encryption algorithm is used to generate a unique digital signature for each object, binding the submitter's identity to prevent policy tampering. When the policy file is released for execution, the caller must verify the signature integrity before reading it to prevent tampering. Inconsistencies are immediately rejected during loading and reported to the security and compliance module. The signing key is protected by a hardware security module or key management system. It provides fast retrieval capabilities by version number, branch, and tag, enabling the mapping service module to find the target policy in milliseconds. It supports batch export of policy packages of specified versions for the distributed execution engine to pull. It can also push change events, pushing new commits, branch merges, and signing anomaly events to the monitoring and alarm module in real time, allowing it to calculate the policy iteration frequency or trigger security alarms. The pushed content only covers the repository's own metadata and does not include execution metrics to avoid overlap with the functions of the real-time monitoring and alarm module.

[0030] The mapping service module receives context information from decision requests, including product number, request channel, user region, and real-time risk control indicators. It performs a two-level decision-making process in the memory-mapped table using consistent hashing and conditional routing algorithms. The consistent hashing algorithm, combined with the conditional routing algorithm, dynamically matches the target policy version corresponding to the current request, ensuring the mapping logic flexibly adapts to changes in business scenarios. Consistent hashing maintains stable request hits during node scaling, while the conditional routing algorithm performs fine-grained rule judgments on dynamic fields to ultimately determine the policy version. The entire process does not persist policy files or parse rule content; it simply outputs version identifiers, avoiding overlap with the distributed execution engine and policy repository. The rule dimension splitting unit breaks down multi-dimensional routing conditions, including product number, channel, region, and real-time indicators, into independently cacheable logical units, thereby constructing a prefix tree index. The prefix tree index only stores dimension prefixes and policy version pointers, optimizing caching for high-frequency query conditions. Combined with local caching, this significantly reduces the latency of a single query in the mapping table. A built-in canary release unit allocates canary traffic according to preset rules when a new policy version is released, and distributes traffic based on user granularity, traffic ratio, or custom feature values. Requests are split into different versions to achieve smooth deployment or rollback. User-granular allocation routes traffic to the new version strategy based on user ID or feature values. Proportional allocation splits traffic to the old and new versions by a percentage. Feature value allocation assigns differentiated strategy versions based on real-time metrics. The canary deployment logic is only responsible for traffic splitting, not for version approval or rollback records. Related governance is handled by the version rollback module. The configuration hot update unit updates the strategy mapping table online when it detects a change in mapping configuration, and the update process does not affect running service instances. The configuration hot update unit dynamically refreshes the mapping in memory. The cache update operation is transparent to the execution engine, requiring no service restart or interruption of the decision-making process. This capability guarantees zero downtime, and the update is completely unaware of the running instance. A unique policy version identifier is generated based on the multi-dimensional context for subsequent module calls. The mapping table adopts a key-value structure, where the key is the hash value of the multi-dimensional conditions and the value is the target policy version number. It supports millisecond-level matching response to meet the needs of high-concurrency scenarios. If the requested dimension combination does not match a default version or a neighboring policy, and the mapping table is not hit, the preset fallback policy version is activated, the matching failure event is recorded, and an alarm is pushed to the monitoring module.

[0031] The execution engine module transforms the policy version ID returned by the mapping service module into a high-concurrency, scalable rule execution flow and outputs a unified decision result to upstream or subsequent modules. After receiving the target policy file, the execution engine module analyzes the execution node dependencies described in the policy file using a DAG parser, generates a directed acyclic graph (DAG), identifies input-output dependencies between execution nodes to ensure no circular references, and provides the topology foundation for subsequent parallel scheduling. Each execution node loads a rule execution container, within which various types of execution units run, including DMN, Drools, Groovy, Python, SparkUDF, and R... ESTful machine learning service uses hot-swappable execution units as plug-ins, eliminating the need to restart the entire mesh or modify the engine's core code. The execution environment automatically adapts to the technology stack requirements of different rule types. Containers are independent of each other while exposing a unified execution interface to the parallel scheduler. The execution engine does not parse metadata other than policy content, avoiding duplication of storage functions with the policy repository module. The DAG parser parses the node dependencies declared in the policy file into a directed acyclic graph, providing topology sorting results for subsequent scheduling. The parallel scheduler concurrently distributes independent nodes to each execution container based on the DAG topology and real-time load. When queue length or CPU / memory metrics change... During this process, the scheduler triggers dynamic scaling to maintain an optimal balance between throughput and cost. Through this mechanism, in embodiment S103, the system can simultaneously execute subgraph nodes such as "credit scoring, anti-fraud, and compliance verification," achieving parallel acceleration. Execution nodes that are independent of each other are assigned to independent container nodes for synchronous execution, while execution nodes with dependencies are asynchronously scheduled according to the data flow order, ensuring that the execution order conforms to the process logic. The exception handling unit provides three types of strategies for each node: replay, circuit breaking, and degradation. When a failure occurs, it first attempts to retry idempotently. If the threshold is exceeded, it automatically triggers circuit breaking or rollback to the preset degradation logic to ensure the availability of the overall decision-making chain. When a node times out or submits repeatedly, the module internally handles the issue. To address these issues, the system prevents intermediate errors from being leaked and avoids confusion with the alarm generation logic of the real-time monitoring and alarm module. Idempotent retries automatically retry replayable tasks to ensure consistent results. Timeout degradation occurs after a timeout, with a simplified execution node outputting the degradation result. Circuit breaker protection suspends the receiving of new tasks by faulty nodes to prevent a cascading failure effect. The resource elastic scaling unit continuously monitors the task queue length, CPU and memory usage, and automatically expands or shrinks execution container instances based on load thresholds. When an indicator triggers a threshold, it automatically starts a new node or shrinks an idle node to achieve horizontal scaling. The scaling process is transparently integrated into the parallel scheduler without affecting tasks already being executed, and it does not handle version gray-scale or rollback operations.

[0032] The data management module is responsible for generating a timestamped versioned snapshot of all external variables in each decision request. It assigns a unique timestamp to each decision request, marking the snapshot version, and stores external variables in isolation by timestamp. This ensures that variable reads and writes from different requests do not interfere with each other. A two-phase cache invalidation strategy and a timestamp-based multi-version concurrency control strategy generate a read-only consistent view, completely avoiding concurrent dirty reads and ensuring that all reads and writes in the same decision chain fall on the same data version. Upon receiving the decision context, the module immediately requests a monotonically increasing snapshot version number and appends it to the context of the current call for identification and pass-through by the subsequent execution engine module. Multi-version concurrency control based on timestamps provides a consistent view for concurrent requests. All read operations retrieve the latest version less than or equal to the snapshot version number from the multi-version data structure, avoiding reading uncommitted or outdated data and achieving instantaneous consistent reads under high concurrency. Write operations generate a new version greater than the snapshot version number, ensuring that reads after writes do not pollute the current request view. The two-phase cache invalidation strategy safeguards data read and write operations. Consistency is achieved through two phases: Phase 1 involves proactively invalidating historical versions of external variables in the local cache before the external variable is updated; Phase 2 involves broadcasting or asynchronously updating the metadata table after the variable is updated, synchronizing expired information to other running nodes to avoid reading stale data across nodes. These two steps ensure that hot data hits with low latency and global consistency are completed within milliseconds, without triggering service restarts or overlapping with the caching logic of dynamic mapping services or execution engine modules. Snapshot data is stored independently according to the request timestamp, serving only the current decision-making process. Temporary snapshots are automatically cleaned up after the decision is completed, retaining only the necessary version records for auditing, providing a consistent view to the execution engine module, shielding the intermediate state of external variable changes, and encapsulating versioned snapshots into immutable datasets for direct use by the rule execution unit. During execution, all execution nodes read the same snapshot version, ensuring that the decision logic is based on static data, operations are first implemented on the new version, and then the cache is refreshed through the two-phase invalidation strategy, without affecting the view of the currently active snapshot version number. With the help of distributed invalidation broadcasting, the next request on a different node will definitely generate a new snapshot version number based on the latest snapshot, eliminating concurrent write-read penetration.

[0033] The version rollback module is responsible for recording the complete pipeline information of policy releases. All release and rollback operations are written to the blockchain's immutable ledger as release transactions. Ledger fields include release time, publisher, CommitID, policy version number, release content, approver, grayscale ratio, hash signature, and target environment, ensuring that no one can tamper with it afterward. For multi-branch operations of the same policy, the ledger saves the branch topology and merging relationship, providing a data foundation for subsequent conflict analysis and historical tracing. The module stores and manages the historical record of policy execution, including metadata for each decision request. It supports quick retrieval of backtracking execution records by time range, version number, or request identifier. Key summaries of execution records are synchronously written to the blockchain to enhance audit reliability. When a new version of the policy encounters problems, the module supports one-click rollback to any historical stable version. Rollback operations require no manual intervention; the system automatically loads the target version's policy file and applies it. Rollback can cover grayscale or full environments, ensuring that the recovery process does not affect other running policy instances. The time of all rollback operations, The target version and operator information are recorded in the blockchain ledger and simultaneously pushed to the audit log. During the strategy merging process, the module automatically detects version conflicts and generates conflict reports for manual handling. Strategy merging requires approval from the module. Only after approval can a new version number be generated. The approver, time, and result are recorded and written to the blockchain. After merging, a new version number conforming to semantic markup is generated, ensuring that the version identifier is unique and traceable. During the canary release process, the module is responsible for managing the switching logic of the canary strategy version. According to preset rules, requests are dynamically allocated to the old and new versions. If the canary version is abnormal, the module supports quick rollback to the stable version and redirects canary traffic back to the original version to ensure business continuity. All release, rollback, and merging operations generate audit logs and are stored on the blockchain. Ledger data, audit logs, and approval records can be directly delivered to audit, internal control, or regulatory audits, meeting the compliance requirements of traceable operation process and verifiable results. It connects to the signature verification results and RBAC authentication of the security compliance module, but does not duplicate the specific encryption or permission logic.

[0034] The security and compliance module provides five key capabilities across the entire process: policy package integrity verification, fine-grained RBAC, audit logs, encrypted transmission, and support for national cryptographic algorithms. This meets the mandatory requirements of financial regulators for data security, identity control, and traceability. Policy package integrity verification exposes a unified secure signature verification service, accepting file hashes and signatures uploaded by the policy repository module. It uses asymmetric encryption algorithms to verify the submitter's digital signature and outputs a pass / reject result. If verification fails, it immediately reports the anomaly to the repository module for interception during the data entry process. The module also manages the key lifecycle, assigning public and private key pairs to each policy contributor. Private keys are hosted in a hardware security module or key management system, while public keys are centrally registered to prevent forgery, based on role-based authentication. The access control mechanism manages user operation permissions, dividing permission granularity into three dimensions: policy, environment, and operation. Through role binding and permission policies, it restricts unauthorized users from accessing sensitive functions, supporting precise authorization down to a specific version policy × pre-production environment × rollback operation level. The permission model is maintained by a role-resource-operation mapping. Before the version rollback module executes a merge, release, or rollback, it uniformly calls the authentication interface to determine the authorization relationship between the current operator and the target resource, ensuring operational compliance. Permission control covers all critical processes, but the business logic for the approval process is handled by the version rollback module. The module generates an immutable, end-to-end audit log, recording key operations such as policy release, rollback, permission changes, and signature verification results. The logs include operation time, operator identity, operation type, and result status. An append-only log channel is provided, log copies are archived daily, and retention periods comply with regulatory requirements. All logs are stored according to financial regulatory requirements. The system interfaces with a real-time monitoring and alarm module to implement security alerts for post-event auditing and compliance checks, but does not involve the collection of execution metrics. To ensure secure data transmission between system modules, a unified TLS-based encryption channel encapsulation library is exposed, defaulting to SM2 / SM4 / SMTLS1.1 negotiation, compatible with international algorithms to handle cross-border links, preventing data theft or tampering during transmission. The encryption process is transparent to business logic and requires no intervention from other modules, providing performance-friendly session reuse. With hardware-accelerated access points, encryption overhead is kept under control in high-concurrency risk control scenarios. To meet the security standards of China's financial industry, it supports national cryptographic algorithms approved by the State Cryptography Administration. These algorithms are applied to digital signature generation, encrypted transmission, and key management, ensuring that the system complies with the requirements of stringent financial supervision. Financial-grade identity and access control meet the requirements of the "Financial Data Security Specification of the People's Bank of China" regarding the principle of least privilege and the immediate effect of permission changes. All external communications are enabled by default using the SM series algorithms. Critical links support software / hardware dual-stack, complying with the encryption and decryption requirements of the regulation "GB / T39786-2021". Log fields and retention periods comply with the "Cybersecurity Law" and the data retention regulations of regulatory authorities, supporting delivery for regulatory spot checks.

[0035] The real-time monitoring and alarm module is responsible for collecting system operation metrics, detecting abnormal events, and triggering alarms. System operation metrics include TPS, P99 latency, and rule hit rate. TPS is used to calculate system throughput in real time, P99 latency is used to monitor the tail latency of request response time to ensure high percentile performance is achieved, and rule hit rate is used to record the actual trigger frequency of policy rules for optimizing policy effectiveness. Metrics are collected asynchronously from the execution chain through lightweight probes to avoid intruding on business logic or affecting execution performance. Lightweight instrumentation is embedded in key nodes to calculate TPS and P99 latency by request dimension, without parsing business data. To avoid coupling with the execution logic, the rule hit rate probe reports the hit identifier and version number to this module every time the execution engine completes a rule evaluation, used to measure the effectiveness of the policy. The exception retry counter increments the corresponding count and pushes an event only when the exception handling unit triggers replay or degradation. It collects and counts the number of exception retries, records retry operations triggered by node failures in the execution engine module, distinguishes exception types, receives signature exception events and consistency exception passing events pushed by the policy repository module, marks them as security risk events, monitors matching failure events of the mapping service module, identifies routing configuration defects, and has an AI anomaly detection engine. A time-series model is trained based on historical metric data. For non-linear fluctuation scenarios, the model automatically learns a baseline and identifies abnormal fluctuations in performance metrics. It automatically detects scenarios where rule hit rates deviate from expected ranges, assisting in determining policy failures or configuration errors. Detection results are output as abnormal events, avoiding direct rollback or circuit breaker triggers to prevent overlap with version control or execution engine responsibilities. Static or dynamic thresholds are set for different metrics. Capacity alarms are triggered when metrics fall below a preset static threshold. Dynamic threshold alarm limits are adaptively adjusted based on AI anomaly detection results to reduce false alarms. Alarm policies support warning / critical / catastrophic levels and are linked to email. The system uses message, SMS, and work order notification channels to send information including indicator snapshots, policy version numbers, and fault module locations, enabling on-duty personnel to quickly assess the situation. It receives audit log events from the security and compliance module, generates real-time security alerts, and immediately triggers security alerts for signature anomalies or unauthorized access attempts reported by the policy repository module. It provides a real-time monitoring dashboard that dynamically displays the time-series trends of TPS, latency, and hit rate indicators. It aggregates audit logs and event logs pushed by various modules, but does not store original policy files or execution snapshot data. Logs are archived according to regulatory requirements and can be quickly retrieved by time range and event type.

[0036] Example 1: Online Credit Instant Approval Scenario On a certain online microloan platform, upon receiving a loan request, the gateway immediately passes the product number, request channel, user region, and real-time risk control indicators to the mapping service module. This module uses consistent hashing and conditional routing algorithms to locate the "Credit-Prod-v3.2.1" policy version within milliseconds. If the new policy is being rolled out in a canary release unit with 10% traffic, then some requests are allocated to "v3.3.0-beta" based on user ID. The mapping results are refreshed online via the configuration hot update unit without requiring a service restart. Subsequently, the execution engine module pulls the hit policy file, the DAG parser generates a directed acyclic graph for credit scoring, anti-fraud, and compliance verification, and the parallel scheduler simultaneously schedules independent nodes to rule execution containers that support DMN, Drools, and SparkUDF. When CPU load spikes, the resource elastic scaling unit automatically horizontally scales the load. Expanding to two container instances, if a node times out, the exception handling unit replays the event twice. If the threshold is exceeded, a circuit breaker is triggered and the default scoring logic is rolled back. Throughout the process, the data management module generates a unique snapshot version number for each request, employing a multi-version concurrency control strategy and a two-phase cache invalidation strategy to ensure that all nodes read and write based on the same data view. The strategy execution summary is simultaneously written to the immutable blockchain ledger. If a sudden drop in hit rate is detected, operations and maintenance can roll back to the stable version "v3.1.8" with one click through the version rollback module. The monitoring and alarm module continuously collects TPS, P99 latency, rule hit rate, and number of abnormal retries, and uses AI anomaly detection to determine performance baseline drift. Any signature verification failure event is reported by the security compliance module, synchronously written to the audit log, and pushed to on-duty personnel through the SM2 / SM4 / SMTLS1.1 encrypted link to achieve end-to-end security compliance.

[0037] Example 2: Intelligent Review Scenario for Insurance Claims In large insurance companies, after a customer submits a claim application with a photo, the mapping service module quickly locates "Claim-v2.0.4" using a prefix tree index based on the product number (auto insurance), region (East China), and real-time risk score. If the region is piloting a new image recognition model, the gray-scale release unit directs high-risk cases to "v2.1.0-gray" at 30% capacity. After the execution engine module reads the strategy file, the DAG parser identifies three subgraphs: image authenticity detection, rule comparison, and manual review triggering. The image detection node is run in a GPU container by a RESTful machine learning service, while the rule comparison node calls Gr... In the oovy script library, if the image service latency is abnormal, the exception handling unit immediately downgrades to static threshold judgment and records the number of exception retries. To ensure process traceability, the data management module generates a snapshot version number and locks external policy data when a case is created. The version rollback module writes each rule change, grayscale ratio, and approver information into the blockchain ledger for easy auditing in the future. During operation, if the monitoring and alarm module detects that the rule hit rate is continuously lower than 5%, it issues a "critical" level alarm via email and SMS channels. At the same time, fine-grained RBAC is used to restrict only the claims risk control group to view highly sensitive image fields. All transmissions use a unified TLS encrypted channel.

[0038] Example 3: Cross-border E-commerce Payment Risk Management Scenario During settlement, the cross-border platform sends the channel (Pay-X), user region (EU), and real-time payment score to the decision engine. The mapping service module uses consistent hashing to ensure stable request hits after node expansion and combines conditional routing algorithms to finely match "PayRisk-v1.5.9". If the configuration hot update unit is enabled to adjust the EU KYC policy, it only needs to refresh the mapping cache within 200ms to take effect. The execution engine module's parallel scheduler processes anti-money laundering detection and limit verification in parallel. When the queue length suddenly increases, the resource elastic scaling unit automatically expands to 20 Pods. If a Spark task fails, the exception handling unit records the replay and triggers degradation logic after a threshold, outputting... Risk assessment and upstream flow control are notified. The data management module ensures data consistency under the EU GDPR scenario through a two-stage cache invalidation strategy. Execution summaries and key indicators are written to the blockchain ledger for easy regulatory auditing. If a new version causes P99 latency to exceed 500ms, the AI ​​anomaly detection of the monitoring and alarm module determines it as a performance anomaly and triggers a catastrophic alarm. The version rollback module automatically rolls back to the previous stable version and synchronizes gray-scale traffic. Throughout the process, the security and compliance module uses SMTLS 1.1 channels for bidirectional encryption of cross-border links. All audit logs and key operation events are uniformly archived to meet the requirements of the Cybersecurity Law and GB / T39786-2021.

[0039] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A decision engine based on risk control strategies, characterized by: It includes a strategy repository module, a mapping service module, an execution engine module, a data management module, a version rollback module, a security compliance module, and a monitoring and alerting module. The strategy repository module is used to store strategy files with version numbers, rule scripts, and metadata, and supports Git / API dual-channel commits, branch management, and secure signatures. The mapping service module dynamically matches target policy versions based on multi-dimensional context including product number, channel, region, and real-time risk control indicators, using a consistent hashing and conditional routing algorithm. The execution engine module consists of multi-node rule execution containers, supporting pluggable execution units for DMN, Drools, Groovy, Python, SparkUDF, and RESTfulML services, and achieving parallel execution of nodes independent of each other through DAG parsing. The data management module generates versioned snapshots of external variables when decision requests arrive, ensuring read-write consistency with a two-phase cache invalidation strategy. The version rollback module records the policy release pipeline, traces back execution records, and supports one-click rollback to any historical stable version. The security and compliance module includes policy package integrity verification, fine-grained RBAC, audit logs, encrypted transmission, and support for national cryptographic algorithms. The monitoring and alarm module collects metrics such as TPS, P99 latency, rule hit rate, and abnormal retry counts, and triggers alarms based on AI anomaly detection. These modules are decoupled from each other and interact through a unified interface to achieve risk control decision-making functions such as dynamic policy loading, canary release, distributed parallel execution, version governance, and security compliance.

2. The decision engine based on risk control strategy according to claim 1, characterized in that: The policy repository module supports fast retrieval by version number, branch, and tag. It implements mandatory signature verification when policy files are added to the repository and pushes change events to the monitoring and alarm module.

3. The decision engine based on risk control strategy according to claim 1, characterized in that: The mapping service module includes a rule dimension splitting unit, a canary release unit, and a configuration hot update unit. The rule dimension splitting unit is used to split multi-dimensional routing conditions into cacheable prefix tree indexes. The canary release unit is used to allocate canary traffic according to users, proportions, or feature values. The configuration hot update unit is used to refresh the mapping cache without interrupting the service. The traffic allocation methods of the canary release unit include directed routing by user ID, traffic splitting by percentage, and allocation of differentiated policy versions based on real-time metrics.

4. The decision engine based on risk control strategy according to claim 1, characterized in that: The execution engine module includes a DAG parser, a parallel scheduler, an exception handling unit, and a resource elastic scaling unit. The DAG parser is used to parse the dependencies described in the policy file into a directed acyclic graph. The parallel scheduler dynamically allocates tasks to execution nodes based on the topology sorting result. The exception handling unit provides replay, circuit breaking, and degradation policies. The resource elastic scaling unit automatically expands and shrinks based on queue length and CPU / memory metrics. The parallel scheduler allocates independent execution nodes to independent container nodes for synchronous execution and asynchronously schedules dependent execution nodes according to the data flow order.

5. The decision engine based on risk control strategy according to claim 1, characterized in that: The data management module employs a timestamp-based multi-version concurrency control strategy to generate a consistent view for each decision request.

6. The decision engine based on risk control strategy according to claim 1, characterized in that: The version rollback module utilizes the immutable ledger of the blockchain to record and publish pipeline information, thereby achieving traceability.

7. The decision engine based on risk control strategy according to claim 1, characterized in that: The security and compliance module provides a unified encrypted channel encapsulation library based on TLS, which negotiates SM2 / SM4 / SMTLS1.1 by default and supports fine-grained RBAC access control down to policy version, environment, and operation level.

8. The decision engine based on risk control strategy according to claim 1, characterized in that: The monitoring and alarm module asynchronously collects system operation indicators through a lightweight probe, identifies abnormal fluctuations in performance indicators through a built-in AI anomaly detection engine, and triggers security alarms in real time for signature anomaly events reported by the policy repository module.

9. A method for applying the decision engine based on risk control strategy as described in claims 1-8, characterized in that: Includes the following steps: S.

1. Receive decision requests containing product number, request channel, user region, and real-time risk control indicators; S.2 The mapping service module determines the target policy version by combining consistent hashing with conditional routing algorithm, and allocates requests according to the preset traffic ratio in the canary release scenario. The canary release divides the traffic of requests based on user granularity, traffic ratio or custom feature value. S.

3. Call the policy repository module to retrieve the policy file of the target policy version; S.4 The execution engine module uses a DAG resolver to resolve policy dependencies and allocates independent nodes to the rule execution container for parallel execution according to the parallel scheduler. The rule execution container supports the execution units of DMN, Drools, Groovy, Python, SparkUDF and RESTful machine learning services in a pluggable manner, and can be hot-swapped and expanded without restarting the service. S.5 The data management module generates a snapshot version number for the request and provides a consistent view, and all execution nodes access the data based on the same snapshot version number; S.

6. If an exception occurs during execution, the exception handling unit selects a replay, circuit breaker, or degradation strategy and notifies the monitoring and alarm module to record the number of exception retries. The circuit breaker protection avoids the avalanche effect when the fault node suspends receiving new tasks and automatically resumes task reception after the fault is recovered. S.

7. Aggregate the results of each execution node to form a single decision output and return it to the caller; S.8 The version rollback module records the execution summary based on the blockchain ledger, and supports one-click rollback to a historical stable version when necessary; S.9 The security and compliance module audits the entire operation and transmits data through an encrypted channel.

Images