A user credit scoring and hierarchical procurement authority management system of a centralized procurement platform

Abstract

The present application relates to the technical field of computer, disclose a kind of user credit score and hierarchical procurement authority management system of collection platform, the system includes: instantaneous transaction risk assessment module, when receiving the procurement request that exceeds the procurement party user basis credit authority, calculate the instantaneous transaction risk index for the procurement request;Reverse transaction structure generation module, at least one candidate transaction structure containing additional transaction terms for hedging risk is generated reversely according to the instantaneous transaction risk index;Cooperative interaction and smart contract module is used to present the candidate transaction structure to the procurement party user for its selection, and generate smart contract containing the additional transaction terms after confirmation.The present application converts the traditional authority control problem into the business decision problem carried out by procurement party autonomously, while effectively controlling risk, significantly improves the flexibility and success rate of transaction.

Description

Technical Field

[0001] This invention relates to the field of computer technology, specifically to a user credit scoring and tiered procurement authority management system for a centralized procurement platform. Background Technology

[0002] In the field of centralized procurement, online centralized procurement platforms typically set basic procurement permissions for purchasing users in order to improve transaction efficiency and standardize management. These permissions are often directly linked to a credit limit based on historical transaction data or static enterprise qualification assessment.

[0003] When a purchasing user initiates a purchase request exceeding their preset credit limit, the existing platform's commonly used permission management mechanisms reveal their inherent limitations. These mechanisms often operate with rigid binary logic, directly rejecting or blocking the excessive request and forcing it into a lengthy and inefficient manual approval process. This approach not only fails to effectively identify and facilitate potentially beneficial transactions but also leads to the loss of numerous transaction opportunities due to its one-size-fits-all control model, directly impacting the platform's transaction activity and overall revenue.

[0004] At a deeper level, the risk assessment basis of such systems is relatively static. The credit limits they rely on are updated slowly, making it difficult to reflect the buyer's current actual ability to fulfill obligations and their willingness to trade in a real-time and accurate manner. Furthermore, they fail to take into account the inherent risk characteristics of each individual transaction (such as commodity category and market price fluctuations). Therefore, when faced with transactions where risk exposure exceeds static thresholds, existing technologies lack an automated mechanism capable of dynamically assessing instantaneous risks and proactively constructing risk-controlled alternative trading solutions. Consequently, they cannot achieve an effective balance between ensuring platform fund security and maximizing transaction success rates. Summary of the Invention

[0005] The technical problem to be solved by this invention is that existing centralized procurement platforms often use rigid rejection or manual approval mechanisms when processing procurement requests that exceed the user's basic credit authorization. This mechanism is inefficient, inflexible, and prone to transaction failure, and cannot maximize the success rate of platform transactions while effectively controlling risks.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: The first aspect of this invention provides a user credit scoring and tiered procurement authority management system for a centralized procurement platform, the system comprising: The instant transaction risk assessment module is used to calculate the instant transaction risk index for a purchase request based on the purchase request and the dynamic credit profile of the purchaser user when a purchase request that exceeds the basic credit authorization of the purchaser user is received. A reverse transaction structure generation module is used to generate at least one candidate transaction structure containing additional transaction terms for hedging risk, based on the instantaneous transaction risk index; and The collaborative interaction and smart contract module is used to present the at least one candidate transaction structure to the purchasing user for selection, and generate a smart contract containing the additional transaction terms after the purchasing user makes a selection and the relevant parties confirm.

[0007] Furthermore, the instantaneous transaction risk assessment module is specifically used to perform weighted calculation based on the buyer risk score obtained by quantifying the dynamic credit profile of the buyer user and the transaction risk score obtained by quantifying the intrinsic parameters of the purchase request, to obtain the instantaneous transaction risk index.

[0008] Furthermore, the dynamic credit profile of the purchasing user includes at least one of the following dimensions: basic credit score, recent activity index, performance stability coefficient, or supply chain network strength.

[0009] Furthermore, the reverse transaction structure generation module is also used to calculate a risk mitigation value based on the risk preference profile of the candidate supplier user before generating the candidate transaction structure; and to calculate a net risk index based on the instantaneous transaction risk index and the risk mitigation value; wherein the reverse transaction structure generation module generates the candidate transaction structure based on the net risk index.

[0010] Furthermore, the risk preference profile of the candidate supplier user includes at least one utility function transformed according to the transaction condition rules defined by the supplier user; the utility function is used to input the purchase request and output whether the purchase request meets the transaction condition rules.

[0011] Furthermore, the reverse transaction structure generation module is specifically used to formalize the process of generating the candidate transaction structure into a combinatorial optimization problem. The combinatorial optimization problem aims to minimize the total cost to be borne by the purchaser, provided that the total risk reduction capability of the selected risk hedging tool combination is not less than the net risk value calculated according to the net risk index, thereby determining the additional transaction terms.

[0012] Furthermore, the system also includes: a risk hedging cost pricing module, used to calculate a base price based on the instantaneous transaction risk index and the total order amount, and to calculate a market adjustment coefficient based on the platform's current total risk demand exposure and total risk bearing capacity, and to determine the marketization cost of the risk hedging tool through the base price and the market adjustment coefficient; wherein, the calculation of the total cost is based on the marketization cost.

[0013] Furthermore, the collaborative interaction and smart contract module is specifically used to present the at least one candidate transaction structure in the form of a comparable list on the client interface of the purchasing user, wherein each candidate transaction structure presents its corresponding supplier information, the additional transaction terms, and the total cost to be paid for executing the additional transaction terms.

[0014] Furthermore, the collaborative interaction and smart contract module is specifically used to automatically generate the code of the smart contract based on a preset smart contract template library and according to the additional transaction terms included in the candidate transaction structure selected by the purchasing user.

[0015] A second aspect of the present invention provides a method for managing user credit scoring and tiered procurement permissions on a centralized procurement platform, the method comprising: When a purchase request that exceeds the basic credit authorization of the purchaser user is received, an instantaneous transaction risk index is calculated for the purchase request based on the purchase request and the dynamic credit profile of the purchaser user. Based on the instantaneous trading risk index, generate at least one candidate trading structure that includes additional trading terms for hedging risk; and The at least one candidate transaction structure is presented to the purchasing user for selection, and after the purchasing user selects and the relevant parties confirm, a smart contract containing the additional transaction terms is generated.

