Data management system and method of supply chain finance platform

Abstract

The application relates to the technical field of supply chain finance, and particularly discloses a data management system and method of a supply chain finance platform, which collects source storage data sets; obtains unique data fingerprints through recursive hash mapping, and encapsulates the unique data fingerprints, payment conditions and financing thresholds as an automatic constraint field set; through recursive truncation comparison of a delivery timestamp and reverse recursive operation of a logistics node coding path, double-layer recursive verification of trade background authenticity is completed, and verified trade data packets are generated; the data packets are input into a state machine, a bond confirmation signal is obtained through cyclic redundancy iteration amplification, and fund clearing instruction parameters are generated in combination with clearing channel coding; according to the bond confirmation signal, the total amount of the bill is disturbed and replaced and is cut according to bits, the creditor's rights certificate is split into multiple transferable sub-certificates carrying hierarchical constraint marks, and a loan request is sent; the application does not need core enterprise authentication, and realizes automatic closed-loop verification of a financing process and splitting and transfer of creditor's rights.

Description

Technical Field

[0001] This invention relates to the field of supply chain finance technology, specifically to a data management system and method for a supply chain finance platform. Background Technology

[0002] In supply chain finance, financing activities between core enterprises and their upstream and downstream partners typically rely on verifying the authenticity of the trade background. In traditional supply chain finance models, lenders require core enterprises to confirm accounts receivable or orders to verify the authenticity of the trade background and thus reduce financing risk.

[0003] Under the premise that the core enterprise does not provide direct confirmation of rights and does not occupy its own credit line, how to transform the order data, logistics data and invoice data generated in the supply chain transactions into a recursive verification chain that can prove authenticity, and on this basis realize the automatic triggering of financing conditions and the hierarchical splitting and circulation of debt instruments. Summary of the Invention

[0004] The purpose of this invention is to provide a data management system and method for a supply chain finance platform to solve the problems mentioned above.

[0005] The objective of this invention can be achieved through the following technical solutions: A data management method for a supply chain finance platform includes the following steps: S1: Collect order data, logistics data, and invoice data between the enterprise and its upstream and downstream enterprises, and then store the collected order data, logistics data, and invoice data with timestamps into the blockchain evidence storage network to form a traceable source evidence dataset. S2: Perform hash mapping on the source evidence dataset to generate unique data fingerprints for each data unit, and combine the data fingerprints with preset payment conditions and financing trigger thresholds to encapsulate them into a set of automated constraint fields driven by a state machine. S3: In response to the establishment of the set of automated constraint fields, the data fingerprint is compared with the trade execution message in real time. When the key status in the trade execution message matches the constraint field in the data fingerprint, a two-layer recursive verification of the authenticity of the trade background is triggered, and a verified trade data packet is generated. S4: Input the verified trade data packet into the state machine. The state machine outputs a bond confirmation signal that meets the lending conditions and the corresponding fund clearing instruction parameters according to the internally preset debt transfer rules. S5: Based on the bond confirmation signal and fund clearing instruction parameters, automatically send a loan request to the funding party interface, and after the loan is successfully disbursed, split the debt certificate into multiple liquid transferable certificates according to the hierarchical relationship in the order data, thus completing the automated closed loop of the financing process.

[0006] As a further aspect of the present invention: S2 specifically includes: Concatenate the timestamp, content byte sequence, and hash remainder of the previous data unit in the source evidence dataset for each data unit. A recursive hash operation is performed on the concatenated result. In each recursion, the hash value of the previous output is used as the initial vector for the next input. After a preset number of iterations, a fixed-length bit string is extracted as the unique data fingerprint of the data unit.

[0007] As a further aspect of the present invention: the encapsulation as a set of automated constraint fields based on state machine driving specifically includes: The data fingerprint is split into a high-bit verification segment and a low-bit trigger segment. The payment conditions are converted into a condition threshold mask, and the financing trigger threshold is converted into a comparison benchmark value. Then, the condition threshold mask and the comparison benchmark value are bit-interleaved and XORed with the high-bit verification segment to generate a constraint verification head. The low-bit trigger segment is used as the step trigger pulse parameter of the state machine.

[0008] As a further aspect of the present invention: S3 specifically includes: The first layer of verification extracts a preset time window hash string from the data fingerprint and compares it with the carrier timestamp in the trade execution message using binary interval recursive truncation. After confirming that the intermediate value of each recursive output is consistent with the suffix of the time window hash string, it proceeds to the second layer of verification. The second layer of verification involves splitting the logistics node location code in the trade execution message into a path prefix and a path suffix. Using the path prefix as the initial vector and the path suffix as the iteration step size, a reverse recursive operation is performed on the logistics trajectory hash in the data fingerprint until the output value returns to zero, thus generating a verified trade data packet.

[0009] As a further aspect of the present invention: the generation of the verified trade data packet specifically includes: Extract the first group of fixed bytes that appear consecutively in the logistics node location code as the path prefix, and reassemble the remaining bytes into a path suffix sequence after being separated by commas. The path prefix is ​​used as the initial recursive carrier, and each element in the path suffix sequence is used as the variable step size for single-step recursion. After performing a bitwise reverse operation on the logistics trajectory hash in the data fingerprint, the system cyclically shifts to the right based on the current stride length value, and then performs a bitwise AND-NOT operation on the right shift result and the initial recursive carrier. The result is used as the input value for the next recursion. The process continues until the output value reaches zero, at which point a verified trade data packet is generated.

