Method, apparatus, device, medium and program product for managing permissions

Abstract

This application provides a method, apparatus, device, medium, and program product for access control, which can be applied to the fields of artificial intelligence and big data technologies. The method includes: in response to an authorization signing operation, obtaining a structured authorization document, wherein the structured authorization document includes a set of constraints; using a constraint authorization model, performing type identification and standardization transformation on the constraints in the constraint set to obtain constraint rules, and writing the constraint rules into a constraint registry center; receiving a scheduling instruction generated by a fund scheduling engine, and querying the constraint registry center for matching constraint rules based on the scheduling instruction to obtain a target constraint rule; verifying whether the scheduling instruction satisfies the target constraint rule, obtaining a verification result; and in response to the verification result indicating that the verification passed, executing the scheduling instruction.

Description

Technical Field

[0001] This application relates to the financial field, specifically to the fields of artificial intelligence and big data technology, and more specifically to a method, apparatus, device, medium, and program product for access control. Background Technology

[0002] In existing technologies, access control is generally based on a "user-role-function" paradigm, with the authorized object being individual users and the authorized content being functional access permissions. However, in automated business scheduling scenarios under multi-organizational architectures, the core issue is not the operational permissions of individual users, but rather whether there are legitimate and valid business authorizations between organizations, and how the scope and constraints of such authorizations are automatically identified and executed by the system. Furthermore, in existing technologies, authorization management and business execution systems are disconnected; that is, when the business engine generates operational instructions, it is unaware of the corresponding authorization status and its constraints, and compliance assurance relies on post-event manual verification, resulting in an irreversible compliance exposure from instruction execution to risk discovery. Summary of the Invention

[0003] In view of the above problems, this application provides a method, apparatus, device, medium and program product for access control.

[0004] According to a first aspect of this application, a permission management method is provided, comprising: in response to an authorization signing operation, obtaining a structured authorization document, wherein the structured authorization document includes a set of constraint conditions; through a constraint authorization model, performing type identification and standardization transformation on the constraint conditions in the constraint condition set to obtain constraint rules, and writing the constraint rules into a constraint registration center; receiving a scheduling instruction generated by a fund scheduling engine, and querying the constraint registration center for matching constraint rules according to the scheduling instruction to obtain a target constraint rule; verifying whether the scheduling instruction satisfies the target constraint rule to obtain a verification result; and in response to the verification result indicating that the verification passed, executing the scheduling instruction.

[0005] According to embodiments of this application, the method further includes: in response to successful execution of a scheduling instruction, obtaining an execution result record after the scheduling instruction has been executed; backtracking the target constraint rules that the scheduling instruction has matched, and determining the authorization identifier of the associated structured authorization document based on the target constraint rules; and establishing an authorization association record between the scheduling instruction and the structured authorization document based on the execution result record and the authorization identifier.

[0006] According to embodiments of this application, the method further includes: calculating the evidence hash value of the authorized associated record; and storing the evidence hash value in the evidence chain, wherein the evidence chain is an evidence chain organized by a chained hash structure.

[0007] According to embodiments of this application, the method further includes: in response to a tracing query request, performing one of the following operations based on the query type of the tracing query request: querying the constraint rules associated with the authorization letter identifier from the constraint registry center based on the authorization letter identifier, and returning a list of executed scheduling instructions corresponding to the constraint rules; or returning the target constraint rule that the scheduling instruction has matched, and the structured authorization letter associated with the target constraint rule, based on the instruction identifier of the scheduling instruction.

[0008] According to an embodiment of this application, verifying whether a scheduling instruction satisfies a target constraint rule and obtaining a verification result includes: verifying the parameters in the scheduling instruction corresponding to the constraint dimension according to the constraint dimension of the target constraint rule, and obtaining a verification result.

[0009] According to an embodiment of this application, constraint rules are obtained by performing type identification and standardization transformation on the constraint conditions in the constraint condition set through a constraint authorization model, including: based on the constraint type of the constraint condition, using the constraint authorization model to convert the constraint condition into a logical expression corresponding to the constraint type; and assembling the logical expression into a constraint rule.

[0010] According to embodiments of this application, the method further includes: scanning the status of each constraint rule in the constraint registry center; and switching the status of the constraint rule from a valid state to a first transitional state, from the first transitional state to a second transitional state, or from the second transitional state to an invalid state according to the remaining validity period of the constraint rule; wherein, in the valid state, all scheduling instructions are allowed to be executed; in the first transitional state, all scheduling instructions are allowed to be executed and a warning notification is sent; in the second transitional state, scheduling instructions that meet preset scheduling conditions are prohibited from being executed; and in the invalid state, all scheduling instructions are prohibited from being executed.

[0011] According to an embodiment of this application, it further includes: in response to a verification result indicating that the verification failed, refusing to execute the scheduling instruction and sending a violation notification.

[0012] A second aspect of this application provides a permission management device, comprising: an acquisition module, configured to acquire a structured authorization document in response to an authorization signing operation, wherein the structured authorization document includes a set of constraint conditions; a conversion module, configured to perform type identification and standardization conversion on the constraint conditions in the constraint condition set through a constraint authorization model to obtain constraint rules, and write the constraint rules into a constraint registration center; a matching module, configured to receive a scheduling instruction generated by a fund scheduling engine, and query the constraint registration center for matching constraint rules according to the scheduling instruction to obtain a target constraint rule; a verification module, configured to verify whether the scheduling instruction meets the target constraint rule and obtain a verification result; and an execution module, configured to execute the scheduling instruction in response to the verification result indicating that the verification passed.

[0013] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0014] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0015] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0016] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0017] Figure 1 This illustration schematically depicts an application scenario of the permission management method according to an embodiment of this application;

[0018] Figure 2 A flowchart illustrating a permission management method according to an embodiment of this application is shown schematically.

[0019] Figure 3 This illustration schematically shows an overall flowchart of the permission management method according to an embodiment of this application;

[0020] Figure 4 This schematically illustrates a structural block diagram of a permission management device according to an embodiment of this application; and

[0021] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a permission management method according to an embodiment of this application. Detailed Implementation

[0022] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0024] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0025] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0026] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0027] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all provide users with corresponding operation entry points for users to choose to agree to or reject the automated decision results; if the user chooses to reject, the process enters the expert decision-making process.

[0028] As used in this article, "corporate authorization" refers to a legal license granted by one legal entity within an organization to another legal entity to perform specific fund allocation operations on its behalf. The authorization letter is presented in structured data format, specifying: the authorizing party (the authorized party, such as the parent company), the authorized object (the authorizing party, such as a subsidiary), the authorized business module, the set of constraints, the validity period, and the digital signature, etc.

