Prepaid asset slicing processing method, system and apparatus

Abstract

The disclosure discloses a prepayment asset slicing processing method, system and device. The method comprises: in response to a prepayment request of a user, obtaining an industry classification identifier and a real-time credit risk score of a target merchant; determining an industry risk weight according to the industry classification identifier, and combining the real-time credit risk score and a policy bias constant to calculate a dynamic supervision coefficient; according to the dynamic supervision coefficient, slicing a total amount of prepayment of the user into a supervision deposit asset and a merchant free asset; transferring the supervision deposit asset to a third-party supervision account and transferring the merchant free asset to a merchant free account; and packaging the dynamic supervision coefficient and the fund slicing result for chain storage. Through the scheme, the supervision ratio can be dynamically and adaptively adjusted according to the industry risk and the credit of the merchant, and through chain storage, the supervision decision process can be ensured to be tamper-proof and traceable.

Description

Technical Field

[0001] This disclosure generally pertains to the fintech sector. More specifically, this disclosure relates to a method, system, and apparatus for processing prepaid asset slices. Background Technology

[0002] In the issuance and use of single-purpose prepaid cards (such as gym memberships, beauty salon memberships, and education and training cards), the safety of consumers' prepaid funds has always been a key focus and challenge for regulators.

[0003] Existing solutions typically freeze funds at a fixed percentage, making it impossible to dynamically adjust the percentage based on the differentiated regulatory requirements of the merchant's industry (e.g., 80% freezing for education and only 40% for catering) and the merchant's real-time credit status. Summary of the Invention

[0004] In order to at least address one or more of the technical issues mentioned above, this disclosure proposes a prepaid asset slicing solution in several aspects.

[0005] In the first aspect, this disclosure provides a method for processing prepaid asset slices, including the following steps: In response to a user's prepayment request, obtain the target merchant's industry classification identifier and real-time credit risk score; The industry risk weight is determined based on the industry classification identifier, and the dynamic regulatory coefficient λ is calculated by combining the real-time credit risk score and the policy bias constant, where the value of λ ranges from 0 to 1. Based on the dynamic regulatory coefficient λ, the total amount prepaid by users is divided into regulated escrow assets and merchant-owned assets, wherein the amount of regulated escrow assets is equal to the total amount multiplied by λ, and the amount of merchant-owned assets is equal to the total amount minus the regulated escrow assets. The assets under supervision and custody are transferred to a third-party supervision account, and the merchant's free assets are transferred to the merchant's freely disposable account. The dynamic regulatory coefficient λ and the fund allocation result are packaged and stored on the blockchain for evidence preservation.

[0006] In some embodiments, the method further includes, in response to a user’s consumption confirmation instruction, releasing escrow assets corresponding to the consumption amount from the third-party escrow account to the merchant’s discretionary account.

[0007] In some embodiments, when the user prepayment request involves multiple payment media, the process further includes the following before performing fund allocation: Perform a pre-locking operation on each internal payment medium and obtain the pre-locking status identifier of each internal payment medium; Call each external payment channel to execute pre-deduction and obtain the pre-deduction status identifier of each external payment channel; When all pre-locks and pre-deductions are in a successful state, continue to execute the fund splitting operation; When any pre-lock or pre-deduction fails, a transaction rollback is triggered, releasing all executed pre-locks and pre-deductions.

[0008] In some embodiments, after obtaining the pre-lock status identifiers of each internal payment medium and the pre-deduction status identifiers of the external payment channel, the method further includes: The global transaction hash consensus operator aggregates all pre-locked status identifiers and all pre-deduction status identifiers to generate a global transaction hash value, which is then confirmed by the corresponding nodes in the blockchain network. When the global transaction hash value is confirmed through consensus and all pre-locking and pre-deduction are in a successful state, the fund splitting operation continues.

