Private cross-border transaction performance settlement system and method

Abstract

The invention provides a private cross-border transaction performance settlement system and method. Comprising a private access control module used for controlling access of private quotation data and order data associated with cooperative relationship identification based on an access control strategy; the contract modeling module is used for performing structured modeling on the private transaction quotation contract instance; the fulfillment arrangement module is used for generating a collection instruction corresponding to each payment node and a fulfillment instruction corresponding to each fulfillment node according to the stage node graph; the cross-border settlement control module is used for carrying out batch settlement control on the order funds, and transferring the funds of the corresponding batch to a merchant settlement account when a preset settlement condition is detected to be met; and the risk control module is used for generating risk parameters for adjusting the node parameters of the stage node graph and the control parameters of the settlement path and the exchange strategy. According to the invention, structured management of private contract terms can be realized, the cooperative efficiency of batch performance and cross-border settlement is improved, and the cost and risk of private cross-border transaction are reduced.

Description

Technical Field

[0001] This application relates to the field of transaction settlement system technology, and in particular to a private cross-border transaction performance settlement system and method. Background Technology

[0002] In the fields of cross-border trade and cross-border e-commerce, with the increasing demand for large-scale customized procurement, more and more merchants and overseas buyers are forming relatively stable transaction models through long-term cooperative relationships. Most existing mainstream platforms adopt an open-shelf model, where product prices and transaction terms are publicly available to all users, suitable for standardized products and small-amount, instant transactions. However, for "private transaction" scenarios based on existing cooperative relationships, requiring customized pricing for different customers, batch production, batch shipping, and batch payment collection, the above model is difficult to meet business needs.

[0003] In existing technologies, some platforms support private transactions by adding features such as "agreed price" and "large customer price" to their order management systems, or by signing contracts offline and entering simplified terms online. However, the technical implementation often only covers price field differentiation, simple installment payment configuration, and manual maintenance of shipping batches. Cross-border logistics, customs clearance, escrow collection, and currency exchange settlement are usually handled by different systems, lacking a unified contract term modeling and collaborative control mechanism for the performance process, as well as the technical means to dynamically adjust payment rhythm and settlement path based on cooperative relationships and risk status.

[0004] Therefore, in existing technologies, there is a lack of structured connection between the price terms, payment terms, and delivery terms of private transactions and the cross-border performance and settlement process. It is impossible to orchestrate and control the phased payment and performance at the system level. Access control is mostly at the account or role level, making it difficult to finely limit the visibility of private quotations and order data under different cooperative relationships. Risk assessment and compliance verification are not linked to specific payment nodes and settlement batches, resulting in operations relying on a large amount of manual docking and monitoring, which leads to low efficiency and high error rate when handling complex private cross-border transactions. Summary of the Invention

[0005] In view of this, embodiments of this application provide a private cross-border transaction performance settlement system and method to solve the problems of existing technologies, such as the lack of structured connection between private transaction contract terms and performance settlement process, the inability to uniformly arrange and control installment payments and installment performances in stages, and the inability to dynamically manage private data access and cross-border settlement paths based on cooperative relationships and risk parameters.

[0006] The first aspect of this application provides a private cross-border transaction fulfillment and settlement system, comprising: a private access control module, used to receive cooperation invitation information from merchants and buyers, establish cooperation relationship records, generate a cooperation relationship identifier and access control policy for each cooperation relationship, and control access to private quotation data and order data associated with the cooperation relationship identifier based on the access control policy; a contract modeling module, used to generate a private transaction quotation contract instance associated with the target buyer based on the cooperation relationship identifier and a preset quotation template, perform structured modeling on the private transaction quotation contract instance, and solidify the target version of the private transaction quotation contract instance as contract baseline data after negotiation and confirmation; and a fulfillment orchestration module, used to parse a stage node diagram containing multiple payment nodes and fulfillment nodes based on the contract baseline data, establish an association between the stage node diagram and the order to construct an order state machine. The system generates payment instructions for each payment node and performance instructions for each performance node based on the phase node diagram, and drives the order state machine to perform state transitions according to the phase node diagram to form order status data. The cross-border settlement control module is used to determine the settlement path and exchange strategy based on contract baseline data, order status data, and risk parameters. It performs batch settlement control on order funds paid by the buyer to the escrow account. When the preset settlement conditions are met, the corresponding batch of funds is transferred to the merchant's settlement account, and a settlement record carrying the order identifier and batch identifier is generated. The risk control module is used to conduct risk assessment and compliance verification on the buyer and the order based on the cooperation relationship record, contract baseline data, and payment and performance information generated during order execution. It generates risk parameters to adjust the node parameters of the phase node diagram and the control parameters of the settlement path and exchange strategy.

[0007] The second aspect of this application provides a method for private cross-border transaction performance settlement, including: receiving cooperation invitation information from a merchant and a buyer, establishing a cooperation relationship record, generating a cooperation relationship identifier and access control policy for each cooperation relationship, and performing controlled access to private quotation data and order data associated with the cooperation relationship identifier based on the access control policy; generating a private transaction quotation contract instance associated with the target buyer based on the cooperation relationship identifier according to a preset quotation template, performing structured modeling on the private transaction quotation contract instance, and solidifying the target version of the private transaction quotation contract instance into contract baseline data after negotiation and confirmation; parsing the contract baseline data to obtain a stage node diagram containing multiple payment nodes and performance nodes, establishing an association between the stage node diagram and the order to construct an order state machine; and generating each payment node according to the stage node diagram. The system generates order status data by driving the order state machine to transition according to the stage node diagram when receiving payment and performance information, based on the corresponding payment instructions and performance instructions for each node. It also generates risk parameters for adjusting node parameters and settlement control parameters in the stage node diagram, based on cooperation records, contract baseline data, and payment and performance information generated during order execution. The system determines settlement paths and exchange strategies based on contract baseline data, order status data, and risk parameters, and performs batch settlement control on order funds paid by buyers to the escrow account. When preset settlement conditions are met and risk parameters are within preset ranges, the corresponding batch of funds is transferred from the escrow account to the merchant's settlement account according to the settlement path and exchange strategy, generating settlement records.

[0008] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: The privacy access control module receives cooperation invitations from merchants and buyers, establishes cooperation relationship records, generates a cooperation relationship identifier and access control policy for each cooperation relationship, and controls access to privacy pricing data and order data associated with the cooperation relationship identifier based on the access control policy. The contract modeling module generates privacy transaction pricing contract instances associated with target buyers based on the cooperation relationship identifier and a preset pricing template, performs structured modeling of these instances, and solidifies the target version of the privacy transaction pricing contract instance as contract baseline data after negotiation and confirmation. The performance orchestration module parses the contract baseline data to obtain a stage node diagram containing multiple payment and performance nodes, establishes a relationship between the stage node diagram and the order to construct an order state machine, and generates payment node pairs based on the stage node diagram. The system receives payment instructions and fulfillment instructions for each fulfillment node, driving the order state machine to transition states according to the stage node diagram to form order status data. The cross-border settlement control module determines the settlement path and exchange strategy based on contract baseline data, order status data, and risk parameters. It performs batch settlement control on order funds paid by the buyer to the escrow account, transferring the corresponding batch of funds to the merchant's settlement account when preset settlement conditions are met, and generating settlement records carrying order and batch identifiers. The risk control module performs risk assessment and compliance verification on the buyer and order based on cooperation records, contract baseline data, and payment and fulfillment information generated during order execution, generating risk parameters to adjust the node parameters of the stage node diagram and the control parameters of the settlement path and exchange strategy. This application enables structured management of private contract terms, improves the efficiency of batch fulfillment and cross-border settlement collaboration, and reduces the cost and risk of private cross-border transactions. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of the structure of the private cross-border transaction fulfillment and settlement system provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the private cross-border transaction performance and settlement method provided in the embodiments of this application. Detailed Implementation

[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0012] In existing technologies, cross-border trade and e-commerce platforms mostly adopt an open shelf model, supporting instant transactions through unified and publicly available product prices and standardized order processes. For private transaction scenarios based on existing partnerships, which require customized pricing for different customers, batch production, batch shipping, and batch payment collection, existing systems typically only make simple extensions at the price field and installment payment parameters levels. Cross-border logistics, customs clearance, escrow payment collection, and currency exchange settlement are mostly handled separately by fragmented business systems, lacking unified technical architecture support.

[0013] Against this backdrop, existing technologies suffer from the following main problems: First, there is a lack of structured connection between the price terms, payment terms, and delivery terms of private transactions and the actual performance and settlement process, making it impossible to uniformly orchestrate and control batch payments and batch performance at the system level. Second, access control for private pricing and order data is mostly limited to the account or role level, making it difficult to precisely define the specific cooperative relationship. Third, risk assessment and compliance verification results are difficult to link with specific payment nodes, settlement batches, and settlement paths, resulting in insufficient responsiveness of cross-border settlement processes to cooperative relationships and risk conditions, and operations relying heavily on manual intervention.

[0014] To address the aforementioned technical issues, this application proposes a private cross-border transaction performance settlement system and method. The system includes a private access control module that parses cooperation invitations between merchants and buyers, generating cooperation relationship identifiers and access control policies. These identifiers are then used as indexes for controlled access to private quotation and order data. A contract modeling module performs structured modeling and version management on private transaction quotation contract instances generated from preset quotation templates, solidifying them as contract baseline data after negotiation and confirmation. A performance orchestration module parses the contract baseline data to obtain a stage node diagram containing multiple payment and performance nodes, and associates this diagram with orders to construct an order state machine. Based on the stage node diagram, corresponding payment and performance instructions are generated, driving the order status to migrate stage by stage along with payment and performance information. A cross-border settlement control module determines settlement paths and exchange strategies based on contract baseline data, order status data, and risk parameters, implementing batch settlement control for order funds in the escrow account. Finally, a risk control module conducts risk assessments and compliance checks on the cooperation relationship and order execution process, generating risk parameters for adjusting stage node diagram parameters and settlement control parameters.

[0015] By adopting the above technical solutions, this application can achieve structured modeling and baseline solidification of private transaction contract terms, enabling the orchestration and control of the installment payment and installment performance processes within a unified framework of stage node diagrams and order state machines; it can implement fine-grained access control on private quotation data and order data at the level of cooperation relationships, and enhance data security through field-level encryption; at the same time, it embeds risk assessment and compliance verification results into the control of performance orchestration and cross-border settlement paths in a parameterized form, improving the collaborative efficiency of installment performance and cross-border settlement, and reducing the operating costs and risks of private cross-border transactions.

[0016] The specific structure and functions of the private cross-border transaction performance and settlement system provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 This is a schematic diagram of the structural composition of the private cross-border transaction fulfillment and settlement system provided in the embodiments of this application, as shown below. Figure 1 As shown, this private cross-border transaction fulfillment and settlement system may specifically include the following modules: The private access control module 101 is used to receive cooperation invitation information from merchants and buyers, establish cooperation relationship records, generate cooperation relationship identifiers and access control policies for each cooperation relationship, and control access to private quotation data and order data associated with the cooperation relationship identifier based on the access control policies. The contract modeling module 102 is used to generate a private transaction quotation contract instance associated with the target buyer based on the cooperation relationship identifier and according to the preset quotation template, to perform structured modeling of the private transaction quotation contract instance, and to solidify the target version of the private transaction quotation contract instance into the contract baseline data after negotiation and confirmation. The performance orchestration module 103 is used to parse the contract baseline data to obtain a stage node diagram containing multiple payment nodes and performance nodes, establish a relationship between the stage node diagram and the order to build an order state machine, generate the payment instructions corresponding to each payment node and the performance instructions corresponding to each performance node according to the stage node diagram, and drive the order state machine to perform state transitions according to the stage node diagram to form order state data. The cross-border settlement control module 104 is used to determine the settlement path and exchange strategy based on contract baseline data, order status data and risk parameters, to perform batch settlement control on order funds paid by the buyer to the escrow account, and to transfer the corresponding batch of funds to the merchant's settlement account when the preset settlement conditions are met, and to generate a settlement record carrying the order identifier and batch identifier. The risk control module 105 is used to conduct risk assessment and compliance verification of buyers and orders based on cooperation relationship records, contract baseline data, and payment and performance information generated during order execution. It generates risk parameters to adjust the node parameters of the stage node diagram and the control parameters of settlement path and foreign exchange strategy.