[0010] As a further aspect of the present invention: S4 specifically includes: The verified trade data packets are parsed into trade amount values, payment node identifiers, and thresholds for the number of debt transfers. Using the threshold for the number of debt transfers as an offset, extract the corresponding loan disbursement condition threshold and clearing channel code from the pre-set debt transfer rule table; When the trade amount is greater than or equal to the loan condition threshold, the payment node identifier is used as the initial seed, and the current system timestamp is subjected to cyclic redundancy iterative expansion to generate a bond confirmation signal. The bond confirmation signal and the clearing channel code are split in half bit by bit, cross-combined, and then shifted to the right by a fixed number of bits to obtain the fund clearing instruction parameters.

[0011] As a further aspect of the present invention: the generation of the bond confirmation signal specifically includes: The byte sequence of payment node identifier is reversed bitwise and then filled into the initial bit value of a cyclic redundancy register of a preset fixed length; The current system timestamp is split into a high half and a low half. The order of the two halves is swapped and used as the input bit stream. The bits are shifted into the cyclic redundancy register in sequence. For each bit shifted in, the current bit value of the cyclic redundancy register is XORed with a fixed generator polynomial and the entire bit value of the register is updated. Using the updated register bit value as the new initial value, perform shift-in and XOR feedback operations again on the bit stream after swapping the lower half and higher half of the current system timestamp; After repeating the shift-in and XOR feedback operations a preset number of times, the final register bit value is output as a bond confirmation signal.

[0012] As a further aspect of the present invention: S5 specifically includes: Extract the weight coefficients of each level node and the hash values ​​of the parent-child constraint boundaries from the order data; Using the bond confirmation signal as the initial splitting seed, the total face value of the bond certificate is proportionally divided according to the weight coefficient of each level node to generate multiple primary sub-certificates with different face values. For each primary sub-certificate, perform a bit binding operation with the parent-child constraint boundary hash value of the corresponding hierarchical node to form a traversable rotor certificate carrying hierarchical constraint tags; All traversable rotor vouchers are sequentially appended to a sequential voucher linked list to complete the split.

[0013] As a further aspect of the present invention: the generation of multiple primary sub-certificates with different face values ​​specifically includes: Using the binary bit sequence of the bond confirmation signal as the initial perturbation value, the decimal string of the total face value is inserted and permuted bit by bit to generate a randomized total string. The weight coefficients of each level node are converted into corresponding binary masks, and then bitwise AND and NOT operations are performed with each digital bit in the randomized total string to obtain the split offset corresponding to each node. Using each segmentation offset as a cutoff point, sequentially extract the corresponding length of numeric substrings from the randomized total string, and then convert each numeric substring into an integer as the primary sub-voucher denomination of the corresponding node.

[0014] A data management system for a supply chain finance platform includes: The data collection and evidence storage module is used to collect order data, logistics data, and invoice data between enterprises and their upstream and downstream enterprises. After assigning a timestamp to the collected order data, logistics data, and invoice data, it stores them in the blockchain evidence storage network to form a traceable source evidence dataset. The fingerprint generation and constraint encapsulation module is used to perform hash mapping on the source evidence dataset, generate unique data fingerprints for each data unit, and combine the data fingerprints with preset payment conditions and financing trigger thresholds to encapsulate them into a set of automated constraint fields driven by a state machine. The trade authenticity verification module is used to respond to the establishment of an automated constraint field set, compare the data fingerprint with the real-time access trade execution message, and trigger a two-level recursive verification of the trade background authenticity when the key status in the trade execution message matches the constraint field in the data fingerprint, generating a verified trade data packet. The debt confirmation and settlement parameter generation module inputs the verified trade data package into the state machine. The state machine outputs a bond confirmation signal that meets the loan conditions and the corresponding fund settlement instruction parameters according to the internally preset debt transfer rules. The loan execution and voucher splitting module automatically sends a loan request to the funding party's interface based on the bond confirmation signal and fund clearing instruction parameters. After the loan is successfully disbursed, the debt voucher is split into multiple liquid transferable vouchers according to the hierarchical relationship in the order data, thus completing the automated closed loop of the financing process.

[0015] The beneficial effects of this invention are: (1) This invention stores order data, logistics data and invoice data on the blockchain and generates unique data fingerprints. It combines a two-layer recursive verification mechanism to perform binary interval recursive truncation comparison of the carrier timestamp and to perform reverse recursive operation after splitting the path prefix and suffix of the logistics node location code. Only when both recursive verifications pass will the verified trade data packet be output. This realizes fully automatic closed-loop verification of the authenticity of the trade background, avoids the process of relying on core enterprise confirmation or manual order-by-order verification in traditional solutions, and reduces the risk of financing interruption caused by insufficient willingness to confirm rights or human oversight.

[0016] (2) This invention uses the pre-set debt transfer rules inside the state machine to generate a bond confirmation signal by performing cyclic redundancy iterative amplification on the system timestamp with the payment node identifier as the initial seed. The bond confirmation signal is then cross-merged with the clearing channel code and cyclically shifted to the right to obtain the fund clearing instruction parameters. At the same time, the total face value is inserted and replaced bit by bit according to the hierarchical weight coefficient in the order data, and bitwise AND and NOT operations are performed to obtain the splitting offset. In this way, the debt certificate is split into multiple liquidable rotor certificates carrying parent-child constraint boundary hash values. This realizes the automatic determination of loan conditions and the hierarchical splitting and transfer of debt. The core enterprise does not need to occupy its own credit line, which improves the automation of the financing process and the flexibility of debt transfer. Attached Figure Description

[0017] The invention will now be further described with reference to the accompanying drawings.

[0018] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system block diagram of the present invention. Detailed Implementation

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

