An inter-agency AI payment authority management method

Abstract

This invention discloses a cross-institutional AI payment permission control method, relating to the fields of financial payment security and artificial intelligence permission control technology. This method is applied to AI payment agent nodes and payment escrow nodes deployed in independent financial systems. It verifies the legitimacy of both ends through bidirectional payment handshake messages, aligns permission dimensions based on payment permission meta-templates, and generates a negotiated and agreed-upon payment permission set through five-dimensional boundary trimming. Both parties store this as a mutually recognized payment authorization snapshot, and synchronize the authorization status through state change messages. This solution can be applied to scenarios such as cross-institutional AI payment escrow and smart contract payments.

Description

Technical Field

[0001] This invention relates to the fields of financial payment security and artificial intelligence access control technology, and in particular to a method for negotiating payment permissions and synchronizing states between nodes deployed in mutually independent financial systems. Background Technology

[0002] As the application of AI agent technology in financial payment scenarios expands, the demand for cross-institutional AI payment collaboration continues to grow. Payment nodes belonging to different financial institutions and different trust domains need to conduct permission interaction and fund operation control.

[0003] Existing financial payment access control solutions are all deployed within a single financial institution's system, operating on a unified account system and a unified payment access model, with a single control node handling access allocation, modification, and revocation. When payment nodes belonging to different independent financial systems interact across institutions, existing technologies suffer from the following technical shortcomings: First, the payment permission models of different institutions are inconsistent in terms of dimension definition, field format and enumeration value, and lack a standardized permission metadata mapping mechanism, making it impossible for heterogeneous systems to directly identify each other's permission descriptions. Secondly, the cross-institutional interaction process only performs single-end identity verification and lacks a standardized two-way identity verification process, which poses a security risk of identity forgery. Third, the authorization limits cannot be dynamically adjusted based on the risk control rules of the receiving end and the real-time status of the account, and the authorization boundaries do not match the actual risk control requirements; Fourth, after authorization, the permission status of both ends is maintained independently, lacking a reliable cross-end synchronization mechanism, which easily leads to inconsistent authorization status between the two ends, and thus causes security risks such as permission mismatch and overspending. Fifth, the lack of a full-chain structured evidence storage mechanism means that authorized operations and status changes cannot be fully traced, failing to meet the audit requirements of financial scenarios. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a cross-institutional AI payment permission management method to address the issues of heterogeneous permission models, one-way identity verification, insufficient risk control adaptability, and inconsistent states in the interaction of payment permissions across independent financial systems.

[0005] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: AI payment agent nodes and payment escrow nodes are deployed in independent financial systems, each maintaining its local payment permission model and transaction risk control rules. The AI ​​payment agent node generates and sends a payment handshake request message containing the institution's registration identifier, payment qualification certificate, and payment permission metadata template. Upon receiving the message, the payment escrow node verifies the identity and returns a payment handshake response message containing the corresponding fields. After completing two-way verification, the AI ​​payment agent node generates and sends a payment authorization permission set containing five dimensions: payment operation type, fund account range, authorization validity period, single transaction limit, and daily cumulative limit. The payment escrow node, based on local transaction risk control rules and real-time account status, performs boundary trimming on the five dimensions, generating a trimmed payment authorization set and returning it. Both parties store the trimmed payment authorization set as a snapshot of the mutually recognized payment authorization. When a change in payment authorization status occurs at either end, a status change message is generated and synchronized to the other node, which then updates the corresponding status of its local mutually recognized payment authorization snapshot.

[0006] Furthermore, both the payment permission meta template field and the hosting permission meta template field contain payment operation type enumeration values, account type enumeration values, time limit unit enumeration values, and limit granularity enumeration values.

[0007] Furthermore, the boundary trimming specifically includes: comparing the fund account range dimension field with the local whitelist of registered accounts and removing unregistered fund account items; comparing the payment operation type dimension field with the local set of allowed payment operations and removing unopened payment operation items; comparing the single transaction limit dimension field with the local single transaction risk control limit threshold and trimming the portion exceeding the threshold to the single transaction risk control limit threshold; comparing the daily cumulative limit dimension field with the local daily cumulative risk control limit threshold and trimming the portion exceeding the threshold to the daily cumulative risk control limit threshold; adjusting the single transaction limit and daily cumulative limit based on the account's real-time available balance, wherein the adjusted limit does not exceed the account's real-time available balance.