[0017] In some embodiments, a partnership identifier and access control policy are generated for each partnership, and access to private pricing data and order data associated with the partnership identifier is controlled based on the access control policy, including: The received cooperation invitation information is parsed to determine the merchant identifier, buyer identifier, and cooperation level parameters, and a unique cooperation relationship identifier is generated based on the merchant identifier and buyer identifier. Based on the cooperation level parameters, product category parameters, and risk parameters, a target access control template is selected from the preset strategy template library, and the cooperation relationship identifier is injected into the target access control template to generate the corresponding access control policy; When writing private pricing data and order data, the partnership identifier is written as an index field into the corresponding data record, and the fields marked as restricted access are stored with field-level encryption according to the access control policy. When receiving access requests for private pricing data and order data, the target partnership identifier is obtained by parsing the subject identifier in the access request. The access control policy corresponding to the target partnership identifier is called to determine the access permission. If the permission is allowed, the encrypted restricted fields are decrypted and output. If the permission is not allowed, the reading of the corresponding restricted fields is blocked.

[0018] Specifically, the privacy access control module in the privacy cross-border transaction performance and settlement system is used to achieve fine-grained access control over privacy quotation data and order data at the level of cooperation relationship. By generating a cooperation relationship identifier and access control policy for each cooperation relationship, all subsequent data reading and writing related to the cooperation relationship are uniformly incorporated into the same control logic, thereby achieving differentiated permission management for different buyers, different products and different risk levels without changing the business process.

[0019] In this embodiment, the "cooperation relationship identifier" can be understood as a globally unique identifier generated by the system for each pair of merchants and buyers. This identifier corresponds one-to-one with the merchant identifier, buyer identifier, and cooperation level parameter, and is used to bind subsequent private pricing data, order data, and specific cooperation relationships.

[0020] The "cooperation level parameter" is used to characterize the level of cooperation between the buyer and the merchant. For example, it can be divided into different levels such as trial cooperation, ordinary cooperation, and key cooperation based on factors such as historical order volume, cooperation duration, and performance record.

[0021] The "Product Category Parameter" is used to identify the category of the products involved in the private transaction. For example, by setting up a product classification tree, products can be classified into categories such as steel, agricultural products, and electronic products, which makes it easier to control the scope of data access by category in the future.

[0022] The "risk parameters" are calculated by the risk control module based on the cooperation relationship records, contract baseline data, and payment and performance information during the execution process. They are used to reflect the current risk status of the cooperation relationship and the order.

[0023] The "Policy Template Library" is a collection of pre-defined access control policies in the system. Each access control template predefines the range of data that can be accessed, field-level permissions, and encryption rules under different cooperation levels, product categories, and risk conditions.

[0024] "Field-level encryption" refers to independently encrypting and storing fields marked as restricted access in a data record. Even if an unauthorized entity can access the entire record, it cannot directly obtain the plaintext content of the encrypted fields.

[0025] The "subject identifier" can be a login account, an operator role, or a service identifier of the calling party, and is used to identify the visitor when receiving an access request.

[0026] In some examples, the system first receives a cooperation invitation message when a merchant and a buyer establish a cooperative relationship through a front-end page or interface. The cooperation invitation message includes at least a merchant identifier, a buyer identifier, and cooperation level parameters configured by business rules or operations personnel. The privacy access control module parses the received cooperation invitation message, identifies the merchant identifier and buyer identifier, and then calls the unique identifier generation logic to generate a unique cooperation relationship identifier based on the merchant identifier and buyer identifier. For example, the system can combine the merchant ID "SUP001" and the buyer ID "BUY1001" using a preset encoding rule to generate the cooperation relationship identifier "REL-SUP001-BUY1001", and write this cooperation relationship identifier and the corresponding cooperation level parameters into the cooperation relationship record.

[0027] Furthermore, after generating the partnership identifier, the privacy access control module needs to configure an access control policy for this partnership. To this end, the module reads the partnership level parameters from the partnership record and combines them with the product category parameters provided by the contract modeling module or product management module, as well as the risk parameters output by the risk control module, to form access policy selection conditions. For example, when the partnership level is "key partnership," the product category is "electronic products," and the risk parameters are in the low-risk range, the system will select a matching target access control template from the preset policy template library based on the above three parameter combinations. This access control template can be predefined to allow key partners to view relatively complete quotation details, historical orders, and some cost-related fields, while ordinary partners can only view non-sensitive fields such as the total price including tax and delivery terms. After selecting the target access control template, the privacy access control module injects the aforementioned partnership identifier into the template, instantiates all the condition parameters related to the "scope of partnership" in the template, generates a dedicated access control policy for this partnership, and establishes an association between the partnership identifier and the access control policy in the policy storage area.

[0028] During the writing of private quotation and order data, the contract modeling module or order management module, when generating private transaction quotation contract instances and order records, will write the corresponding cooperation relationship identifier as an index field into the data records. For example, when generating a quotation record, the value of the field "relation_id" is set to "REL-SUP001-BUY1001", and the unit price, discount coefficient, cost estimate, and other fields are marked as restricted access fields in the same record. Based on the aforementioned access control strategy, the private access control module performs field-level encrypted storage operations on these restricted access fields. It can use symmetric encryption algorithms or the encryption / decryption interface provided by the hardware security module to encrypt the unit price, discount, and other fields one by one, and write the encrypted results into the database instead of directly storing plaintext. For general fields that are not marked as restricted access, such as product name, currency, tax rate, etc., they can be stored in plaintext form.

[0029] When the system receives access requests for confidential pricing and order data, the requests include the subject identifier and the scope of data to be accessed. The confidential access control module first parses the subject identifier to determine the account, role, and authorized partnership set of the initiating subject. Then, based on the conditions in the request message, it retrieves data records from the data storage that meet the conditions. During the retrieval process, the module categorizes the records according to the partnership identifiers and applies a pre-bound access control policy to each partnership identifier. The access control policy specifies the set of fields that the subject can access under the corresponding partnership and whether decryption of restricted fields is allowed.

[0030] The privacy access control module determines access permissions according to these rules: for fields that are allowed access, the encryption / decryption interface is called to decrypt the encrypted restricted fields when reading data, and the decrypted plaintext data is filled into the returned result; for restricted fields that the current subject does not have permission to access, the encrypted form is maintained and not decrypted, or the field is masked in the returned result, for example, by replacing it with an empty value or a mask, thereby ensuring that the visitor cannot obtain the corresponding sensitive information. In some embodiments, when the subject does not belong to any authorized subject that matches the target cooperation relationship identifier, the privacy access control module can also directly reject the access request to avoid unauthorized access.

[0031] Through the processing flow described in the above embodiments, the system can generate exclusive access control policies for each pair of merchants and buyers at the granularity of the cooperation relationship identifier. In both data writing and reading directions, the system uses the cooperation relationship identifier as an index to implement field-level control over private quotation data and order data. This ensures that the data access scope for different cooperation levels, different product categories, and different risk states is driven by a unified policy template, thereby achieving consistency, configurable permission management, and encryption protection for private cross-border transaction-related data.

[0032] In some embodiments, based on a partnership identifier, a private transaction quotation contract instance associated with the target buyer is generated according to a preset quotation template, including: Based on the partnership identifier, the target buyer identifier, partnership level parameters, and target settlement currency parameters are obtained from the partnership record, and the quotation template group corresponding to the partnership level parameters is determined. In the quotation template group, select the target preset quotation template according to the product category parameter and transaction mode parameter, and write the target buyer identifier and cooperation relationship identifier into the target preset quotation template to form a template instance identifier; Based on the set of fields defined in the target preset quotation template, combined with historical order data, pricing rules and risk parameters, the system automatically calculates the product parameters, price parameters, payment terms and delivery terms to be written, and generates a structured parameter set. The structured parameter set is bound to the template instance identifier to generate the corresponding private transaction quotation contract instance, and a contract instance identifier is assigned to the private transaction quotation contract instance.

[0033] Specifically, the contract modeling module is used to automatically generate private transaction quotation contract instances associated with target buyers in the dimension of cooperation relationship, so that the product parameters, price parameters, payment terms and delivery terms of private transactions are formed into structured contract objects in the system that can be directly referenced by the subsequent performance orchestration module.

[0034] In this embodiment, the "cooperation relationship identifier" is used to uniquely identify the cooperation relationship between a merchant and a certain buyer, corresponding to the basic key value in the aforementioned cooperation relationship record.

[0035] A “quotation template group” is a set of quotation templates pre-configured by the system according to different cooperation levels. Each quotation template group corresponds to one or more cooperation levels, such as trial cooperation, ordinary cooperation, and key cooperation. Each template group contains multiple preset quotation templates adapted to different product categories and transaction models.

[0036] The “Transaction Model Parameter” is used to identify the business model used in private transactions, such as one-off large orders, rolling replenishment, long-term framework agreements, etc. The price structure and payment and delivery rhythm differ under different transaction models.

[0037] "Historical order data" refers to the past order records related to the merchant and target buyers stored in the system, as well as statistical information such as price, quantity, and fulfillment status, which can be used as a reference for this quotation.

[0038] "Pricing rules" are parameterized pricing strategies configured by merchants in the system, such as cost-plus pricing, tiered quantity discounts, and premium adjustments based on settlement currency and settlement cycle.

[0039] The “risk parameters” are generated by the risk control module and are used to reflect the risk level of the current cooperative relationship and transaction scenario. The system can use this to introduce risk buffers in the price terms and payment terms.

[0040] "Structured parameter set" refers to a data set that organizes product parameters, price parameters, payment terms, delivery terms, etc., into a storable and computable data set in the form of key-value pairs according to the set of fields defined in the target preset quotation template.

[0041] The "Contract Instance Identifier" is used to uniquely identify a specific instance of a private transaction quotation contract, providing a reference entry point for subsequent version management and performance orchestration.

[0042] The "template instance identifier" is used to identify a template instance generated based on a preset quotation template and a specific partnership and buyer combination.

[0043] In some examples, when a merchant intends to initiate a new private transaction offer for an existing overseas buyer, the contract modeling module first receives a quote generation request from the front-end interface. This request includes a partnership identifier and basic information about the product to be quoted. Based on this partnership identifier, the contract modeling module retrieves the corresponding partnership entry from the partnership records and reads the target buyer identifier, partnership level parameters, and target settlement currency parameters.

[0044] For example, the system parses a buyer identifier of "BUY1001" from the cooperation relationship record, indicating a cooperation level of "Key Cooperation" and a target settlement currency of "EUR". Based on this cooperation level parameter, the contract modeling module retrieves the quotation template group associated with the "Key Cooperation" level from the quotation template configuration data, resulting in a set of quotation templates suitable for key cooperation clients. This template group is pre-configured with price structure fields, installment payment fields, and multi-batch delivery fields suitable for long-term stable cooperation relationships.