[0009] In some embodiments, the packaging and on-chain evidence storage is specifically performed using the following hash chain formula: H n = Hash(T_data∥H n-1 (∥Timestamp) Among them, H n The current block hash value is T_data, which contains the parameters and results involved in the splitting. n-1 The hash value is the hash value of the previous block, Timestamp is the timestamp, and ∥ indicates concatenation.

[0010] In some embodiments, the industry risk weight and the real-time credit risk score are obtained through big data analysis, specifically: Obtain historical operating data, historical complaint data, and historical performance data of multiple merchants within the target merchant's industry, and calculate the industry risk weight using a big data analysis model; Obtain the target merchant's historical operating data, historical complaint data, and historical performance data, and calculate the real-time credit risk score using a big data analysis model.

[0011] In some embodiments, when the calculation result of the dynamic monitoring coefficient λ deviates from the preset threshold range, an early warning is triggered and the monitoring end is notified to conduct manual review.

[0012] In some embodiments, the dynamic regulatory coefficient λ is calculated using a weighted summation model: λ = σ(W1·H + W2·S + L) Wherein, H is the industry risk weight, S is the real-time credit risk score, L is the policy bias constant, W1 and W2 are preset weight coefficients and W1+W2=1, and σ is the activation function that maps the input value to the interval [0,1].

[0013] In the second aspect, this disclosure provides a prepaid asset slicing processing system, including: processor; Memory, which stores computer programs; When the processor executes the computer program, it implements the method as described in the first aspect.

[0014] In the third aspect, this disclosure provides a prepaid asset slicing processing device, comprising: The acquisition module is used to respond to a user's prepayment request by obtaining the target merchant's industry classification identifier and real-time credit risk score; The calculation module is used to determine the industry risk weight based on the industry classification identifier, and calculate the dynamic regulatory coefficient λ by combining the real-time credit risk score and the policy bias constant, where the value of λ ranges from 0 to 1. The slicing module is used to divide the total amount prepaid by the user into escrow assets and merchant-owned assets according to the dynamic regulatory coefficient λ, wherein the amount of escrow assets is equal to the total amount multiplied by λ, and the amount of merchant-owned assets is equal to the total amount minus the escrow assets. The allocation module is used to transfer the regulated assets to a third-party regulated account and the merchant's free assets to a merchant's freely disposable account. The evidence storage module is used to package the dynamic regulatory coefficient λ and the fund allocation result and store them on the blockchain for evidence storage.

[0015] By utilizing the prepaid asset slicing method, system, and apparatus provided above, this disclosed embodiment obtains merchant industry classifications and real-time credit risk scores, combines these with policy biases to calculate a dynamic regulatory coefficient λ in real time, and allocates funds accordingly. This enables the regulatory ratio to dynamically and adaptively adjust based on industry risk and merchant credit. Furthermore, by storing λ and the fund allocation results on the blockchain, the immutability and traceability of the regulatory decision-making process can be ensured. Moreover, by performing pre-locking and transaction rollback when multiple payment media are used interchangeably, the atomicity of cross-media transactions and accounting consistency can be guaranteed. Attached Figure Description

[0016] The above and other objects, features, and advantages of exemplary embodiments of this disclosure will become readily apparent upon reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this disclosure are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein: Figure 1 An exemplary scenario in which embodiments of this disclosure can be applied is shown; Figure 2 An exemplary flowchart of a prepaid asset slicing method according to some embodiments of this disclosure is shown; Figure 3 A schematic diagram of a prepaid asset slicing processing device 300 is shown. Detailed Implementation

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

[0018] It should be understood that the terms “comprising” and “including” used in this disclosure and claims indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0019] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. As used in this disclosure and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this disclosure and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0020] As used in this specification and claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0021] The specific embodiments disclosed herein will now be described in detail with reference to the accompanying drawings.

[0022] Figure 1 An exemplary scenario in which embodiments of this disclosure can be applied is shown.

[0023] like Figure 1 As shown, this application scenario includes at least: users, merchants, regulatory platforms, and financial institutions.