[0029] In related technologies, access control is generally based on a "user-role-function" authorization paradigm. The authorizing subject is the natural person user, the authorized object is the system function, and the basic principle of the authorization relationship is "one user to one function." However, in the multi-legal entity structure of a group treasury, the authorizing subject is a legal entity (such as subsidiary A), and the authorized object is "the act of acting as an agent to allocate funds" (such as parent company P transferring funds to subsidiary A's account). The authorization relationship also comes with complex constraints such as upper limits on the amount, frequency restrictions, account scope, and fund direction. This is essentially an "organization-to-organization" authorization model, which belongs to a completely different level of abstraction from the existing "user-function" model and cannot be directly applied.

[0030] Furthermore, in existing technologies, the authorization management system and the automated scheduling and execution system are disconnected, operating as independent software. The authorization management system configures "who can do what," while the scheduling engine calculates "how to schedule optimally." When generating collection, allocation, and transfer instructions, the scheduling engine is completely unaware of the existence of corresponding legal entity authorization records, the constraints of that authorization, or whether the authorization is still valid. Compliance assurance relies on manual post-event verification. The scheduling engine automatically executes fund transfers, and then finance or compliance personnel manually compare paper authorization documents with system operation logs at the end of the month or quarter. This "execute first, verify later" model inherently exposes users to compliance risks; irreversible financial risks may have already occurred between the execution of the operation and the discovery of violations by humans.

[0031] Meanwhile, existing technology's authorization lifecycle management lacks a refined and automated linkage mechanism. Authorization expiration is usually handled with a simple "disable upon expiration," meaning that all system operational capabilities under that authorization are abruptly cut off at midnight on the expiration date. This approach has two shortcomings: First, it lacks a gradual early warning mechanism before expiration, and authorization administrators and scheduling operators may suddenly lose scheduling capabilities without their knowledge, causing the collection plan being executed that day to be interrupted. Second, the handling after expiration lacks differentiation; low-risk, small-amount daily operations do not need to be immediately and completely prohibited, and the one-size-fits-all strategy is too rigid.

[0032] Furthermore, existing audit traceability technologies lack an end-to-end link between "scheduling operation → authorization basis." Audit logs only record the execution facts of scheduling operations, failing to answer the most critical questions in compliance audits: What is the legal authorization basis for this operation? Which authorization letter is relied upon? What is the status of the authorization letter at the time of operation execution? Did the operation strictly comply with the authorization constraints? Answering these questions requires auditors to perform manual cross-system comparisons across multiple systems, such as retrieving paper authorization letters or authorization records from electronic contract management systems and then verifying them against the scheduling system's operation logs for fields such as time, amount, and subject—a time-consuming and error-prone process.

[0033] In view of this, embodiments of this application provide a permission management method, apparatus, device, medium, and program product.

[0034] Figure 1 The illustration shows an application scenario diagram of the permission management method according to an embodiment of this application.

[0035] like Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a database 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the first terminal device 101, the second terminal device 102, the database 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, an authorized administrator can use the first terminal device 101 to generate a structured authorization certificate through an authorization signing operation and send the structured authorization certificate to the server 105 via the network 104. A scheduling operator can use the second terminal device 102 to view the execution status and compliance verification results of scheduling instructions.

[0036] The first terminal device 101 and the second terminal device 102 can be electronic devices such as smartphones, tablets, laptops, and desktop computers. For example, an authorized administrator can use the first terminal device 101 to log in to the authorization management client and complete the online signing of the structured authorization document through digital signature; a dispatch operator or compliance auditor can use the second terminal device 102 to view the compliance verification results of dispatch instructions, receive early warning notifications, or initiate source tracing query requests.

[0037] Server 105 can be a server providing access control and compliance verification services. For example, server 105 can process received structured authorization documents, convert constraints into constraint rules, and write the constraint rules into the constraint registry in database 103. Server 105 can also receive scheduling instructions generated by the fund scheduling engine, query the database 103 for matching target constraint rules based on the scheduling instructions, and perform compliance verification on the scheduling instructions. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks, and basic cloud computing services such as big data.

[0038] Database 103 is a professional storage system for storing and managing data. It can store constraint rules, authorization association records, and evidence chain data from the constraint registry center. It supports structured, semi-structured, or unstructured data storage and has management capabilities such as adding, deleting, modifying, querying, backing up, and restoring data. In this application scenario, Database 103 can connect to Server 105 via a communication link. Server 105 can retrieve matching constraint rules from Database 103 for verification based on scheduling commands, and can also synchronously store the verification results and newly generated authorization association records to Database 103, thereby achieving data persistence and efficient retrieval.

[0039] It should be noted that the permission management method provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-102. Accordingly, the permission management device provided in this application embodiment can generally be set in server 105 and / or terminal devices 101-102.

[0040] It should be understood that Figure 1 The number of terminal devices, networks, databases, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, databases, and servers can be included.

[0041] The following will be based on Figure 1 The described scene, through Figure 2 and Figure 3 The permission management method according to the embodiments of this application will be described in detail.

[0042] Figure 2 A flowchart illustrating a permission management method according to an embodiment of this application is shown schematically.

[0043] like Figure 2 As shown, the permission management method 200 according to the embodiments of this application may include steps S210 to S250.

[0044] In step S210, in response to the authorization signing operation, a structured authorization document is obtained, wherein the structured authorization document includes a set of constraints.

[0045] Users can complete the electronic signing of a legal entity's power of attorney online through the 'Authorization and Signing' entry on the system homepage. The signing can be initiated by the authorizing entity (the authorized party, which may be the parent company), confirmed by the authorized object (the authorizing party, which may be a subsidiary), and then completed by both parties through digital signatures. The power of attorney is stored in structured data format, and its fields may include: authorizing entity identifier (unique identifier of the legal entity), authorized object identifier, list of authorized business modules, set of constraints, effective start time of authorization, effective end time of authorization, and digital signatures of both parties. This structured data constitutes the input for the subsequent constraint authorization model, and a notification of authorization data changes will be pushed after the signing is completed.

[0046] In some embodiments, the set of constraints can define boundary restrictions for authorized operations. Each constraint can be structured as {constraint type, constraint value}, where the constraint type can cover single transaction amount limit, daily cumulative amount limit, single transaction amount limit, daily operation frequency limit, applicable account list (accounts allowed to be operated on), fund direction constraint (collection only / disbursement only / both), applicable time period (e.g., weekdays only), minimum balance of the collected party, etc.

[0047] In some embodiments, the list of authorized business modules can define the types of scheduling operations covered by the authorization. In a typical group treasury scenario, business modules include, but are not limited to: fund collection (funds transferred from subordinate units to superior units), fund allocation (funds transferred from superior units to subordinate units), fund transfer (funds transferred between units at the same level), and financing agency (acting as an agent for subordinate units to handle financing business), etc. Each business module can be authorized independently. For example, subsidiary A can only authorize parent company P to act as an agent for fund collection, but not to act as an agent for financing repayment, thereby achieving fine-grained configuration of authorization.

[0048] Understandably, by using a structured legal person authorization letter, the authorizing entity is elevated from a natural person to a legal entity, and a multi-dimensional set of constraints is introduced, thereby providing a legal basis for the automated management and control of inter-organizational fund allocation.

[0049] In step S220, the constraint conditions in the constraint condition set are identified and standardized through the constraint authorization model to obtain constraint rules, and the constraint rules are written into the constraint registration center.

[0050] The constraint authorization model can be integrated into the constraint modeling engine to convert the natural language constraint clauses in the authorization letter into formal constraint rules that the system can automatically calculate and write into the constraint registry.

[0051] The constraint registry can be a database component that centrally stores all valid authorized constraint rules, providing constraint query and status notification services for the pre-scheduling verification engine and the lifecycle linkage engine. At the data structure level, the constraint registry can organize constraint rules using a three-level composite index: the first-level index key is {outgoing entity identifier, incoming entity identifier} (i.e., legal entity pair), the second-level index key is {operation type}, and the third-level index key is {constraint dimension}. This index structure ensures that the pre-scheduling verification engine can locate the applicable set of constraint rules with constant time complexity when it receives a scheduling instruction. At the lifecycle level, the constraint registry can maintain the following status attributes for each constraint rule: rule status (valid / warning / limited / frozen), rule effective time, rule expiration time, and associated authorization document identifier. When the rule status changes, such as from "valid" to "warning" or from "limited" to "frozen," the constraint registry can push status change notifications to the lifecycle linkage engine and the pre-scheduling verification engine, ensuring that both engines always use the latest constraint status for compliance determination. At the concurrency level, the constraint registry can support high-concurrency read-only queries (from the pre-scheduling verification engine, triggered once per scheduling instruction), low-frequency write updates (from the constraint modeling engine, triggered once per authorization signing or change), and near real-time state change pushes (triggered by scheduled inspections from the lifecycle linkage engine). The execution of these three processes is isolated from each other, and read and write operations do not block each other.

[0052] For example, the authorization clause states: "Subsidiary A authorizes its parent company P to collect funds from A's current account daily, with a single collection amount not exceeding 2 million yuan, and no more than one collection per day. After collection, A's remaining balance shall not be less than 5 million yuan." The output of the constraint authorization model is three constraint rules: Rule R1: {Collection, Single Transaction Amount, ≤, 2,000,000, None}; Rule R2: {Collection, Number of Operations per Day, <, 2, Time Window = Calendar Days}; Rule R3: {Collection, Remaining Balance of the Transferor, ≥, 5,000,000, None}. All rules can be associated with the corresponding authorization record and written to the constraint registry.

[0053] In step S230, the scheduling instruction generated by the fund scheduling engine is received, and the matching constraint rule is queried from the constraint registry center according to the scheduling instruction to obtain the target constraint rule.

[0054] The funds scheduling engine can be an existing automated funds management component of the system, responsible for automatically generating collection / allocation / transfer instructions based on the funds plan, liquidity rules, and account balance. In this embodiment, the funds scheduling engine itself is not modified; authorization control is achieved by embedding verification checkpoints in the execution channel, rather than intruding into or modifying the internal logic of the scheduling engine. This design is applicable to common engineering constraints in enterprise groups where "the scheduling engine is third-party commercial software or a legacy system, and internal teams have no modification permissions."

[0055] In some embodiments, the scheduling instruction output by the funds scheduling engine may include the following metadata: instruction unique identifier, operation type, sending entity identifier, receiving entity identifier, scheduling amount, involved account identifiers, instruction generation time, and planned execution time window. The sending entity identifier and receiving entity identifier in the scheduling instruction correspond to the authorized object identifier and authorized entity identifier, respectively. This instruction can be submitted to the scheduling pre-verification engine for authorization compliance verification.

[0056] The pre-scheduling verification engine can initiate a read-only query to the constraint registry center using {outgoing subject identifier, incoming subject identifier, operation type} as the join query key to retrieve all applicable constraint rules that are in a "valid" state, which will serve as the target constraint rule set. Due to the constraint registry center's three-level composite index structure, this query can be completed in constant time complexity, with end-to-end query latency controlled within milliseconds (P99 < 10ms), thus avoiding becoming a performance bottleneck in the scheduling instruction chain.

[0057] In other embodiments, a tightly coupled model can be adopted, where constraint rules are directly embedded within the fund scheduling engine. An authorization constraint determination step is added to the instruction generation logic, and the scheduling engine considers the authorization constraints simultaneously when calculating the scheduling scheme. This approach can reduce network latency in cross-service calls, but it requires modification of the scheduling engine's internal code, making it impractical for third-party commercial engines or legacy systems. Furthermore, once the authorization constraint logic is coupled with the scheduling engine, any change to either party (such as adding constraint dimensions or modifying validation logic) requires redeploying the entire engine.

[0058] In step S240, the scheduling instruction is checked to see if it meets the target constraint rules, and the check result is obtained.

[0059] The pre-scheduling verification engine performs compliance checks on the corresponding parameters of the scheduling instruction for each matched target constraint rule. If all target constraint rules pass verification, a verification pass signal is output as the verification result. If at least one constraint rule fails verification, a verification rejection signal is output as the verification result. The above verification chain is synchronous and blocking, meaning that the scheduling instruction is not executed until verification is completed, ensuring the rigidity of the "verify first, execute later" time sequence. The end-to-end latency of the entire verification process can be controlled within milliseconds.

[0060] In other embodiments, an asynchronous verification mode can be adopted, where the scheduling instruction is executed directly without prior verification. After execution, the asynchronous verification service performs authorization compliance determination in the background, triggering alarms and fund rollback operations if violations occur. The advantage of this scheme is that the execution delay of the scheduling instruction is not affected by the verification process (verification does not increase the instruction path length), making it suitable for small-amount, high-frequency scheduling scenarios that are extremely sensitive to latency. However, its disadvantage is that there is a compliance risk window between operation execution and asynchronous verification completion, during which funds may have already been transferred, and the rollback operation involves technical complexity (e.g., funds have already been used by the recipient) and legal risks (e.g., resulting in actual illegal operation).

[0061] In step S250, in response to the verification result indicating that the verification passed, the scheduling instruction is executed.

[0062] For dispatch instructions that pass verification, the actual fund transfer operation can be executed. After execution, the execution result can be fed back to the dispatch-authorization association engine. The execution result may include: execution status (success / failure / partial success), actual execution time, actual execution amount (which may have slight differences from the dispatch amount, such as rounding errors), execution serial number, etc.

[0063] In embodiments of this application, the method further includes: in response to a verification result indicating that the verification failed, refusing to execute the scheduling instruction and sending a violation notification.

[0064] For scheduling instructions that fail verification, execution can be refused. The instructions are placed in the failure handling queue, and a violation notification is sent to the relevant parties. At the same time, the failure information can be recorded in the system operation log for subsequent auditing.

[0065] The content of the violation notification may include: a summary of the rejected dispatch instruction, the number of the failed constraint rule, and the specific reason for the failure (such as "a single collection amount of 3 million exceeds the constraint limit of 2 million").

[0066] Understandably, completing compliance assessments and intercepting non-compliant instructions before execution enables proactive prevention and real-time alerts for non-compliant operations, fundamentally eliminating the irreversible compliance risk exposure between the execution of non-compliant operations and manual discovery.

[0067] For example, a large enterprise group comprises one parent company P, five holding subsidiaries (A, B, C, D, E), and three sub-subsidiaries (A1, A2, B1). The group deploys an automated fund allocation system. The parent company acts as an agent for each subsidiary in executing daily fund collection and disbursement. Each subsidiary has a legal person authorization relationship with the parent company, with varying authorization content. During the authorization signing phase, subsidiary A and parent company P sign a structured authorization agreement online. The structured content of the authorization agreement includes: Authorizing entity = P, Authorized object = A, Business module = [Fund collection], Authorization validity period = January 1, 2026 to December 31, 2026, Constraints = {Maximum single collection amount = 2 million, Number of collections per day = 1, Minimum balance retained by the collected party = 5 million, Applicable accounts = [A-Current 001, A-Current 002]}. The constraint authorization model converts the above constraints into four constraint rules and writes them into the constraint registry center. During the scheduling verification phase, at 9:00 AM one morning, the fund scheduling engine generated the instruction "Collect 1.5 million yuan of funds from subsidiary A to parent company P, operating account A-current 001". The pre-scheduling verification engine checked and verified four target constraint rules: 1.5 million ≤ 2 million (passed), no collection record on the day and 1 ≤ 1 (passed), A's current balance is 7 million and after collection, 5.5 million ≥ 5 million (passed), A-current 001 ∈ the permitted account list (passed). After all rules passed, the instruction entered the execution module to complete the fund transfer. That same afternoon, the engine generated the instruction "Collect 3 million yuan of funds from A to P". During verification, the instruction was rejected and a violation notification was sent because 3 million > 2 million violated the single transaction limit, and the instruction had already been executed once that day, resulting in a cumulative violation of the frequency limit (2 times > 1 time).

[0068] It should be noted that the authorization signing operation is used to convert the constraints in the structured authorization form into constraint rules and write them into the constraint registry center. This is a configuration or entry action and does not directly trigger the generation or verification of scheduling instructions. After the signing is completed, the fund scheduling engine may generate scheduling instructions and trigger verification on the same day, or there may be a long interval before a matching scheduling instruction appears with the relevant legal entity, or no matching scheduling instruction may be generated within the authorization validity period, and the authorization may expire naturally. There is no necessary temporal binding relationship between authorization signing and scheduling verification.

[0069] It is understandable that, through the above process, this application embodiment achieves automated compliance verification of legal entity authorization constraints. That is, it transforms authorization constraints from textual clauses in paper contracts into formal rules that the system can automatically calculate, and embeds them into the execution channel of scheduling instructions, forming a rigid "verify first, execute later" sequence. This eliminates the inherent compliance risk exposure of the traditional "execute first, then manually verify" model. Based on the volume of dozens of automated scheduling operations per day for a large enterprise group, the timeliness of compliance verification is improved from "monthly / quarterly manual spot checks" in the traditional model to "millisecond-level automatic verification for each operation." Simultaneously, authorization control functions are implemented through an independent pre-scheduling verification engine and constraint registration center, without modifying the existing fund scheduling engine. The verification engine is deployed as an independent service on the execution channel, interacting with the scheduling engine through a standardized instruction interface, achieving loosely coupled integration of authorization control and the scheduling engine. Ultimately, it overcomes the shortcomings of existing permission management methods and authorization models that are not applicable to inter-organizational scenarios, the disconnect between authorization management and business execution systems, and the reliance on post-event verification for compliance checks, thus promoting the leap of fund allocation and control from "manual post-event verification" to "system pre-event verification".

[0070] Based on the above embodiments, in this embodiment, the constraint conditions in the constraint condition set are identified and standardized through a constraint authorization model to obtain constraint rules, including: based on the constraint type of the constraint condition, using the constraint authorization model to convert the constraint condition into a logical expression corresponding to the constraint type; and assembling the logical expression into constraint rules.

[0071] During the conversion process, the original constraint list can first be extracted from the authorization data. The original constraints exist in the authorization document as key-value pairs of {constraint type, constraint value}. Then, the constraint authorization model can convert the set of constraints in the authorization document into constraint rules that the system can automatically calculate, based on the constraint types. The constraint types can cover multiple dimensions, and different types of constraints correspond to different standardized conversion logics. Specifically, these can include: upper limit constraints, including single transaction upper limits and daily cumulative upper limits, converted into the comparison expression "operation amount ≤ threshold," used to verify the upper limit of the scheduling amount in scheduling instructions; frequency limit constraints, including daily operation frequency upper limits, weekly operation frequency upper limits, and monthly operation frequency upper limits, converted into the cumulative counting expression "number of operations within the current time window < threshold," used to cumulatively verify the number of times scheduling instructions are executed within a specified time window; and account scope constraints, including applicable account lists and prohibited account lists, converted into the set membership expression "operation account ∈ permitted account list," used to verify the scheduling... The system checks whether the account identifier involved in the dispatch instruction falls within the scope of authorization; fund direction constraints, including collection only, allocation only, and both directions, are converted into the matching expression "operation direction = authorized direction" to verify whether the fund flow of the dispatch instruction is consistent with the authorization letter; effective time period constraints, including working days only, specified date range, and specified time period, are converted into the time judgment expression "current time ∈ authorized time period window" to verify whether the planned execution time of the dispatch instruction falls within the authorized time period; and retention balance constraints, including the lower limit of the retention balance of the collection party and the lower limit of the retention balance of the allocation party, are converted into the balance threshold expression "current balance of the transferor - operation amount ≥ retention lower limit" to verify whether the remaining balance of the transferor's account after dispatch meets the minimum retention requirement.

[0072] Through type identification and standardized transformation of the constraint authorization model, various constraints can be uniformly converted into computable logical expressions. These logical expressions can ultimately be assembled into a five-tuple form of constraint rules: {C Operation Type, D Constraint Dimension, O Comparison Operator, V Threshold, C Effective Condition}. Here, the operation type is inherited from the business module list in the authorization document, the constraint dimension and comparison operator are determined by type identification, the threshold is the constraint value in the constraint condition, and the effective condition is the logical prerequisite for the constraint's application. For example, "time window = calendar days" is the effective condition for a frequency limit constraint.

[0073] For example, the authorization letter states that "Subsidiary A authorizes its parent company P to collect funds from A's current account daily, with a single collection amount not exceeding RMB 2 million, and no more than one collection per day, and A's remaining balance after collection not less than RMB 5 million." The constraint authorization model can perform type identification and standardization transformation on the three types of constraints in the above clauses. Specifically, "single collection amount not exceeding 2 million yuan" is a limit constraint, converted into the comparison expression "operation amount ≤ 2,000,000", assembled into rule R1: {collection, single amount, ≤, 2,000,000, none}; "collection not exceeding once per day" is a frequency limit constraint, converted into the cumulative count expression "number of operations per day < 2", with the effective condition being "time window = calendar day", assembled into rule R2: {collection, number of operations per day, <, 2, time window = calendar day}; "A's remaining balance after collection is not less than 5 million yuan" is a remaining balance constraint, converted into the balance threshold expression "A's current balance - collection amount ≥ 5,000,000", assembled into rule R3: {collection, transferor's remaining balance, ≥, 5,000,000, none}. All three constraint rules can be associated with the corresponding authorization record and written to the constraint registry center.

[0074] Understandably, by converting different types of constraints into corresponding logical expressions and assembling them into unified constraint rules, a systematic formal modeling of various constraint clauses in the authorization document is achieved, thereby providing a complete rule foundation for automated compliance verification.

[0075] Based on the above embodiments, in this embodiment, verifying whether the scheduling instruction satisfies the target constraint rules and obtaining the verification result includes: verifying the parameters in the scheduling instruction corresponding to the constraint dimensions according to the constraint dimensions of the target constraint rules, and obtaining the verification result.

[0076] The pre-scheduling verification engine can automatically complete the authorization compliance verification after the fund scheduling engine generates the scheduling instruction and before the instruction is actually executed. Instructions that fail the verification will be blocked from execution.

[0077] In the verification process, firstly, instruction parameters are extracted. Contextual parameters required for verification are extracted from the scheduling instruction, including operation type (aggregation / allocation / transfer), sending entity identifier, receiving entity identifier, scheduling amount, account identifier, and scheduled execution time. These parameters constitute the input for subsequent constraint queries and compliance determinations. Secondly, constraint rules are matched. Using {sending entity identifier, receiving entity identifier, operation type} as the joint query key, a read-only query is initiated to the constraint registry center to obtain all applicable and currently valid constraint rules, which serve as the target constraint rule set. The query result is a list of constraint rules that meet the following conditions: both the sending and receiving entities match (or are derived from the abstract legal entity hierarchy in the authorization file), the operation type matches (or the scope of application of the constraint rule covers the operation type), and the rule is currently in a "valid" state. Then, compliance verification is performed on a rule-by-rule basis. For each matched target constraint rule, compliance determination is performed on the corresponding parameters of the scheduling instruction based on its constraint dimension and comparison operator. The verification logic is implemented according to constraint dimensions, specifically including: Amount-based verification: comparing the scheduled amount with the amount threshold in the constraint rules; if the scheduled amount does not meet the constraint relationship defined by the comparison operator, the constraint verification fails. Frequency-based verification: querying the number of operations executed within the current time window; if the current operation will cause the cumulative number to exceed the upper limit, the constraint verification fails. Account-based verification: verifying whether all account identifiers involved in the scheduling instruction belong to the permitted account list defined in the constraint rules; if any account is not in the permitted list, the constraint verification fails. Fund direction-based verification: verifying whether the operation direction of the scheduling instruction is consistent with the permitted direction in the authorization letter. Time window-based verification: verifying whether the planned execution time of the scheduling instruction falls within the permitted time period defined in the constraint rules. Retained balance-based verification: calculating the difference between the current balance of the transferor and the current scheduled amount, comparing it with the lower limit of the retained balance in the constraint rules; if the difference is lower than the lower limit, the constraint verification fails. Finally, the verification results are summarized and processed. After verifying all target constraint rules one by one, the verification results are summarized. If all target constraint rules pass the validation, a validation pass signal is output, allowing the scheduling instruction to enter the execution module. If at least one constraint rule fails the validation, a validation rejection signal is output, preventing the scheduling instruction from executing and sending a violation notification.

[0078] For example, in a scenario where the verification passes: On a certain morning, the funds scheduling engine generates instruction 001 based on the daily liquidity plan: "Collect 1.5 million yuan of funds from subsidiary A to parent company P, operating account A-current 001". The pre-scheduling verification engine queries the constraint registry center using {A, P, collection} as the joint key, and matches four target constraint rules R1 to R4. Each rule is verified: R1 verifies 1.5 million ≤ 2 million (passes); R2 verifies no previous collection record on that day, 1 ≤ 1 (passes); R3 verifies A's current balance of 7 million, after collection 5.5 million ≥ 5 million (passes); R4 verifies A-current 001 ∈ the permitted account list (passes). All verifications pass, and the instruction enters the execution module to complete the fund transfer.

[0079] For example, in a scenario involving verification rejection and adjustment, on the same afternoon, the scheduling engine generates instruction 002: "Collect 3 million yuan of funds from subsidiary A to parent company P, operating account A-current 001". The verification engine matches the same target constraint rules R1 to R4. Verification is performed item by item: R1 verifies 3 million > 2 million (failed, violating the single transaction amount limit); R2 verifies that one collection has been executed that day, and the cumulative total is 2 > 1 (failed, violating the daily operation frequency limit). Verification is rejected, and the instruction is blocked from execution. The system sends a violation notification, including: "Instruction 002 was rejected. Violation rules: R1 (single transaction amount limit 2 million, scheduling amount 3 million), R2 (daily operation frequency limit 1, already executed 1 time that day). Recommendation: Adjust the scheduling amount to within 2 million, or wait for the next calendar day to execute."

[0080] Understandably, embedding authorization constraint rules into the execution channel of scheduling instructions allows for the automatic judgment of each constraint dimension before instruction execution, thus ensuring the compliance of each scheduling operation is systematically guaranteed before instruction execution.

[0081] In embodiments of this application, the method further includes: scanning the status of each constraint rule in the constraint registry center; and switching the status of the constraint rule from a valid state to a first transitional state, from the first transitional state to a second transitional state, or from the second transitional state to an invalid state according to the remaining validity period of the constraint rule; wherein, in the valid state, all scheduling instructions are allowed to be executed; in the first transitional state, all scheduling instructions are allowed to be executed and a warning notification is sent; in the second transitional state, scheduling instructions that meet preset scheduling conditions are prohibited from being executed; and in the invalid state, all scheduling instructions are prohibited from being executed.

[0082] The lifecycle linkage engine continuously monitors the validity status of all authorized constraint rules and automatically drives gradual adjustments to scheduling capabilities. This engine can run as a scheduled task with a configurable inspection cycle (e.g., once per hour by default, which can be shortened to once every 15 minutes for organizations with intensive authorization processes). Each inspection iterates through all rule records in the constraint registry, assessing the validity status of each rule. The constraint registry maintains status attributes for each constraint rule, including rule status, rule effective time, rule expiration time, and associated authorization document identifier. When a rule status changes, the constraint registry can push a status change notification to both the lifecycle linkage engine and the scheduling pre-verification engine, ensuring that both engines always use the latest constraint status for compliance determination.

[0083] The specific judgment logic for state switching can include the following scenarios: Warning switching: When the remaining validity period of a rule is less than or equal to the preset warning advance number of days but greater than zero (e.g., remaining validity period ≤ 7 days and > 0 days), the rule status automatically switches from valid to the first transitional state. The system can send a warning notification that the authorization is about to expire. The notification content can include the information of the expiring authorization, the corresponding list of constraint rules, the expiration date, and the renewal operation entry point. Quota switching: When a rule has exceeded its expiration time but is within the first stage window of the tiered transition (e.g., from day 0 to day N after expiration, where N is configurable), the rule status switches from the first transitional state to the second transitional state. The system downgrades the scheduling capability under this rule to quota mode, prohibiting execution that meets preset scheduling conditions (e.g., scheduling amount exceeding a preset limit). Scheduling instructions with a threshold amount are allowed, but daily operations below the threshold are still permitted to ensure uninterrupted basic business operations. Freeze switching occurs when a rule is in the second phase of a tiered transition (e.g., starting from day N+1 after expiration). The rule status changes from the second transition state to the invalid state, freezing all scheduling capabilities under that rule. Any scheduling instructions involving that authorization are directly rejected by the pre-scheduling verification engine. Renewal recovery occurs when the authorization is renewed. The constraint modeling engine writes a new constraint rule record to the constraint registry or updates the expiration time of an existing record. The rule status is reset from invalid or any currently invalid state to valid. The lifecycle linkage engine detects this change in the next inspection cycle, synchronously updates the status, and notifies the pre-scheduling verification engine to restore normal verification logic.

[0084] The number of transition levels and the transition time windows for each stage can be flexibly configured by the authorizing party when signing the authorization agreement. This means gradually restricting scheduling capabilities according to a preset level sequence, rather than implementing a one-size-fits-all prohibition. Specifically, this can include the following variations: a three-level transition mode, i.e., effective state → first transition state → second transition state → ineffective state. The first transition state corresponds to the warning level (all operations are allowed as usual with an added warning reminder, such as "This authorization is about to expire or has already expired; it is recommended to renew it as soon as possible"). The second transition state corresponds to the limit level (operations exceeding a preset threshold are prohibited, such as "operations exceeding 1 million yuan in a single transaction are prohibited" or "operations exceeding 2 million yuan in a single day are prohibited"). Small-scale daily operations are still permitted to ensure uninterrupted basic cash flow. The invalidation state corresponds to a frozen state (all operations are prohibited; any scheduling instructions involving the legal entity are directly rejected by the pre-scheduling verification engine). A two-tier transition mode omits the first transition state, retaining only the second transition state and the invalidation state, suitable for scenarios where sufficient reminders have been given through other channels before the authorization expires. A multi-tier transition mode adds intermediate levels for finer-grained control, such as large-amount restriction level (single transaction > 5 million prohibited) → medium-amount restriction level (single transaction > 1 million prohibited) → small-amount restriction level (single transaction > 100,000 prohibited) → frozen state, suitable for large groups with extremely high compliance and precision requirements for fund scheduling operations. The system provides default configurations to reduce configuration burden; the authorizing party can adjust these parameters according to their compliance tolerance.

[0085] For example, in a scenario involving authorization expiration and tiered freezing, authorization A-2025-001 is valid until December 31, 2025. During its inspection on December 25, 2025 (7 days in advance), the lifecycle linkage engine detected that rules R1 to R4 had less than 7 days remaining before expiration and automatically pushed a warning notification to the authorization administrators of subsidiary A and parent company P, reminding them that the authorization was about to expire and suggesting that they renew it as soon as possible. During the first inspection after expiration on January 1, 2026, the status of R1 to R4 changed from valid to the second transitional state (the authorizing party's configuration skipped the first transitional state), and the single transaction limit for rule R1 was reduced from 2 million to 1 million (the authorizing party's preset limit ratio is 50%). During the inspection on January 8, 2026 (7+1 days after expiration), the status of R1 to R4 changed from the second transitional state to invalid. After this, any scheduling instructions involving {outgoing entity = A, incoming entity = P, operation type = aggregation} will be directly rejected by the pre-scheduling verification engine. On January 10, 2026, the administrators of A and P completed the online renewal signing, extending the validity period to December 31, 2026. The constraint modeling engine generated new constraint rules R1' to R4' and wrote them into the constraint registry center. The rule status was initially valid. The lifecycle linkage engine updated the status synchronously after detecting the new rule in the database in the next inspection cycle, and A's daily automatic collection returned to normal.

[0086] In other embodiments, a unified early warning output channel may also be included to automatically generate and push compliance early warning notifications in the following scenarios: Authorization expiration warnings, triggered by the lifecycle linkage engine, with the notification content including a summary of the expiring authorization, the expiration date, the affected legal entities and business modules, and the renewal operation entry point. These notifications can be pushed once on the 30th, 7th, and 3rd day before the expiration date, with increasing frequency to enhance the reminder effect; and scheduling verification rejection warnings, triggered by the scheduling pre-verification engine, with the violation notification content including a summary of the rejected scheduling instruction, details of the violated constraint rules, the reason for rejection, and... Suggested solutions (e.g., "adjusting the scheduling amount from 3 million to within 2 million"); Tiered transition status change warnings, triggered by the lifecycle linkage engine during status transitions, with warning notifications including the current level, affected legal entities and business modules, transition time and reason, and recovery conditions; Authorization coverage gap warnings, triggered by periodic inspections by the constraint registry center. When it is detected that a legal entity lacks a valid authorization record in a certain business module, but the legal entity has a recent scheduling operation history, it is determined to be an authorization coverage gap, and a warning notification is generated to remind relevant administrators to supplement the authorization as soon as possible. Warning notifications can be pushed through preset channels, including but not limited to the system message center, email, SMS, enterprise instant messaging tools, etc., and the channels are configurable.

[0087] Understandably, the aforementioned lifecycle linkage and tiered transition mechanism achieves refined linkage between the authorization lifecycle and scheduling capabilities, making the activation and deactivation of scheduling capabilities entirely driven by the authorization status, thus solving the rigidity defect of the traditional one-size-fits-all approach of disabling upon expiration. Simultaneously, the system automatically restores scheduling capabilities after renewal, avoiding omissions or delays that might occur with manual restoration.

[0088] In embodiments of this application, the method further includes: in response to successful execution of a scheduling instruction, obtaining an execution result record after the scheduling instruction has been executed; backtracking the target constraint rules that the scheduling instruction has matched, and determining the authorization identifier of the associated structured authorization document based on the target constraint rules; and establishing an authorization association record between the scheduling instruction and the structured authorization document based on the execution result record and the authorization identifier.

[0089] After each scheduling instruction is successfully executed, the scheduling-authorization association engine can automatically establish an association between the scheduling operation and the authorization basis.

[0090] During the construction of the association binding, firstly, the execution result record after the scheduling instruction is executed can be obtained, including the instruction identifier, operation type, outgoing entity, incoming entity, execution amount, execution time, and execution serial number. Then, the set of target constraint rules matched during the constraint rule matching phase of the scheduling pre-verification engine before execution can be traced back. This set is cached during the verification process, and by tracing back, it can be determined which constraint rules provided the authorization compliance basis for this operation. Furthermore, the source authorization letter can be traced up along the target constraint rules to obtain the authorization letter identifier and key summary information. The key summary information may include the authorizing parties, signing date, and validity period. Finally, the association record between the scheduling instruction and the structured authorization letter can be assembled. The structure of the association record may include: {R: Record Identifier, D: Scheduling Instruction Identifier, A: List of Authorization Letter Identifiers, C: List of Effective Constraint Rule Identifiers, T: Verification Pass Timestamp, S: Authorization Status at Verification Pass, E: Execution Result Summary}.

[0091] The construction of the association binding realizes the hierarchical association of "scheduling operation → constraint rule → authorization letter". Specifically, a single scheduling operation can be traced back to the structured authorization letter that provides legal authorization for the operation through the target constraint rule matched in the verification stage; a single structured authorization letter can cover multiple executed scheduling operations through its associated constraint rules.

[0092] Understandably, establishing authorization-related records from scheduling operations to authorization basis can provide a complete data foundation for subsequent compliance audits, thereby significantly improving the efficiency and accuracy of compliance audits.

[0093] In embodiments of this application, the method further includes: calculating the evidence hash value of the authorized associated record; and storing the evidence hash value in the evidence chain, wherein the evidence chain is an evidence chain organized by a chained hash structure.

[0094] After receiving the authorization association records submitted by the scheduling-authorization association engine, the entire evidence chain can be protected against tampering through a chained hash structure.

[0095] First, the notarized hash value of the authorized associated record can be calculated. For the i-th associated record Ri, its notarized hash value Hi is calculated as follows: Hi = H(Ri) serialized ‖Hi-1‖Ti), where H is a cryptographic hash function (adaptive selection), ‖ represents the concatenation operation, and Ri serialized Ri is the normalized serialized data (all fields of the record are arranged in a fixed order and converted into a byte string), Hi-1 is the evidence hash value of the previous authorized associated record, and Ti is the evidence timestamp of Ri. Meanwhile, the hash calculation latency for a single associated record is less than 1 millisecond, which will not become a performance bottleneck for the system.

[0096] Then, the evidence hash value can be stored in the evidence chain. The evidence chain is a chain of evidence organized using a chained hash structure, with its starting record (i=1) having a preset genesis hash value H0 as its predecessor dependency. The genesis hash value is generated and made public during system initialization, serving as the trust anchor point for the entire evidence chain.

[0097] The security of a chained hash structure relies on two cryptographic guarantees. Specifically, guarantee one: the collision resistance of the hash function. Records with different content will generate different hash values. Tampering with any field in any record Ri (such as amount, timestamp, or constraint rule number) will cause Hi to change. Guarantee two: the cascading failure effect of the chained structure. Changing any record Ri will cause Hi ≠ the original value. Since the calculation of Hi+1 depends on Hi, Hi+1 will also not be equal to the original value, and this will sequentially invalidate the hash values ​​of all subsequent records. This means that to tamper with the Kth related record on the chain, the hash values ​​of the Kth record and all subsequent records (a total of N-K+1 records) must be recalculated simultaneously, and this must be done before the new evidence record is appended to the evidence chain, which is computationally infeasible.

[0098] The evidence storage chain is stored internally within the system, while the latest recorded hash value (i.e., the chain tail hash) is periodically synchronized to external evidence storage media, such as enterprise-built blockchain nodes or compliant audit institutions' hosted evidence storage servers, to further enhance the credibility and tamper-proof capabilities of the evidence storage.

[0099] In other embodiments, the evidence chain storage structure can be changed from a chained hash to a Merkle tree. The Merkle tree is used to organize and schedule the storage of authorized associated records, replacing the linear chained hash structure in this embodiment. This alternative uses a time window (e.g., a calendar day) as a unit, constructing a Merkle tree with all associated records within the window as leaf nodes, and only storing the root hash of the Merkle tree on the chain. The advantage of this approach is that it can compress the storage of a batch of associated records into a single root hash value, significantly reducing the storage overhead of the evidence chain and the amount of data synchronization with external storage media. When it is necessary to verify the integrity of an associated record, only the Merkle proof path of that record (log₂N hash values, where N is the number of records within the window) needs to be provided, without traversing the entire chain. However, its disadvantage is that it increases the complexity of constructing and verifying the evidence chain, i.e., it requires maintaining the Merkle tree structure for each time window and does not support cross-window chain tracing.

[0100] Understandably, the chain hash evidence storage mechanism establishes a complete and tamper-proof chain of evidence from scheduling operations to authorization basis, enabling the chain of evidence to serve as a valid basis for compliance audits and judicial evidence collection.

[0101] In embodiments of this application, the method further includes: responding to a source tracing query request and performing one of the following operations based on the query type of the source tracing query request: querying the constraint rules associated with the authorization letter identifier from the constraint registry center based on the authorization letter identifier, and returning a list of executed scheduling instructions corresponding to the constraint rules; or returning the target constraint rule that the scheduling instruction has matched and the structured authorization letter associated with the target constraint rule based on the instruction identifier of the scheduling instruction.

[0102] Embodiments of this application also provide a compliance tracing query function based on the chain of evidence, which can be implemented through an external service interface for auditors. The query type for tracing can include forward tracing and reverse tracing modes.

[0103] The forward tracing mode starts with the authorization letter, inputs the authorization letter identifier, and returns the current and historical status of all constraint rules under that authorization letter, as well as a list of all executed scheduling operations covered by that authorization letter (including operation time, amount, and execution result). This mode is suitable for scenarios where auditors need to answer "What actual operations does this authorization letter cover?" It can trace back from the legal authorization basis to all scheduling operations executed based on that authorization, achieving top-down tracing "from authorization to operation".

[0104] The reverse tracing mode starts with the scheduling operation, inputs the scheduling instruction identifier or execution sequence number, and returns the target constraint rules on which the operation depends, the structured authorization letter (such as the original summary), the authorization status when the verification passed, the evidence hash value of the associated record, and the evidence timestamp. This mode is suitable for scenarios where auditors need to answer "What is the legal basis for this scheduling operation?" It can trace back from a single operation to the constraint rules and authorization letter that provide the basis for authorization compliance, achieving bottom-up tracing "from operation to authorization".

[0105] In other embodiments, a chain of evidence integrity verification mode may also be included, where a start record identifier and an end record identifier are input, and the sequence of stored hash values ​​of all authorized associated records between these two records is returned. Auditors can verify whether the hash values ​​of each link match, i.e., verify whether Hi equals H(Ri). serialized The hash value (|Hi-1|Ti) is used to determine the integrity of the evidence chain. Any mismatch in hash values ​​indicates that tampering has occurred in the evidence chain, thus achieving tamper-proof verification of the entire evidence chain.

[0106] It should be noted that all of the above query modes can be managed through the system access control layer. Only authorized compliance auditors can access them, and the query operation itself can also be recorded as an operation log for traceability, ensuring the auditability of the audit query behavior itself.

[0107] Understandably, by using source tracing queries, end-to-end source tracing capability is achieved from scheduling operations to authorization basis, enabling compliance audits to complete end-to-end source tracing with a single search, without the need for manual comparison across systems.

[0108] Figure 3 The illustration shows an overall flowchart of the permission management method according to an embodiment of this application.

[0109] like Figure 3As shown, the authorization process begins with data entry and modeling, converting the authorization agreement between legal entities from legal text into constraint rules that the system can automatically calculate. Specifically, in step S301, the authorized party and the authorizing party sign a structured authorization document using digital signatures. The structured authorization document's fields may include the authorizing entity identifier, the authorized object identifier, a list of business modules, a set of constraint conditions, and the authorization validity period. In step S302, the constraint modeling engine receives the structured authorization data and performs type identification and standardization transformation on the constraint conditions in the constraint condition set using the constraint authorization model. Each constraint condition is converted into a constraint rule containing operation type, constraint dimension, comparison operator, and threshold. In step S303, the constraint rules are written into the constraint registration center and stored in an index structure of outgoing entity identifier, incoming entity identifier, and operation type. Then, scheduling execution and pre-verification are performed. This process is the normal operation of the system and is triggered with each generation of scheduling instructions. In step S304, the funds scheduling engine generates scheduling instructions according to the established funds plan and liquidity rules. These scheduling instructions include the operation type, outgoing entity identifier, incoming entity identifier, scheduling amount, and account identifier. In step S305, the pre-scheduling verification engine extracts the aforementioned parameters from the scheduling instruction, queries the constraint registry center for a matching set of target constraint rules, and performs compliance verification on the corresponding parameters of the scheduling instruction according to the constraint dimension, summarizing the verification results. If all verifications pass, the actual fund transfer operation is executed in step S306; if at least one verification fails, in step S307, the instruction is rejected and a violation notice is generated. The violation notice includes a summary of the rejected scheduling instruction, details of the violation constraint rules, and suggested adjustment schemes. Furthermore, an evidence chain is established. This process is triggered after each successful execution of a scheduling instruction and forms the basis for post-event compliance audit capabilities. The scheduling-authorization association engine traces back the target constraint rules matched in the verification phase, tracing upwards along the target constraint rules to their source structured authorization letter, obtaining the authorization letter identifier, and establishing an authorization association record in step S308 based on the execution result record and the authorization letter identifier. Then, in step S309, the evidence hash value of the authorization association record can be calculated and appended to the evidence chain. Simultaneously, in step S310, three query modes can be provided externally: forward tracing, reverse tracing, and evidence chain integrity verification. Furthermore, the process is linked throughout its lifecycle. This segment of the process runs continuously in a scheduled loop.In step S311, the lifecycle linkage engine scans the status of each constraint rule in the constraint registry according to the configurable inspection cycle, and performs a timeliness judgment based on the remaining validity period of each constraint rule (step S312): if the remaining validity period is greater than the warning advance days, the valid status remains unchanged; if the remaining validity period is less than or equal to the warning advance days, the status of the constraint rule is switched from the valid status to the first transitional status, and a warning notification is triggered (step S313); if the expiration time has been exceeded, the status of the constraint rule is switched from the first transitional status to the second transitional status or from the second transitional status to the invalid status, and in step S314, the scheduling capability is gradually restricted according to the preset level sequence until it is completely prohibited. When the structured authorization is renewed and signed, the status of the constraint rule is reset to the valid status, and the scheduling capability is automatically restored.

[0110] It is understandable that, through the above process, this application embodiment achieves a closed-loop process from authorization signing, scheduling verification, violation handling, expiration linkage to renewal recovery. In the verification pass scenario, the end-to-end latency of the entire verification process is controlled at the millisecond level, and will not become a performance bottleneck in the scheduling instruction link. In the verification fail scenario, the violation instruction is intercepted before the scheduling instruction is executed, eliminating the compliance risk exposure of the traditional "execute first, then manually verify" approach. In the authorization expiration scenario, the tiered transition mechanism allows the scheduling capability to be gradually phased out, ensuring that the basic flow of funds will not be completely interrupted due to a one-size-fits-all strategy during the transition period after expiration.

[0111] Based on the above-described access control method, this application also provides an access control device. The following will be combined with... Figure 4 The device is described in detail.

[0112] Figure 4 A schematic block diagram of a permission management device according to an embodiment of this application is shown.

[0113] like Figure 4 As shown, the permission management device 400 in this embodiment includes an acquisition module 410, a conversion module 420, a matching module 430, a verification module 440, and an execution module 450.

[0114] The acquisition module 410 is used to acquire a structured authorization document in response to the authorization signing operation, wherein the structured authorization document includes a set of constraints. In one embodiment, the acquisition module 410 may be used to perform step S210 described above, which will not be repeated here.

[0115] The conversion module 420 is used to perform type identification and standardization conversion on the constraints in the constraint set through the constraint authorization model to obtain constraint rules, and then write the constraint rules into the constraint registry center. In one embodiment, the conversion module 420 can be used to execute step S220 described above, which will not be repeated here.

[0116] The matching module 430 is used to receive scheduling instructions generated by the fund scheduling engine, and according to the scheduling instructions, query the matching constraint rules from the constraint registry center to obtain the target constraint rule. In one embodiment, the matching module 430 can be used to execute step S230 described above, which will not be repeated here.

[0117] The verification module 440 is used to verify whether the scheduling instruction meets the target constraint rules and obtain the verification result. In one embodiment, the verification module 440 can be used to execute the step S240 described above, which will not be repeated here.

[0118] The execution module 450 is used to execute the scheduling instruction in response to the verification result indicating that the verification has passed. In one embodiment, the execution module 450 can be used to execute the step S250 described above, which will not be repeated here.

[0119] According to an embodiment of this application, the execution module 450 can also be used to: in response to the successful execution of the scheduling instruction, obtain the execution result record after the scheduling instruction is completed; backtrack the target constraint rules that the scheduling instruction has matched, and determine the authorization identifier of the associated structured authorization document according to the target constraint rules; and establish an authorization association record between the scheduling instruction and the structured authorization document based on the execution result record and the authorization identifier.

[0120] According to an embodiment of this application, the execution module 450 can also be used to: calculate the evidence hash value of the authorized associated record; and store the evidence hash value to the evidence chain, wherein the evidence chain is an evidence chain organized by a chain hash structure.

[0121] According to an embodiment of this application, the execution module 450 can also be used to: respond to a source tracing query request and, based on the query type of the source tracing query request, perform one of the following operations: query the constraint rules associated with the authorization letter identifier from the constraint registry center and return a list of executed scheduling instructions corresponding to the constraint rules; or, based on the instruction identifier of the scheduling instruction, return the target constraint rule that the scheduling instruction has matched and the structured authorization letter associated with the target constraint rule.

[0122] According to an embodiment of this application, the verification module 440 can be specifically used to: verify the parameters in the scheduling instruction corresponding to the constraint dimension according to the constraint dimension of the target constraint rule, and obtain the verification result.

[0123] According to an embodiment of this application, the conversion module 420 can be specifically used to: convert constraints into logical expressions corresponding to the constraint types based on the constraint types using a constraint authorization model; and assemble the logical expressions into constraint rules.

[0124] According to an embodiment of this application, the conversion module 420 can also be used to: scan the status of each constraint rule in the constraint registry center; and, according to the remaining validity period of the constraint rule, switch the status of the constraint rule from a valid state to a first transitional state, from the first transitional state to a second transitional state, or from the second transitional state to an invalid state; wherein, in the valid state, all scheduling instructions are allowed to be executed; in the first transitional state, all scheduling instructions are allowed to be executed and a warning notification is sent; in the second transitional state, scheduling instructions that meet preset scheduling conditions are prohibited from being executed; and in the invalid state, all scheduling instructions are prohibited from being executed.

[0125] According to an embodiment of this application, the execution module 450 can also be used to: refuse to execute the scheduling instruction and send a violation notification in response to a verification result indicating that the verification failed.

[0126] According to embodiments of this application, any multiple modules among the acquisition module 410, conversion module 420, matching module 430, verification module 440, and execution module 450 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the acquisition module 410, conversion module 420, matching module 430, verification module 440, and execution module 450 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the acquisition module 410, conversion module 420, matching module 430, verification module 440 and execution module 450 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0127] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a permission management method according to an embodiment of this application.