[0045] After determining the corresponding quotation template group, the contract modeling module further combines the product category parameters and transaction mode parameters to select a specific target preset quotation template within that group. For example, if the product category parameter indicates that the quotation involves "electronic products" and the transaction mode parameter indicates that the transaction is a "long-term framework agreement," the system will select a preset quotation template from the "Key Cooperation" template group that is suitable for electronic products and supports long-term agreements, partial shipments, and partial settlements. After selecting the target preset quotation template, the contract modeling module writes the aforementioned target buyer identifier and cooperation relationship identifier into the association field in the template header. For example, it records "buyer_id=BUY1001" and "relation_id=REL-SUP001-BUY1001" in the template header field, and generates a template instance identifier through preset coding rules, such as "TMP-REL-SUP001-BUY1001-001," indicating that this template instance is the first quotation template instance generated for this cooperation relationship and this buyer.

[0046] Subsequently, the contract modeling module drives the system to automatically calculate the structured parameter set for this private transaction quote based on the set of fields defined in the target preset quote template. For example, the target preset quote template predefines the field names, field types, and value rules for product parameters, price parameters, payment terms, and delivery terms. For instance, product parameter fields include product code, specifications, minimum order quantity, maximum single batch size, etc.; price parameter fields include base unit price, tiered quantity ranges and corresponding discount coefficients, currency, tax rate, etc.; payment term fields include prepayment ratio, installment payment time points or triggering conditions, maximum payment period, etc.; and delivery term fields include production cycle, initial shipment quantity, subsequent batch shipment intervals, and minimum shipment quantity per batch, etc.

[0047] Furthermore, the contract modeling module, based on this, extracts past transaction records related to the merchant and the target buyer from historical order data, and calculates information such as the buyer's average purchase quantity, price range, and timeliness of performance for similar products. At the same time, it reads the pricing rules configured by the merchant, such as the basic cost markup ratio, tiered discount rules based on purchase volume, and cost adjustment coefficients corresponding to different settlement currencies. It also calls the risk parameters provided by the risk control module to determine whether the current cooperative relationship is at a low-risk, moderate-risk, or high-risk level.

[0048] Based on the above data, the contract modeling module automatically fills in and calculates each field. For example, for the price parameter, the initial discount level can be determined based on the buyer's average purchase quantity range in historical orders. Then, combined with the basic markup ratio in the current pricing rules and the exchange rate adjustment factor for the settlement currency "EUR", the base unit price and the discounted unit price for different quantity ranges can be calculated. For payment terms, within the limits allowed by the pricing rules, risk parameters can be referenced. When the risk parameters indicate that the cooperation relationship is low-risk, a lower prepayment ratio and more installments can be set. When the risk parameters indicate that the risk is high, the prepayment ratio can be increased, the payment period can be shortened, and the maximum allowed number of installments can be reduced. For delivery terms, the initial shipment quantity and the interval between subsequent shipments are automatically generated based on the buyer's past delivery rhythm and the merchant's internal capacity rules in the historical performance data.

[0049] Through the above calculations and filling, the contract modeling module generates a structured parameter set containing complete product parameters, price parameters, payment terms, and delivery terms. This structured parameter set is organized into a set of key-value pair records according to the template field order.

[0050] After generating the structured parameter set, the contract modeling module binds this set to the aforementioned template instance identifier, writes all parameter fields into a new contract instance record, and assigns a contract instance identifier to the record. For example, the system can generate a contract instance identifier "CON-REL-SUP001-BUY1001-20250101" for this private transaction quotation contract instance, where the code includes the partnership identifier, buyer identifier, and generation date information.

[0051] There is a one-to-one correspondence between the contract instance identifier and the template instance identifier. At the same time, the contract instance record retains the template instance identifier field and the cooperation relationship identifier field to facilitate quick association during subsequent contract version management and performance arrangement.

[0052] At this point, the system has completed the entire process of automatically generating a private transaction quotation contract instance associated with the target buyer based on the cooperation relationship identifier and according to the preset quotation template. In subsequent negotiations with the buyer, version iterations and parameter fine-tuning can be carried out based on this contract instance.

[0053] In some embodiments, a structured model is performed on a private transaction offer contract instance, and after negotiation and confirmation, the target version of the private transaction offer contract instance is solidified as contract baseline data, including: The product parameters, price parameters, payment terms, and delivery terms in the private transaction quotation contract instance are split and mapped into a set of contract fields, and each contract field is configured with a field type identifier, association constraint parameters, and risk weight parameters to form contract structure description data; Assign version identifiers to each version of the private transaction quotation contract instance under the same cooperation relationship, construct a contract version record containing version identifiers and corresponding contract structure description data, and record the set of difference fields between each contract version record; Upon receiving the negotiation confirmation instruction, select the target version of the contract version record, lock the parameters marked as core constraint fields, generate a contract baseline identifier carrying the contract instance identifier and version identifier, and bind the contract structure description data with the contract baseline identifier and store it as contract baseline data.

[0054] Specifically, after generating a private transaction quotation contract instance associated with the target buyer, the contract modeling module is also used to perform structured modeling of the private transaction quotation contract instance. After the merchant and the buyer have negotiated and confirmed, the target version of the private transaction quotation contract instance is solidified into contract baseline data, so that the subsequent performance orchestration module and cross-border settlement control module can perform node parsing and settlement control based on the unified contract baseline.

[0055] In this embodiment, the "contract field set" is used to represent the field-level data set after the original product parameters, price parameters, payment terms and delivery terms were arranged from a business perspective. Each contract field has a fixed field name, field type and value range, which facilitates subsequent automatic verification and constraint management.

[0056] The "Field Type Identifier" is used to identify whether the field belongs to the product dimension, price dimension, payment dimension, or delivery dimension, or to other extended dimensions. For example, the "unit_price" field can be marked as a price field, and the "prepay_ratio" field can be marked as a payment field.

[0057] "Association constraint parameters" are used to record the constraint relationship between this field and other fields, such as whether a field depends on another field, whether it needs to satisfy the condition that the sum of the field and other fields is 100%, and whether it is subject to a certain upper or lower limit condition.

[0058] The “risk weight parameter” is calculated by the risk control module or rule engine and is used to characterize the sensitivity of the field in the overall risk assessment. For example, price-related fields and payment period-related fields can be assigned higher risk weights so that they can be given priority when adjusting risk parameters in the future.

[0059] "Contract structure description data" is a combination of the above-mentioned set of contract fields, their field type identifiers, associated constraint parameters, and risk weight parameters, forming structured contract metadata that can be parsed by the system.

[0060] The “Version Identifier” is used to distinguish different contract versions formed during multiple rounds of negotiation under the same cooperative relationship. The “Difference Field Set” is used to record the list of fields that have changed between different versions, making it easy to quickly identify the adjustments made in this round of negotiation relative to the previous version.

[0061] The "Contract Baseline Identifier" is used to uniquely identify the finally confirmed contract baseline. It usually carries a contract instance identifier and a version identifier and is used for reference in all subsequent performance and settlement logic.

[0062] In some examples, after the contract modeling module completes the generation of the private transaction quotation contract instance in the previous embodiment, it will perform field-level splitting of the product parameters, price parameters, payment terms, and delivery terms in the contract instance. According to preset field definitions, the system categorizes the "product code," "specifications," and "minimum order quantity" in the contract instance into the product field; "base unit price," "tiered quantity range," "discount coefficient," and "target settlement currency" into the price field; "prepayment ratio," "number of installments," "payment deadline for each installment," and "maximum payment period" into the payment field; and "initial shipment quantity," "interval between each shipment," "minimum shipment quantity," and "latest delivery time" into the delivery field.

[0063] For each field, the contract modeling module generates a corresponding contract field entry and configures a field type identifier for it. For example, it identifies "base_price" as type "PRICE", "prepay_ratio" as type "PAYMENT", and "delivery_deadline" as type "DELIVERY", thus forming a structured set of contract fields.

[0064] While generating the contract field set, the contract modeling module configures associated constraint parameters for each field according to preset contract constraint rules and merchant-configured business rules. For example, the system can configure a constraint relationship with a sum of 100% for the three fields "prepay_ratio", "middle_payment_ratio", and "final_payment_ratio", configure a constraint relationship for the "delivery_deadline" field that it cannot be earlier than the end time of the production cycle, and configure a constraint relationship for the "discount_rate" field that it cannot exceed a certain upper limit.

[0065] Furthermore, based on the risk parameters output by the risk control module, the system assigns risk weight parameters to each field. For example, fields affecting financial and price risks, such as "prepay_ratio," "credit_days," and "unit_price," are assigned higher risk weights, while non-critical fields like "packaging requirements" are assigned lower risk weights. These field names, field type identifiers, associated constraint parameters, and risk weight parameters together constitute the contract structure description data, which is temporarily bound and stored with the contract instance identifier.

[0066] During the multiple rounds of negotiations between merchants and buyers regarding private transaction pricing, the contract modeling module generates a new contract version record after each modification. It assigns a unique version identifier to each private transaction pricing contract instance version under the same partnership, such as "VER-001", "VER-002", and "VER-003". For each version change, the contract modeling module performs a field-level comparison of the current version's contract structure description data with the previous version's, identifying modified, added, or deleted fields in product parameters, price parameters, payment terms, and delivery terms. These fields are then aggregated into a set of differing fields and written into the contract version record along with the corresponding version identifier.

[0067] In this way, the system can intuitively record the differences between different versions of contracts under the same cooperative relationship. For example, from "VER-001" to "VER-002", only the discount coefficient and prepayment ratio were adjusted, while from "VER-002" to "VER-003", the installment payment time point and the first shipment quantity were adjusted, which facilitates subsequent review and automatic verification.

[0068] When the negotiation process concludes and the buyer confirms a specific contract version on the front-end interface, the contract modeling module receives the confirmation instruction and selects the corresponding target contract version record based on the contract instance identifier and version identifier in the confirmation information. The system first determines the core constraint fields that should be locked based on the field type identifier and risk weight parameters. These include price-related fields such as "unit_price" and "discount_rate," payment-related fields such as "prepay_ratio" and "credit_days," and delivery-related fields such as "delivery_deadline" and "first_shipment_qty." The system then locks the current parameters of these core constraint fields, preventing arbitrary modification during subsequent performance.

[0069] After locking the core constraint fields, the contract modeling module generates a contract baseline identifier carrying a contract instance identifier and a version identifier, such as "BASE-CON-REL-SUP001-BUY1001-VER-003", indicating that the third version of the contract instance "CON-..." is used as the contract baseline under this cooperation relationship. Subsequently, the system binds and stores the contract structure description data in the target version contract version record with the contract baseline identifier, using it as contract baseline data for reference by the performance orchestration module and the cross-border settlement control module. This ensures that the subsequent generation of the node diagram and the selection of settlement strategies are based on the contract structure that is consistent with the buyer's final confirmation.

[0070] Through the processing flow of this embodiment, the system achieves field-level structured modeling, version management, and final baseline solidification of private transaction quotation contract instances. This transforms contract terms from simple text records into structured data objects with field types, constraints, and risk weights. On one hand, contract version records and sets of differing fields make the multi-round negotiation process transparent and traceable, reducing the workload of manual comparison of contract content. On the other hand, contract baseline data provides a unified and reliable source of parameters for subsequent stage node diagram construction, order state machine configuration, and batch settlement strategy generation, improving the consistency and controllability of batch performance and cross-border settlement processes in private cross-border transactions.

[0071] In some embodiments, a stage node diagram containing multiple payment nodes and performance nodes is obtained based on contract baseline data parsing. An order state machine is constructed by associating the stage node diagram with the order, including: Based on the payment and delivery terms extracted from the contract baseline data, a node set containing multiple payment nodes and performance nodes is generated, and each node is configured with a node type identifier, trigger condition parameters, and target stage parameters. Based on the order and dependency agreements recorded in the payment and delivery terms, directed connections are established for the nodes in the node set to form a stage node diagram that describes the order execution process, and stage diagram identifiers are assigned to the stage node diagram. Upon receiving an order generated based on contract baseline data, the order identifier is bound to the stage diagram identifier. The state set and state transition rules of the order state machine are determined according to the node type identifier and trigger condition parameters in the stage node diagram, and the order state machine is associated with the order.