[0008] Furthermore, when the mutual recognition payment authorization snapshot is generated, the AI ​​payment agent node performs a hash calculation on the local snapshot content to obtain a first hash value and sends it to the payment escrow node; the payment escrow node performs a hash calculation on the local snapshot content to obtain a second hash value and sends it to the AI ​​payment agent node; when both parties compare the received hash value with the locally calculated hash value, the payment escrow node triggers a pre-freeze operation on the amount of funds in the account.

[0009] Furthermore, the payment status code includes four types: credit limit deduction, risk control freeze, payment completion, and authorization revocation; the status change message includes a transaction serial number and a change timestamp.

[0010] Furthermore, the payment handshake request message, payment authorization permission set, trimmed payment permission set, and status change message are respectively structured and stored to generate a payment authorization audit log; the payment authorization audit log includes message hash value, transaction flow association identifier, both parties' institution identifiers, and operation timestamp.

[0011] Furthermore, the payment escrow node is a blockchain smart contract node; the pruned payment permission set is written into the smart contract for on-chain storage; state changes are triggered by on-chain transactions. Beneficial effects

[0012] 1. By using a unified structure of payment permission metadata template fields, the mapping and alignment of payment permission dimensions between different financial institutions can be achieved, adapting to cross-domain interaction scenarios of heterogeneous permission models.

[0013] 2. By using two-way handshake messages and two-way identity verification, the legitimacy of the entities interacting across institutions is guaranteed, reducing the security risks of unauthorized operations and identity forgery.

[0014] 3. By combining five-dimensional boundary trimming with adjustments to limits based on the account's real-time available balance, the final authorization permissions are matched with the risk control rules of the receiving end and the actual status of the account, thereby improving the risk control adaptability of payment authorization.

[0015] 4. By using the mutual recognition payment authorization snapshot and status change synchronization mechanism, the authorization status of both ends is kept consistent, avoiding issues such as mismatch of permissions and overspending.

[0016] 5. Generate payment authorization audit logs through structured storage of end-to-end messages to meet the end-to-end audit and traceability requirements of financial scenarios.

[0017] 6. When using blockchain smart contract nodes as payment escrow nodes, on-chain trusted storage of authorization results and transparent execution of state changes can be achieved, further enhancing the credibility of cross-institutional payment authorization. Detailed Implementation

[0018] The present invention will be further described in detail below with reference to specific embodiments.

[0019] This embodiment provides a cross-institutional AI payment permission control method. The AI ​​payment agent node is deployed in the first financial institution system, and the payment escrow node is deployed in the second financial institution system. The two financial institution systems are independent of each other, each maintaining its own independent account system, payment permission model, and transaction risk control rules. The two systems interact with each other through a dedicated financial network.

[0020] This method specifically includes the following steps: Step 1: Trusted Handshake Phase The AI ​​payment agent node generates a payment handshake request message. The message structure includes a header, an institution registration identifier field, a payment qualification certificate field, a payment authority metadata template field, and a footer. The institution registration identifier field carries the registration information of the primary financial institution; the payment qualification certificate field carries the payment qualification verification data of the AI ​​payment agent node; and the payment authority metadata template field includes enumerated values ​​for payment operation type, account type, time limit unit, and limit granularity. The AI ​​payment agent node then sends the payment handshake request message to the payment escrow node.

[0021] After receiving the payment handshake request message, the payment escrow node extracts the institution registration identifier field and the payment qualification certificate field, and compares them with the locally stored list of legitimate institution registrations and the payment qualification database. If the verification fails, the interaction terminates; if the verification succeeds, a payment handshake response message is generated. The message structure includes a header, an escrow institution identifier field, an escrow qualification certificate field, an escrow terminal permission meta-template field, and a message footer. The escrow terminal permission meta-template field contains enumerated values ​​for payment operation type, account type, time limit unit, and limit granularity. The payment escrow node then returns the payment handshake response message to the AI ​​payment agent node.

[0022] After receiving the payment handshake response message, the AI ​​payment agent node extracts the custodian identifier field and the custodian qualification certificate field, and compares them with the locally stored list and qualification database of legitimate custodians. If the verification fails, the interaction terminates; if the verification succeeds, a two-way trusted identity handshake is completed, and the process enters the permission negotiation phase.