[0128] like Figure 5As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory 502 or a program loaded from a storage portion 508 into a random access memory 503. The processor 501 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0129] Random access memory 503 stores various programs and data required for the operation of electronic device 500. Processor 501, read-only memory 502, and random access memory 503 are interconnected via bus 504. Processor 501 executes various steps of the method flow according to embodiments of this application by executing programs stored in read-only memory 502 and / or random access memory 503. It should be noted that programs may also be stored in one or more memories other than read-only memory 502 and random access memory 503. Processor 501 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0130] According to embodiments of this application, the electronic device 500 may further include an input / output interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card, such as a local area network card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0131] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0132] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 502, and / or random access memory 503, and / or one or more memories other than read-only memory 502 and random access memory 503 described above.

[0133] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0134] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0135] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0136] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0137] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0138] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for managing access permissions, characterized in that, include: In response to the authorization and signing operation, a structured authorization document is obtained, wherein the structured authorization document includes a set of constraints; The constraint authorization model is used to identify and standardize the constraints in the constraint set to obtain constraint rules, which are then written into the constraint registry. Receive scheduling instructions generated by the fund scheduling engine, and query matching constraint rules from the constraint registration center according to the scheduling instructions to obtain the target constraint rule; Verify whether the scheduling instruction satisfies the target constraint rule, and obtain the verification result; and In response to the verification result indicating that the verification passed, the scheduling instruction is executed.