[0072] Specifically, the performance orchestration module automatically parses a phase node diagram containing multiple payment nodes and performance nodes based on the aforementioned contract baseline data, and builds a corresponding order state machine for each order on this basis, so that the payment terms and delivery terms in the contract terms are mapped to the order execution process in a phased and executable form.

[0073] In this embodiment, "stage events" can be understood as key execution events abstracted from payment or delivery terms in the contract baseline data, such as "prepayment received", "production started", "first shipment", "interim payment received", "final payment received", "final delivery completed", etc.; "payment node" refers to the node corresponding to a certain stage of payment behavior; "performance node" refers to the node corresponding to performance behaviors such as production, shipment, customs clearance, and receipt confirmation.

[0074] The “Node Type Identifier” is used to distinguish whether a node is a payment node or a fulfillment node. It can also be further divided into sub-types such as prepayment node, interim payment node, final payment node, production node, and delivery node.

[0075] The "Trigger Condition Parameter" describes the conditions that must be met for a node to transition from pending execution to completed execution, such as a certain amount of money arriving, arrival at a certain time point, completion of a certain preceding node, or the logistics status reaching a specific value. The "Target Stage Parameter" identifies the macro-level stage that the order should move to after the node is completed, such as "Pending Production," "In Production," "Partial Shipment," "Pending Settlement," or "Completed."

[0076] The "Stage Node Graph" is a directed graph composed of the aforementioned nodes and their directed connections, used to describe the overall stage process of an order from contract confirmation to final settlement. The "Stage Graph Identifier" uniquely identifies a stage node graph generated under a specific contract baseline. The "Order State Machine" is a state transition model instantiated for a specific order, based on the stage node graph. It includes a set of states, a set of events, and state transition rules, used to drive changes in the order state with payment and fulfillment events.

[0077] In some examples, the contract modeling module has already solidified the negotiated and confirmed contract content into contract baseline data. This data includes payment terms such as prepayment percentages, prepayment due dates, interim payment trigger conditions, and final payment trigger conditions; and delivery terms such as production cycle, initial shipment date or trigger conditions, subsequent batch shipment rules, and final delivery deadline. The performance orchestration module first reads the payment and delivery terms from the contract baseline data and breaks them down into a series of phased events according to preset parsing rules.

[0078] For example, for a long-term cooperation framework contract for electronic products, the system can extract events such as "prepayment receipt event," "interim payment receipt event," and "final payment receipt event" from the payment terms, and "production start event," "first batch shipment event," "subsequent batch shipment event," and "final delivery completion event" from the delivery terms. For each stage event, the performance orchestration module generates a corresponding node entry, forming a node set; at the same time, it configures a node type identifier, trigger condition parameters, and target stage parameters for each node. For example, the "prepayment receipt node" is marked as a payment node, with the trigger condition parameter "received in the escrow account no less than the prepayment amount stipulated in the contract within the agreed period," and the target stage parameter "payment completed, production pending"; the "first batch shipment node" is marked as a performance node, with the trigger condition parameter "production progress reaches the first batch quantity and the prepayment node status is completed," and the target stage parameter "first batch shipment completed."

[0079] After generating the node set and the attributes of each node, the performance orchestration module further establishes directed connections between the nodes in the node set based on the sequence and dependency agreements in the contract baseline data. For example, if the contract stipulates that "production will start after the prepayment is received, the first batch of goods will be shipped after the first batch of goods is produced, the interim payment will be made within a specified time after the first batch of goods is shipped, and the final payment will be made by the buyer after the interim payment is received and all goods are shipped", then the system will automatically establish directed edges for "prepayment node → production start node → first batch of goods shipment node → interim payment node → subsequent shipment node → final payment node → final delivery confirmation node", thus forming a complete order execution phase flowchart.

[0080] For clauses involving parallel or interdependent relationships, such as "the interim payment can be made at any time after the first shipment, but the final payment can only be made after all shipments are completed," the system can configure multiple directed edges between nodes and add a check on the status of preceding nodes to the trigger condition parameters to ensure that the stage node graph accurately reflects the temporal and dependency relationships in the contract. After establishing complete directed connections, the performance orchestration module saves the directed graph as a stage node graph and assigns it a unique stage graph identifier, such as "FLOW-BASE-CON-REL-SUP001-BUY1001".

[0081] When the business side generates a specific order based on the contract baseline data, such as generating an order "ORD-20250101-0001" for a certain batch of actual purchase quantities, the fulfillment orchestration module receives the order generation event and binds the order identifier with the aforementioned stage diagram identifier, establishing a relationship between the order and the stage node diagram. Subsequently, the fulfillment orchestration module derives the order status set and state transition rules corresponding to the order based on the node type identifier and trigger condition parameters in the stage node diagram.

[0082] For example, the order status set is defined as "Confirmed pending prepayment", "Prepayment received pending production", "In production", "First batch shipment completed", "Partial shipment", "All shipments pending settlement", "Settlement in progress", "Completed", etc. The node completion event is mapped to a transition rule from one state to another, such as "Prepayment node completed → Status transitions from 'Confirmed pending prepayment' to 'Prepayment received pending production'", and "First batch shipment node completed → Status transitions from 'In production' to 'First batch shipment completed'". The fulfillment orchestration module encapsulates these status sets and transition rules into an order state machine model and associates the order state machine with the order identifier one-to-one. This allows the order state machine to automatically transition the order status according to the stage node diagram when receiving payment information, production progress information, and logistics status information.

[0083] Through the processing flow of this embodiment, the system automatically parses the payment and delivery terms in the contract baseline data into a stage node diagram containing multiple payment and performance nodes. Based on this, a corresponding order state machine is constructed for each order, realizing a structured mapping from contract terms to the execution process. On the one hand, the stage node diagram fully depicts the temporal and dependency relationships between batch payments and batch performance, providing a unified process basis for the subsequent generation of payment and performance instructions. On the other hand, the order state machine instantiates the stage node diagram to the specific order granularity, enabling the order status to automatically migrate according to preset rules with payment and performance events. This reduces manual intervention and hard-coding of rules, improving the controllability and execution efficiency of multi-stage performance and settlement processes in private cross-border transactions.

[0084] In some embodiments, a payment instruction corresponding to each payment node and a fulfillment instruction corresponding to each fulfillment node are generated according to the stage node diagram, and the order state machine is driven to perform state transitions according to the stage node diagram to form order state data, including: Based on the node type identifier, trigger condition parameters, and target stage parameters of each node in the stage node diagram, a payment instruction record carrying an order identifier, node identifier, and node sequence number is generated for each payment node, and a performance instruction record carrying an order identifier, node identifier, and node sequence number is generated for each performance node. The payment instruction record and the performance instruction record are then registered in the instruction queue. When receiving payment information or performance information, the target instruction record is located from the instruction queue according to the order identifier and node sequence number. The trigger condition parameters of the corresponding node of the target instruction record are used to determine whether the state transition conditions are met. If the conditions are met, the order state machine is invoked to perform the state transition from the current state to the state corresponding to the target stage parameter. Upon completion of the state transition, the states before and after the transition, node identifiers, and time identifiers are written into the order status data record to form a relationship with the stage nodes. Figure 1 One corresponding order status data.

[0085] Specifically, the "Payment Instruction Record" describes the payment action that the system should initiate or wait for for a certain payment node. It is a structured representation of the payment requirement at a certain stage in the contract and includes at least fields such as order identifier, node identifier, node sequence number, target payment amount, and target currency.

[0086] The "Fulfillment Instruction Record" describes the production, delivery, or other fulfillment actions that should be performed for a specific fulfillment node. It also includes order identifier, node identifier, node sequence number, and constraint fields related to fulfillment, such as quantity and time.

[0087] "Node identifier" is used to identify a specific node in the stage node diagram. For example, it can be encoded as "NODE-001" or "NODE-002".

[0088] The “node sequence number” is used to indicate the execution order or logical position of a node in the stage node diagram, which facilitates the sequential retrieval and comparison of the instruction queue.

[0089] The "instruction queue" can be understood as an ordered set of instructions maintained within the system. It is used to register all payment and fulfillment instructions that are to be executed or verified, and supports quick location of target instructions according to order identifier and node sequence number.

[0090] "Payment information" refers to payment result data returned by the payment gateway or settlement system, which includes at least fields such as order identifier, actual payment amount, and payment time; "fulfillment information" can be reported by the production system, warehousing system, or logistics system, reflecting the actual production completion status, outbound status, or arrival status.

[0091] "State transition conditions" refer to the criteria for determining whether a node is considered "complete," such as "the actual payment amount is not less than the target amount and is within the agreed period" or "the production quantity meets the requirements for the first batch of shipments."

[0092] "Order Status Data Record" is used to record the result of each state transition in the order state machine, including at least the state before the transition, the state after the transition, the node identifier that triggered the transition, and the time identifier.

[0093] In some examples, assuming the contract baseline data generated for the partnership "REL-SUP001-BUY1001" already includes a phase node diagram constructed by the performance orchestration module, the node set includes the prepayment node N1, production start node N2, first shipment node N3, interim payment node N4, all shipments completed node N5, final payment node N6, and final delivery confirmation node N7. After constructing the order state machine, the performance orchestration module traverses each node in the phase node diagram, generating corresponding instruction records for each node based on the node type identifier, trigger condition parameters, and target phase parameters.

[0094] For payment nodes, such as prepayment node N1 and mid-term payment node N4, the system generates a payment instruction record. This record includes the order identifier "ORD-20250101-0001", node identifier "N1" or "N4", node sequence number "1" or "4", and extended fields containing information such as the target payment amount, target currency, and the latest allowed arrival time. For fulfillment nodes, such as production start node N2, first batch shipment node N3, all shipments completed node N5, and final delivery confirmation node N7, the system generates a fulfillment instruction record. This record includes the order identifier, node identifier, node sequence number, required production quantity, first batch shipment quantity, all shipment completion conditions, and receipt confirmation conditions. Both the generated payment instruction record and fulfillment instruction record are written to an instruction queue. This queue can be sorted and indexed by order identifier and node sequence number to ensure quick matching of corresponding instructions during subsequent processing.

[0095] During order execution, when a buyer pays a prepayment through a cross-border payment channel, the payment gateway sends a payment information message back to this system. This message includes the order identifier "ORD-20250101-0001", the transaction type "prepayment", the actual payment amount, and the payment time. Upon receiving this payment information, the fulfillment orchestration module first retrieves the associated payment instruction record in the instruction queue based on the order identifier. Then, it determines the corresponding node sequence number "1" by combining the transaction type or internal mapping table, thereby locating the payment instruction record for the prepayment node N1.

[0096] Subsequently, the module reads the pre-configured trigger condition parameters from the payment instruction record, such as "the actual payment amount is not less than the prepayment amount stipulated in the contract and the payment time is not later than the agreed deadline," and substitutes the actual payment amount and payment time from the payment information into the judgment. If the judgment is satisfied with the state transition conditions, the order state machine corresponding to the order is invoked to perform the state transition operation, so that the order status changes from "confirmed and awaiting prepayment" to "prepayment received and awaiting production," and the prepayment node N1 is marked as completed; if the judgment is not satisfied with the conditions, the payment information can be recorded as an abnormal event or a partial performance record, and the order status transition is not triggered.