[0020] Please see Figure 1 As shown, this invention is a data management method for a supply chain finance platform, comprising the following steps: S1: Collect order data, logistics data, and invoice data between the enterprise and its upstream and downstream enterprises, and then store the collected order data, logistics data, and invoice data with timestamps into the blockchain evidence storage network to form a traceable source evidence dataset. S2: Perform hash mapping on the source evidence dataset to generate unique data fingerprints for each data unit, and combine the data fingerprints with preset payment conditions and financing trigger thresholds to encapsulate them into a set of automated constraint fields driven by a state machine. S3: In response to the establishment of the set of automated constraint fields, the data fingerprint is compared with the trade execution message in real time. When the key status in the trade execution message matches the constraint field in the data fingerprint, a two-layer recursive verification of the authenticity of the trade background is triggered, and a verified trade data packet is generated. S4: Input the verified trade data packet into the state machine. The state machine outputs a bond confirmation signal that meets the lending conditions and the corresponding fund clearing instruction parameters according to the internally preset debt transfer rules. S5: Based on the bond confirmation signal and fund clearing instruction parameters, automatically send a loan request to the funding party interface, and after the loan is successfully disbursed, split the debt certificate into multiple liquid transferable certificates according to the hierarchical relationship in the order data, thus completing the automated closed loop of the financing process.

[0021] In S1, order data, logistics data, and invoice data between the enterprise and its upstream and downstream enterprises are collected. These collected data are then timestamped and stored in a blockchain-based evidence storage network, forming a traceable source evidence dataset, specifically including: A data export interface is configured on the enterprise resource planning server. This interface uses a descriptive state-transfer style to extract order data daily. Simultaneously, the same interface is configured on the server of the third-party logistics transportation management system to extract logistics data daily. Furthermore, an invoice data retrieval channel is configured in the authorized interface of the tax invoice service platform to extract invoice data daily. The above extraction operations are performed by a separate data acquisition server, which establishes secure connections with the aforementioned three interfaces via Internet Protocol. The data acquisition server sequentially calls the three interfaces at midnight each day to read all order data, logistics data, and invoice data generated that day into its local memory. For each data record read, the data acquisition server appends a timestamp accurate to milliseconds based on its built-in hardware clock. After timestamp appending, the data acquisition server arranges the timestamped order data, logistics data, and invoice data in ascending order of data generation time, forming a data block sequence. Subsequently, the data acquisition server sends this data block sequence to any consensus node in the blockchain evidence storage network. After receiving the data block sequence, the consensus node reaches an agreement with other consensus nodes using a practical Byzantine fault-tolerant algorithm, packages the data block sequence into a new block, and connects this new blockchain to the longest chain in the blockchain evidence storage network, thus forming a traceable source evidence dataset. Each piece of data in this source evidence dataset can be uniquely located through block height and transaction index, allowing subsequent steps to verify that the data has not been tampered with.

[0022] In S2, the source evidence dataset is hashed to generate a unique data fingerprint for each data unit. This data fingerprint is then combined with preset payment conditions and financing trigger thresholds, and encapsulated into a state machine-driven set of automated constraint fields, specifically including: The source evidence dataset generated by S1 is read from the blockchain evidence storage network. This dataset consists of multiple data blocks, each containing several timestamped order data, logistics data, and invoice data. Each data item is considered an independent data unit, containing at least three pieces of information: the timestamp appended when the data was collected, the complete byte sequence of the data itself, and the hash remainder generated by hashing the preceding data unit in the source evidence dataset. For the first data unit in the source evidence dataset, the hash remainder of the preceding data unit is initialized with a preset fixed value, which is a bit string of fixed output length, filled with zeros.

[0023] For each data unit, the timestamp, content byte sequence, and hash remainder of the previous data unit are concatenated into a long, continuous bit string, with the timestamp first, the content byte sequence in the middle, and the hash remainder last. A recursive hash operation is then performed on this long bit string: In the first recursion, the long bit string is used as input, and a fixed-length version of the secure hash algorithm is used to calculate a first hash value; in the second recursion, the first hash value is used as input, and the same secure hash algorithm is used again to calculate a second hash value; this process continues for a predetermined number of iterations, a fixed integer between 16 and 32. Each recursion uses the hash value output from the previous recursion as the initial input vector for the next recursion, and the final recursion outputs a final hash value.

[0024] After obtaining the final hash value, a fixed-length bit string is extracted from the binary sequence of the final hash value as the unique data fingerprint of that data unit. The extraction method is as follows: starting from the most significant bit of the final hash value, consecutively extract the lower bits with a length equal to the preset fingerprint length, discarding the remaining higher bits. The preset fingerprint length is either 128 bits or 256 bits. Thus, each data unit in the source evidence dataset obtains a corresponding unique data fingerprint, used to distinguish different data units and verify their integrity.

[0025] After calculating the data fingerprints of all data units, each data fingerprint is combined with preset payment conditions and financing trigger thresholds to form an automated constraint field set. First, the binary bit sequence of each data fingerprint is split bit-by-bit into two parts: the consecutive high-order bits starting from the most significant bit are called the high-order check segment, and the remaining low-order bits are called the low-order trigger segment. The preset payment conditions include two specific parameters: a minimum payment amount threshold and a payment period in days threshold. The specific method for converting the payment conditions into a condition threshold mask is as follows: the minimum payment amount threshold is converted into a fixed-length binary number, and each bit of this binary number is logically ANDed with the corresponding bit of the binary representation of the payment period in days threshold to obtain a binary string of the same length, called the condition threshold mask.

[0026] The financing trigger threshold is converted into a comparison benchmark value, which is a pre-defined total amount of trade data. This value is then converted into a fixed-length binary number, padded with zeros at the high bits to the same length as the condition threshold mask, resulting in the comparison benchmark value. A bit-interleaving permutation operation is then performed: the least significant bit of the condition threshold mask is alternately interleaved with the least significant bit of the comparison benchmark value. Specifically, the first bit of the condition threshold mask is taken as the first bit of the new sequence, the first bit of the comparison benchmark value is taken as the second bit, the second bit of the condition threshold mask is taken as the third bit, the second bit of the comparison benchmark value is taken as the fourth bit, and so on, until all bits are taken, generating a permutation sequence that is twice the length. This permutation sequence is then XORed with the high-order parity segment, i.e., an XOR operation is performed bit by bit on both binary strings of the same length; the result is called the constraint check header.