2. The method according to claim 1, characterized in that, Also includes: In response to the successful execution of the scheduling instruction, the execution result record after the scheduling instruction is executed is obtained; Backtrack the target constraint rules that the scheduling instruction has matched, and determine the authorization identifier of the associated structured authorization document based on the target constraint rules; as well as Based on the execution result record and the authorization certificate identifier, an authorization association record is established between the scheduling instruction and the structured authorization certificate.

3. The method according to claim 2, characterized in that, Also includes: Calculate the evidence hash value of the authorized associated record; as well as The evidence hash value is stored in the evidence chain, wherein the evidence chain is an evidence chain organized by a chain hash structure.

4. The method according to claim 2 or 3, characterized in that, Also includes: In response to a source tracing query request, and depending on the query type of the source tracing query request, perform one of the following operations: Based on the authorization identifier, query the constraint rules associated with the authorization identifier from the constraint registry center, and return a list of executed scheduling instructions corresponding to the constraint rules; or Based on the instruction identifier of the scheduling instruction, return the target constraint rule that the scheduling instruction has matched, and the structured authorization letter associated with the target constraint rule.

5. The method according to claim 1, characterized in that, The step of verifying whether the scheduling instruction satisfies the target constraint rule and obtaining the verification result includes: Based on the constraint dimension of the target constraint rule, the parameters in the scheduling instruction corresponding to the constraint dimension are verified to obtain the verification result.