[0023] Step Two: Permission Negotiation and Boundary Trimming Phase The AI ​​payment agent node generates a payment authorization permission set based on the local payment permission policy. This set is represented using structured fields, including: payment operation type, fund account range, authorization validity period, single transaction limit, and daily cumulative limit. Specifically, the payment operation type field is a subset of the payment operation type enumeration values ​​in the payment permission meta-template; the fund account range field is the set of specific accounts corresponding to the account type enumeration values ​​in the payment permission meta-template; the authorization validity period field contains the start and end timestamps; and the single transaction limit and daily cumulative limit fields contain the corresponding monetary values. The AI ​​payment agent node then sends the payment authorization permission set to the payment escrow node.

[0024] After receiving the payment authorization set, the payment escrow node performs boundary trimming based on local transaction risk control rules and the real-time account status. The trimming process is divided into five dimensions: First, the scope of funds accounts is pruned: the scope of funds accounts in the payment authorization permission set is compared with the local whitelist of registered accounts, and unregistered funds account items are removed; Second, payment operation type dimension pruning: compare the payment operation type dimension field in the payment authorization permission set with the local allowed payment operation set, and remove payment operation items that are not enabled; Third, single transaction limit dimension pruning: compare the single transaction limit dimension field with the local single transaction risk control limit threshold, and prune the part exceeding the threshold to the single transaction risk control limit threshold; Fourth, daily cumulative limit dimension pruning: compare the daily cumulative limit dimension field with the local daily cumulative risk control limit threshold, and prune the part exceeding the threshold to the daily cumulative risk control limit threshold; Fifth, account balance adaptation adjustment: adjust the single transaction limit and daily cumulative limit based on the real-time available balance of the corresponding account, and the adjusted limit shall not exceed the real-time available balance of the account.

[0025] After the payment escrow node completes the above-mentioned trimming process, it generates a trimmed payment permission set and returns the trimmed payment permission set to the AI ​​payment agent node.

[0026] Step 3: Mutual Recognition Payment Authorization Snapshot Generation Stage The AI ​​payment agent node receives the trimmed payment permission set, and the payment escrow node locally retains the trimmed payment permission set. Both parties store the trimmed payment permission set as a mutual recognition payment authorization snapshot. The data structure of the mutual recognition payment authorization snapshot includes: the identifiers of both institutions, the negotiation timestamp, the payment operation type dimension field, the fund account range dimension field, the authorization validity period dimension field, the single transaction limit dimension field, the daily cumulative limit dimension field, and the unique payment authorization identifier.

[0027] Hash consistency checks are performed during snapshot generation: The AI ​​payment agent node performs a hash calculation on the local mutual recognition payment authorization snapshot content, obtains the first hash value, and sends it to the payment escrow node. The payment escrow node performs a hash calculation on the local mutual recognition payment authorization snapshot content to obtain a second hash value and sends it to the AI ​​payment agent node; Both parties compare the received hash value with the locally calculated hash value. If they match, the negotiation is confirmed to be complete, and the payment escrow node triggers the pre-freezing operation of the corresponding fund account.

[0028] Step 4: Authorization Status Synchronization Phase When the payment authorization status changes at an AI payment agent node or payment escrow node, a status change message is generated. The structure of the status change message includes a unique payment authorization identifier, a payment status code, a transaction serial number, and a change timestamp. The payment status code can have four values: credit limit deduction, risk control freeze, payment completion, and authorization revocation. The status change message is synchronized to the other node via a dedicated financial network.

[0029] After receiving the status change message, the counterpart node locates the corresponding mutual recognition payment authorization snapshot based on the unique payment authorization identifier and updates the corresponding status field in the snapshot.

[0030] Step 5: Audit Evidence Preservation Stage The payment handshake request message, payment handshake response message, payment authorization permission set, trimmed payment permission set, and status change message generated during the interaction process are stored in a structured manner. Each stored record includes a message hash value, transaction flow association identifier, sender institution identifier, receiver institution identifier, and operation timestamp, forming a complete payment authorization audit log for subsequent audit traceability.

[0031] Optional Blockchain Implementation Examples In another embodiment, the payment escrow node is a blockchain smart contract node. The pruned payment permission set is written into the smart contract for on-chain storage, and the hash value of the mutually recognized payment authorization snapshot is synchronously recorded on the blockchain; changes in payment authorization status are triggered by on-chain transactions, and the transaction records are synchronously stored in the blockchain distributed ledger.

[0032] The above description is only a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. Any equivalent modifications or changes made by those skilled in the art based on the disclosure of the present invention should be included within the scope of protection set forth in the claims.