[0027] The constraint verification header and the low-order trigger segment together form an automated constraint field set. The constraint verification header is used to verify the authenticity of trade data in subsequent steps, while the low-order trigger segment serves as the stepping trigger pulse parameter for the state machine. Specifically, for each trade message verified, a fixed-width binary value is extracted from the low-order trigger segment as the pulse step size. The state machine then transitions from the current state to the next state based on this pulse step size. After this encapsulation, the automated constraint field set is stored in a local cache.

[0028] In S3, in response to the establishment of the automated constraint field set, the data fingerprint is compared with the real-time access trade execution message. When the key status in the trade execution message matches the constraint field in the data fingerprint, a two-layer recursive verification of the authenticity of the trade background is triggered, generating a verified trade data packet, specifically including: An automated constraint field set is encapsulated in the local cache. This set includes the constraint check header and low-order trigger segment for each data unit. Simultaneously, trade execution messages are accessed via a real-time data stream interface. These messages are generated by the core enterprise's business system at the time of each transaction and contain at least the following fields: shipping timestamp, logistics node location code, logistics trajectory hash value, and key status fields (such as order status code and receipt status code). The key status fields identify whether the trade has been completed and their values ​​match predefined rules with the constraint fields in the data fingerprint.

[0029] The first layer of verification begins by extracting a pre-defined time window hash string from the constraint verification header of each data unit. This time window hash string is generated as follows: during step S2, when encapsulating the automated constraint field set, a specific continuous bit segment is extracted from the high-order check segment of the data fingerprint and used as a fixed-bit string with a length equal to the length of the binary representation of the shipping timestamp. The shipping timestamp in the trade execution message is converted into a binary string of the same length. Then, a recursive truncation comparison of binary intervals is performed. The recursive truncation comparison process is as follows: the binary string of the shipping timestamp is divided into multiple intervals of equal length, each interval containing a fixed number of bits. For example, a 64-bit binary string is divided into 8 intervals, each containing 8 bits. The recursion depth is set to be equal to the number of intervals. The formula for calculating the recursive intermediate value is defined as follows: ; in, Indicates the first The intermediate value output by the next recursive step From 1 to recursion depth ; The initial base is set to a preset value, which is the integer value converted from a string of all 1 bits. The multiplication coefficient is a preset value, which is a fixed prime number, such as 131; For the carrier timestamp The integer values ​​corresponding to each interval segment; The modulus is a power of 2 minus 1, for example, 65535. After calculating the intermediate value output in each recursive step, the intermediate value is converted into a binary string, and its least significant bit is used as the check bit for the current step. This check bit is compared with the corresponding bit in the time window hash string. If all bits are equal, the intermediate value output in each recursive step is confirmed to match the suffix of the time window hash string, the first level of verification passes, and the second level of verification proceeds. If any bit is not equal, the verification terminates, a verification failure flag is output, and subsequent steps are not executed.

[0030] After the first layer of verification passes, the second layer of verification is executed. The second layer of verification verifies the logistics node location code in the trade execution message and the logistics trajectory hash in the data fingerprint. The logistics node location code is a string consisting of multiple comma-separated byte segments, each representing the location sequence number of a logistics node, such as "03,AB,7F,2C". The logistics trajectory hash in the data fingerprint is a fixed-width substring, 256 bits long, obtained by hashing the logistics data corresponding to the trade in step S2.

[0031] Extract the first consecutive fixed byte segment from the logistics node location code as the path prefix. The fixed byte segment refers to all characters from the beginning of the string to the first comma, such as "03". Separate the remaining byte segments by commas and reassemble them into a path suffix sequence, such as "AB", "7F", "2C". Convert the path prefix to a binary integer, denoted as P, which serves as the initial recursion carrier. Convert each element in the path suffix sequence to a binary integer, representing the variable-length step size of the single-step recursion, denoted as P. , where M is the length of the path suffix sequence.