[0097] Similarly, when the production system reports that the production progress has reached the initial production quantity, or when the warehousing system reports that the first batch of goods has been shipped, the fulfillment orchestration module receives a fulfillment message. This message also carries an order identifier and an event type that can be used to determine the node sequence number, such as "first batch shipment". The module retrieves the fulfillment instruction record related to the order in the instruction queue based on the order identifier, and matches it to the first batch shipment node N3 with node sequence number "3" through the event type or preset mapping.

[0098] Subsequently, the system compares the actual production quantity, outbound record and waybill number in the fulfillment information according to the trigger condition parameters configured in the fulfillment instruction record, such as "the quantity of production completed is not less than the first batch quantity and the corresponding logistics waybill has been generated". When the conditions are met, the system calls the order state machine to change the order status from "in production" to "first batch shipment completed" and marks node N3 as completed.

[0099] For the mid-term payment node, the full shipment completion node, the final payment node, and the final delivery confirmation node, the system adopts a similar mechanism, driving the completion of the corresponding node through payment information or performance information, and updating the order status according to the target stage parameters in the stage node diagram.

[0100] Furthermore, after each state transition is completed, the fulfillment orchestration module generates an order status data record, writing the pre-migration status, post-migration status, the node identifier that triggered the transition, and the transition time into the order status data storage.

[0101] For example, when the prepayment node N1 is completed, the system generates a status data record containing "from_state=Confirmed, awaiting prepayment", "to_state=Prepayment received, awaiting production", "node_id=N1", and "timestamp=2025-01-05 10:30:00". When the first batch shipment node N3 is completed, another record is generated, containing "from_state=In production", "to_state=First batch shipment completed", "node_id=N3", and "timestamp=2025-01-10 15:20:00". As orders are executed, the order status data records accumulate according to the node sequence, forming a record corresponding to the stage nodes. Figure 1 A corresponding state transition trajectory provides complete historical data for the subsequent cross-border settlement control module to determine the settlement batch trigger conditions and for the risk control module to review the performance status.

[0102] Through the processing flow of this embodiment, the system generates structured payment instruction records and performance instruction records for each payment node and performance node based on the stage node graph. It then uses an instruction queue to match external payment and performance information with internal nodes one by one, and executes controlled state transitions through an order state machine, ultimately forming traceable order status data. On the one hand, this achieves decoupling and standardized mapping between external events and contract stage nodes, enabling complex phased payment and performance processes to be controlled through a unified instruction and state machine framework. On the other hand, by recording each state transition, a clear order execution trajectory is constructed, providing a reliable data foundation for settlement control, risk control analysis, and post-event auditing, thereby improving the controllability and visibility of the private cross-border transaction performance process.

[0103] In some embodiments, settlement paths and exchange strategies are determined based on contract baseline data, order status data, and risk parameters, and batch settlement control is implemented for order funds paid by the buyer to the escrow account, including: Based on payment terms, completed payment nodes, performance nodes, and risk parameters, corresponding settlement path identifiers and foreign exchange strategy parameters are configured for different stage combinations and risk levels to generate a settlement strategy matrix that describes the triggering conditions and settlement ratios of each settlement batch. Order funds paid by buyers to the escrow account are split into multiple fund batch records according to the settlement strategy matrix, and each fund batch record is associated with the corresponding order identifier, target settlement path identifier, target currency and settlement ratio parameters; When the order status data is detected to meet the trigger conditions corresponding to the current fund batch record and the current risk parameters are within the preset threshold range, the foreign exchange and fund transfer instructions are initiated according to the settlement path identifier and foreign exchange strategy parameters recorded in the current fund batch record. The corresponding funds are transferred from the escrow account to the merchant settlement account, and the remaining amount to be settled and the settlement record of the order are updated simultaneously.

[0104] Specifically, the "settlement path identifier" is used to identify different settlement channels available on the platform, such as the self-operated settlement path, the settlement path of partner bank A, the settlement path of partner bank B, etc. Different paths have differences in terms of handling fees, arrival time, compliance requirements, etc.

[0105] "Exchange strategy parameters" are used to indicate the exchange method used under a specific settlement path, such as real-time exchange rate trading, timed exchange rate matching, and weighted floating exchange rate within a range. Different exchange strategies have different sensitivities to exchange rate fluctuations.

[0106] The "settlement strategy matrix" describes the settlement path and exchange strategy adopted under different stage combinations and risk levels, as well as the corresponding settlement ratio. It can be understood as a strategy configuration table based on stage status and risk level.

[0107] "Funds Batch Records" are used to identify multiple fund batches after the order funds in the escrow account are split according to the settlement strategy. Each batch is associated with a corresponding order identifier, settlement path identifier, target currency, and settlement ratio parameter.

[0108] "Escrow account" refers to an intermediary account opened by the platform or a designated financial institution to temporarily accept payments from buyers and transfer funds to merchants after settlement conditions are met.

[0109] A “merchant settlement account” is a receiving account opened by a merchant at a domestic or overseas financial institution, used to receive payments for goods after currency exchange and settlement.

[0110] The “order status data” is generated by the aforementioned order state machine and reflects the completed payment and fulfillment nodes of each order as well as its current status.

[0111] The "risk parameters" are calculated by the risk control module based on cooperation relationship records, contract baseline data, and payment and performance information during order execution, marking the current order's risk level and available settlement control range.

[0112] In some examples, suppose an order "ORD-20250101-0001" is placed under the partnership "REL-SUP001-BUY1001". The contract baseline data stipulates a 30% prepayment, 50% interim payment, and 20% final payment, with goods shipped in two batches: the first batch (60%) and the second batch (40%). The cross-border settlement control module first reads the payment and delivery terms from the contract baseline data and, combined with the available stage node information from the order status data, identifies several key stage combinations, such as "prepayment completed only," "prepayment completed and first batch shipment completed," "prepayment and interim payment completed and all shipments completed," and "final payment completed and buyer confirms receipt." Simultaneously, the module reads the risk parameters output by the risk control module to determine the risk level of the current partnership and order, classifying it as low risk (L1), medium risk (L2), or high risk (L3).

[0113] Based on this, the cross-border settlement control module configures corresponding settlement path identifiers and exchange rate strategy parameters for different stage combinations and risk levels according to preset strategy rules, generating a settlement strategy matrix. For example, when the stage combination is "prepayment completed and first batch of shipment completed" and the risk level is L1, the system can configure the settlement path identifier as "PATH_SELF", indicating that settlement is prioritized through the platform's self-operated settlement channel, and configure the exchange rate strategy as "real-time exchange rate + small price difference"; when the stage combination is "prepayment completed and first batch of shipment completed" and the risk level is L2, the settlement path identifier is configured as "PATH_BANK_A", and the "timed exchange rate matching + price limit range" strategy is adopted; when the stage combination is "all shipments completed and final payment completed" and the risk level is L1, the settlement ratio can be configured as 100%, the settlement path identifier is "PATH_SELF", and the exchange rate strategy parameter is "real-time exchange rate or exchange rate optimization algorithm"; for the high-risk L3 combination, the settlement path identifier can be configured as "PATH_BANK_B", adopting a more prudent exchange rate strategy and reducing the proportion of batch settlements. With this configuration, each row in the settlement strategy matrix corresponds to a "stage combination + risk level" scenario, clearly recording its respective "settlement batch trigger conditions", "settlement ratio", "settlement path identifier" and "foreign exchange strategy parameters".

[0114] When a buyer pays the prepayment, interim payment, and final payment to the platform's escrow account as stipulated in the contract, the payment gateway pushes each payment receipt information to the cross-border settlement control module. The module aggregates each payment receipt, accumulating all actual amounts received for order "ORD-20250101-0001" into the total escrow funds. Based on the settlement strategy matrix, the escrow funds are then split into multiple batch records.

[0115] For example, at risk level L1, the module can generate three batch records of funds based on the strategy matrix: the first batch corresponds to the stage of "prepayment completed and first batch shipment completed", with a settlement ratio of 40%, the target currency being "EUR" as agreed in the contract, and the settlement path identifier being "PATH_SELF"; the second batch corresponds to the stage of "interim payment completed and all shipments completed", with a settlement ratio of 40%; and the third batch corresponds to the stage of "final payment completed and receipt confirmed", with a settlement ratio of 20%. The cross-border settlement control module associates the order identifier "ORD-20250101-0001", the target settlement path identifier, the target currency "EUR", and the settlement ratio parameter with each batch of funds, and records the calculation method of the settlementable amount in the batch of funds record, such as multiplying the total amount of orders actually received in the escrow account by the corresponding ratio to obtain the target settlement amount.

[0116] During order execution, the fulfillment orchestration module continuously updates order status data, recording the completion status of each payment and fulfillment node. The cross-border settlement control module subscribes to order status data change events or periodically queries order status data to determine if the trigger conditions for any phase combination corresponding to a funding batch record have been met. For example, when the order status data indicates that the prepayment node has been completed and the first shipment node N3 has been completed, the module checks whether the trigger conditions corresponding to the first funding batch record match the current status and simultaneously reads risk parameters to determine whether the current risk level is still L1 or within the preset allowable range.

[0117] If both conditions are met, the cross-border settlement control module initiates a currency exchange and fund transfer instruction to the settlement system or external bank interface based on the settlement path identifier and exchange strategy parameters in the fund batch record. The instruction includes escrow account information, merchant settlement account information, target currency "EUR", the settlement amount, and the required exchange strategy. Once the settlement system returns a successful exchange and transfer result, the cross-border settlement control module deducts the settlement amount from the order's escrow funds, updates the remaining amount pending settlement for the order, and adds a new record to the settlement record, including the order identifier, fund batch number, settlement amount, settlement path identifier, actual exchange rate, and settlement time.

[0118] For the second and third batches of payment records, the cross-border settlement control module monitors and triggers them in a similar manner. When order status data indicates that the mid-term payment node and all shipment nodes have been completed, and the risk parameters are within the allowable range set by the operational strategy, the module triggers the second batch of settlement; when the final payment node and goods receipt confirmation node are completed, the module triggers the third batch of settlement. If risk parameters change during execution, such as due to payment delays or disputes with buyers, the risk control module adjusts the risk level to L2 or L3. In the next assessment, the settlement control module will select a more conservative settlement path and a smaller settlement ratio in the settlement strategy matrix based on the updated risk level, or even suspend some batches of settlement, until the risk returns to a safe range.

[0119] Through the processing flow of this embodiment, the cross-border settlement control module, under the joint constraints of contract baseline data, order status data, and risk parameters, splits the order funds paid by the buyer to the escrow account into multiple controlled fund batches. It then uses a settlement strategy matrix to configure a settlement path and currency exchange strategy for each batch. Based on the order stage combination and risk level, it triggers the corresponding batch's currency exchange and transfer operations, thereby achieving dynamic linkage between the cross-border settlement process and the progress and risk status of batch fulfillment. On the one hand, batch settlement control ensures that the release of funds is consistent with fulfillment nodes such as goods shipment and receipt confirmation, reducing the risk associated with single full-amount settlement. On the other hand, by automatically switching settlement paths and currency exchange strategies under different risk levels, it reduces manual intervention and temporary adjustments, improving the security and execution efficiency of multi-transaction, multi-stage fund settlements in private cross-border transactions.

[0120] In some embodiments, risk assessments and compliance checks are performed on buyers and orders to generate risk parameters, including: Risk assessment factors are extracted based on cooperation relationship records, contract baseline data, and payment and performance information generated during order execution, and corresponding risk feature vectors are constructed. The risk feature vector is input into a preset risk assessment model and matched with the rules of the target country / region and the product compliance rules in the compliance rule base to obtain the risk score, risk level and compliance mark of the buyer and the order; Based on risk scores, risk levels, and compliance indicators, risk parameters are generated according to a preset mapping relationship. These risk parameters include node control parameters used to limit the time interval and amount ratio of payment nodes, and settlement control parameters used to limit the range of settlement path selection and foreign exchange strategy selection.