Claims

1. A cross-institutional AI payment permission control method, applied to AI payment agent nodes and payment escrow nodes deployed in mutually independent financial systems, wherein each AI payment agent node and payment escrow node maintains its own local payment permission model and transaction risk control rules, characterized in that, The method includes the following steps: S1. The AI ​​payment agent node generates a payment handshake request message and sends it to the payment escrow node. The payment handshake request message includes an institution filing identifier field, a payment qualification certificate field, and a payment authority meta template field. S2. The payment escrow node receives the payment handshake request message, extracts the institution registration identifier field and the payment qualification certificate field for legality verification, and generates a payment handshake response message after the verification is passed and returns it to the AI ​​payment agent node. The payment handshake response message includes the escrow institution identifier field, the escrow qualification certificate field, and the escrow terminal permission meta template field. S3. The AI ​​payment agent node receives the payment handshake response message, extracts the custodian institution identifier field and the custodian qualification certificate field for legality verification, and generates a payment authorization permission set after the verification is passed and sends it to the payment custodian node. The payment authorization permission set includes payment operation type dimension field, fund account range dimension field, authorization time limit dimension field, single transaction limit dimension field, and daily cumulative limit dimension field. S4. The payment escrow node receives the payment authorization permission set and, based on local transaction risk control rules and real-time account status, performs boundary trimming on the payment operation type dimension field, fund account range dimension field, authorization time limit dimension field, single transaction limit dimension field, and daily cumulative limit dimension field, generates a trimmed payment permission set, and returns it to the AI ​​payment agent node. S5. The AI ​​payment agent node and the payment escrow node respectively store the trimmed payment permission set as a mutual recognition payment authorization snapshot. The mutual recognition payment authorization snapshot includes the identification of both parties' institutions, negotiation timestamp, payment operation type dimension field, fund account range dimension field, authorization time limit dimension field, single transaction limit dimension field, daily cumulative limit dimension field, and unique payment authorization identifier. S6. When the payment authorization status of the AI ​​payment agent node or payment escrow node changes, a status change message containing the unique payment authorization identifier and payment status code is generated and synchronized to the other node. After receiving the message, the other node updates the corresponding status of its local mutual recognition payment authorization snapshot.

2. The method according to claim 1, characterized in that, Both the payment permission metadata field and the hosting permission metadata field contain enumerated values ​​for payment operation type, account type, time limit unit, and limit granularity.

3. The method according to claim 1, characterized in that, The boundary trimming in S4 specifically includes: The fund account scope dimension field is compared with the local whitelist of registered accounts, and unregistered fund account items are removed; The payment operation type dimension field is compared with the local set of allowed payment operations, and payment operation items that are not enabled are removed; The single transaction limit dimension field is compared with the local single transaction risk control limit threshold, and the portion exceeding the threshold is pruned to the single transaction risk control limit threshold. The daily cumulative limit dimension field is compared with the local daily cumulative risk control limit threshold, and the portion exceeding the threshold is cropped to the daily cumulative risk control limit threshold; The single transaction limit and daily cumulative limit are adjusted based on the account's real-time available balance, and the adjusted limit shall not exceed the account's real-time available balance.

4. The method according to claim 1, characterized in that, S5 specifically includes: The AI ​​payment agent node performs a hash calculation on the local mutual recognition payment authorization snapshot content, obtains the first hash value, and sends it to the payment escrow node. The payment escrow node performs a hash calculation on the local mutual recognition payment authorization snapshot content to obtain a second hash value and sends it to the AI ​​payment agent node; When both parties compare the received hash value with the locally calculated hash value, the payment escrow node triggers a pre-freeze operation on the amount of funds in the account.

5. The method according to claim 1, characterized in that, The payment status codes include four types: credit limit deduction, risk control freeze, payment completion, and authorization revocation; the status change message includes a transaction serial number and a change timestamp.

6. The method according to claim 1, characterized in that, Also includes S7: The payment handshake request message, payment authorization permission set, trimmed payment permission set, and status change message are stored in a structured manner to generate a payment authorization audit log. The payment authorization audit log includes message hash value, transaction flow association identifier, identifiers of both parties, and operation timestamp.

7. The method according to claim 1, characterized in that, The payment escrow node is a blockchain smart contract node; the pruned payment permission set is written into the smart contract for on-chain storage; state changes are triggered by on-chain transactions.