[0016] This invention provides a user credit scoring and tiered procurement authority management system for a centralized procurement platform. It has the following beneficial effects: 1. This invention replaces the traditional binary approval model by generating a transaction structure with additional terms in reverse, transforming potentially rejected over-authority transactions into risk-controlled alternatives, significantly improving transaction flexibility and final matching success rate.

[0017] 2. This invention shifts the focus of risk assessment from static user credit to specific transaction events by constructing an instantaneous transaction risk index, and combines it with a market-based pricing mechanism to achieve accurate risk measurement, dynamic pricing, and effective hedging.

[0018] 3. This invention presents complex risk hedging solutions to users in an intuitive and comparable manner, enabling users to make independent decisions based on business costs, and ensuring the security of transactions by ensuring that additional terms are accurately executed through automatically generated smart contracts. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the logical functional modules of a user credit scoring and tiered procurement authority management system for a centralized procurement platform according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating a user credit scoring and tiered procurement permission management method according to an embodiment of the present invention.

[0020] The module includes: 100, Data Acquisition and Preprocessing Module; 200, Bilateral User Profile Construction Module; 300, Instantaneous Transaction Risk Assessment Module; 400, Risk Hedging Cost Pricing Module; 500, Reverse Transaction Structure Generation Module; and 600, Collaborative Interaction and Smart Contract Module. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings.

[0022] See attached document Figure 1 , Figure 1 This is a schematic diagram of the logical functional modules of a centralized procurement platform user credit scoring and tiered procurement authority management system according to an embodiment of the present invention. The embodiment of the present invention provides a centralized procurement platform user credit scoring and tiered procurement authority management system, which is deployed on a centralized procurement platform server. The server is physically connected to multiple buyer clients and supplier clients. The server stores a computer program, which, when executed by a processor, implements the steps of the method of the present invention.

[0023] As attached Figure 1 As shown, the system is logically divided into multiple functional modules, which work together to achieve the technical solution of this invention. The system may include: a data acquisition and preprocessing module 100, a bilateral user profile construction module 200, an instantaneous transaction risk assessment module 300, a risk hedging cost pricing module 400, a reverse transaction structure generation module 500, and a collaborative interaction and smart contract module 600.

[0024] The data acquisition and preprocessing module 100 is used to acquire data related to purchasing and supply users from multiple data sources. These data sources include, but are not limited to: business registration information directly entered by users through the client interface; user front-end behavior tracking data obtained through data acquisition scripts deployed on the client, such as page views, clicks, and dwell time; transaction logs extracted from the server's backend business database, including historical order details, payment records, and logistics status; and external data obtained through application programming interfaces (APIs) from third-party credit reporting agencies or enterprise information service platforms. This module also performs preprocessing operations such as cleaning, format standardization, and missing value imputation on the acquired raw data to generate a structured dataset that can be used by subsequent modules.

[0025] The bilateral user profile building module 200 receives data processed by the data acquisition and preprocessing module 100 and builds and updates dynamic profiles for both purchasing and supply users within the platform in real time. For purchasing users, this module builds a multi-dimensional dynamic credit profile, which replaces the traditional single credit score; for supply users, this module builds a structured risk preference profile.

[0026] The instantaneous transaction risk assessment module 300 is activated when the system receives a purchase request that exceeds the basic credit authorization level of the purchasing user. This module calls the dynamic credit profile of the purchasing party generated by the bilateral user profile construction module 200, and combines it with the transaction parameters of the purchase request itself (such as product category, order amount, price volatility, etc.) to calculate the instantaneous transaction risk index for that specific transaction. This index is used to quantify the risk exposure that needs to be compensated to complete this transaction.

[0027] The Risk Hedging Cost Pricing Module 400 dynamically prices the costs required to complete risk hedging. This module continuously monitors the platform's overall risk status, including the total risk exposure of all pending transactions and the total risk-bearing capacity provided by the platform and its partners. Based on this, the module calculates a market adjustment coefficient and, combined with the instantaneous transaction risk index output by the Instantaneous Transaction Risk Assessment Module 300, calculates real-time, market-based usage costs for the platform's risk hedging tools (such as platform guarantees and payment terms).

[0028] The reverse transaction structure generation module 500 is used to proactively design risk-controlled transaction schemes without directly rejecting excessive procurement requests, thereby achieving flexible, tiered procurement permission management. This module receives the instantaneous transaction risk index and the cost of dynamically priced risk hedging tools, while also accessing the supplier's user risk preference profile. Through a combined optimization algorithm, this module generates one or more candidate transaction structures for the procurement request. Each candidate transaction structure includes a designated supplier, a set of additional transaction terms for hedging risk (i.e., a combination of risk hedging tools), and the additional costs incurred in executing these terms.

[0029] The collaborative interaction and smart contract module 600 presents the candidate transaction structures generated by the reverse transaction structure generation module 500 to the purchasing user and handles the subsequent multi-party collaborative confirmation process. This module displays each candidate transaction structure in a comparable list on the purchasing user's client interface. After the purchasing user makes a selection, this module sends an offer including additional terms to the corresponding supplier for confirmation. Once both parties reach an agreement, this module programmatically merges the additional terms with the standard contract text to generate an immutable smart contract, which is then distributed and stored, completing the final locking of the transaction.

[0030] See attached document Figure 2 , Figure 2 This is a flowchart illustrating a user credit scoring and tiered procurement authority management method according to an embodiment of the present invention. The overall workflow of the method according to this embodiment is as follows: S201 continuously acquires and processes data from the purchaser and supplier through the data acquisition and preprocessing module 100.

[0031] S202, the bilateral user profile building module 200 builds and maintains dynamic profiles of both parties in real time based on the data processed by S201.

[0032] S203: The server receives a purchase request initiated by the purchaser and determines whether the request exceeds the purchaser's basic permissions. If so, proceed to S204.

[0033] S204, the instant transaction risk assessment module 300 is triggered to assess the transaction and calculate the instant transaction risk index.

[0034] S205, Risk Hedging Cost Pricing Module 400 dynamically prices the tools needed to hedge the risk based on the platform's real-time risk market conditions.

[0035] S206, the reverse transaction structure generation module 500 uses the aforementioned risk index and pricing results, combined with the risk preference profile of the matched supplier, to generate a series of candidate transaction structures.

[0036] S207, the collaborative interaction and smart contract module 600 presents the generated candidate transaction structure to the purchasing user for decision-making.