[0121] Specifically, "risk assessment factors" are used to characterize the objective features of cooperative relationships and orders in terms of fund security, performance stability, and compliance. These include, but are not limited to, multiple indicators across the dimensions of cooperative relationship, order, and product. Examples include the validity period of the cooperative relationship, the cumulative amount of historical orders, the number of historical overdue payments, historical records of refused delivery or returns, historical records of disputes or refusal to pay, the proportion of the current order amount to the cooperative credit line, the length of the current order payment period, the deviation in the current order performance, and the identification of sensitive categories of the products involved.

[0122] The "risk feature vector" is a multi-dimensional feature array constructed based on the aforementioned risk assessment factors, used as input to the risk assessment model. The "risk assessment model" can be a pre-trained statistical model or a machine learning model, or a hybrid model combining rules and scorecards, used to output risk scores and risk levels for buyers and orders.

[0123] The "Compliance Rule Base" records the regulatory rules of the target countries and regions and the compliance requirements for different product categories, such as settlement restrictions for certain high-risk countries / regions, access conditions for certain sensitive products, and single transaction amount limits. The "Target Country / Region Rules" and "Product Compliance Rules" are subsets of the compliance rule base for countries / regions and product categories, respectively.

[0124] "Risk score" is used to numerically reflect the level of risk, "risk level" can be divided into different levels such as L1, L2, L3 according to preset ranges, and "compliance mark" is used to mark whether the current transaction meets the compliance requirements of the relevant country / region and the product.

[0125] "Node control parameters" include the minimum / maximum time interval allowed for payment nodes and the maximum allowable payment ratio for each node, while "settlement control parameters" include the set of optional settlement paths, the types of foreign exchange strategies allowed, and the maximum settlement ratio for a single batch. Together, they constitute the specific content of the risk parameters.

[0126] In some examples, the risk control module first extracts risk assessment factors based on cooperation relationship records, contract baseline data, and payment and performance information generated during order execution. For example, for the cooperation relationship "REL-SUP001-BUY1001" and its order "ORD-20250101-0001", the system extracts factors such as cooperation start time, historical cooperation duration, historical order cumulative amount, historical overdue payment count, and historical dispute records from the cooperation relationship records; it extracts factors such as the total contract amount, prepayment ratio, payment period length, and number of batches of goods from the contract baseline data; and it extracts factors such as whether the prepayment for this order arrived on time, whether there was a delay in the interim payment, whether the production progress was completed as planned, whether there was a delay in the first batch of shipments, and whether there were any abnormalities in the logistics trajectory from the payment and performance information received during order execution.

[0127] The above factors are standardized and combined into a risk feature vector, which includes a series of dimensions such as "historical_total_amount", "overdue_count", "chargeback_count", "current_order_ratio", "credit_days", "delay_days_production", "delay_days_delivery", "sensitive_category_flag", and "destination_country_risk_level".

[0128] Secondly, the risk control module inputs the constructed risk feature vector into a preset risk assessment model for calculation. The risk assessment model can use a trained scoring model to output a risk score from 0 to 100 based on the weight of each risk assessment factor. For example, when there are few historical overdue records, zero dispute records, the current order amount is a moderate proportion of the historical amount, the payment period is within a reasonable range, and the current prepayment and the first batch of shipments are completed on schedule, the risk score output by the model may be "25", corresponding to a risk level of L1; if there are multiple historical overdue records, the current order amount is too high, and there are significant delays in production and shipment, the risk score may be "70", corresponding to a risk level of L3.

[0129] While obtaining risk scores and risk levels, the risk control module also matches risk feature vectors with the compliance rule base. On the one hand, it checks whether the destination country is in a high-risk area and whether there are restrictive requirements based on the rules of the target country / region. On the other hand, it checks whether the products involved belong to restricted or sensitive categories and whether they exceed the regulatory thresholds for single transaction amount or single batch quantity based on the product compliance rules. If the matching results show that the destination country is on the list of tradable countries and the products do not belong to prohibited or additionally permitted categories, the system generates a compliance identifier "COMPLIANT" for the order; if compliance risks are found in the destination country or product category, an identifier such as "LIMITED" or "NON_COMPLIANT" can be generated.

[0130] After obtaining the risk score, risk level, and compliance identifier, the risk control module generates the final risk parameters based on a preset mapping relationship. For example, the system can define a set of mapping rules: when the risk level is L1 and the compliance identifier is "COMPLIANT", the node control parameters allow prepayments, interim payments, and final payments to be executed according to the proportions and time intervals agreed in the contract, with constraints only imposed on extreme cases; when the risk level is L2, the node control parameters raise the lower limit of the prepayment ratio and lower the upper limit of the final payment ratio, while shortening the maximum allowed payment period and prohibiting the addition of temporary installments beyond the contract baseline; when the risk level is L3 or the compliance identifier is "LIMITED", the node control parameters will limit the maximum amount ratio of each payment node, increase the minimum time interval between nodes, or require certain nodes to be triggered only after the previous performance node is fully completed.

[0131] Regarding settlement control parameters, at L1 level, the system allows the use of multiple settlement paths such as "PATH_SELF" and "PATH_BANK_A," and permits the use of real-time exchange rates or exchange rate optimization strategies. At L2 level, it restricts the use to only "PATH_BANK_A," which has higher compliance requirements, and adopts a more conservative timed matching exchange rate strategy. At L3 level or when there are restrictions on compliance indicators, it requires the use of strictly regulated paths such as "PATH_BANK_B," and lowers the settlement ratio for each batch to a lower level. If necessary, it suspends settlement for some batches until the risk is mitigated. The above node control parameters and settlement control parameters are output in a structured form and provided as risk parameters to the performance orchestration module and the cross-border settlement control module. This allows for dynamic adjustment of node parameters and settlement path selection space during the execution of the stage node diagram and the generation of the settlement strategy matrix.

[0132] Through the processing flow of this embodiment, the risk control module abstracts the large amount of discrete data generated during the cooperation relationship, contract baseline, and order execution into risk assessment factors. It then calculates risk scores, risk levels, and compliance indicators using a risk assessment model and compliance rule base, further mapping these to risk parameters that can directly drive node control and settlement control. On one hand, this achieves parameterized constraints on payment node time intervals and amount ratios based on risk assessment results, allowing the phased payment rhythm to be adjusted according to risk conditions. On the other hand, it embeds national and regional rules and commodity compliance rules into the selection range of settlement paths and foreign exchange strategies, enabling cross-border settlement paths and foreign exchange strategies to automatically narrow or widen according to risk levels, reducing manual approval and temporary intervention, thereby improving the risk controllability and compliance of private cross-border transactions during performance and settlement.

[0133] In some embodiments, the system further includes: The data encryption module is used to perform field-level encryption storage of preset sensitive fields, provide read / write and decryption access support for encrypted data to various modules, and generate structured order status data and structured settlement result data for private cross-border transaction performance and settlement processing.

[0134] Specifically, "sensitive fields" can be understood as a type of data field that needs to be protected during storage and transmission, such as unit price, discount coefficient, cost estimate, merchant settlement account information, buyer identification number, risk control score, settlement amount, etc.

[0135] "Field-level encrypted storage" refers to encrypting certain specified fields in a data record individually, rather than encrypting the entire record or table as a whole, so that the system can retrieve and perform statistics on non-sensitive fields without decrypting sensitive fields.

[0136] The "key identifier" is used to identify the key or key group used in this encryption, making it easier to select the correct key during decryption.

[0137] The "Encryption Policy Configuration Table" is used to record which fields need to be encrypted under different data types and different business scenarios, what algorithms are used, and how to group and manage keys.

[0138] "Encryption domains" can be used to limit the scope of a certain group of encryption operations, such as dividing encryption domains according to partnerships, merchants, or business systems.

[0139] "Structured order status data" refers to the collection of order status change records output by the order status machine and processed by the encryption module.

[0140] "Structured settlement result data" refers to a collection of batch settlement result records generated by the cross-border settlement control module and processed and stored by the encryption module.

[0141] In some examples, during the deployment phase, the security administrator or platform provider pre-configures an encryption policy configuration table to specify which fields in quotation data, order data, order status data, and settlement result data are considered sensitive. For example, for confidential quotation records, "unit_price", "discount_rate", and "cost_estimate" are marked as sensitive fields; for order records, "buyer_account_no", "seller_settlement_account", and "tax_id" are marked as sensitive fields; for order status data, "internal_risk_score", which may reveal internal risk assessments, is marked as a sensitive field; and for settlement result data, fields such as "settlement_amount" and "actual_fx_rate" are marked as sensitive fields. The encryption policy configuration table can also specify the encryption algorithm type, key length, key update cycle, and corresponding key identifier generation rules for each type of sensitive field.

[0142] On the data write path, when the contract modeling module, performance orchestration module, or cross-border settlement control module generates new quotation records, order records, order status data records, or settlement result records, these data are not directly written to persistent storage. Instead, the data to be written is submitted to the data encryption module through an internal API call. The data encryption module first identifies the data set to be written based on the data type and table name, and then consults the encryption strategy configuration table to determine which fields are sensitive fields that need to be encrypted.

[0143] For each record, the data encryption module generates one or more key identifiers, such as "KEY-REL-SUP001-BUY1001-01" based on the partnership identifier, merchant identifier, or encryption field. It then calls the underlying encryption / decryption component to encrypt the values ​​of sensitive fields, writing the encrypted ciphertext and key identifiers into the corresponding field locations. The original plaintext is discarded before being written. For non-sensitive fields, such as product name, product code, currency, node identifier, and time identifier, the data encryption module stores them as is. Finally, the encrypted record is written to a structured data table. When viewed from outside the system or at the database level, sensitive fields appear as unreadable ciphertext and are isolated from key identifiers bound to different partnerships or business scopes.

[0144] Furthermore, along the data reading path, when the privacy access control module, contract modeling module, performance orchestration module, or cross-border settlement control module needs to read historical quotations, orders, order status, or settlement result data, they also submit a read request to the data encryption module through an internal interface. The read request typically includes information such as the calling module identifier, the subject identifier, the target data type, the cooperation relationship identifier, and the query conditions. The data encryption module first retrieves matching data records from storage based on the query conditions, and then, combining the calling module identifier and the subject identifier, calls the privacy access control module to determine whether the read operation has the necessary permissions to access the corresponding cooperation relationship and fields.

[0145] When permissions permit, the data encryption module parses the key identifier carried in the record for sensitive fields to be output, obtains the corresponding key from the key management component, and performs decryption operations on the ciphertext fields, filling the returned result with the decrypted plaintext data. For sensitive fields that the current caller does not have permission to access, the data encryption module either keeps the ciphertext intact or returns null values, masks, or aggregated statistical values ​​according to a preset strategy to avoid leakage of sensitive information. In some embodiments, even for some fields in order status data and settlement result data, such as "internal_risk_score", "settlement_amount", and "actual_fx_rate", differential decryption can be performed according to the caller's role. For example, only risk control personnel and the financial settlement module can read the entire plaintext, while the business operations module can only see some anonymized information.

[0146] During the generation of order status data and settlement result data, each time the fulfillment orchestration module drives the order state machine to complete a state transition, it generates a status change record containing the state before the transition, the state after the transition, the node identifier, and the time identifier. It can also attach some internal assessment data, such as risk level snapshots or anomaly markers. After completing a batch of fund settlement operations, the cross-border settlement control module generates a settlement result record containing fields such as order identifier, fund batch number, settlement amount, target currency, actual exchange rate, settlement path identifier, and settlement time.