[0032] Perform a bitwise NOT operation on the logistics trajectory hash in the data fingerprint to obtain the inverse bit string, denoted as . Define the initial input values ​​for the reverse recursive operation. equal Then iterate according to the step size in the path suffix sequence. step( The reverse recursive calculation process from 1 to M is as follows: based on the current stride... The length value, relative to the previous output value. Perform a circular right shift operation. The number of bits shifted to the right is equal to... The value. After a circular right shift, an intermediate result is obtained, denoted as. Then... Perform a bitwise NAND operation with the initial recursive carrier P. The bitwise NAND operation first performs a logical AND operation on each bit of the two operands, and then performs a logical NOT operation on each bit. The result is used as the first... Step output value This process can be represented by the following mathematical formula: ; in, This indicates a circular right shift operation. Indicates a bitwise AND operation. This indicates a bitwise NOT operation. This is the output value from the previous step. For initial input values , For the path suffix sequence, the first... Integers converted from elements, This serves as the initial recursive vector for path prefix transformation. After each step, the current output value is checked. Is the output string all zeros? If the output value is all zeros in any step, terminate the recursion and record the current step number. If, after completing all M iterations, the output value of the last step is... If the result is all zeros, the second-level verification passes, and a verified trade data packet is generated. This verified trade data packet consists of the original trade execution message, the first-level verification pass flag, the second-level verification pass flag, and the intermediate values ​​output in each recursive step are appended. The hash value is used as a verification redundancy for use by S4. If the output value is never zero, the verification fails, an error code is returned, and no trade data packet is generated.

[0033] In the aforementioned two-layer recursive verification process, if either the first or second layer of verification fails, the verification of the authenticity of the trade background is terminated, no data packet is generated, and a verification failure notification message is sent to the core enterprise and funding party interfaces. Only when both layers of verification pass is the verified trade data packet output. This data packet is temporarily stored in a memory queue, waiting to be read by the S4 state machine.

[0034] In S4, the verified trade data packet is input into the state machine. Based on pre-set internal debt transfer rules, the state machine outputs a bond confirmation signal that meets the lending conditions, along with corresponding fund clearing instruction parameters, specifically including: The verified trade data packet generated in step S3 is read from the memory queue. This data packet contains the original trade execution message, the first-level verification pass identifier, the second-level verification pass identifier, and the intermediate value hash value of each recursive output as verification redundancy. The verified trade data packet is input into a pre-built state machine. This state machine is a finite state automaton that internally stores a pre-set debt transfer rule table. This rule table is stored in key-value pair format, and each record contains three fields: debt transfer frequency threshold, loan condition threshold, and clearing channel code. The debt transfer rule table is pre-set and fixed by the core enterprise when encapsulating the set of automated constraint fields in step S2, and cannot be dynamically modified in subsequent business processes.

[0035] After receiving the verified trade data packet, the state machine first performs a parsing operation on the packet. The parsing process involves extracting three parameters from a fixed offset position in the verified trade data packet. The first parameter is the trade amount, which is taken from the total transaction amount field in the original trade execution message, expressed in RMB fen, and is a positive integer. The second parameter is the payment node identifier, which is taken from the unique number of the purchaser in the core enterprise business system in the original trade execution message, and is a 32-byte hexadecimal string. The third parameter is the debt transfer threshold, which is taken from the first 8 bits of the low-order trigger segment of the automated constraint field set in step S2, converted to decimal, and is an integer ranging from 1 to 16.

[0036] Using the parsed threshold for the number of debt transfers as an offset, the state machine performs a lookup operation in the pre-defined debt transfer rule table. The lookup method is as follows: the threshold fields for the number of debt transfers in the debt transfer rule table are arranged in ascending order of value; using the currently parsed threshold as an index, the system locates the corresponding row. Two fields are extracted from this row: the loan condition threshold and the clearing channel code. The loan condition threshold is a monetary value in RMB fen (cents), and the clearing channel code is an 8-byte binary string used to uniquely identify the lending interface routing address of the funding party.

[0037] The state machine compares the trade amount with the loan disbursement threshold. If the trade amount is greater than or equal to the threshold, the loan disbursement condition is met, and the process proceeds to the bond confirmation signal generation step. If the trade amount is less than the threshold, the loan disbursement condition is not met, the state machine outputs a "reject loan" signal, and the process terminates. The bond confirmation signal generation process is as follows: First, the byte sequence of the parsed payment node identifier is reversed bit by bit, that is, the most significant bit of the 32-byte hexadecimal string is swapped with the least significant bit, the second most significant bit is swapped with the second least significant bit, and so on, to obtain a reversed byte sequence. This reversed byte sequence is then filled into the initial bit value of a cyclic redundancy register. The length of this cyclic redundancy register is a preset fixed value of 32 bits. The filling method is as follows: the least significant bit of the reversed byte sequence is used as the most significant bit of the cyclic redundancy register, and zeros are padded to the most significant bit if the length is less than 32 bits.

[0038] The current system timestamp is a 64-bit binary number. This 64-bit binary number is split into a high 32-bit segment and a low 32-bit segment. The order of the two segments is swapped, with the original low 32-bit segment placed before the high 32-bit segment, forming a new 64-bit input bitstream. This input bitstream is shifted bit by bit into a Cyclic Redundancy Check (CRCD) register, starting from the most significant bit and shifting in one bit at a time. After each shift, the current 32-bit value of the CRCD register is XORed with a fixed generator polynomial. This generator polynomial is the binary representation of a polynomial commonly used in 32-bit CRCD, specifically: the most significant bit is 1, and the remaining bits are arranged according to the preset coefficients of the 32-bit CRCD polynomial. The XOR operation rule is as follows: when shifting in a new bit, the most significant bit of the CRCD register is checked. If the most significant bit is 1, the current value of the CRCD register is shifted left by one bit and then XORed with the generator polynomial. The result is used as the new register value; if the most significant bit is 0, the current value of the CRCD register is simply shifted left by one bit. After all 64-bit input bitstreams have been shifted in, the register bit values ​​are obtained after the first update.

[0039] Using the updated register bit value as the new initial value, the above shift-in and XOR feedback operation is performed again on the current system timestamp bit stream after swapping the high and low halves, for a preset number of times. This preset number of times is equal to the threshold value for the number of debt transfers, ranging from 1 to 16 times. In each iteration, the bit value of the cyclic redundancy register at the end of the previous iteration is used as the new initial value, and the same input bit stream (i.e., the system timestamp after swapping the high and low halves) is used as the shift-in data. After completing the preset number of iterations, the final 32-bit value of the cyclic redundancy register is output, and this value is used as the bond confirmation signal. The bond confirmation signal is a 32-bit binary string. Subsequently, the bond confirmation signal is combined with the clearing channel code extracted in step four: the 32-bit bond confirmation signal and the 8-bit clearing channel code are split into high and low halves, respectively. For example, the 32-bit signal is split into high 16 bits and low 16 bits, and the 8-bit signal is split into high 4 bits and low 4 bits. Then, the high 16 bits and low 16 bits of the bond confirmation signal, and the high 4 bits and low 4 bits of the clearing channel code are interleaved and merged in the order of high 16 bits of the bond confirmation signal, high 4 bits of the clearing channel code, low 16 bits of the bond confirmation signal, and low 4 bits of the clearing channel code, forming a 52-bit merged bit string. This 52-bit merged bit string is then cyclically shifted right by a fixed number of bits, which is 8 bits, to obtain the final funds clearing instruction parameters. The state machine outputs the bond confirmation signal and the funds clearing instruction parameters together for use in step S5.

[0040] In S5, based on the bond confirmation signal and fund clearing instruction parameters, a loan request is automatically sent to the funding party's interface. After successful loan disbursement, the debt instrument is split into multiple liquid transferable instruments according to the hierarchical relationship in the order data, completing the automated closed loop of the financing process, specifically including: The bond confirmation signal is read from the bond confirmation signal and fund clearing instruction parameters, and the corresponding order data is read from the source evidence dataset formed in step S1. The weight coefficients of each level node and the hash values ​​of the parent-child constraint boundaries are extracted from the order data. The hierarchical relationship in the order data reflects the multi-level supply structure between the core enterprise and its upstream and downstream enterprises, such as first-tier suppliers, second-tier suppliers, and third-tier suppliers. Each level node corresponds to a weight coefficient, which is a positive integer representing the proportion of that node in the entire debt split. The sum of the weight coefficients of all level nodes equals a preset total allocation base, which is 10000. The hash value of the parent-child constraint boundary is a constraint verification string for each level node to its superior and subordinate nodes. It is obtained by concatenating the parent node identifier and the child node identifier and then performing a secure hash algorithm, with a length of 256 bits.

[0041] The bond confirmation signal is used as the initial seed for splitting. The bond confirmation signal is a 32-bit binary string. Each bit of its binary sequence is extracted sequentially as the initial perturbation value. Simultaneously, the face value of the bond certificate is obtained, which is a decimal integer in RMB, for example, 10,000,000 represents 100,000 RMB. The face value is converted into a decimal number string, i.e., each digit is written out, for example, "10,000,000". A bit-by-bit insertion and permutation operation is performed on this decimal number string: starting from the highest bit, each digit is read sequentially, while simultaneously taking one bit from the binary sequence of the bond confirmation signal as a perturbation flag. If the perturbation flag is 1, the number is swapped with the next digit; if the perturbation flag is 0, it remains in its original position. After one iteration, the resulting number string is used as an intermediate result, and the above insertion and permutation operation is performed again in reverse order of the binary sequence of the bond confirmation signal to obtain the final randomized total amount string.

[0042] The weight coefficients of each level node are converted into corresponding binary masks. The weight coefficients are integers, ranging from 0 to 10000. This integer is represented as a fixed-length binary number, 16 bits long, padded with zeros at the high bits. For example, a weight coefficient of 500 is converted to 0000000111110100. Each bit of the binary mask corresponds to a position in the randomized total amount string, the length of which is equal to the length of the decimal string representing the ticket amount. Bitwise AND operations are performed between the binary mask and each bit in the randomized total amount string: for each decimal digit in the randomized total amount string, it is converted to a 4-bit binary representation; the corresponding bit in the binary mask is then ANDed with each bit of the 4-bit binary representation, i.e., a logical AND operation is performed first, followed by a logical NOT operation on the result. All operation results are aggregated into a single binary string, which is then converted to a decimal integer and used as the splitting offset for that node.

[0043] The splitting offset of each node obtained in the previous step is used as the truncation point to sequentially extract numeric substrings from the randomized total amount string. The truncation rules are as follows: according to the order of the hierarchical nodes, the splitting offset of the first node represents the length of the characters to be extracted starting from the first position of the randomized total amount string. After extraction, the remaining part is used as the source string for subsequent extractions. The splitting offset of the second node represents the length of the characters to be extracted starting from the first position of the remaining source string, and so on. The last node extracts all remaining characters. Each extracted numeric substring is a decimal number sequence. This numeric substring is converted into a decimal integer and used as the face value of the primary sub-voucher for the corresponding node. Since the sum of the weight coefficients equals the total amount allocation base, and the splitting offset is obtained by bitwise NAND operation of the weight coefficients, the sum of the face values ​​of all primary sub-vouchers is exactly equal to the original total amount. This generates multiple primary sub-vouchers with different face values.

[0044] For each primary sub-certificate, a bit-binding operation is performed between it and the parent-child constraint boundary hash value of the corresponding hierarchical node. The specific method for bit-binding is as follows: the face value of the primary sub-certificate is converted into a fixed-length binary string of 64 bits, padded with zeros at the high bits; this binary string is concatenated with the corresponding parent-child constraint boundary hash value (256 bits), i.e., the binary string of the face value is placed before the hash value, forming a new 320-bit binary string. Then, a bitwise circular left shift operation is performed on this 320-bit binary string, with the shifted number equal to the hierarchical number of the corresponding hierarchical node modulo 32. The result after the circular left shift is the traversable sub-certificate carrying the hierarchical constraint flag. In this way, each traversable sub-certificate contains both face value information and its compliance verification flag within the hierarchical constraints.

[0045] All liquid tranche certificates are sequentially appended to a sequential certificate linked list, completing the splitting of the debt certificate. The sequential certificate linked list is a predefined data structure; each node contains two fields: a binary string representing the liquid tranche certificate and a pointer to the next node. Each liquid tranche certificate is inserted as a node in the linked list in ascending order of its hierarchical node number. The head node pointer of the linked list is returned to the caller. Subsequently, based on the funds clearing instruction parameters output in step S4, a loan request is automatically sent to the funding party interface. The loan request includes the funds clearing instruction parameters and the head pointer of the split sequential certificate linked list. After receiving the request, the funding party interface completes the loan disbursement operation and returns a successful disbursement receipt. At this point, the automated closed loop of the financing process is complete.

[0046] Please see Figure 2 As shown, a data management system for a supply chain finance platform includes: The data collection and evidence storage module is used to collect order data, logistics data, and invoice data between enterprises and their upstream and downstream enterprises. After assigning a timestamp to the collected order data, logistics data, and invoice data, it stores them in the blockchain evidence storage network to form a traceable source evidence dataset. The fingerprint generation and constraint encapsulation module is used to perform hash mapping on the source evidence dataset, generate unique data fingerprints for each data unit, and combine the data fingerprints with preset payment conditions and financing trigger thresholds to encapsulate them into a set of automated constraint fields driven by a state machine. The trade authenticity verification module is used to respond to the establishment of an automated constraint field set, compare the data fingerprint with the real-time access trade execution message, and trigger a two-level recursive verification of the trade background authenticity when the key status in the trade execution message matches the constraint field in the data fingerprint, generating a verified trade data packet. The debt confirmation and settlement parameter generation module inputs the verified trade data package into the state machine. The state machine outputs a bond confirmation signal that meets the loan conditions and the corresponding fund settlement instruction parameters according to the internally preset debt transfer rules. The loan execution and voucher splitting module automatically sends a loan request to the funding party's interface based on the bond confirmation signal and fund clearing instruction parameters. After the loan is successfully disbursed, the debt voucher is split into multiple liquid transferable vouchers according to the hierarchical relationship in the order data, thus completing the automated closed loop of the financing process.

[0047] The working principle of this invention is as follows: A data acquisition server extracts order data, logistics data, and invoice data daily from an enterprise resource planning server, a third-party logistics management system, and a tax invoice platform, respectively. After attaching a timestamp generated by a hardware clock, the data block sequence is written into a blockchain evidence storage network using a practical Byzantine fault-tolerant consensus mechanism, forming a traceable source evidence dataset. Each data unit undergoes concatenation and recursive hashing operations. A fixed-length bit string is extracted as a unique data fingerprint. The high-order check segment of the fingerprint, along with payment conditions and financing trigger thresholds, is combined using bit-interleaving permutation and XOR fusion to generate a constraint check header. The low-order trigger segment serves as the state machine step pulse parameter, encapsulated into an automated constraint field set. The data fingerprint is compared with the real-time trade execution message. First, a recursive truncation comparison is performed on the carrier timestamp. Then, the logistics node location code is split into a path prefix and suffix. Using the path prefix as the initial carrier and the suffix as the step size, a reverse recursive operation is performed on the logistics trajectory hash. After double verification, a unique data fingerprint is generated. The verified trade data packet is input into the state machine. The loan condition threshold and clearing channel code are extracted from the pre-set debt transfer rule table. When the trade amount meets the conditions, the cyclic redundancy register is filled with the payment node identifier. The system timestamps of the high and low halves are amplified by multiple rounds of cyclic redundancy iteration. The bond confirmation signal is output and cross-merged with the clearing channel code. After cyclic right shift, the fund clearing instruction parameters are obtained. Finally, the bond confirmation signal is used as the perturbation value to insert and replace the face value of the total amount string bit by bit. The weight coefficients of each level node are converted into binary masks and bitwise AND and NOT operations are performed with the replaced total amount string to obtain the segmentation offset. The numerical substring is truncated according to the offset to generate primary sub-certificates. Then, the bits are bound and cyclically left shifted with the parent-child constraint boundary hash value to form multiple flowable sub-certificates carrying hierarchical constraint tags and appended to the sequential certificate linked list. At the same time, a loan request is sent to the funder interface according to the fund clearing instruction parameters, thereby completing the automated closed loop of the financing process.

[0048] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A data management method for a supply chain finance platform, characterized in that, Includes the following steps: S1: Collect order data, logistics data, and invoice data between the enterprise and its upstream and downstream enterprises, and then store the collected order data, logistics data, and invoice data with timestamps into the blockchain evidence storage network to form a traceable source evidence dataset. S2: Perform hash mapping on the source evidence dataset to generate unique data fingerprints for each data unit, and combine the data fingerprints with preset payment conditions and financing trigger thresholds to encapsulate them into a set of automated constraint fields driven by a state machine. S3: In response to the establishment of the set of automated constraint fields, the data fingerprint is compared with the trade execution message in real time. When the key status in the trade execution message matches the constraint field in the data fingerprint, a two-layer recursive verification of the authenticity of the trade background is triggered, and a verified trade data packet is generated. S4: Input the verified trade data packet into the state machine. The state machine outputs a bond confirmation signal that meets the lending conditions and the corresponding fund clearing instruction parameters according to the internally preset debt transfer rules. S5: Based on the bond confirmation signal and fund clearing instruction parameters, automatically send a loan request to the funding party interface, and after the loan is successfully disbursed, split the debt certificate into multiple liquid transferable certificates according to the hierarchical relationship in the order data, thus completing the automated closed loop of the financing process.

2. The data management method for a supply chain finance platform according to claim 1, characterized in that, S2 specifically includes: Concatenate the timestamp, content byte sequence, and hash remainder of the previous data unit in the source evidence dataset for each data unit. A recursive hash operation is performed on the concatenated result. In each recursion, the hash value of the previous output is used as the initial vector for the next input. After a preset number of iterations, a fixed-length bit string is extracted as the unique data fingerprint of the data unit.

3. The data management method for a supply chain finance platform according to claim 1, characterized in that, The encapsulation is a set of automated constraint fields based on state machine driving, specifically including: The data fingerprint is split into a high-bit verification segment and a low-bit trigger segment. The payment conditions are converted into a condition threshold mask, and the financing trigger threshold is converted into a comparison benchmark value. Then, the condition threshold mask and the comparison benchmark value are bit-interleaved and XORed with the high-bit verification segment to generate a constraint verification head. The low-bit trigger segment is used as the step trigger pulse parameter of the state machine.

4. The data management method for a supply chain finance platform according to claim 1, characterized in that, S3 specifically includes: The first layer of verification extracts a preset time window hash string from the data fingerprint and compares it with the carrier timestamp in the trade execution message using binary interval recursive truncation. After confirming that the intermediate value of each recursive output is consistent with the suffix of the time window hash string, it proceeds to the second layer of verification. The second layer of verification involves splitting the logistics node location code in the trade execution message into a path prefix and a path suffix. Using the path prefix as the initial vector and the path suffix as the iteration step size, a reverse recursive operation is performed on the logistics trajectory hash in the data fingerprint until the output value returns to zero, thus generating a verified trade data packet.

5. The data management method for a supply chain finance platform according to claim 4, characterized in that, The generation of the verified trade data packet specifically includes: Extract the first group of fixed bytes that appear consecutively in the logistics node location code as the path prefix, and reassemble the remaining bytes into a path suffix sequence after being separated by commas. The path prefix is ​​used as the initial recursive carrier, and each element in the path suffix sequence is used as the variable step size for single-step recursion. After performing a bitwise reverse operation on the logistics trajectory hash in the data fingerprint, the system cyclically shifts to the right based on the current stride length value, and then performs a bitwise AND-NOT operation on the right shift result and the initial recursive carrier. The result is used as the input value for the next recursion. The process continues until the output value reaches zero, at which point a verified trade data packet is generated.

6. The data management method for a supply chain finance platform according to claim 1, characterized in that, S4 specifically includes: The verified trade data packets are parsed into trade amount values, payment node identifiers, and thresholds for the number of debt transfers. Using the threshold for the number of debt transfers as an offset, extract the corresponding loan disbursement condition threshold and clearing channel code from the pre-set debt transfer rule table; When the trade amount is greater than or equal to the loan condition threshold, the payment node identifier is used as the initial seed, and the current system timestamp is subjected to cyclic redundancy iterative expansion to generate a bond confirmation signal. The bond confirmation signal and the clearing channel code are split in half bit by bit, cross-combined, and then shifted to the right by a fixed number of bits to obtain the fund clearing instruction parameters.

7. The data management method for a supply chain finance platform according to claim 6, characterized in that, The generation of the bond confirmation signal specifically includes: The byte sequence of payment node identifier is reversed bitwise and then filled into the initial bit value of a cyclic redundancy register of a preset fixed length; The current system timestamp is split into a high half and a low half. The order of the two halves is swapped and used as the input bit stream. The bits are shifted into the cyclic redundancy register in sequence. For each bit shifted in, the current bit value of the cyclic redundancy register is XORed with a fixed generator polynomial and the entire bit value of the register is updated. Using the updated register bit value as the new initial value, perform shift-in and XOR feedback operations again on the bit stream after swapping the lower half and higher half of the current system timestamp; After repeating the shift-in and XOR feedback operations a preset number of times, the final register bit value is output as a bond confirmation signal.

8. The data management method for a supply chain finance platform according to claim 1, characterized in that, S5 specifically includes: Extract the weight coefficients of each level node and the hash values ​​of the parent-child constraint boundaries from the order data; Using the bond confirmation signal as the initial splitting seed, the total face value of the bond certificate is proportionally divided according to the weight coefficient of each level node to generate multiple primary sub-certificates with different face values. For each primary sub-certificate, perform a bit binding operation with the parent-child constraint boundary hash value of the corresponding hierarchical node to form a traversable rotor certificate carrying hierarchical constraint tags; All traversable rotor vouchers are sequentially appended to a sequential voucher linked list to complete the split.

9. A data management method for a supply chain finance platform according to claim 8, characterized in that, The generation of multiple primary sub-certificates with different face values ​​specifically includes: Using the binary bit sequence of the bond confirmation signal as the initial perturbation value, the decimal string of the total face value is inserted and permuted bit by bit to generate a randomized total string. The weight coefficients of each level node are converted into corresponding binary masks, and then bitwise AND and NOT operations are performed with each digital bit in the randomized total string to obtain the split offset corresponding to each node. Using each segmentation offset as a cutoff point, sequentially extract the corresponding length of numeric substrings from the randomized total string, and then convert each numeric substring into an integer as the primary sub-voucher denomination of the corresponding node.

10. A data management system for a supply chain finance platform, characterized in that, A data management method for implementing a supply chain finance platform according to any one of claims 1-9 includes: The data collection and evidence storage module is used to collect order data, logistics data, and invoice data between enterprises and their upstream and downstream enterprises. After assigning a timestamp to the collected order data, logistics data, and invoice data, it stores them in the blockchain evidence storage network to form a traceable source evidence dataset. The fingerprint generation and constraint encapsulation module is used to perform hash mapping on the source evidence dataset, generate unique data fingerprints for each data unit, and combine the data fingerprints with preset payment conditions and financing trigger thresholds to encapsulate them into a set of automated constraint fields driven by a state machine. The trade authenticity verification module is used to respond to the establishment of an automated constraint field set, compare the data fingerprint with the real-time access trade execution message, and trigger a two-level recursive verification of the trade background authenticity when the key status in the trade execution message matches the constraint field in the data fingerprint, generating a verified trade data packet. The debt confirmation and settlement parameter generation module inputs the verified trade data package into the state machine. The state machine outputs a bond confirmation signal that meets the loan conditions and the corresponding fund settlement instruction parameters according to the internally preset debt transfer rules. The loan execution and voucher splitting module automatically sends a loan request to the funding party's interface based on the bond confirmation signal and fund clearing instruction parameters. After the loan is successfully disbursed, the debt voucher is split into multiple liquid transferable vouchers according to the hierarchical relationship in the order data, thus completing the automated closed loop of the financing process.

Images