6. The method according to claim 1, characterized in that, The constraint authorization model is used to identify and standardize the constraints in the constraint set to obtain constraint rules, including: Based on the constraint type of the aforementioned constraints, the constraint authorization model is used to convert the constraints into logical expressions corresponding to the constraint type; and The logical expressions are assembled into the constraint rules.

7. The method according to claim 1 or 6, characterized in that, Also includes: Scan the status of each constraint rule in the constraint registry center; as well as Based on the remaining validity period of the constraint rule, the state of the constraint rule is switched from a valid state to a first transitional state, from the first transitional state to a second transitional state, or from the second transitional state to an invalid state. In the effective state, all scheduling instructions are allowed to be executed; in the first transitional state, all scheduling instructions are allowed to be executed and a warning notification is sent; in the second transitional state, scheduling instructions that meet preset scheduling conditions are prohibited from being executed; and in the ineffective state, all scheduling instructions are prohibited from being executed.

8. The method according to claim 1, characterized in that, Also includes: In response to the verification result indicating that the verification failed, the scheduling instruction is refused to be executed, and a violation notification is sent.

9. A permission management device, characterized in that, include: The acquisition module is used to acquire a structured authorization document in response to the authorization and signing operation, wherein the structured authorization document includes a set of constraints. The conversion module is used to perform type identification and standardization conversion on the constraints in the constraint set through the constraint authorization model to obtain constraint rules, and write the constraint rules into the constraint registry center; The matching module is used to receive the scheduling instructions generated by the fund scheduling engine, and according to the scheduling instructions, query the matching constraint rules from the constraint registration center to obtain the target constraint rules; The verification module is used to verify whether the scheduling instruction satisfies the target constraint rule and obtain the verification result; and An execution module is used to execute the scheduling instruction in response to the verification result indicating that the verification has passed.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images