[0147] The aforementioned status change records and settlement result records also need to be processed by the data encryption module before being written. For example, non-sensitive fields such as order identifier, node identifier, and time identifier are stored in plaintext, while fields such as settlement amount, actual exchange rate, and internal risk score are encrypted as sensitive fields. After the data encryption module completes encryption and writing, it forms structured order status data and structured settlement result data for subsequent statistical analysis, risk control tracing, and reconciliation verification. This data can be read and decrypted by different modules according to their permissions.

[0148] Through the processing flow of this embodiment, the data encryption module uniformly manages the field-level encryption and key usage of sensitive fields within the system, integrating the security protection of multiple types of data, such as quotations, orders, order status, and settlement results, under the same encryption framework. On the one hand, sensitive fields are stored in encrypted form, making it difficult to directly obtain key business information even if the storage medium is illegally accessed, significantly improving data security in private cross-border transaction scenarios. On the other hand, the data encryption module, through fine-grained control of decryption access, works in conjunction with the private access control module to achieve granular authorization based on cooperation relationships and roles, while preserving the usability of structured order status data and structured settlement result data in the statistical, analytical, and settlement processes. This achieves a balance between privacy protection and business usability, improving the security and controllability of private cross-border transaction performance and settlement processing.

[0149] The above embodiments have described in detail the specific modules and functions of the private cross-border transaction performance and settlement system of this application. The implementation process of the private cross-border transaction performance and settlement method of this application will be described in detail below with reference to specific embodiments. Figure 2 This is a flowchart illustrating the private cross-border transaction performance and settlement method provided in this application embodiment, as follows: Figure 2 As shown, the method may specifically include the following steps: S201: Receive cooperation invitation information from merchants and buyers, establish cooperation relationship records, generate cooperation relationship identifiers and access control policies for each cooperation relationship, and perform controlled access to private quotation data and order data associated with the cooperation relationship identifier based on the access control policies. S202, Based on the cooperative relationship identifier, generate a private transaction quotation contract instance associated with the target buyer according to the preset quotation template, perform structured modeling on the private transaction quotation contract instance, and solidify the target version of the private transaction quotation contract instance into the contract baseline data after negotiation and confirmation. S203: Based on the contract baseline data parsing, a stage node diagram containing multiple payment nodes and performance nodes is obtained. The stage node diagram is then associated with the order to construct an order state machine. S204, Generate payment instructions for each payment node and fulfillment instructions for each fulfillment node according to the stage node diagram. When receiving payment information and fulfillment information, drive the order state machine to perform state transitions according to the stage node diagram to form order state data. S205, based on cooperation relationship records, contract baseline data, and payment and performance information generated during order execution, conducts risk assessment and compliance verification of buyers and orders, and generates risk parameters for adjusting stage node diagram node parameters and settlement control parameters; S206 determines the settlement path and exchange strategy based on contract baseline data, order status data, and risk parameters, and performs batch settlement control on order funds paid by the buyer to the escrow account. When the preset settlement conditions are met and the risk parameters are within the preset range, the corresponding batch of funds is transferred from the escrow account to the merchant's settlement account according to the settlement path and exchange strategy, and a settlement record is generated.

[0150] Specifically, in step S201, the system first receives cooperation invitation information submitted by merchants and buyers through the front-end page or open interface. The cooperation invitation information includes at least a merchant identifier, a buyer identifier, and cooperation level parameters calculated by business rules or configured by operations personnel. The privacy access control module in the system parses the cooperation invitation information, generates a unique cooperation relationship identifier based on the merchant identifier and buyer identifier, for example, a combination code resulting in "REL-SUP001-BUY1001", and simultaneously establishes a cooperation relationship record, writing basic information such as the cooperation relationship identifier, cooperation level parameters, and target settlement currency into the cooperation relationship record table. Based on this, the privacy access control module combines the cooperation level parameters, product category parameters, and initial risk parameters to select a target access control template from the preset policy template library, injects the cooperation relationship identifier into the template, and generates the corresponding access control policy.

[0151] Subsequently, when the contract modeling module generates confidential quotation data and the order management module generates order data, the system will write the cooperation relationship identifier as an index field into the corresponding record and call the data encryption module to perform field-level encryption storage of sensitive fields such as unit price, discount, and settlement account. When the confidential access control module receives access requests for quotation data or order data, it will parse the visitor's identity and the scope of accessible cooperation relationships based on the subject identifier in the access request, match the corresponding access control policy, and only call the data encryption module to decrypt and output the encrypted fields if the permissions are permitted, thus achieving controlled access to the confidential quotation data and order data associated with the cooperation relationship identifier.

[0152] Further, in step S202, the contract modeling module generates a private transaction quotation contract instance associated with the target buyer based on the aforementioned cooperation relationship identifier. For example, the module obtains the target buyer identifier, cooperation level parameter, and target settlement currency parameter from the cooperation relationship record based on the cooperation relationship identifier, and determines the quotation template group corresponding to the cooperation level parameter. In an actual business transaction, a merchant intends to sign a long-term supply agreement for electronic products with a key cooperative buyer "BUY1001". The system will select a target preset quotation template from the "key cooperation" template group based on the product category parameter "electronic products" and the transaction mode parameter "long-term framework agreement", write the target buyer identifier "BUY1001" and the cooperation relationship identifier "REL-SUP001-BUY1001" into the template header, and generate a template instance identifier.

[0153] Subsequently, the contract modeling module, based on the field set defined in the preset quotation template, combined with historical order data, merchant-configured pricing rules, and risk parameters output by the current risk control module, automatically calculates the parameters for each product, price, payment terms, and delivery terms in this quotation. For example, it determines discount coefficients, prepayment ratios, payment terms, and the number of shipment batches based on historical purchase volume and risk level, forming a structured parameter set. The system binds this structured parameter set to a template instance identifier, generating a private transaction quotation contract instance. During multiple rounds of online negotiation, the contract modeling module generates different contract version records for each modification, recording the differences between the versions.

[0154] Once a buyer confirms a version on the front end, the contract modeling module selects that target version and splits and maps the product parameters, price parameters, payment terms, and delivery terms into a set of contract fields. It then configures a field type identifier, association constraint parameters, and risk weight parameters for each field to form contract structure description data. The module locks the price, payment period, and delivery node parameters marked as core constraint fields. Finally, it generates a contract baseline identifier that carries a contract instance identifier and a version identifier. The contract structure description data and the contract baseline identifier are then bound and stored as contract baseline data.

[0155] Further, in step S203, the performance orchestration module uses the contract baseline data to perform phased parsing of the contract terms, constructing a phased node diagram and an order state machine. Specifically, the module reads the payment and delivery terms from the contract baseline data, extracts a series of phased events, such as "prepayment received," "production started," "first shipment," "interim payment received," "all shipments completed," "final payment received," and "final receipt confirmation," and maps these phased events to payment nodes and performance nodes respectively, forming a node set. Each node is configured with a node type identifier, trigger condition parameters, and target phase parameters. For example, the trigger condition parameter for the prepayment node is "the escrow account receives no less than the prepayment amount within the agreed period," and the target phase parameter is "prepayment received and production is pending."

[0156] The performance orchestration module establishes directed connections between node sets based on the sequence and dependency agreements recorded in the contract, forming a complete phase node graph and assigning phase graph identifiers to it. When the business side generates a specific order based on the contract baseline, such as an order with the identifier "ORD-20250101-0001", the performance orchestration module binds the order identifier to the phase graph identifier. Based on the type and triggering conditions of each node in the phase node graph, it derives the order state set and corresponding state transition rules, encapsulates these states and rules into an order state machine, and associates the order state machine with the order, thus providing a state control foundation for the subsequent execution process.

[0157] Further, in step S204, the fulfillment orchestration module generates payment instructions for each payment node and fulfillment instructions for each fulfillment node based on the stage node diagram. The instruction queue drives the order state machine to transition states according to the stage node diagram, forming order status data. Specifically, the module traverses all nodes in the stage node diagram. For each payment node, such as prepayment, mid-term payment, and final payment, it generates a payment instruction record containing an order identifier, node identifier, and node sequence number, and records information such as the target payment amount, target currency, and latest arrival time. For each fulfillment node, such as the first batch shipment node, subsequent batch shipment nodes, and final delivery confirmation node, it generates a fulfillment instruction record carrying an order identifier, node identifier, and node sequence number, and configures parameters such as the required production quantity, shipment quantity, and allowable delay range. These payment instruction records and fulfillment instruction records are uniformly registered in the instruction queue.

[0158] When the system receives payment information from the payment gateway or fulfillment information from the production, warehousing, or logistics systems, the fulfillment orchestration module locates the corresponding target instruction record from the instruction queue based on the order identifier and mappable node sequence information in the payment or fulfillment information. It then determines whether the state transition conditions are met based on the trigger condition parameters of the associated nodes in the instruction record. If the conditions are met, the order state machine is invoked to perform a transition operation from the current state to the state corresponding to the target stage parameter, such as transitioning from "Confirmed pending prepayment" to "Prepayment received pending production," or from "In production" to "First batch shipment completed." After each state transition, the fulfillment orchestration module writes the pre-transition state, post-transition state, the node identifier that triggered the transition, and the time identifier into the order status data record, ensuring a one-to-one correspondence between the order status data and each node in the stage node diagram.

[0159] Furthermore, in step S205, the risk control module performs dynamic risk assessment and compliance verification on the buyer and the order throughout the entire order execution process, generating risk parameters for adjusting the node parameters of the stage node diagram and settlement control parameters. The module first extracts risk assessment factors based on cooperation relationship records, contract baseline data, and payment and performance information generated during order execution, and constructs a risk feature vector.

[0160] For example, the system extracts historical order cumulative amounts, historical overdue counts, and historical dispute records from cooperation relationship records; it extracts current contract amounts, payment terms, number of batches, and prepayment ratios from contract baseline data; and it extracts whether prepayments and interim payments arrived on time, whether shipments were delayed, and whether there were any abnormal returns or rejections from payment and performance information. The risk control module inputs the above risk feature vectors into a preset risk assessment model to calculate a risk score and risk level. Simultaneously, it queries the compliance rule base for national and regional rules and product compliance rules corresponding to the destination country and product category to determine whether the order meets regulatory requirements and generates a compliance identifier.

[0161] Subsequently, the module generates risk parameters based on risk scores, risk levels, and compliance indicators according to a preset mapping relationship. These parameters include node control parameters that limit the time interval between payment nodes and the amount ratio of a single node, as well as settlement control parameters that limit the range of settlement path selection and the types of available currency exchange strategies. The performance orchestration module can adjust the triggering conditions of some nodes in the stage node diagram accordingly, such as increasing the prepayment ratio of high-risk orders or shortening the payment period; the cross-border settlement control module, in turn, restricts the optional settlement paths and lowers the single settlement ratio.

[0162] Furthermore, in step S206, the cross-border settlement control module determines the settlement path and exchange strategy based on contract baseline data, order status data, and risk parameters, and performs batch settlement control on order funds paid by the buyer to the escrow account. When the buyer pays the prepayment, interim payment, and final payment to the platform's escrow account in installments according to the contract terms, the module collects the actual funds received by order dimension, and combines the payment terms in the contract baseline, the completed payment nodes and performance node information in the order status data, and the current risk parameters to configure corresponding settlement path identifiers and exchange strategy parameters for different stage combinations and risk levels, generating a settlement strategy matrix.