[0024] Users access the regulatory platform 103 through applications installed on user terminal 101 (such as Alipay mini-program or the regulatory platform's own app), browse prepaid card products published by merchants on the platform, select the target product, initiate a prepayment request, and complete the payment.

[0025] Merchants access the regulatory platform 103 through merchant terminal 102, complete registration and qualification review on the platform, and publish prepaid card products (such as "10 gym sessions, 5,000 yuan").

[0026] The regulatory platform 103 provides end-to-end services including front-end display, transaction processing, and fund transfer. In response to a user's prepayment request, the platform obtains the merchant's industry classification identifier and real-time credit risk score. Based on the industry classification identifier, it determines the corresponding industry risk weight and calculates a dynamic regulatory coefficient by combining the real-time credit risk score and policy bias constant. Based on the dynamic regulatory coefficient, it performs a fund allocation operation, dividing the total prepayment amount into regulatory custody assets and merchant-owned assets, and generating separate fund transfer instructions to financial institutions.

[0027] Financial institution 104, based on the fund transfer instructions sent by regulatory platform 103, deposits the regulated assets into the merchant's corresponding third-party regulatory account (provided by a bank, trust institution, or notary office) and transfers the merchant's free assets to the merchant's freely disposable account.

[0028] When a user makes a purchase at the store, they send a purchase confirmation instruction to the regulatory platform 103 through the user terminal 101. In response to the instruction, the regulatory platform 103 notifies the financial institution 104 to release the regulatory custody assets corresponding to the purchase amount from the third-party regulatory account to the merchant's discretionary account.

[0029] The regulatory platform 103 will also package the dynamic regulatory coefficient and the fund allocation results and store them on the blockchain for verification in case of subsequent audits or disputes.

[0030] Figure 2 An exemplary flowchart illustrating a prepaid asset slicing method according to some embodiments of this disclosure is shown. Figure 2As shown, the method 200 includes: step S201, in response to a user's prepayment request, obtaining the target merchant's industry classification identifier and real-time credit risk score; step S202, determining the industry risk weight based on the industry classification identifier, and calculating the dynamic regulatory coefficient λ by combining the real-time credit risk score and the policy bias constant, where the value of λ ranges from 0 to 1; step S203, based on the dynamic regulatory coefficient λ, dividing the total amount of the user's prepayment into escrow assets and merchant-owned assets, wherein the amount of escrow assets is equal to the total amount multiplied by λ, and the amount of merchant-owned assets is equal to the total amount minus the escrow assets; step S204, transferring the escrow assets to a third-party escrow account, and transferring the merchant-owned assets to a merchant-owned discretionary account; step S205, packaging the dynamic regulatory coefficient λ and the fund allocation result onto the blockchain for evidence storage.

[0031] By acquiring merchant industry classifications and real-time credit risk scores, and combining these with policy biases to calculate a dynamic regulatory coefficient λ in real time, and allocating funds accordingly, the regulatory ratio can be dynamically and adaptively adjusted according to industry risk and merchant credit. Furthermore, by storing λ and the fund allocation results on the blockchain, the regulatory decision-making process can be ensured to be tamper-proof and traceable.

[0032] In step S201, the user browses prepaid card products published by merchants on the regulatory platform through their user terminal, selects a target product, and initiates a prepayment request. This prepayment request includes at least the user identifier, merchant identifier, and prepayment amount. Upon receiving the prepayment request, the regulatory platform obtains the target merchant's industry classification identifier and real-time credit risk score based on the merchant identifier.

[0033] Specifically, when merchants register on the regulatory platform, they select their industry category (such as education and training, fitness, catering, beauty and hairdressing, etc.) from the industry classification options provided by the platform based on their actual business operations. The regulatory platform then determines the merchant's industry category identifier and stores it in the rules database. When a user initiates a prepayment request, the regulatory platform retrieves the merchant's industry category identifier from the rules database based on the merchant identifier. This industry category identifier is used to determine the merchant's industry category, such as education and training, fitness, catering, beauty and hairdressing, etc.

[0034] Simultaneously, the regulatory platform obtains the merchant's real-time credit risk score. This real-time credit risk score is generated and provided by a credit assessment system to quantitatively evaluate the merchant's current ability to fulfill obligations and their creditworthiness. The credit assessment system can be a third-party credit assessment system independent of the regulatory platform (such as Sesame Credit, Baihang Credit, or other third-party credit reporting agencies), or it can be a credit evaluation module built into the regulatory platform. The credit assessment system calculates the credit risk score in real-time or periodically based on one or more of the following factors: the merchant's complaint rate (such as complaint data from the 12315 platform or government complaint channels), abnormal business records (such as whether the merchant is listed in the abnormal business directory by the market supervision department), administrative penalty records (such as whether there have been administrative penalties in the past 12 months), registered capital size, duration of operation (operating time calculated from the date of registration), number of employees paying social security, etc. These factors can be used individually or in combination, and the credit risk score is calculated comprehensively by the credit assessment system according to a preset weighted algorithm or machine learning model.

[0035] In one example, the target merchant is a fitness institution. The credit assessment system calculates a real-time credit risk score of 25 out of 100 based on factors such as the merchant's complaint rate over the past 6 months (3 complaints / 1000 orders), no abnormal business records, registered capital of 2 million yuan, and duration of existence of 5 years. This indicates that the merchant has a low credit risk.

[0036] In another example, the target merchant is an educational training institution. Due to a recent administrative penalty record and a high complaint rate, the real-time credit risk score calculated by the credit assessment system is 82 points (out of 100), indicating that the merchant has a high credit risk.

[0037] In step S202, the regulatory platform first determines the industry risk weight corresponding to the target merchant's industry based on the industry classification identifier obtained in step S201. The industry risk weight is pre-set and stored in a rules database by the regulatory platform or a third-party platform based on the inherent risk level of prepaid card business in each industry. Different industries correspond to different risk weight values; for example, education is high risk, fitness is relatively high risk, catering is medium risk, and retail is relatively low risk. The industry risk weight can be adjusted periodically or in real-time by the regulatory platform based on industry development and risk trends.

[0038] In some examples, the regulatory platform combines the real-time credit risk score obtained in step S201 with the current policy bias constant to calculate the dynamic regulatory coefficient λ according to the following weighted summation model: Z = W1·H + W2·S + L; λ = σ(Z); Wherein, W1 and W2 are preset weighting coefficients and W1+W2=1, used to adjust the relative importance of industry risk weight H and merchant real-time credit risk score S in the final regulatory ratio, respectively; L is a policy bias constant, which is dynamically configured by the regulatory platform according to the current policy orientation, and its value range can be, for example, [-0.1, 0.1], with positive values ​​indicating stricter regulation and negative values ​​indicating relaxed regulation; σ is an activation function, such as the Sigmoid activation function, used to map the weighted input value Z to the interval between 0 and 1, ensuring that the output λ is always an effective regulatory ratio.

[0039] In one example, a fitness industry merchant has an industry risk weight H of 0.7, a real-time credit risk score S of 0.65, is currently in a special rectification period, has a policy bias constant L of +0.05, and preset weight coefficients W1=0.7 and W2=0.3. Then: Z = 0.7×0.7 + 0.3×0.65 + 0.05 = 0.735; λ = σ(0.735) ≈ 67.6%; That is, approximately 67.6% of the funds in this prepayment transaction should be frozen in a regulatory account.

[0040] In a preferred embodiment, the industry risk weight and the real-time credit risk score can be obtained through big data analytics. Specifically, the regulatory platform or credit assessment system acquires historical operating data, historical complaint data, and historical performance data of multiple merchants within the target merchant's industry, and calculates the industry risk weight using a big data analytics model, ensuring that the weight reflects the overall risk level of the industry. Simultaneously, it acquires the target merchant's own historical operating data, historical complaint data, and historical performance data, and calculates the real-time credit risk score using a big data analytics model, ensuring that the real-time credit risk score reflects the individual merchant's creditworthiness. The big data analytics model can be implemented using at least one of the following: logistic regression model, random forest model, gradient boosting decision tree model, or neural network model.

[0041] The policy bias constant is an adjustment range that a regulatory platform adds or subtracts to implement specific macroeconomic or industry control policies. Its value typically ranges from -10% to +10%. For example, when tightening control over the prepaid card market, the policy bias constant can be set to a positive value (e.g., +5%), automatically increasing the regulatory ratio for all industries by 5 percentage points. When supporting industry development, the policy bias constant can be set to a negative value (e.g., -3%), automatically decreasing the regulatory ratio for all industries by 3 percentage points. When there is no specific policy control need, the policy bias constant is set to 0. The core value of this parameter lies in its ability to quickly respond to policy changes without modifying the risk weights of each industry; by adjusting a single global bias constant, it achieves a shift from "industry-by-industry adjustment" to "one-click control."

[0042] In step S203, the regulatory platform, based on the dynamic regulatory coefficient λ calculated in step S202, divides the total amount prepaid by the user, A_total, into regulated assets A_reg and merchant-owned assets A_free. Wherein: The value of assets under supervision and custody is A_reg = A_total × λ; Merchant's free assets A_free = A_total - A_reg.

[0043] The total amount prepaid by users, A_total, is the amount actually paid by the user, excluding discounts and deductions. The escrow assets, A_reg, are the frozen amount that should be deposited into a third-party escrow account, and the merchant's free assets, A_free, are the amount that can be allocated to the merchant's freely disposable account.

[0044] Using the example above, if the user's actual prepayment amount is 5,000 yuan, then the regulated escrow asset A_reg = 5,000 × 67.6% = 3,380 yuan, and the merchant's free asset A_free = 5,000 - 3,380 = 1,620 yuan.

[0045] In step S204, the regulatory platform generates fund transfer instructions to financial institutions based on the segmentation results of step S203. Each transfer instruction includes at least the merchant identifier, the transfer amount, and the target account information. The financial institution executes the fund transfer operation according to the instructions: depositing the regulated assets into the corresponding third-party regulated account (provided by a bank, trust institution, or notary office), and transferring the merchant's freely disposable assets to the merchant's freely disposable account. The third-party regulated account is independent of the merchant's freely disposable account, and the merchant has no right to directly transfer funds from this account.

[0046] In step S205, the regulatory platform packages the dynamic regulatory coefficient λ and the fund allocation results (including the amount of assets under regulatory custody and the amount of assets owned by merchants) calculated for this transaction into data blocks and stores them through the blockchain network.

[0047] In one embodiment, the on-chain storage of the packaged evidence is achieved using the following hash chain formula: H n = Hash(T_data ∥ H n-1 ∥ Timestamp); Among them, H n T_data represents the hash value of the current block, and T_data represents the parameters and results involved in the splitting (including λ, A_reg, A_free, H, S, L, W1, W2, etc.). n-1 `hash` represents the hash value of the previous block, `Timestamp` represents the current timestamp, and `∥` indicates the data concatenation operation. Using this hash chain notation method, any tampering with historical data will cause the hash chain to break, thus ensuring the security and immutability of the notified data.

[0048] In some embodiments, when the calculation result of the dynamic monitoring coefficient λ deviates from the preset threshold range, an early warning is triggered and the monitoring end is notified to conduct manual review.

[0049] Specifically, the dynamic regulatory coefficient λ, as the regulatory ratio, should have an effective value range of 0 to 1. Although the activation function used in this disclosure can map the input value to the [0,1] interval, ensuring that λ will not exceed the limit under normal calculation conditions, in actual operation, if there are situations such as incorrect parameter configuration, abnormal data source, accidental modification of model parameters, or internal system overflow, the calculation result of λ may still exceed the effective range. The above situations indicate that the system is in an abnormal operating state, and continuing to rely on this abnormal result to execute business processes will lead to improper supervision (λ<0 is equivalent to allowing merchants to use funds beyond the limit, and λ>1 is equivalent to requiring the freezing of funds exceeding the actual payment amount by the user, neither of which is reasonable).

[0050] When the system detects λ < 0 or λ > 1, it automatically triggers an early warning and sends an early warning notification to the regulatory authority. The early warning notification includes at least the merchant's identifier, the current λ value, the actual values ​​of all parameters involved in the calculation (including H, S, L, W1, W2), and the trigger time. Upon receiving the early warning notification, regulatory personnel manually review it, checking for any anomalies in the parameter configuration or data source. Based on the review results, they correct the relevant configurations and recalculate λ, or suspend the merchant's prepaid transactions until the system returns to normal.

[0051] Through the above mechanism, human intervention can be introduced in a timely manner when anomalies occur in the calculation process, so as to avoid inappropriate supervision due to data anomalies or model deviations and ensure the reliability of system operation.

[0052] In some embodiments, the method further includes, in response to a user’s consumption confirmation instruction, releasing escrow assets corresponding to the consumption amount from the third-party escrow account to the merchant’s discretionary account.

[0053] Specifically, when a user arrives at the store to receive services or pick up goods, the merchant initiates a verification request through the merchant terminal. This verification request includes at least the user's identifier, the merchant's identifier, the amount of the transaction, and order information. The user confirms the transaction through their user terminal, generating a transaction confirmation instruction. This transaction confirmation instruction can be triggered in various ways, including but not limited to: manual confirmation by the user after scanning the verification code at the merchant terminal, and automatic confirmation by the user after completing service receipt through biometric identification (such as fingerprint recognition or facial recognition).

[0054] Upon receiving a consumption confirmation instruction, the regulatory platform first verifies whether the user's remaining spending credit is sufficient. If the remaining spending credit is sufficient, the regulatory platform calculates the amount of escrow assets to be released based on the consumption amount and the dynamic regulatory coefficient λ corresponding to the prepaid transaction (i.e., λ locked when the user placed the order). The amount to be released equals the consumption amount multiplied by λ. The regulatory platform then sends a fund release instruction to the financial institution, which includes at least the merchant identifier, the release amount, the third-party escrow account identifier, and the transaction serial number. The financial institution, based on this instruction, transfers the corresponding amount from the merchant's third-party escrow account to the merchant's discretionary account. If the remaining spending credit is insufficient, the regulatory platform releases the remaining escrow assets in full. The user must make up the shortfall by paying the merchant through other payment methods; the regulatory platform does not participate in the transfer of these funds.

[0055] After the funds are released, the regulatory platform updates the balance of the user's corresponding regulated assets and packages the relevant information of this release operation (including the release amount, release time, source of consumption confirmation instruction, remaining balance of regulated assets, etc.) onto the blockchain for evidence storage, ensuring that the consumption verification process is traceable and tamper-proof.

[0056] The aforementioned consumption verification and fund release mechanism ensures that prepaid funds are only transferred to merchants after the user actually makes a purchase, preventing merchants from obtaining all funds in advance without providing services, thereby protecting consumers' funds.

[0057] In some embodiments, when the user prepayment request involves multiple payment media, before executing the fund splitting, the method further includes: performing a pre-locking operation on each internal payment media to obtain the pre-locking status identifier of each internal payment media; calling each external payment channel to perform pre-deduction to obtain the pre-deduction status identifier of each external payment channel; continuing to execute the fund splitting operation when all pre-locking and pre-deduction are in a successful state; and triggering a transaction rollback when any pre-locking or pre-deduction is in a failed state to release all executed pre-locking and pre-deduction.

[0058] Specifically, when the user's prepayment request involves multiple payment methods, meaning that the prepayment transaction requires the simultaneous combination of at least two different types of payment methods from various sources to complete the fund collection, these multiple payment methods can be internal payment methods such as internal account balances and platform virtual assets, as well as external payment channels such as third-party bank cards and third-party payment channels. Before executing the fund splitting, the following processing steps are also included.

[0059] Perform a pre-locking operation on each internal payment medium to obtain the pre-locking status identifier for each internal payment medium. The pre-locking operation is used to mark the funds of the corresponding transaction amount in the internal payment medium as occupied, but does not directly deduct the actual balance of funds in the medium. The pre-locking status identifier includes at least different status types such as pre-locking successful, insufficient pre-locking balance, medium status abnormality, and pre-locking timeout.

[0060] The system invokes various external payment channels to execute pre-deductions and obtains the pre-deduction status identifiers for each channel. Pre-deduction by an external payment channel involves initiating a transaction pre-authorization request to the external payment gateway, whereby the external payment institution pre-authorizes and freezes the transaction funds in the user's account. The pre-deduction status identifier records the processing results returned by the external channels, including result types such as successful pre-deduction, channel call failure, insufficient user account balance, user authentication failure, and external channel response timeout.

[0061] When all pre-locking and pre-deductions are successful, the fund splitting operation continues. Only when all internal media pre-locking results and all external channel pre-deduction results are successful simultaneously does it mean that all funding sources for this combined prepayment transaction have sufficient available funds, the transaction pre-verification is passed, and the subsequent fund splitting and transfer process begins.

[0062] When any pre-lock or pre-deduction fails, a transaction rollback is triggered, releasing all executed pre-locks and pre-deductions. Specifically, if any internal payment medium's pre-lock fails, or any external payment channel's pre-deduction fails, regardless of whether the pre-locks or pre-deductions of the remaining payment mediums are successful, the combined pre-payment pre-verification is deemed to have failed, and the distributed transaction rollback logic is initiated: iterating through all internal payment mediums that have completed pre-locks, canceling the corresponding fund occupation markers, and releasing the occupied fund amount; simultaneously, sending a pre-authorization revocation instruction to the corresponding external payment channel to release the pre-deduction freeze already completed on the external side, restoring each payment medium to its original state before the transaction was initiated, thus avoiding the problem of some medium funds being abnormally occupied while the actual transaction was not completed, resulting in financial losses.

[0063] In some embodiments, after obtaining the pre-lock status identifiers of each internal payment medium and the pre-deduction status identifiers of the external payment channel, the method further includes: aggregating all pre-lock status identifiers and all pre-deduction status identifiers through a global transaction hash consensus operator to generate a global transaction hash value, and having the corresponding nodes in the blockchain network perform consensus confirmation on the global transaction hash value; when the global transaction hash value is confirmed through consensus and all pre-locks and pre-deductions are in a successful state, the fund splitting operation continues.

[0064] Specifically, after obtaining the pre-lock status identifiers corresponding to each internal payment medium and the pre-deduction status identifiers corresponding to each external payment channel, this method also adds a blockchain-based global transaction consensus verification process. This decentralized consensus mechanism ensures the authenticity of the status, the immutability of the data, and the consistency of the transaction in multi-medium combined prepayment transactions. The specific execution steps are as follows: The system retrieves all pre-lock status identifiers and pre-deduction status identifiers corresponding to this prepayment transaction, and extracts transaction fields such as the unique identifier of each payment medium, transaction amount, timestamp, and transaction serial number. These, along with the aforementioned status identifiers, are then used in subsequent hash aggregation calculations. Based on this, through a preset global transaction hash consensus logic, all pre-lock status identifiers, pre-deduction status identifiers, and associated transaction fields are batch-aggregated and cryptographically hashed to uniformly generate a unique and irreversible global transaction hash value.

[0065] The global transaction hash consensus logic employs a segmented encrypted aggregation algorithm. This algorithm sequentially concatenates, deduplicates, and performs unified hash compression on multiple sets of dispersed internal media pre-lock status identifiers, external channel pre-deduction status identifiers, and corresponding transaction fields. This ensures that each set of status identifiers and transaction fields participates in the aggregation calculation, and that different data combinations correspond to a unique global transaction hash value. This effectively avoids problems such as data tampering, data omissions, and abnormal status matching. After the hash value is generated, the system broadcasts the global transaction hash value, carrying all status identifiers and transaction field information for this transaction, to the pre-defined consensus nodes in the blockchain network. These pre-defined consensus nodes are trusted nodes pre-deployed on the sides of government regulatory agencies, financial institutions, and the regulatory platform itself. Each trusted node performs distributed consensus confirmation of the global transaction hash value.

[0066] The specific consensus confirmation process can be as follows: Each blockchain node independently performs hash recalculation on the received status identifier and transaction field, compares and verifies the locally recalculated hash value with the global transaction hash value generated by the system, and when all consensus nodes in the network verify the same result and reach a valid consensus, the global transaction hash value is determined to be confirmed through blockchain consensus; if there is node inconsistency, data abnormality or consensus timeout, the hash consensus verification is determined to fail and the subsequent transaction process is suspended.

[0067] In this embodiment, the optimized transaction execution judgment logic employs a dual verification mechanism, no longer relying solely on local state verification. Only when the global transaction hash value is successfully confirmed through blockchain network consensus, and all internal payment medium's pre-lock status identifiers and all external payment channel's pre-deduction status identifiers are in a successful state, is the pre-verification of this multi-medium prepayment transaction deemed fully compliant, the status identifiers genuine and valid, and the data traceable. Only then can the system continue to execute subsequent fund splitting operations. This approach, leveraging the immutable and distributed consensus characteristics of blockchain technology, solves the technical problems of easily forged local status identifiers, difficulty in transaction traceability, and inconsistent states across multiple terminals in traditional multi-payment medium transactions, significantly improving the security and credibility of combined prepayment transactions.

[0068] This disclosure also provides a prepaid asset slicing processing system. This system can be used to execute the prepaid asset slicing processing method of any of the foregoing embodiments, and possesses full-process processing capabilities including transaction preprocessing, asset verification, dynamic slicing, fund allocation, blockchain notarization, and anomaly rollback. The system includes a processor and a memory. The memory is a readable storage medium that internally stores computer programs executable on the processor, as well as preset rule databases, hash consensus operators, regulatory coefficient models, and other core program logic. When the processor calls and executes the computer program stored in the memory, it can implement all steps of the prepaid asset slicing processing method as described in any of the foregoing method embodiments, accurately completing a series of operations such as pre-verification of multi-media prepaid transactions, state aggregation consensus, fund slicing, targeted fund allocation, transaction data notarization, and anomaly rollback.

[0069] In a preferred embodiment, the system is deployed on an independent regulatory platform, distinct from the merchant, user, and financial institution business systems. It possesses independent regulatory and data verification permissions, enabling isolated control of transaction operations and regulatory audits. This regulatory platform system establishes encrypted communication connections with user terminals, merchant terminals, and financial institution business systems, enabling real-time multi-terminal data interaction, secure transmission of transaction instructions, and synchronous verification of transaction status.

[0070] In the specific business execution process, users can fill in prepayment transaction information, select payment medium, and initiate a prepayment asset transaction request through their user terminals. The user terminals then encrypt and upload standardized prepayment request messages to the regulatory platform. Subsequently, the processor on the regulatory platform side responds to the terminal request, calls and executes the computer program in the memory, and sequentially executes steps S201 to S205 in the aforementioned method embodiment. Specifically, it completes core operations such as transaction parameter parsing, dynamic regulatory coefficient calculation, multi-payment medium pre-locking and pre-deduction verification, global transaction hash consensus confirmation, compliant fund dynamic allocation, cross-terminal fund targeted transfer, and on-chain storage of transaction data throughout the entire process.

[0071] This deployment architecture relies on the neutrality and authority of the regulatory platform to conduct compliant control and traceability of the entire process of users' prepaid funds. It effectively avoids problems such as fund misallocation, inconsistent transaction status, abnormal fund occupation, and transaction data tampering that occur in multi-media combined payment scenarios. It realizes standardized, secure, and traceable processing of prepaid asset transactions and improves the standardization and transaction security of prepaid asset slicing.

[0072] Figure 3 A schematic diagram of a prepaid asset slicing processing device 300 is shown. Figure 3As shown, the device 300 includes: an acquisition module 301, used to acquire the industry classification identifier and real-time credit risk score of the target merchant in response to the user's prepayment request; a calculation module 302, used to determine the industry risk weight based on the industry classification identifier, and calculate the dynamic regulatory coefficient λ by combining the real-time credit risk score and the policy bias constant, wherein the value of λ ranges from 0 to 1; a slicing module 303, used to slice the total amount of the user's prepayment into escrow assets and merchant-owned assets based on the dynamic regulatory coefficient λ, wherein the amount of escrow assets is equal to the total amount multiplied by λ, and the amount of merchant-owned assets is equal to the total amount minus the escrow assets; an allocation module 304, used to allocate the escrow assets to a third-party escrow account and the merchant-owned assets to a merchant-owned discretionary account; and an evidence storage module 305, used to package the dynamic regulatory coefficient λ and the fund slicing result and store them on the blockchain for evidence storage.

[0073] The specific operational details performed by each module correspond one-to-one with the corresponding steps in the aforementioned method embodiments, and will not be repeated here.

[0074] Those skilled in the art will understand that the above-mentioned modules may be software modules running on computing devices, dedicated processing units implemented by hardware circuits, or a combination of software and hardware implementations.

[0075] While numerous embodiments of this disclosure have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Many modifications, alterations, and alternatives will occur to those skilled in the art without departing from the spirit and intent of this disclosure. It should be understood that various alternatives to the embodiments of this disclosure described herein may be employed in the practice of this disclosure. The appended claims are intended to define the scope of this disclosure and therefore cover equivalents or alternatives within the scope of these claims.

Claims

1. A method for processing prepaid asset slices, characterized in that, Includes the following steps: In response to a user's prepayment request, obtain the target merchant's industry classification identifier and real-time credit risk score; The industry risk weight is determined based on the industry classification identifier, and the dynamic regulatory coefficient λ is calculated by combining the real-time credit risk score and the policy bias constant, where the value of λ ranges from 0 to 1. Based on the dynamic regulatory coefficient λ, the total amount prepaid by users is divided into regulated escrow assets and merchant-owned assets, wherein the amount of regulated escrow assets is equal to the total amount multiplied by λ, and the amount of merchant-owned assets is equal to the total amount minus the regulated escrow assets. The assets under supervision and custody are transferred to a third-party supervision account, and the merchant's free assets are transferred to the merchant's freely disposable account. The dynamic regulatory coefficient λ and the fund allocation result are packaged and stored on the blockchain for evidence preservation.

2. The method according to claim 1, characterized in that, It also includes the following steps: In response to the user's consumption confirmation instruction, the escrow assets corresponding to the consumption amount are released from the third-party escrow account to the merchant's discretionary account.

3. The method according to claim 1, characterized in that, When the user's prepayment request involves multiple payment media, the process before fund allocation also includes: Perform a pre-locking operation on each internal payment medium and obtain the pre-locking status identifier of each internal payment medium; Call each external payment channel to execute pre-deduction and obtain the pre-deduction status identifier of each external payment channel; When all pre-locks and pre-deductions are in a successful state, continue to execute the fund splitting operation; When any pre-lock or pre-deduction fails, a transaction rollback is triggered, releasing all executed pre-locks and pre-deductions.

4. The method according to claim 3, characterized in that, After obtaining the pre-lock status indicators of each internal payment medium and the pre-deduction status indicator of the external payment channel, the method further includes: The global transaction hash consensus operator aggregates all pre-locked status identifiers and all pre-deduction status identifiers to generate a global transaction hash value, which is then confirmed by the corresponding nodes in the blockchain network. When the global transaction hash value is confirmed through consensus and all pre-locking and pre-deduction are in a successful state, the fund splitting operation continues.

5. The method according to claim 1, characterized in that, The packaging and on-chain evidence storage is specifically performed using the following hash chain formula: H n = Hash(T_data∥H n-1 ∥Timestamp) Among them, H n The current block hash value is T_data, which contains the parameters and results involved in the splitting. n-1 The hash value is the hash value of the previous block, Timestamp is the timestamp, and ∥ indicates concatenation.

6. The method according to claim 1, characterized in that, The industry risk weights and the real-time credit risk scores are obtained through big data analysis, specifically: Obtain historical operating data, historical complaint data, and historical performance data of multiple merchants within the target merchant's industry, and calculate the industry risk weight using a big data analysis model; Obtain the target merchant's historical operating data, historical complaint data, and historical performance data, and calculate the real-time credit risk score using a big data analysis model.

7. The method according to claim 1, characterized in that, When the calculated result of the dynamic monitoring coefficient λ deviates from the preset threshold range, an early warning is triggered and the monitoring end is notified to conduct a manual review.

8. The method according to claim 1, characterized in that, The dynamic regulatory coefficient λ is calculated using a weighted summation model: λ = σ(W1·H + W2·S + L) Wherein, H is the industry risk weight, S is the real-time credit risk score, L is the policy bias constant, W1 and W2 are preset weight coefficients and W1+W2=1, and σ is the activation function that maps the input value to the interval [0,1].

9. A prepaid asset slicing processing system, characterized in that, include: processor; Memory, which stores computer programs; When the processor executes the computer program, it implements the method as described in any one of claims 1-8.

10. A prepaid asset slicing processing device, characterized in that, include: The acquisition module is used to respond to a user's prepayment request by obtaining the target merchant's industry classification identifier and real-time credit risk score; The calculation module is used to determine the industry risk weight based on the industry classification identifier, and calculate the dynamic regulatory coefficient λ by combining the real-time credit risk score and the policy bias constant, where the value of λ ranges from 0 to 1. The slicing module is used to divide the total amount prepaid by the user into escrow assets and merchant-owned assets according to the dynamic regulatory coefficient λ, wherein the amount of escrow assets is equal to the total amount multiplied by λ, and the amount of merchant-owned assets is equal to the total amount minus the escrow assets. The allocation module is used to transfer the regulated assets to a third-party regulated account and the merchant's free assets to a merchant's freely disposable account. The evidence storage module is used to package the dynamic regulatory coefficient λ and the fund allocation result and store them on the blockchain for evidence storage.

Images