[0037] S208, determine whether the supplier has confirmed the solution selected by the purchaser. After the purchaser selects a solution, the selection is sent to the supplier for confirmation. If the supplier confirms, proceed to S209. If the supplier does not confirm or there is no matching supplier, the transaction cannot be completed along this path, and the process ends.

[0038] S209, the collaborative interaction and smart contract module 600 automatically generates and solidifies a smart contract containing all terms, and the transaction process ends.

[0039] The following is a detailed explanation of the implementation methods of each core module in the user credit scoring and tiered procurement authority management system provided by this invention.

[0040] The data acquisition and preprocessing module 100 is the foundation of the entire system, and it is used to provide data input for all subsequent modules.

[0041] The data acquisition and preprocessing module 100 is configured to acquire multi-dimensional data related to purchasing and supply users from multiple heterogeneous data sources distributed both inside and outside the platform in real time or near real time. The data sources include at least: user-inputted data, system front-end behavioral data, system back-end business data, and third-party interface data.

[0042] Specifically, user-input data refers to the information submitted by users through the purchasing or supplying party's client interface when registering, authenticating, or updating their information. This information constitutes the user's static basic profile, such as company name, unified social credit code, registered address, legal representative information, business scope, and industry classification.

[0043] System front-end behavioral data refers to the sequence of user interaction behaviors captured by data collection scripts deployed in client applications or web pages. These scripts record every interaction event between the user and the interface, attaching a unique user identifier and a timestamp accurate to milliseconds to each event. The recorded behavioral events include, but are not limited to: page browsing events, recording the page paths visited by the user; element click events, recording the specific buttons or links clicked by the user; form submission events, recording the content of the inquiry form or order draft submitted by the user; and page dwell and scrolling events, used to analyze user attention and information browsing depth. These data collectively constitute the dynamic behavioral characteristics of the user.

[0044] System backend business data refers to transaction and fulfillment records generated during business processing on the server side and stored in the platform's core database. This data is the core basis for assessing a user's historical credit. Specific data fields include: order records, including order number, creation time, product details, order amount, and purchase quantity; payment records, including payment serial number, payment time, payment method, whether there was a delayed payment and its duration; and logistics and acceptance records, including delivery time, arrival and receipt time, acceptance and warehousing or return records, transaction disputes and their handling results.

[0045] Third-party interface data refers to supplementary credit information obtained by the system from authorized third-party service providers through API interfaces. Examples include corporate credit reports obtained from commercial credit reporting agencies, or judicial risk information such as corporate litigation involvement and status as a dishonest judgment debtor obtained from judicial information platforms.

[0046] After completing the multi-source data acquisition, the data acquisition and preprocessing module 100 performs a series of preprocessing operations on the acquired raw data to ensure the accuracy, consistency, and integrity of the data. These operations include data cleaning, format standardization, and missing value handling.

[0047] After the above collection and preprocessing process, the data collection and preprocessing module 100 finally outputs a structured dataset, which is transmitted to the bilateral user profile building module 200 as data for building dynamic credit profiles of purchasers and risk preference profiles of suppliers.

[0048] The bilateral user profile building module 200 provides profiles for each purchasing user. Building dynamic credit profiles This profile is a multi-dimensional, structured vector that reflects a user's credit status and behavioral patterns in real time. This design aims to overcome the shortcomings of traditional credit scoring, such as delayed updates and limited dimensions, providing more accurate input for subsequent risk assessment.

[0049] Specifically, dynamic credit profiling It can be represented as a vector that contains at least the following four core dimensions: basic credit score Recent Activity Index Performance stability coefficient and the strength of the supply chain network The bilateral user profile building module 200 calculates and updates the profile by performing the following steps: S221, the bilateral user profile building module 200 receives a clean, structured dataset about a specific purchasing user from the data acquisition and preprocessing module 100.

[0050] S222, Calculate the user's basic credit score This score serves as a benchmark measure of a user's creditworthiness, calculated based on the user's static baseline data and long-term historical transaction data. In one embodiment, the score is calculated using a linear weighted model: ; in, It is the total number of static and long-term characteristics used for evaluation; It is the first Standardized scores for each characteristic, such as registered capital, historical certification level, years of establishment, and average performance rate over the past three years; It is the first The weight coefficients corresponding to each feature are pre-set by the platform's risk control strategy, and .

[0051] S223, Calculate the user's recent activity index This index is used to capture users' current platform engagement and transaction intentions, and is a frequently updated dynamic indicator. The index is calculated using a time-decay weighted model, assigning higher weight to recently occurring behavioral events. The specific calculation formula is as follows: ; in, It is the total number of user behavior events within a preset time window (e.g., the past 30 days); It is the first Each behavioral event is assigned a pre-defined value weight, and different behaviors are given different values. For example, the value of a "submit an inquiry" behavior is higher than the value of a "view a product page" behavior. It is the first The timestamp of each behavioral event; It is the timestamp of the current computation execution; It is the time decay factor, a constant greater than zero. The value of determines the rate at which the weight decays; the larger the value, the smaller the impact of earlier actions on the current index.

[0052] S224, Calculate the user's performance stability coefficient This coefficient aims to quantify the consistency and predictability of a user's recent payment performance, rather than simply assessing the quality of their performance. A user with a consistently excellent payment record or a consistent pattern of minor delays demonstrates higher stability than a user whose payment performance is inconsistent and fluctuates irregularly. In one specific implementation, this coefficient is defined as the reciprocal of the coefficient of variation (CV) of a user's recent payment delay time series.

[0053] First, obtain the payment delay time series of the user over the past period (e.g., the most recent 10 orders). ,in For the first The number of days the payment for this order is delayed.

[0054] Calculate the mean of the sequence. and standard deviation : ; ; in, This represents the arithmetic mean of the payment delay time series; The standard deviation of the payment delay time series represents the sample standard deviation. This represents the number of order samples contained in the time series. It is the first in the sequence The number of days the payment is delayed for each order.

[0055] Calculate the coefficient of variation : ; in, This is the coefficient of variation of the payment delay time series, used to measure the relative dispersion of the data. To avoid the denominator being zero, when... At that time, it can be set .

[0056] Finally, the performance stability coefficient The calculation is as follows: ; This formula ensures The value falls within the range (0,1]. The closer the value is to 1, the more stable the user's fulfillment behavior is.