[0163] For example, the first batch settlement ratio and corresponding settlement path are configured for the "prepayment completed and first batch shipment completed" stage; the second batch settlement ratio is configured for the "interim payment completed and all shipments completed" stage; and the final settlement ratio is configured for the "final payment completed and goods received confirmed" stage. Based on the settlement strategy matrix, the cross-border settlement control module splits the order funds in the escrow account into multiple fund batch records, associating each batch record with an order identifier, target settlement path identifier, target currency, and settlement ratio parameters.

[0164] When the module detects that the order status data meets the trigger conditions corresponding to a certain batch of funds and the current risk parameters are within the preset range, it initiates a foreign exchange and fund transfer instruction to the settlement system or bank interface according to the settlement path identifier and foreign exchange strategy parameters configured in the batch of funds. The corresponding funds are transferred from the escrow account to the merchant's settlement account, and information such as order identifier, batch identifier, settlement amount, actual exchange rate and settlement time are written into the settlement record. At the same time, the remaining amount to be settled in the order is updated, so that the entire settlement process is dynamically linked with the performance progress and risk status.

[0165] Through steps S201 to S206 of the above embodiments, the private cross-border transaction performance and settlement method of this application realizes a complete closed-loop process, from establishing cooperative relationships and controlling private data access, generating contract instances based on quotation templates and solidifying contract baselines, associating stage node diagrams and order state machines based on contract baselines, driving payment instructions and performance instructions based on stage node diagrams, generating risk parameters combining performance processes and compliance rules, and finally controlling batch settlement paths and foreign exchange strategies under risk parameter constraints. This method enables contract terms, performance processes, and cross-border settlement in private cross-border transactions to form a structured mapping and linkage control at the system level, which helps reduce the intensity of manual intervention and improves the efficiency and security of batch performance management and cross-border settlement processing.

[0166] It should be understood that the sequence number of each step in the above method embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0167] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A private cross-border transaction fulfillment and settlement system, characterized in that, include: The privacy access control module is used to receive cooperation invitation information from merchants and buyers, establish cooperation relationship records, generate cooperation relationship identifiers and access control policies for each cooperation relationship, and control access to privacy quotation data and order data associated with the cooperation relationship identifier based on the access control policies. The contract modeling module is used to generate a private transaction quotation contract instance associated with the target buyer based on the cooperation relationship identifier and according to the preset quotation template, perform structured modeling on the private transaction quotation contract instance, and solidify the target version of the private transaction quotation contract instance into the contract baseline data after negotiation and confirmation. The performance orchestration module is used to parse the contract baseline data to obtain a stage node diagram containing multiple payment nodes and performance nodes, establish an association between the stage node diagram and the order to construct an order state machine, generate payment instructions corresponding to each payment node and performance instructions corresponding to each performance node according to the stage node diagram, and drive the order state machine to perform state transitions according to the stage node diagram to form order state data. The cross-border settlement control module is used to determine the settlement path and exchange strategy based on the contract baseline data, the order status data and risk parameters, to perform batch settlement control on the order funds paid by the buyer to the escrow account, and to transfer the corresponding batch of funds to the merchant's settlement account when the preset settlement conditions are met, and to generate a settlement record carrying the order identifier and batch identifier. The risk control module is used to conduct risk assessment and compliance verification of buyers and orders based on the cooperation relationship records, the contract baseline data, and the payment and performance information generated during order execution, and to generate the risk parameters, which are used to adjust the node parameters of the stage node diagram and the control parameters of the settlement path and exchange strategy.

2. The system according to claim 1, characterized in that, The process of generating a partnership identifier and access control policy for each partnership, and controlling access to private pricing data and order data associated with the partnership identifier based on the access control policy, includes: The received cooperation invitation information is parsed to determine the merchant identifier, buyer identifier, and cooperation level parameters, and a unique cooperation relationship identifier is generated based on the merchant identifier and the buyer identifier; Based on the cooperation level parameters, product category parameters, and risk parameters, a target access control template is selected from the preset strategy template library, and the cooperation relationship identifier is injected into the target access control template to generate a corresponding access control policy; When writing private pricing data and order data, the cooperation relationship identifier is written as an index field into the corresponding data record, and the fields marked as restricted access are stored with field-level encryption according to the access control policy. When receiving access requests for private pricing data and order data, the target partnership identifier is obtained by parsing the subject identifier in the access request. The access control policy corresponding to the target partnership identifier is called to determine the access permission. If the permission is allowed, the encrypted restricted fields are decrypted and output. If the permission is not allowed, the reading of the corresponding restricted fields is blocked.

3. The system according to claim 1, characterized in that, The step of generating a private transaction quotation contract instance associated with the target buyer based on the cooperation relationship identifier and a preset quotation template includes: Based on the cooperation relationship identifier, the target buyer identifier, cooperation level parameter, and target settlement currency parameter are obtained from the cooperation relationship record, and the quotation template group corresponding to the cooperation level parameter is determined; In the quotation template group, a target preset quotation template is selected according to the product category parameter and the transaction mode parameter, and the target buyer identifier and the cooperation relationship identifier are written into the target preset quotation template to form a template instance identifier; Based on the set of fields defined in the target preset quotation template, combined with historical order data, pricing rules and risk parameters, the product parameters, price parameters, payment terms and delivery terms to be written are automatically calculated to generate a structured parameter set; The structured parameter set is bound to the template instance identifier to generate a corresponding private transaction quotation contract instance, and a contract instance identifier is assigned to the private transaction quotation contract instance.

4. The system according to claim 3, characterized in that, The process of structurally modeling the private transaction quotation contract instance and, after negotiation and confirmation, solidifying the target version of the private transaction quotation contract instance into contract baseline data includes: The product parameters, price parameters, payment terms, and delivery terms in the private transaction quotation contract instance are split and mapped into a set of contract fields, and each contract field is configured with a field type identifier, association constraint parameters, and risk weight parameters to form contract structure description data; Assign version identifiers to each version of the private transaction quotation contract instance under the same cooperation relationship, construct a contract version record containing version identifiers and corresponding contract structure description data, and record the set of difference fields between each contract version record; Upon receiving the negotiation confirmation instruction, the target version of the contract version record is selected, the parameters marked as core constraint fields are locked, a contract baseline identifier carrying the contract instance identifier and version identifier is generated, and the contract structure description data is bound to the contract baseline identifier and stored as contract baseline data.

5. The system according to claim 1, characterized in that, The process of parsing the contract baseline data to obtain a stage node diagram containing multiple payment and performance nodes, and then establishing an association between the stage node diagram and the order to construct an order state machine, includes: Based on the payment terms and delivery terms extracted from the contract baseline data, a node set containing multiple payment nodes and performance nodes is generated, and each node is configured with a node type identifier, trigger condition parameters, and target stage parameters. Based on the order and dependency agreements recorded in the payment and delivery terms, directed connections are established for the nodes in the node set to form a stage node diagram describing the order execution process, and a stage diagram identifier is assigned to the stage node diagram. Upon receiving an order generated based on the contract baseline data, the order identifier is bound to the stage diagram identifier. The state set and state transition rules of the order state machine are determined according to the node type identifier and trigger condition parameters in the stage node diagram, and the order state machine is associated with the order.

6. The system according to claim 1, characterized in that, The step of generating payment instructions for each payment node and fulfillment instructions for each fulfillment node based on the stage node diagram, and driving the order state machine to perform state transitions according to the stage node diagram to form order state data, includes: Based on the node type identifier, trigger condition parameters, and target stage parameters of each node in the stage node diagram, a payment instruction record carrying an order identifier, node identifier, and node sequence number is generated for each payment node, and a performance instruction record carrying an order identifier, node identifier, and node sequence number is generated for each performance node. The payment instruction record and the performance instruction record are then registered in the instruction queue. When receiving payment information or performance information, the target instruction record is located from the instruction queue according to the order identifier and node sequence number. The trigger condition parameters of the node corresponding to the target instruction record are used to determine whether the state transition condition is met. If the condition is met, the order state machine is invoked to perform the state transition from the current state to the state corresponding to the target stage parameter. Upon completion of the state transition, the states before and after the transition, node identifiers, and time identifiers are written into the order status data record to form order status data that corresponds one-to-one with the stage node graph.

7. The system according to claim 1, characterized in that, The process of determining settlement paths and exchange strategies based on the contract baseline data, order status data, and risk parameters, and implementing batch settlement control for order funds paid by buyers to escrow accounts, includes: Based on the payment terms, completed payment nodes, performance nodes, and the aforementioned risk parameters, corresponding settlement path identifiers and foreign exchange strategy parameters are configured for different stage combinations and risk levels to generate a settlement strategy matrix that describes the triggering conditions and settlement ratios of each settlement batch. The order funds paid by the buyer to the escrow account are split into multiple fund batch records according to the settlement strategy matrix, and each fund batch record is associated with a corresponding order identifier, target settlement path identifier, target currency and settlement ratio parameter; When the order status data is detected to meet the triggering conditions corresponding to the current fund batch record and the current risk parameter is within the preset threshold range, a foreign exchange and fund transfer instruction is initiated according to the settlement path identifier and foreign exchange strategy parameters recorded in the current fund batch record. The corresponding funds are transferred from the escrow account to the merchant settlement account, and the remaining amount to be settled and the settlement record of the order are updated simultaneously.

8. The system according to claim 1, characterized in that, The risk assessment and compliance verification of buyers and orders, and the generation of the risk parameters, include: Based on the cooperative relationship records, the contract baseline data, and the payment and performance information generated during order execution, risk assessment factors are extracted to construct a corresponding risk feature vector. The risk feature vector is input into a preset risk assessment model and matched with the rules of the target country / region and the product compliance rules in the compliance rule base to obtain the risk score, risk level and compliance mark of the buyer and the order; Based on the risk score, risk level, and compliance identifier, the risk parameters are generated according to a preset mapping relationship. The risk parameters include node control parameters for limiting the time interval and amount ratio of payment nodes, and settlement control parameters for limiting the range of settlement path selection and foreign exchange strategy selection.

9. The system according to claim 1, characterized in that, The system also includes: The data encryption module is used to perform field-level encryption storage of preset sensitive fields, provide read / write and decryption access support for encrypted data to various modules, and generate structured order status data and structured settlement result data for private cross-border transaction performance and settlement processing.

10. A method for private cross-border transaction performance and settlement based on the system described in any one of claims 1 to 9, characterized in that, include: Receive cooperation invitation information from merchants and buyers, establish cooperation relationship records, generate cooperation relationship identifiers and access control policies for each cooperation relationship, and perform controlled access to private quotation data and order data associated with the cooperation relationship identifier based on the access control policies; Based on the cooperative relationship identifier, a private transaction quotation contract instance associated with the target buyer is generated according to the preset quotation template. The private transaction quotation contract instance is then structured and modeled. After negotiation and confirmation, the target version of the private transaction quotation contract instance is solidified as the contract baseline data. Based on the contract baseline data parsing, a stage node diagram containing multiple payment nodes and performance nodes is obtained, and the stage node diagram is associated with the order to construct an order state machine; Based on the stage node diagram, the payment instruction corresponding to each payment node and the fulfillment instruction corresponding to each fulfillment node are generated. When receiving payment information and fulfillment information, the order state machine is driven to perform state transition according to the stage node diagram to form order state data. Based on the cooperative relationship records, the contract baseline data, and the payment and performance information generated during order execution, risk assessment and compliance verification are performed on the buyer and the order to generate risk parameters for adjusting the node parameters of the stage node diagram and the settlement control parameters. Based on the contract baseline data, the order status data, and the risk parameters, a settlement path and exchange strategy are determined. Order funds paid by the buyer to the escrow account are subject to batch settlement control. When the preset settlement conditions are met and the risk parameters are within the preset range, the corresponding batch of funds is transferred from the escrow account to the merchant's settlement account according to the settlement path and the exchange strategy, and a settlement record is generated.

Images