[0057] S225, Calculate the user's supply chain network strength This dimension is used to assess a user's status and influence within the platform's overall transaction ecosystem. The two-sided user profile building module 200 first abstracts the platform's transaction history into a directed weighted graph. , where the set of nodes Representing all users of the platform (including buyers and suppliers), the edge collection This represents the transaction relationship between users. An edge from user A to user B indicates that A has initiated a purchase from B. The weight of the edge can be determined by the total transaction amount or the number of transactions.

[0058] In this graph structure, a graph centrality algorithm is used to calculate the strength of each node. In a preferred embodiment, the PageRank algorithm is used. (User's supply chain network strength) This refers to its PageRank score in the transaction network graph. This score considers not only the number of a user's trading partners, but more importantly, the network strength of those trading partners themselves, effectively identifying key users at the core of the network.

[0059] S226, After completing the calculations for all the above dimensions, the bilateral user profile building module 200 combines these calculation results into a structured vector. This vector constitutes the complete dynamic credit profile of the purchasing user at the current moment, and is stored in the user profile database for other modules to access at any time. This profile is updated periodically or triggered by events based on the inflow of new data.

[0060] In addition to building an objective and dynamic credit profile for the purchaser, the bilateral user profiling module 200 also provides a profile for each supplier user. Construct a structured risk preference profile that reflects their subjective trading intentions. The core function of this profile is to transform the risk-return preferences formed by suppliers in business practices into calculation rules that can be understood and invoked by the system.

[0061] To achieve this functionality, the bilateral user profile building module 200 builds and maintains a risk preference profile of the supplier by performing the following steps: S227, the system provides supplier users with a dedicated rule configuration interface on their client side. Through this interface, supplier users can independently define the combination of transaction conditions they are willing to accept or prioritize. This interface guides suppliers to transform their business strategies into structured "if-then" rules through preset condition fields (such as "buyer credit rating", "historical cooperation duration", "order profit margin", etc.), logical relationships (such as "greater than", "less than", "belongs to", etc.), and result operations (such as "provide N-day payment terms", "grant X% discount", etc.).

[0062] For example, a supplier can configure the following rules: Rule 1: If the purchaser's performance stability coefficient If the value is greater than 0.9 and the historical cooperation period exceeds 365 days, then I am willing to provide a payment period of up to 60 days.

[0063] Rule 2: If the profit margin of a single order is higher than 20%, then I am willing to accept a minimum prepayment rate of 10%.

[0064] Rule 3: If the buyer is a certified A-level customer of the platform, then I am willing to bear all logistics insurance costs for their orders.

[0065] S228, the bilateral user profile building module 200 parses, compiles, and transforms the discrete rules submitted by the supplier in the background. Each rule is transformed into a Boolean or numerical utility function that can be executed by the machine. This function accepts the transaction object to be evaluated. As input parameters, the transaction object It is a data structure that encapsulates all relevant information for the current transaction, including a complete dynamic credit profile of the purchasing user. Order details (amount, category, quantity, etc.) and proposed transaction terms (such as payment method, delivery period, etc.).

[0066] S229, the bilateral user profile building module 200 aggregates all the transformed utility functions into a set of functions, which constitutes the complete risk preference profile of the supplier-side user. ,in The total number of rules configured for this vendor. This profile is stored in a user profile database and can be dynamically adjusted as the vendor updates its preferences.

[0067] Taking Rule 1 described in S227 as an example, its corresponding utility function It can be defined as a Boolean function to determine whether a transaction meets the supplier's favorable terms regarding payment terms: ; in, It represents the object of the transaction currently being evaluated; This indicates the performance stability coefficient of the purchasing user corresponding to the transaction; this data is derived from their dynamic credit profile. Obtain from; This indicates the duration of the historical cooperation between the supplier and the purchaser (in days), which is calculated from historical transaction records. This indicates the current proposed payment period for the transaction (in days).

[0068] The function returns 1 if the transaction fully meets the discount rule, and 0 if it does not.

[0069] When the subsequent reverse transaction structure generation module 500 runs, it can directly call the specific supplier's... and enter a transaction. By iterating through and executing each utility function, it is possible to quickly determine the extent to which the transaction will be favored by the supplier and what specific preferential conditions will be triggered, thereby providing personalized decision-making basis for risk hedging and transaction structure design.

[0070] The Instant Transaction Risk Assessment Module 300's core function is to accurately and dynamically quantify the risks inherent in a purchase request that exceeds the purchaser's basic credit authorization. This module assesses the specific "transaction event" rather than the isolated "transaction user," thus achieving a more targeted measurement of risk.

[0071] This module assesses instantaneous transaction risk by performing the following steps: S301, the instant transaction risk assessment module 300 is activated when a purchasing user... Total order amount in the submitted purchase request (Req) The transaction exceeds the user's static or dynamic base credit limit. Once activated, the module immediately begins an independent risk assessment process for the transaction.

[0072] S302, the Instantaneous Transaction Risk Assessment Module 300 constructs a multi-factor risk coupling model to calculate a comprehensive instantaneous transaction risk index (ITRI). This index is a dimensionless numerical value, and its magnitude directly reflects the risk exposure level of the transaction. The model's calculation integrates three dimensions: buyer risk, transaction-specific risk, and (in the case of a designated supplier) supplier risk. Its calculation formula is as follows: ; in, It is the final calculated instantaneous trading risk index; By creating dynamic credit profiles of the purchasers The risk score of the purchaser obtained after quantification; It is a transaction risk score obtained by quantifying the intrinsic parameters of the transaction; This is the supplier risk score obtained by quantifying the credit profile of the designated supplier. If no supplier is specified, this item is 0. , , These are the weighting coefficients for three risk dimensions: the buyer, the transaction, and the supplier. These weights are configured by the platform based on its overall risk control strategy and must meet certain conditions. .

[0073] S303, the instantaneous transaction risk assessment module 300 standardizes the multi-dimensional inputs for each risk dimension, converting them into a single, weighted risk score. In a specific embodiment, this standardization process employs the max-min normalization method. For any original indicator that needs to be standardized... Its standardized score The calculation is as follows: ; in, It is the current value of the indicator to be standardized; and These are the minimum and maximum values ​​allowed for the indicator in historical data or preset rules, respectively.

[0074] Specifically, regarding the risk score of the purchasing party The system first starts with a dynamic credit profile of the purchaser. We extract indicators from each dimension, apply the normalization formula described above to each indicator, and then obtain a comprehensive score through linear weighting. For positive indicators (higher scores indicate lower risk, such as...),... , , Its risk contribution is For negative indicators (higher scores indicate higher risk), their risk contribution is: .

[0075] For transaction risk score The instantaneous transaction risk assessment module 300 first constructs a transaction parameter vector TP, which contains at least the total order amount. Historical volatility of commodity prices Commodity Market Liquidity Index The higher the total order amount, the greater the risk; the higher the price volatility, the greater the risk of adverse price changes in the future; the worse the market liquidity, the more difficult it is to resell to make up for losses in the event of default. These indicators, after being normalized, are weighted to obtain... .

[0076] For supplier risk score Its calculation process is the same as Similarly, but using credit profile data of the supplier users specified in the transaction.

[0077] S304, after calculating the risk scores for each dimension , and Then, according to the formula defined in S302, they are weighted and summed using preset weighting coefficients to finally obtain the instantaneous transaction risk index ITRI for this transaction.

[0078] The ITRI value, as a key output, is transmitted to the risk hedging cost pricing module 400 and the reverse transaction structure generation module 500, serving as the core quantitative basis for subsequent cost pricing and structure design.

[0079] Upon receiving the Instantaneous Transaction Risk Index (ITRI) generated by the Instantaneous Transaction Risk Assessment Module (300), the Risk Hedging Cost Pricing Module (400) initiates a dynamic pricing process for risk hedging services. This pricing process calculates the base price for the risk exposures that need to be hedged. This base price constitutes a benchmark measure of risk cost, and its value directly reflects the inherent risk value of a particular transaction, serving as the initial cost before subsequent market adjustment factors are added.

[0080] In one specific implementation, the base price The calculation logic is designed to couple an abstract risk index with a concrete transaction amount, and the calculation is completed by performing the following steps: S401, the risk hedging cost pricing module 400 obtains the instantaneous transaction risk index ITRI for the current transaction from the instantaneous transaction risk assessment module 300, and simultaneously obtains the total order amount from the transaction request. .

[0081] S402, the module uses a preset pricing model to calculate the base price of the risk hedging service. The model defines the base price as the product of the instantaneous transaction risk index, the total order amount, and a base pricing coefficient. The specific calculation formula for this pre-defined pricing model is as follows: ; in, The base price for risk hedging services is expressed in the system's standard currency (e.g., yuan). This price represents the initial cost that the purchaser must pay to obtain risk hedging tools (such as credit guarantees) provided by the platform. ITRI is a dimensionless instantaneous transaction risk index calculated by the instantaneous transaction risk assessment module 300 for the current transaction. This is the total order amount specified in the current procurement request, representing the direct risk exposure in this transaction; It is the platform's preset basic pricing coefficient, which is a dimensionless positive number. This coefficient is set by the platform's risk management department based on factors such as the platform's overall profit target, risk tolerance, historical bad debt rate, and industry benchmarks. Adjustments to this coefficient are low-frequency operations and represent the platform's basic pricing strategy for unit risk exposure.

[0082] The meaning of this calculation logic is: the basic cost of risk hedging is directly proportional to the level of abstract risk in the transaction (represented by ITRI), and also related to the specific amount associated with that risk (represented by...). The risk exposure from a high-risk, high-value transaction has a significantly higher hedging cost than that from a low-risk or low-value transaction.

[0083] In this way, the system transforms standardized risk indices into a monetary cost benchmark with clear commercial significance.

[0084] The base price for risk hedging services is calculated. Subsequently, the risk hedging cost pricing module 400 further introduces a market-based adjustment mechanism, aiming to ensure that the final pricing of risk hedging depends not only on the isolated risk of a single transaction, but also dynamically reflects the overall risk supply and demand situation faced by the platform at a given moment. To this end, the module calculates a real-time market adjustment coefficient. This allows for dynamic adjustments to the base price.

[0085] The calculation logic of the market adjustment coefficient lies in quantitatively comparing all pending risk demands within the platform with the platform's risk-bearing capacity, thereby constructing a virtual risk market. This module completes the calculation of the market adjustment coefficient by performing the following steps: S403, Risk Hedging Cost Pricing Module 400 Real-time Calculation Platform: Current Total Risk Demand Exposure This exposure is defined as the total risk value of all pending transactions on the platform that require risk hedging services at the current point in time. Specifically, the module iterates through all eligible transaction requests and sums the product of the instantaneous transaction risk index and the order amount for each transaction. The calculation formula is as follows: ; in, This represents the platform's current total risk exposure. This represents the set of all pending transactions on the current platform that require risk hedging. It is a set The Middle The instantaneous transaction risk index; It is the first The total order amount for this transaction.

[0086] S404, Obtain the platform's current total risk tolerance. This capacity represents the maximum amount of risk that the platform and its partners are willing and able to assume during the current period. This total capacity consists of several parts, including at least the risk reserves set aside by the platform itself, and the total credit guarantee limit agreed upon with partner financial institutions (such as banks or insurance companies). Its calculation formula is as follows: ; in, This represents the platform's current overall risk tolerance capacity; It is the currently available amount in the platform's internal risk reserve pool; It represents the total available credit guarantee or insurance service provided by all external partner financial institutions within the current period.

[0087] S405, in obtaining total risk exposure Total risk tolerance Then, calculate the current market adjustment coefficient. This coefficient is generated using a function that reflects the supply and demand relationship. In a preferred embodiment, an exponential function is used to smoothly and effectively reflect the impact of supply and demand imbalances on prices. The calculation formula is as follows: ; in, It is the final calculated market adjustment coefficient; It is the base of the natural logarithm; and These are the total risk demand exposure and total risk bearing capacity calculated above, respectively. This is a preset price sensitivity adjustment factor on the platform, which is a positive number. This factor controls the degree to which prices react to supply and demand imbalances. The larger the value, the more volatile the price.

[0088] The underlying logic of this formula is: when total demand With aggregate supply When they are equal, the ratio is 1 and the exponent is 0. When the ratio equals 1, the final price is the base price; when aggregate demand exceeds aggregate supply, the ratio is greater than 1, and the index is positive. When the ratio is greater than 1, the final price increases; when aggregate demand is less than aggregate supply, the ratio is less than 1, and the index is negative. If the value is less than 1, the final price will decrease.

[0089] S406, the risk hedging cost pricing module 400 will calculate the market adjustment coefficient. Compared with the previously calculated base price Multiplying these together yields the final, market-based risk hedging cost for the user. : ; The final price This not only reflects the individual risk of a single transaction but also incorporates the overall macro-level state of the platform's risk market, achieving real-time dynamic and market-based pricing of risk costs. This final price... It is transmitted to the reverse transaction structure generation module 500.

[0090] After receiving the instantaneous transaction risk index (ITRI) and market-based pricing results, the reverse transaction structure generation module 500 performs a risk matching and reduction process. The core purpose of this process is to proactively discover and quantify the portion of risk that can be offset by the supplier's subjective will by intelligently matching the profiles of both parties in the transaction, thereby calculating the net risk exposure for a specific counterparty.

[0091] The reverse transaction structure generation module 500 calculates the net risk exposure by performing the following steps: S501 receives the instantaneous transaction risk index ITRI and the complete data object T of the transaction from the preceding module. Simultaneously, based on information such as product category and specifications in the transaction request, it selects one or more candidate supplier users capable of undertaking the order from the platform database, forming a candidate supplier set. .

[0092] S502, regarding the candidate supplier set Each supplier user in Perform an iterative calculation loop to calculate the specific net risk exposure for each potential "buyer-supplier" transaction pair.

[0093] S503, targeting specific suppliers In the calculation loop, the supplier's risk preference profile is first retrieved from the user profile database. .

[0094] S504, calculate the supplier Regarding this transaction Risk mitigation value that can be provided This calculation process reflects the quantitative utilization of suppliers' business preferences. Specifically, the system configures each rule in the supplier's risk preference profile. Pre-calibrate the risk mitigation coefficient This coefficient represents the magnitude of risk reduction that the preferential conditions corresponding to this rule (such as providing payment terms, reducing prepayment ratios, etc.) are equivalent to in the risk management model. Subsequently, the current trading counterpart... Execute one by one as input. All utility functions If the function returns 1 (indicating that the rule is met), then the corresponding risk mitigation coefficient is... Included in the total risk mitigation value. The supplier's total risk mitigation value. The calculation formula is as follows: ; in, Supplier For transactions Total risk mitigation value available; A profile of the supplier's risk appetite The first in A utility function that returns either 1 or 0, representing a transaction. Does this rule apply? Is with rules The risk mitigation coefficient is a dimensionless positive number, determined by the platform's risk control strategy based on the fair market risk value of different preferential terms. For example, it corresponds to a 60-day payment period. The value will be significantly higher than offering a 15-day payment period.

[0095] S505, after calculating a specific supplier Available risk mitigation value Then, calculate the net risk index required to transact with this supplier. The net risk index is the risk exposure remaining after deducting the portion actively borne by the supplier from the initial risk index. Its calculation formula is as follows: ; in, When the counterparty is the supplier The net risk index at the time of the transaction; ITRI is the instantaneous transaction risk index at the beginning of the transaction, without considering counterparty preferences; This is the risk mitigation value that the supplier can provide, calculated according to S504. The function ensures that the net risk index will not be negative.

[0096] By performing the above steps, the reverse transaction structure generation module 500 can transform a transaction with a fixed initial risk into a set of potential transaction schemes with different net risk exposures, matched with different suppliers. The module ultimately outputs a set containing multiple "supplier-net risk index" pairs, such as... This net risk index, after being "filtered" and "reduced" by supplier preferences, will serve as the input for the next step of designing specific risk hedging tool combinations.

[0097] After calculating the relationship with each candidate supplier Corresponding net risk index Subsequently, the reverse transaction structure generation module 500 proceeds with the core transaction structure design process. The goal of this process is to design a lowest-cost risk hedging solution comprised of specific commercial terms for each remaining net risk exposure. This process transforms abstract risk management into concrete transaction solutions that are available to the purchaser, including clearly defined additional terms and costs.

[0098] The reverse transaction structure generation module 500 completes the combination optimization and cost accounting of risk hedging instruments by performing the following steps: S506, pairing each "supplier-net risk index". Initiate an independent scenario generation calculation. In each calculation, first, the dimensionless net risk index is... Converted into specific risk value amount This amount represents the transaction with a specific supplier. Even after matching, the platform still needs to intervene to hedge the risk exposure. The calculation formula is as follows: ; in, It is the net risk value that needs to be hedged; It is with the supplier The net risk index calculated after matching; This is the total amount of the original order for this transaction.

[0099] S507, from the pre-set risk hedging tool library The toolkit allows for selection and combination of various commercial terms that can be attached to transaction contracts, each with clearly defined risk mitigation capabilities and usage costs. At least including: Margin tools This requires the buyer to pay a certain percentage of the transaction as a deposit before the transaction begins. Its risk mitigation capability is equal to the amount of the deposit, and its cost is the cost of tying up the funds (e.g., the opportunity cost calculated based on the market average rate of return on capital).

[0100] Phased payment tools This involves splitting a one-time payment into multiple payments based on the transaction process (e.g., "prepayment," "after shipment," "after acceptance"). Its risk mitigation capability is equal to the total amount of the prepayment, and its cost can be considered zero or associated with potential discounts offered by the supplier.

[0101] Platform Guarantee Tools The platform or its partners provide credit guarantees for the remaining risk portion of the transaction. Its risk mitigation capacity equals the amount of its guarantee, and its cost is the market-based risk hedging cost calculated by the risk hedging cost pricing module 400. .

[0102] S508 formalizes the problem of finding the optimal portfolio of instruments into a portfolio optimization problem. The objective of this problem is to ensure that the total risk reduction capability of the selected portfolio of instruments is not less than the net value at risk. Under the premise that the total cost to be borne by the purchasing party Minimum.

[0103] Specifically, set For decision variables, representing the tools used. The extent (e.g., for margin instruments it is the amount paid, for platform-guaranteed instruments it is the amount of guarantee purchased).

[0104] The optimization problem can be formulated as follows: Minimize: ; Constraints: ; For all ; in, It is with the supplier The minimum total cost that the buyer must pay to hedge net risk during a transaction; It is about using tools achieve The costs incurred at that level; It is about using tools achieve The amount of risk reduction provided at each level, in many cases, the risk reduction function is linear, i.e. ; It represents the total number of tools in the tool library.

[0105] S509, invoke a built-in or external optimization solver (e.g., a linear programming or integer programming solver) to solve the above optimization problem. The solver will provide a set of optimal decision variable values. This set of values ​​clarifies the requirements for fully covering net risk exposure. The optimal amount for each tool required.

[0106] S510, after obtaining the optimal solution, transforms the solution into a human-readable transaction structure scheme. This scheme outlines the transactions with the supplier... When conducting a transaction, the buyer needs to accept additional commercial terms (e.g., "15% of the order amount must be paid as a deposit, and the remaining 30% must be guaranteed by the platform"), and the total cost of enforcing these terms. .

[0107] Ultimately, the reverse transaction structure generation module 500 will generate a complete transaction plan for each candidate supplier, including "supplier, additional terms, and total cost," and output these plans to the collaborative interaction and smart contract module 600 for the purchaser to make the final business decision.

[0108] After receiving one or more candidate transaction schemes output by the reverse transaction structure generation module 500, the collaborative interaction and smart contract module 600 transforms these complex backend calculation results into an intuitive frontend user interface. The core of this process lies in transforming the permission management issue of "whether to approve" into a business choice issue of "how to trade."

[0109] The collaborative interaction and smart contract module 600 completes the dynamic presentation and decision support of candidate transaction structures by executing the following steps: S601, receive a set of transaction schemes generated and transmitted by the reverse transaction structure generation module 500. Each element in the set is an independent and complete transaction scheme, whose data structure includes at least: a unique identifier of the candidate supplier, an additional combination of terms optimized to hedge the net risk of the transaction (including the specific instrument type and amount), and the total cost required to execute the combination of terms.

[0110] S602 parses and adapts each received transaction scheme to the front-end. This process converts the technical identifiers used by the back-end system (e.g., Tool ID: "Tool_margin", Credit: "0.15 * V_order") into user-friendly natural language descriptions (e.g., "Additional Terms: A margin of 15% of the total order amount is required"). The processed result is encapsulated into a structured data object (e.g., JSON format), which contains all the information needed to display on the front-end interface.

[0111] S603, the collaborative interaction and smart contract module 600 dynamically generates and renders a transaction option selection view on the client interface of the purchasing user. In a preferred embodiment, this view adopts a side-by-side card or comparison table format, clearly displaying all feasible transaction options to the user. Each option card or table row presents the following key decision information: Supplier Information: Displays the supplier's name, historical credit rating on the platform, and the number of times or duration of their historical cooperation with the current purchaser.

[0112] Additional transaction terms: List the additional conditions that must be accepted to complete this transaction, such as "Pay a margin of ¥15,000.00" and "Purchase a platform credit guarantee for the remaining balance of ¥50,000.00".

[0113] Total hedging cost: This clearly indicates the total cost that the purchaser needs to pay to satisfy all the above additional terms, calculated by the reverse transaction structure generation module. .

[0114] Final Order Overview: This summary displays the original order amount, total additional costs, and the final total payment estimate, giving users a clear overview of the overall financial impact of the transaction.

[0115] S604, to further assist user decision-making, this interface also provides a series of interactive decision support functions. These functions include: Dynamic sorting: Users can sort all candidate options with one click based on different dimensions such as "lowest total hedging cost", "highest supplier rating" or "fewest additional terms" to quickly filter out the option that best matches their current preferences.

[0116] Expand for details: For each additional clause, users can click or hover to view a more detailed explanation. For example, clicking "Platform Credit Guarantee" will bring up a pop-up window explaining the specific scope of the guarantee, its effective conditions, and why this tool is needed in this transaction.

[0117] Cost Composition Analysis: For the displayed total hedging cost, the interface can provide a cost composition chart, clearly showing the source and proportion of each expense (e.g., opportunity cost of capital occupation, guarantee service fee, etc.), increasing the transparency of pricing.

[0118] By presenting multiple options with different costs and terms side by side, the system successfully transforms the traditional "approval / rejection" binary authority problem, which is unilaterally determined by the platform, into a "choose one of many" business decision problem that is independently made by the purchasing user, weighing costs and partners.

[0119] S605, this interface provides a "Select this option" button for each transaction plan. When the purchasing user makes a decision and clicks one of the buttons, the collaborative interaction and smart contract module 600 accurately captures the user's choice, records the unique identifier of the selected supplier and the complete set of additional transaction terms bound to it. This confirmed selection plan will serve as the basis for the final transaction agreement and will be passed to the subsequent smart contract generation process.

[0120] After the purchasing user makes a final decision on the front-end interface and selects a transaction plan that includes specific additional terms, the collaborative interaction and smart contract module 600 transforms the decision into a digital agreement.

[0121] The collaborative interaction and smart contract module 600 completes the automatic generation and execution of smart contracts by performing the following steps: S606: Obtain the transaction plan finally confirmed by the purchasing user in step S605. This plan, as a complete data package, includes the identity information of both parties (the purchasing party and the selected supplier), all details of the original order (goods, specifications, quantity, unit price, total amount, etc.), and a complete set of additional commercial terms that both parties must abide by (e.g., specific deposit amount, phased payment nodes and proportions, platform guarantee limit, etc.).

[0122] S607 automatically generates smart contract code specific to this transaction based on a pre-set smart contract template library. This library stores a large number of standardized contract clause fragments that have undergone legal review and technical verification. These fragments are divided into two categories: one is basic clause templates applicable to all transactions, such as transaction parties, subject matter, place of performance, and dispute resolution; the other is functional clause templates corresponding to each tool in the risk hedging tool library, such as "margin clause template," "phased payment clause template," and "platform guarantee liability clause template."

[0123] In the smart contract generation process, the collaborative interaction and smart contract module 600 first loads the basic contract framework. Then, based on the additional terms included in the selected transaction plan, it retrieves the corresponding functional clause templates from the template library and embeds these templates into the predetermined positions of the basic framework. During this process, the module fills the parameterized variable positions of the clause templates with the specific values ​​in the transaction plan (such as the margin amount "¥15000.00", the guarantee amount "¥50000.00", etc.), thereby generating complete contract code.

[0124] S608, after the contract code is generated, performs a cryptographic hash operation (e.g., using the SHA-256 algorithm) on the complete content of the contract to generate a unique digital fingerprint. Subsequently, the contract code itself and its digital fingerprint are deployed to a pre-defined blockchain network through a single transaction. This blockchain can be a consortium blockchain jointly maintained by the platform, cooperating financial institutions, logistics providers, and other parties to ensure data immutability, traceability, and multi-party consensus.

[0125] S609, the deployed smart contract enters the automatic execution and state monitoring phase. To achieve awareness of off-chain real-world events, the smart contract interacts with external systems through a set of trusted data services called "oracles." In this embodiment, at least the following types of oracles are configured: Payment Oracle: An API used to monitor the payment gateway of a platform. When a payment (such as a deposit or prepayment) agreed in a contract is successfully made, the oracle will submit the proof of successful payment and related data to the smart contract.

[0126] Logistics Oracle: A system used to connect with partner logistics service providers, obtain the logistics status of orders in real time, and input key node information such as "picked up", "shipped", and "signed for" as trusted data into smart contracts.

[0127] Platform state oracle: Used to monitor key user actions on the platform. For example, when the buyer clicks the "Confirm Receipt and Acceptance" button on the client, the oracle will notify the smart contract of this confirmation event.

[0128] In the S610, the internal logic of a smart contract is designed as a state machine. Based on data input from the oracle, the contract triggers state transitions and preset operations without manual intervention. For example, a typical execution flow is as follows: 1. The initial status of the contract is "awaiting payment of margin".

[0129] 2. Once the payment oracle reports that the purchaser has successfully paid the deposit, the contract will automatically change its status to "awaiting supplier delivery" and automatically update this status to both parties to the transaction.

[0130] 3. Once the logistics oracle reports that the supplier has completed the shipment operation, the contract status changes to "goods in transit".

[0131] 4. Once the platform status oracle reports that the purchaser has "confirmed receipt and passed acceptance", the contract status will enter "awaiting final payment" and a timer will be started according to the contract terms (e.g., payment within N days after acceptance).

[0132] 5. When the final payment conditions are met, if the contract is granted escrow and transfer rights (for example, the final payment is pre-frozen in the platform's escrow account), the contract will automatically execute the fund transfer instruction to pay the final payment to the supplier.

[0133] In this way, the transaction structure selected by the purchasing user is transformed into automatically executed on-chain rules, thereby securely and efficiently executing the hedging terms of the transaction.

[0134] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A user credit scoring and tiered procurement authority management system for a centralized procurement platform, characterized in that, include: The instant transaction risk assessment module is used to calculate the instant transaction risk index for a purchase request based on the purchase request and the dynamic credit profile of the purchaser user when a purchase request that exceeds the basic credit authorization of the purchaser user is received. The reverse transaction structure generation module is used to generate at least one candidate transaction structure containing additional transaction terms for hedging risk, based on the instantaneous transaction risk index. The collaborative interaction and smart contract module is used to present at least one candidate transaction structure to the purchasing user for selection, and after the purchasing user selects and the relevant parties confirm, generate a smart contract containing the additional transaction terms.

2. The user credit scoring and tiered procurement authority management system for the centralized procurement platform according to claim 1, characterized in that, The instantaneous transaction risk assessment module is specifically used for: The instantaneous transaction risk index is obtained by weighting the risk score of the purchaser obtained by quantifying the dynamic credit profile of the purchaser user and the transaction risk score obtained by quantifying the intrinsic parameters of the purchase request.

3. The user credit scoring and tiered procurement authority management system for the centralized procurement platform according to claim 2, characterized in that, The dynamic credit profile of the purchasing user includes at least one of the following dimensions: Basic credit score, recent activity index, performance stability coefficient, or supply chain network strength.

4. The user credit scoring and tiered procurement authority management system for the centralized procurement platform according to claim 1, characterized in that, The reverse transaction structure generation module is also used for: Before generating the candidate transaction structure, a risk mitigation value is calculated based on the risk preference profile of the candidate supplier users; Calculate the net risk index based on the instantaneous transaction risk index and the risk mitigation value; The reverse transaction structure generation module generates the candidate transaction structure based on the net risk index.

5. The user credit scoring and tiered procurement authority management system for the centralized procurement platform according to claim 4, characterized in that, The risk preference profile of the candidate supplier users includes at least one utility function transformed according to the transaction condition rules defined by the supplier users themselves; The utility function is used to input the purchase request and output whether the purchase request meets the transaction condition rules.

6. The user credit scoring and tiered procurement authority management system for the centralized procurement platform according to claim 4, characterized in that, The reverse transaction structure generation module is specifically used for: The process of generating the candidate transaction structure is formalized as a combinatorial optimization problem. The combinatorial optimization problem aims to minimize the total cost to be borne by the purchaser, provided that the total risk reduction capability of the selected risk hedging instrument combination is not less than the net risk value calculated based on the net risk index, thereby determining the additional transaction terms.

7. The user credit scoring and tiered procurement authority management system for the centralized procurement platform according to claim 6, characterized in that, Also includes: The risk hedging cost pricing module is used to calculate the base price based on the instantaneous transaction risk index and the total order amount, and to calculate the market adjustment coefficient based on the platform's current total risk demand exposure and total risk bearing capacity. The market cost of the risk hedging tool is determined by the base price and the market adjustment coefficient. The total cost is calculated based on the marketization cost.

8. The user credit scoring and tiered procurement authority management system for the centralized procurement platform according to claim 1, characterized in that, The collaborative interaction and smart contract module is specifically used for: On the client interface of the purchasing user, the at least one candidate transaction structure is presented in the form of a comparable list, wherein each candidate transaction structure presents its corresponding supplier information, the additional transaction terms, and the total cost to be paid for executing the additional transaction terms.

9. The user credit scoring and tiered procurement authority management system for the centralized procurement platform according to claim 1, characterized in that, The collaborative interaction and smart contract module is specifically used for: Based on a pre-set smart contract template library, and according to the additional transaction terms included in the candidate transaction structure selected by the purchasing user, the code of the smart contract is automatically generated.

10. A method for user credit scoring and tiered procurement authority management on a centralized procurement platform, based on the system described in any one of claims 1-9, characterized in that, Includes the following steps: When a purchase request that exceeds the basic credit authorization of the purchaser user is received, an instantaneous transaction risk index is calculated for the purchase request based on the purchase request and the dynamic credit profile of the purchaser user. Based on the instantaneous trading risk index, at least one candidate trading structure is generated that includes additional trading terms for hedging risk; At least one candidate transaction structure is presented to the purchasing user for selection, and after the purchasing user makes a selection and the relevant parties confirm, a smart contract containing the additional transaction terms is generated.

Images