WO2022161225A1

WO2022161225A1 - Method for storing data in blockchain, related payment management system and non-transitory computer-readable storage medium

Info

Publication number: WO2022161225A1
Application number: PCT/CN2022/072726
Authority: WO
Inventors: Cho Leung LAU
Original assignee: Keychain Fintech Ltd
Current assignee: Keychain Fintech Ltd
Priority date: 2021-01-28
Filing date: 2022-01-19
Publication date: 2022-08-04
Anticipated expiration: 2023-07-28
Also published as: GB2611618A; GB202211455D0

Abstract

A method for storing data including credit information in a blockchain, a related payment management system, and a non-transitory computer-readable storage medium are provided. The method includes: receiving data; masking at least a first part of the data by a cryptography method; storing the masked first part of the data in a blockchain database; and storing the first part of the data, as unmasked first part of the data, in an off-blockchain database.

Description

[Title established by the ISA under Rule 37.2] METHOD FOR STORING DATA IN BLOCKCHAIN, RELATED PAYMENT MANAGEMENT SYSTEM AND NON-TRANSITORY COMPUTER-READABLE STORAGE MEDIUM

TECHNICAL FIELD

The disclosure relates to the field of data storage, and in particular, to a method for storing data in a blockchain, and a related payment management system and a non-transitory computer-readable storage medium.

BACKGROUND

An increasing amount of data is being stored for subsequent use, resulting in great concern on security and correctness of the stored data.

Blockchain is a technology using multiple computing devices also known as blockchain nodes to record, replicate and synchronize data among themselves by using consensus mechanism in a relatively distributed, decentralized and secure fashion compared with the centrally managed traditional database.

There are many different categories under the blockchain technology including a public chain, a private chain, a permission-less chain, a permissioned chain and a consortium chain. Any category of the blockchain technology could be adopted in the actual blockchain. The blockchain is one of the representations of distributed ledger technology (DLT) . Any other DLT with features and design philosophy similar to the blockchain, such as directed acyclic graph (DAG) , could also be used as an alternative for an actual blockchain.

Due to the above properties of the blockchain, data stored on the blockchain is difficult to be tampered. However, a user also does not want to expose his/her raw data (especially confidential data) on the blockchain to the public. Therefore, there is a need to provide a technical scheme for improving security of the stored data and preventing the stored data from being tampered, as well as verifying the correctness of the stored data and preventing the tampered data from being used.

SUMMARY

In one aspect, the current disclosure provides a method for storing data in a blockchain, including:

receiving data;

masking at least a first part of the data by a cryptography method;

storing the masked first part of the data in a blockchain database; and

storing the first part of the data, as unmasked first part of the data, in an off-blockchain database.

In an embodiment, the method further includes: storing a second part of the data in both the blockchain database and the off-blockchain database, wherein the second part of the data is different from the first part of the data.

In an embodiment, the masking at least a first part of the data includes:

masking the entire data by the cryptography method;

storing the masked data in the blockchain database; and

storing the entire data, as unmasked data, in the off-blockchain database.

In an embodiment, after the storing the masked first part of the data and the storing the unmasked first part of the data, the method further includes:

cross-checking the unmasked first part of the data with the masked first part of the data, and

wherein the masking at least a first part of the data by a cryptography method includes masking the first part of the data by a cryptographic hashing function;

wherein the cross-checking the unmasked first part of the data with the masked first part of the data includes:

putting the unmasked first part of the data into a same cryptographic hashing function as the cryptographic hashing function used to mask the first part of the data to obtain output hashes; and

comparing the output hashes with the masked first part of the data retrieved from the blockchain database.

In an embodiment, the masking the first part of the data by a cryptographic hashing function includes:

adding salts into the first part of the data to obtain an intermediate first part of the data; and

putting the intermediate first part of the data into the cryptographic hashing function to obtain the masked first part of the data.

In an embodiment, the method further includes:

storing the salts together with the unmasked first part of the data in the off-blockchain database.

In an embodiment, after the storing a second part of the data, the method further includes cross-checking the second part of the data in the off-blockchain database with the second part of the data in the blockchain database, which includes:

comparing the second part of the data retrieved from the off-blockchain database with the second part of the data retrieved from the blockchain database.

In one aspect, a payment management system is provided, including:

an end-user application configured to receive raw data, wherein the raw data at least includes contract data between a target user and a provider of target goods and/or target services, and payment record data of the target user associated with the contract dada;

an artificial intelligence-powered credit analytical engine configured to generate credit data for the target user based on at least the contract data and the payment record data; and

an application programming interface-enabled middleware configured to:

mask at least a first part of at least one of the contract data, the payment record data and the credit data by a cryptography method;

store the masked first part of at least one of the contract data, the payment record data and the credit data in a blockchain database; and

store the first part, as unmasked first part, of at least one of the contract data, the payment record data and the credit data, in an off-blockchain database.

In an embodiment, the application programming interface-enabled middleware is further configured to:

store a second part of the contract data in both the blockchain database and the off-blockchain database, wherein the second part of the contract data is different from the first part of the contract data.

mask the entire payment record data and the entire credit data by the cryptography method;

store the masked payment record data and the masked credit data in the blockchain database; and

store the entire payment record data as unmasked payment record data and the entire credit data as unmasked credit data, in the off-blockchain database.

mask the entire contract data, the entire payment record data and the entire credit data by the cryptography method;

store the masked contract data, the masked payment record data, and the masked credit data in the blockchain database; and

store the entire contract data as unmasked contract data, the entire payment record data as unmasked payment record, and the entire credit data as unmasked credit data, in the off-blockchain database.

In an embodiment, the application programming interface-enabled middleware is configured to mask at least the first part of the contract data, the entire payment record data and the entire credit data by a cryptographic hashing function.

add salts into the first part of the contract data, the entire payment record data and the entire credit data to obtain an intermediate first part of the contract data, an intermediate payment record data, and an intermediate credit data respectively; and

put the intermediate first part of the contract data, the intermediate payment record data, and the intermediate credit data into the cryptographic hashing function to obtain the masked first part of the contract data, the masked payment record data, and the masked credit data respectively.

store the salts together with the unmasked first part of the contract data, the unmasked payment record data and the unmasked credit data in the off-blockchain database.

cross-check the unmasked first part of the contract data, the unmasked payment record data and the unmasked credit data with the masked first part of the contract data, the masked payment record data and the masked credit data respectively,

wherein the cross-checking the unmasked first part of the contract data, the unmasked payment record data and the unmasked credit data includes:

putting the unmasked first part of the contract data, the unmasked payment record data and the unmasked credit data, and corresponding salts into the same cryptographic hashing functions as the cryptographic hashing function used to mask the first part of the data, the payment record data and the credit data respectively to obtain output hashes; and

comparing the output hashes with the masked first part of the contract data, the masked payment record data and the masked credit data retrieved from the blockchain database respectively.

cross-check the second part of the contract data,

wherein the cross-checking the second part of the contract data includes:

comparing the second part of the contract data retrieved from the off-blockchain database with the second part of the contract data retrieved from the blockchain database.

In an embodiment, the artificial intelligence-powered credit analytical engine is further configured to generate a fraud alert indicating a fraud level with description based on fraudulent and/or suspicious activities done by the target user, and

the application programming interface-enabled middleware is further configured to:

mask at least a first part of the fraud alert data by a cryptography method;

store the masked first part of the fraud alert data in the blockchain database; and

store the first part of the fraud alert data as unmasked first part of the fraud alert data and an second part of the fraud alert data in the off-blockchain database, wherein the first part of the fraud alert data is different from the second part of the fraud alert data,

or, the application programming interface-enabled middleware is further configured to:

mask the entire fraud alert data by a cryptography method;

store the masked fraud alert data in the blockchain database; and

store the fraud alert data, as unmasked fraud alert data, in the off-blockchain database.

In an embodiment, the artificial intelligence-powered credit analytical engine is further configured to generate a credit report data indicating the comprehensive credit overview of the target user based on the data stored in the off-blockchain database; and

mask at least a first part of the credit report data by a cryptography method;

store the masked first part of the credit report data in the blockchain database; and

store the first part of the credit report data as unmasked first part of the credit report data and an second part of the credit report data in the off-blockchain database, wherein the first part of the credit report data is different from the second part of the credit report data,

mask the entire credit report data by a cryptography method;

store the masked credit report data in the blockchain database, and

store the credit report data, as unmasked credit report data, in the off-blockchain database.

In an embodiment, the artificial intelligence-powered credit analytical engine is further configured to:

generate an initial credit score data based on a provided payment method, tenancy information, company search results and criminal record check; and

assign the initial credit score data to the target user, and

mask at least a first part of the initial credit score data by a cryptography method;

store the masked first part of the initial credit score data in the blockchain database; and

store the first part of the credit report data as unmasked first part of the initial credit score data and an second part of the initial credit score data in the off-blockchain database, wherein the first part of the initial credit score data is different from the second part of the initial credit score data,

mask the entire initial credit score data by a cryptography method;

store the masked initial credit score data in the blockchain database; and

store the initial credit score data, as unmasked initial credit score data, in the off-blockchain database.

allow a third-party application to retrieve the unmasked first part of the contract data, the second part of the contract data, the unmasked payment record data, and the unmasked credit data in the off-blockchain database, and retrieve the masked first part of the contract data, the second part of the contract data, the masked payment record data, and the masked credit data in the blockchain database by an application programming interface.

In an embodiment, the artificial intelligence-powered credit analytical engine is further configured to recalculate the credit data when a new successful payment record or a new failed payment record occurs.

In one aspect, a non-transitory computer-readable storage medium storing instructions is provided. When executed by a processor, the instructions cause the processor to perform the above methods.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a flow chart of a method for storing data in a blockchain according to an embodiment of the disclosure;

Fig. 2 is a schematic diagram of a related payment management system according to an embodiment of the disclosure;

Fig. 3 is a flow chart of a method for identifying credit rating of a target user in a payment according to an embodiment of the disclosure;

Fig. 4 is a schematic diagram showing a process of cross-checking contract data in a rental payment according to an embodiment of the disclosure;

Fig. 5 is a schematic diagram showing a process of cross-checking payment record data in a rental payment according to an embodiment of the disclosure; and

Fig. 6 is a schematic diagram showing a process of cross-checking credit data in a rental payment according to an embodiment of the disclosure.

DETAILED DESCRIPTION

A method for storing data in a blockchain is provided below. Fig. 1 is a flow chart of a method for storing data in a blockchain according to an embodiment of the disclosure. As shown in Fig. 1, the method for storing data in a blockchain includes the following steps S10 to S40.

At the step S10, data is received. The data may be any data to be stored in the blockchain.

At the step S20, at least a first part of the data is masked by a cryptography method.

At the step S30, the masked first part of the data is stored in a blockchain database.

At the step S40, the first part of the data, as unmasked first part of the data, is stored in an off-blockchain database.

The step S30 and the step S40 may be performed simultaneously.

In addition to the first part of the data, a second part of the data may be stored in both the blockchain database and the off-blockchain database. The second part of the data is different from the first part of the data, which will be described in detail below.

The data consists of the first part of the data and the second part of the data. The first part of the data may include sensitive details (i.e., sensitive data) , such as personal particulars, and business confidential Information. The second part of the data may include non-sensitive details which may be available in public. However, the data may be divided into more than two to any number of parts as desired.

The masking of the at least the first part of the data further includes: masking the entire data, by a cryptography method; and storing the masked data in the blockchain database and the entire data as unmasked data in the off-blockchain database. That is, the data as a whole is masked by the cryptography method and the masked entire data is stored in the blockchain database, while the entire data as unmasked entire data is stored in the off-blockchain database.

The method for storing data in a blockchain further includes: after the storing the masked first part of the data and the storing the unmasked first part of the data, cross-checking the unmasked first part of the data with the masked first part of the data. The masking of the at least a first part of the data by a cryptography method includes masking the first part of the data by a cryptographic hashing function.

The cross-checking of the unmasked first part of the data with the masked first part of the data includes: putting the unmasked first part of the data into a same cryptographic hashing function as the cryptographic hashing function used to mask the first part of the data to obtain output hashes; and comparing the output hashes with the masked first part of the data retrieved from the blockchain database. If the output hashes are consistent with the masked first part of the data retrieved from the blockchain database, the unmasked first part of the data in the off-blockchain database are determined to be not tampered.

The sensitive data could maintain privacy, secrecy and/or correctness, by being masked and stored in the blockchain database, by stored in the off-blockchain database, and/or by cross-checking the sensitive data in the off-blockchain database with the masked sensitive data in the blockchain database.

In order to prevent the sensitive data from being exposed, the method for storing data in a blockchain may further include: adding salts into the unmasked first part of the data to obtain an intermediate first part of the data; and putting the intermediate first part of the data into the cryptographic hashing function to obtain the masked first part of the data. In an embodiment, the salts together with the unmasked first part of the data are stored in the off-blockchain database. This may make the calculation of all possible hashes become practically infeasible.

The method for storing data in a blockchain may further include cross-checking the second part of the data. The cross-checking of the second part of the data may include: comparing the second part of the data in the off-blockchain database with the second part of the data in the blockchain database. If the second part of the data in the off-blockchain database is consistent with the second part of the data in the blockchain database, the second part of the data in the off-blockchain database is determined to be not tampered.

Based on the above method for storing data in a blockchain, a related payment management system for identifying credit rating of a target user in a payment is provided. Specifically, the related payment management system relates to contract and payment management and credit referencing. Fig. 2 is a schematic diagram of a related payment management system for identifying credit rating of a target user in a payment according to an embodiment of the disclosure. The related payment management system may include an end-user application 21, an application programming interface (API) -enabled middleware 23, a blockchain-network node (including a blockchain database) 24, an artificial intelligence (AI) -powered credit analytical engine (i.e., AI engine) 22 and an off-blockchain database 25. The related payment management system and its work content will be described in detail below.

A target user or a provider of target goods and/or services could login to the end-user application 21 to provide some basic personal particulars and upload an electronic contract or a scanned version of a physical contract agreement. Alternatively, a target user or a provider of target goods and/or services could login to the end-user application 21 to create an electronic contract. For the contract that is not signed by all contracting parties, the system may either prompt the user to re-upload a new contract or send the contract to all required parties to electronically sign it within the system.

An electronic signature could be any form as long as it is reliable, appropriate and agreed by all contracting parties. It could be a name input by the user or a handwritten-style signature signed by using a computing device with a touchscreen and/or a mouse and/or a stylus pen. Alternatively, the electronic signature could be a digital signature which employs asymmetric cryptography. The digital signature may be produced by the user’s private key and could be verified later by the user’s public key. The actual implementation of the digital signature powered by asymmetric cryptography is omitted in the present specification for simplicity.

After a contract is uploaded, created, or electronically signed by all contract parties, the contract and the personal particulars are verified by the system and/or the company staff manually to minimize the possibility of fraud and scam.

The personal particulars along with contract and payment records are then ready to be stored in the blockchain. To avoid all sensitive details of the personal particulars being exposed in the blockchain, the personal particulars are partially or entirely processed by cryptographic technology such as cryptographic hashing function and encryption. In the case of partial masking by a cryptography method, in an example, a first part of the personal particular data, such as sensitive detail data, is masked. The masked first part of the personal particular data together with metadata (if any) is then stored in the blockchain database 24 via the API-enabled middleware 23, and the unmasked first part (as unmasked first part) of the personal particular data is stored in the off-blockchain database 25 via the API-enabled middleware 23.

There is a mathematical and/or computational linkage between the masked personal particulars stored in the blockchain database 24 and the unmasked personal particulars stored in the off-blockchain database 25. The mathematical and/or computational linkage is determined by a cryptographic hashing function which will be described in detail below.

In addition to the first part, the personal particular data may include a second part of the personal particular data, such as non-sensitive detail data, and thus the second part is different from the first part. The second part without being masked could be stored both in the blockchain database 24 and in the off-blockchain database 25 via the API-enabled middleware 23.

Optionally, both the first part and the second part of the personal particular data may be masked. The masked first part and the masked second part of the personal particular data may be stored in the blockchain database 24, and the first part (as unmasked first part) and the second part (as unmasked second part) of the personal particular data may be stored in the off-blockchain database 25. This is, the entire personal particular data may be masked, and may be stored in the blockchain database 24 to maintain the privacy and secrecy of the personal particular data, especially the sensitive data of the personal particular data.

The first part and the second part of the personal particular data may correspond to the Field Names of the personal particular. The correspondence between the first part and the second part of the personal particular data and the Field Names of the personal particular may be determined in advance as desired.

A fraud alert (for example, an initial fraud alert data) indicating a fraud level with description based on fraudulent and/or suspicious activities done by the target user is generated accordingly and is ready to be stored in the blockchain. To avoid all sensitive details of the fraud alert being exposed in the blockchain, the fraud alert is partially or entirely processed by a cryptographic technology such as cryptographic hashing function and encryption. The masked fraud alert is then stored in blockchain database via the API-enabled middleware. The unmasked details of the fraud alert are stored in an off-blockchain database via the API-enabled middleware. There is a mathematical and/or computational linkage between the masked fraud alert stored in the blockchain database 24 and the unmasked fraud alert stored in the off-blockchain database 25.

Similar to the personal particular data, as an example, the fraud alert data may be divided into a first part (e.g., sensitive details) and a second part (e.g., non-sensitive details) . The first part and second part of the fraud alert data are processed and stored in a similar way as above to the personal particular data. The contract data, the payment record data, the credit data, the credit report data, the initial credit score data and the like below would also be divided, processed and stored in a similar way as above to the personal particular data, and the detailed description would be omitted for avoiding repetition.

The contract without government stamp, which may be required in some cases, may either be sent electronically or physically to a respected internal system or third-party system to undergo stamping process.

A stamped contract with or without stamp proof or an unstamped contract is ready to be stored in the blockchain. To avoid all sensitive details of the contract being exposed in the blockchain, the contract data is partially or entirely processed by a cryptographic technology such as cryptographic hashing function and encryption. There is a mathematical and/or computational linkage between the masked contractual data stored in the blockchain database 24 and the unmasked contractual data stored in the off-blockchain database 25.

Table 1 lists examples of the contract data that could be submitted with the application of target services and/or target goods. As shown in table 1, in the case where the contract data is partially masked, a first part and a second part of the contract data may correspond to the Field Name of the contract information. The Field Name corresponding to the first part of the contract data may include but not limited to Submission Time, Payer Country, Payer Name, Payer Email, Payer Phone, Payer Background check, Payee Country, Payee Name, Payee Phone, Payee KYC check, Target Goods/Services, Initiated By, Period, Amount, Deposit, Payer Payment Method, Authentication Result, Payee Bank Account, Supporting Document, Stamp Information, One Time/Recurring, Is Extended Contract, and the like. The Field Name corresponding to the second part of the contract data may include Signature Date, Start Date, End Date and the like. The correspondence between the first part and the second part of the contract data and the Field Names of the contract information may be determined in advance as desired.

Table 1

The cryptographic hashing function is a one-way function which takes in any size of input data and generates a fixed size of output data. The output data could be treated as a digital fingerprint of the input data which means that the output data could uniquely represent the input data. If a hashing function produces the same output data given two different pieces of input data, that hashing function is regarded as insecure. It is practically infeasible to convert the output data back to its input data within a reasonable time, otherwise that hashing function is regarded as insecure. The hashing function is secure due to its irreversible transformation in a short time, and thus in an embodiment, is adopted to mask the data. The input data of the hashing function refers to the unmasked data while the output data of the hashing function refers to the masked data.

For certain types of data like identity card number, which is usually in a fixed digit format with certain restrictions on certain digits, some malicious parties could compute hashes for all possible identity card numbers and try to match those hashes with the masked identity card number in the blockchain. This may expose the sensitive details. To prevent this, a salt (cryptographic hash function: https: //encyclopedia. thefreedictionary. com/One-way+security) could be added together with the original unmasked data for computing the hash data, i.e. the masked data. A salt basically is a piece of random data which could be in any format and any size and could be added to any position of the unmasked data depending on the desired security level. This method makes the calculation of all possible hashes become practically infeasible. The salt is stored along with the unmasked data in the off-blockchain database.

To illustrate how to convert raw data into hash data which are then put into the blockchain database, the contract data is taken as an example. For simplicity, it is assumed that the contract data merely includes the field names, such as, target user name, target service provider name, service price and service period. It is also assumed that the contract data is in JSON (JavaScript Object Notation) data format in which targetUserName, targetServiceProviderName, servicePrice and servicePeriod are the keys of the JSON. It is also assumed that each value corresponds to each key which form a single key-value pair. In actual implementation, the contract data could be in different data format and could include more or less key-value pair.

Firstly, the personal particulars and sensitive information from the contract data are identified. In the example, the targetUserName, the targetServiceProviderName and the servicePrice belong to the personal particulars and sensitive information. Then, a salt can be generated in the API-enabled middleware. There are many approaches to generate the salt as long as it is generated randomly, such as universally unique identifier (UUID) . The salt together with each value associated with the targetUserName, the targetServiceProviderName and the servicePrice are then put into the cryptographic hashing function in the API-enabled middleware. There are many standards for cryptographic hashing function. In the example, SHA-256 is considered to be a sufficiently strong and secure hashing function. In actual implementation, cryptographic hashing function could employ different standards. The following is the further elaboration of the hashing process.

The pre-generated salt together with the value of the targetUserName are put into SHA-256 hashing function to generate an output hash which could be referred as the salted hash of targetUserName. Same process is applied for the value of the targetServiceProviderName and the servicePrice which also include the same pre-generated salts, respectively. In actual implementation, there are many variations for hashing process. For example, multiple values together with the same salt could be put into the hashing function to generate one single salted hash, which is not limited herein. In some variations, salt is not required in every hashing process. Only raw data with a highly-expected or fixed data format such as identity card number may need to go through hashing process with salt included.

After the hashing process, a new JSON is obtained with same 4 keys which are targetUserName, targetServiceProviderName, servicePrice and servicePeriod. Values of the first 3 keys are salted hashes obtained from the aforementioned hashing process while the value of the last key, i.e. the servicePeriod, is just the original plain value. There are also additional key-value pairs to represent metadata such as creationTimestamp, creator, lastUpdatedTimestamp and lastUpdater. The metadata are usually in raw data format but they can also be converted to hashes in case of protecting the business secret. In actual implementation, this new JSON could be in data format other than JSON and the metadata could be more or less than the aforementioned key-value pairs. This new JSON is then inserted in the blockchain by the API-enabled middleware. In actual implementation, the aforementioned salt generation, hashing process, new JSON formation and blockchain data insertion operation could occur in API-enabled middleware or in other module such as blockchain smart contract engine or in multiple modules such as API-enabled middleware and blockchain smart contract.

The target user (s) of the target services and/or the target goods is (are) notified to set up one or multiple payment method (s) in the end-user application 21. Payment method refers to any method to transfer money or its equivalent or assets of value from the payer to the payee. Payment method could include but not limited to cash payment, credit card, debit card, digital wallet, third-party payment service, bank standing instruction, central bank digital currency and cryptocurrency.

An initial credit score is assigned to the target user based on but not limited to one or multiple of the following criteria, i.e., the provided payment method, tenancy information, company search results and background check.

The end-user application 21 is authorized to process one-off and/or recurring payment on behalf of the target user (s) . Each payment record is attached with the data obtained from the associated contract, allowing the system to correctly locate the associated contract by checking the payment record. The payment record with the aforementioned attachment, such as personal particulars, is ready to be stored in the blockchain. To avoid all sensitive details of the payment record being exposed in the blockchain, similar to the operation of the personal particular data described above, the payment record is partially or entirely processed by cryptographic technology such as cryptographic hashing function and encryption. The masked payment data is then stored in the blockchain database via the API-enabled middleware. The unmasked details of the payment record are stored in an off-blockchain database via the API-enabled middleware. There is a mathematical and/or computational linkage between the masked payment data stored in the blockchain database and the unmasked payment data stored in the off-blockchain database. All payment-related user behaviors and interactions from the end-user application are captured and processed by artificial intelligence-powered credit analytical engine to generate credit data regarding that target user.

Table 2 lists examples of fields in payment record data of the target users of target services and/or target goods. As shown in table 2, in the case where the entire payment record data is masked, the Field Name corresponding to the payment record data may include Date Time, Amount, Authentication Date Time, Authentication Result, Payment Method Payment Attempts, Payment Status, Payment Result, Payee Bank Account and the like. The Field Name of the payment record data may be determined in advance as desired. In the case where the payment record data is partially masked, the first part and the second part of the payment record data may correspond to the Field Name of payment record. The Field Name corresponding to the first part of the payment record data may include Amount, Authentication Date Time, Authentication Result, Payment Attempts, Payment Status, Payment Result and the like. The Field Name corresponding to the second part of the payment record data may include Payment Method and the like. The correspondence between the first part and the second part of the payment record data and the Field Names of the payment record may be determined in advance as desired.

Table 2

The artificial-intelligence powered engine 22 is configured to receive initial data, including but not limited to the contract information, the information of the target user (s) of the target services and/or the target goods, the provided payment method, company search results and any means of Know Your Client (KYC) record check (see https: //financial-dictionary. thefreedictionary. com/Know+Your+Client ) , and generate the credit score of the target user (s) of target services and/or the target goods.

According to another aspect, the artificial-intelligence powered engine 22 is configured to receive the initial data and historical record, including but not limited to the payment records, provided payment methods, the digital footprint in the end user application of the target user (s) and the providers of the target services and/or the target goods, and generate the credit score of the target user (s) of target services and/or the target goods.

Preprocessing modules may be included to identify any missing value on the mentioned data set and filling it, validate the values of the fields, identify outliners in the data, before the mentioned data set is taken into training. When filing missing values, for example, if a numeric field is missing, this missing numeric filed is either filled with mean/median value or the value with worst impact to the credit data. When validating the values, incorrect data types or value exceed reasonable range of numeric fields are identified and corrected. When identifying outliners, the specific data is extracted to be excluded from the training set.

With domain knowledge and mathematical functions, specific fields, Payment Attempts, Failed Payment Remedial Action, Failed Payment Response Time, cited for example, are selected as the feature (i.e., raw data set) to be the input of the artificial-intelligence powered engine 22. Fields are first being selected based on domain knowledge, followed by different mathematical feature selection functions, for example, to name a few but not limited to, correlation coefficients, recursive feature elimination (RFE) and Select From Models (SFM) .

The raw data set, after selection, is cut into 3 parts in similar size: training dataset 1, training dataset 2 and validation dataset. Training dataset 1 is prepared for the machine learning with different implementations to create models. Models with different implementations are being built and being proceeded for fine-tuning. Training dataset 2 is prepared for the fine-tuning on the implemented supervised models to reduce the over-fitting of the model to the training dataset 1. The final step of implementations is validating the accuracy of the models by different evaluation function, for example, Root Mean Square Error (RMSE) , R-Squared (R2) .

The artificial-intelligence powered engine 22 includes supervised and/or unsupervised models. Raw data undergoes different process before it is ready for supervised or unsupervised models (See https: //blog. csdn. net/manong_wxd/article/details/78745419; https: //blog. csdn. n et/u010947534/article/details/82025794; https: //encyclopedia. thefreedictionary. com/supervised+learning; https: //encyclopedia. thefreedictionary. com/Unsupervised+learning) .

All payment record data undergoes the mentioned different process before it is ready for both models, for example it is normalized to same scale for better training purpose. Take a number of attempts in payment record data as an example, the number of attempts of the target user of the target goods/services for a particular payment is normalized based on the whole population, and assigned with a value between 0 and 1.

For the supervised models, one single record of data is defined as the aggregation of all previous payments made, digital footprint of the target users of the target goods/services before the next payment. For example, a target user of the target goods/services with 10 payments made in total, and turns out induced 9 records of data, in which the result 0 or 1 of the record of data is the result of the payment, 0 represents failure and 1 represents success. The supervised models provide a prediction of how likely the payment could be successfully made, and the result is being translated to credit information, in the format of score or rank for example. Examples of the supervised models are linear regression, logistics regression, decision tree, neural network.

For the unsupervised models, one single record of data is defined as the aggregation of all historical payment records, digital footprint of the target users of the target goods/services. The result of the unsupervised models is the credit information, in the format of score or rank for example. Examples of the unsupervised machine learning are K-means Clustering, K-Nearest neighbors.

The credit data output by the artificial intelligence-powered credit analytical engine 22 are stored in the blockchain. There are mainly two types of credit data output by AI-powered credit analytical engine 22, i.e., a credit score and a recurring or delayed one-off payment affordability confidence level. The credit score is a numerical summary of the target user’s creditworthiness at one point in time which also represents the likelihood for the target user to repay the debt at a certain moment. The credit score could be a simple integer. Higher credit score represents a higher chance for the target user to repay the debt. The recurring or delayed one-off payment affordability confidence level refers to the likelihood for the target user to make a recurring payment or a delayed one-off payment given a certain payment amount and/or time interval. For example, a 95%confidence level for the target user on $20000 monthly payment means there is a 95%of chance for the target user to make $20000 monthly payment on time. The recurring or delayed one-off payment affordability confidence level could be a set of percentages to cover different scenario including different payment amounts and different time intervals.

When there is a new successful payment record or a new failed payment record, those two types of credit data are recalculated by the artificial intelligence-powered credit analytical engine 22. The updated credit data is ready to be recorded in the blockchain. To avoid all sensitive details of those two types of credit data being exposed in the blockchain, similar to the operation of the personal particular data described above, the credit data are partially or entirely processed by a cryptographic technology such as cryptographic hashing function and encryption. The masked credit data are then stored in the blockchain database via the API-enabled middleware. The unmasked details of the credit data are stored in an off-blockchain database via the API-enabled middleware. There is a mathematical and/or computational linkage between the masked credit data stored in the blockchain database and the unmasked credit data stored in the off-blockchain database.

Table 3 lists examples of fields of the digital footprint data in the end user application of the target users and providers of target services and/or target goods. As shown in table 3, in the case where the entire digital footprint data is masked, the Field Name corresponding to the digital footprint data may include Device, IP Address, Registration Time, Submission Time, Add Payment Method Time, Add Payment Method Result, Failed Payment Remedial Action, Failed Payment Response Time and the like. The Field Name of the digital footprint data may be determined in advance as desired. In the case where the digital footprint data is partially masked, similar to the operation of the personal particular data described above, the first part and the second part of the digital footprint data may correspond to the Field Name of digital footprint information. The Field Name corresponding to the first part of the digital footprint data may include but not limited to IP Address, Registration Time, Submission Time, Add Payment Method Time, Add Payment Method Result, Failed Payment Remedial Action, Failed Payment Response Time and the like. The Field Name corresponding to the second part of the digital footprint data may include Device and the like. The correspondence between the first part and the second part of the digital footprint data and the Field Name of the digital footprint information may be determined in advance as desired.

Table 3

A credit report indicating the comprehensive credit overview of the target user could be generated based on the data already stored in off-blockchain database (s) . The credit report mainly includes (1) the personal particulars like name, identity card number, limited credit card and bank information, (2) the fraud alert due to suspicious and/or fraudulent activities done by the target user, (3) the credit score, (4) the recurring or delayed one-off payment affordability confidence level and (5) the historical and current payment records.

The unmasked personal particulars, the unmasked contracts, the unmasked fraud alert, the unmasked payment records, the unmasked credit data on the off-blockchain database (s) 25 could be retrieved through the API-enabled middleware 23 with proper authentication and authorization mechanism (e.g., Token-based authentication or certificate-based authentication) . The masked personal particulars, the masked contracts, the masked fraud alert, the masked payment records and the masked credit data on the blockchain database could be retrieved through the API-enabled middleware 23 with proper authentication and authorization mechanism. Correspondingly, the unmasked data could be cross-checked with the highly-immutable masked data from blockchain database by using some mathematical and/or computational methods (for example, cryptographic hashing function) to ensure the data integrity of the unmasked data.

In the current invention, the third-party application could integrate the API-end points of the API-enabled middleware 23 in their system. The third-party application also needs an access to the blockchain-network data, either via other third-party with self-hosted blockchain node or by obtaining the permission to host a blockchain node. The permission mechanisms of different permissioned blockchain systems vary but usually certificate authority (CA) is involved in the process. The third-party could obtain a digital certificate from a CA in which the CA’s information could be already configured or could be configured later in the blockchain. Alternatively, the third-party could host its own CA in which its CA digital certificate could be added into the blockchain and the third-party could obtain digital certificate by using its own CA. With the digital certificate, the third-party could host its blockchain node to synchronize the data from the blockchain. For permission-less blockchain, the blockchain node could be established without any permission.

A digital certificate refers to an electronic file to prove a public key is validated by a CA. The digital certificate usually contains an owner’s name, an owner’s public key, a digital signature and an issuer’s name. The digital signature is signed on the owner’s public key by an issuer’s private key. Anyone could check the validity of the owner’s public key by verifying the digital signature with the issuer’s public key which could be found in the issuer’s digital certificate, i.e., CA digital certificate.

When the third-party application requests the unmasked data of the target user, the target user is prompted to authorize the third-party application to retrieve their unmasked contracts, unmasked fraud alert, unmasked payment records and/or unmasked credit data from the off-blockchain database (s) . After the authorization, the third-party application still needs to provide certain key personal identifiers of the target user such as full name and identity card number to retrieve the unmasked data. For certain types of data, the salt used in hashing is also retrieved along with the unmasked data. To retrieve the masked data from the blockchain database, the third-party application needs to build its own API-enabled middleware 23 or uses pre-built API-enabled middleware 23 to connect to its own blockchain node. Alternatively, the third-party application could connect to other third-party’s blockchain node.

The unmasked data alone or along with the salt could be put into the cryptographic hashing function to obtain the output hash. The output hash could then be compared with the masked data retrieved from the blockchain database. The output hash should be completely consistent with the masked data if there is no data tampering occurring in the off-blockchain database (s) . A tiny change in the unmasked data could result in a completely different output hash. This is known as avalanche effect which is a feature of cryptographic hashing function. Implementations are not particularly limited in the present specification.

In the case of partial cryptography, the second part of the personal particular data, the second part of the fraud alert data, the second part of the contract data and the second part of the credit data are cross-checked. Specifically, the second part of the personal particular data, the second part of the fraud alert data, the second part of the contract data and the second part of the credit data in the off-blockchain database are compared with the second part of the personal particular data, the second part of the fraud alert data, the second part of the contract data and the second part of the credit data in the blockchain database 25, respectively. If the second part of the personal particular data, the second part of the fraud alert data, the second part of the contract data and the second part of the credit data in the off-blockchain database are consistent with the second part of the personal particular data, the second part of the fraud alert data, the second part of the contract data and the second part of the credit data in the blockchain database 25, respectively, the second part of the second part of the personal particular data, the second part of the fraud alert data, the second part of the contract data and the second part of the credit data in the off-blockchain database 25 are determined to be not tampered, respectively.

Because of the nature of the blockchain, all historical credit score of the target user could be retrieved, which could create an evolving credit score to better reflect the credit history of the target user.

The credit report could also be retrieved with an approach similar to the unmasked data being retrieved mentioned above.

The target customer using the credit data includes but not limited to lenders, banks, insurance companies, financial institutions, utility companies, due diligence companies, government entity.

According to another aspect of the current invention, a method for identifying credit rating of a target user in a payment is provided. Fig. 3 is a flow chart of a method for identifying credit rating of a target user in a payment. The method includes the following steps S100 to S300.

At the step S100, the contract data between a target user and a provider of target goods and/or target services is received.

At the step S200, the payment record data of the target user associated with the contract dada is received.

At the step S300, the credit data for the target user based on the contract data and the payment record data is generated.

The steps S100 and S200 may be implemented in the end-user application 21.

The step S300 may be implemented in the artificial intelligence-powered credit analytical engine 22.

The method further includes: masking at least a first part of at least one of the contract data, the payment record data and the credit data by a cryptography method, storing the masked first part of at least one of the contract data, the payment record data and the credit data in a blockchain database 24 and storing the first part, as unmasked first part of at least one of the contract data, the payment record data and the credit data, in an off-blockchain database 25, which are implemented in the application programming interface-enabled middleware 23.

Fig. 4 is a schematic diagram showing the process of cross-checking the contract data in a payment.

The rental contract raw data includes sensitive details, such as tenant name, tenant ID card num or BR num, landlord name, landlord ID card num or BR num, rent and the like (as a first part of the rental contract raw data) , and non-sensitive details, such as rental period, address and the like (as a second part of the rental contract raw data) . The first part of the contract data as insert raw data is put into the SHA-256 Hashing Function. Then the SHA-256 Hashing Function outputs the insert masked data of the rental contract raw data (masked first part) to the blockchain. If necessary, salts are added for certain data of the rental contract raw data before the rental contract raw data is masked. The salts could be stored along with the unmasked data in the same off-blockchain database 25 or separately into another off-blockchain database depending on the desired security level. Meanwhile, the first part of the rental contract raw data (unmasked first part) is stored in the off-blockchain database 25. The second part of the rental contract raw data as insert raw data is stored in both the blockchain database 24 and the off-blockchain database 25.

When the rental contract raw data is used, the masked first part is retrieved from the blockchain database 24 and the unmasked first part is retrieved from the off-blockchain database 25. The unmasked first part is put into the SHA-256 Hashing Function to obtain another masked first part (as output hashes) . The another masked first part is compared with the masked first part obtained from the blockchain database to implement cross-checking of the first part. The second part of the rental contract raw data retrieved from the blockchain database is compared with the second part of the rental contract raw data retrieved from the off-blockchain database 25 to cross-check the second part.

Fig. 5 is a schematic diagram showing the process of cross-checking the payment record data in a rental payment.

The rental payment raw data includes payer name, payer ID card num or BR num, payee name, payee ID card num or BR num, payment amount, pay date, payment method, and payment success or not, and the like. The entire rental payment raw data regarded as sensitive details is masked by the SHA-256 Hashing Function. If necessary, salts are added for certain data of the rental payment raw data before the rental payment raw data is masked. The salts could be stored along with the unmasked data in the same off-blockchain database 25 or separately into another off-blockchain database depending on the desired security level. The masked rental payment raw data is stored in the blockchain database. Meanwhile, the rental payment raw data (as unmasked rental payment raw data) is stored in the off-blockchain database 25.

When the rental payment raw data is used, the masked rental payment raw data is retrieved from the blockchain database and the unmasked rental payment raw data is retrieved from the off-blockchain database 25. The unmasked rental payment raw data is put into the SHA-256 Hashing Function to obtain another masked rental payment raw data. The another masked rental payment raw data is compared with the masked rental payment raw data retrieved from the blockchain database to implement cross-checking of the rental payment raw data.

Fig. 6 is a schematic diagram showing the process of cross-checking the credit data in a rental payment.

The credit raw data includes User name, User ID card number, credit score, recurring or delayed one-off payment affordability confidence level, timestamp, and the like. The entire credit raw data regarded as sensitive details is masked by the SHA-256 Hashing Function. If necessary, salts are added for certain data of the credit raw data level before the credit raw data is masked. The salts could be stored along with the unmasked data in the same off-blockchain database 25 or separately into another off-blockchain database 25 depending on the desired security level. The masked credit raw data is stored in the blockchain database. Meanwhile, the credit raw data (as unmasked credit raw data) is stored in the off-blockchain database 25.

When the credit raw data is used, the masked credit raw data is retrieved from the blockchain database and the unmasked credit raw data is retrieved from the off-blockchain database 25. The unmasked credit raw data is put into the SHA-256 Hashing Function to obtain another masked credit raw data. The another masked credit raw data is compared with the masked credit raw data retrieved from the blockchain database to implement cross-checking of the credit raw data.

The raw data (especially the confidential data) would not be exposed to the public via the blockchain by adopting the above methods and the related payment management system. Further, since the stored data on the off-blockchain database is verified for its correctness with its masked data on the blockchain database, the tampered stored data on the off-blockchain database could be found out and thus could be prevented from being used.

According to another aspect of the current invention, a non-transitory computer-readable storage medium with instructions stored thereon is provided. When executing the instructions, the processor performs the above method for storing data in a blockchain.

In the current invention, the sensitive data in the raw data could maintain the privacy, secrecy and/or correctness by masking sensitive data and storing the masked sensitive data in the blockchain database and storing the raw sensitive data in the off-blockchain database, and/or cross-checking the raw sensitive data in the off-blockchain database by the masked sensitive data in the blockchain database.

While the preferred embodiment of the present invention has been described in detail by the examples, it is apparent that modifications and adaptations of the present invention will occur to those skilled in the art. Furthermore, the embodiments of the present invention shall not be interpreted to be restricted by the examples or figures only. It is to be expressly understood, however, that such modifications and adaptations are within the scope of the present invention, as set forth in the following claims. For instance, individual features illustrated or described as part of one embodiment can be used on another embodiment in any combination desired to yield a still further embodiment. Thus, it is intended that the present invention cover such modifications and variations as come within the scope of the claims and their equivalents.

Claims

A method for storing data in a blockchain, comprising:

receiving data;

masking at least a first part of the data by a cryptography method;

storing the masked first part of the data in a blockchain database; and

storing the first part of the data, as unmasked first part of the data, in an off-blockchain database.
The method of claim 1, further comprising: storing a second part of the data in both the blockchain database and the off-blockchain database, wherein the second part of the data is different from the first part of the data.
The method of claim 1, wherein the masking at least a first part of the data comprises:

masking the entire data by the cryptography method;

storing the masked data in the blockchain database; and

storing the entire data, as unmasked data, in the off-blockchain database.
The method of claim 2, wherein after the storing the masked first part of the data and the storing the unmasked first part of the data, the method further comprises:

cross-checking the unmasked first part of the data with the masked first part of the data, and

wherein the masking at least a first part of the data by a cryptography method comprises masking the first part of the data by a cryptographic hashing function;

wherein the cross-checking the unmasked first part of the data with the masked first part of the data comprises:

putting the unmasked first part of the data into a same cryptographic hashing function as the cryptographic hashing function used to mask the first part of the data to obtain output hashes; and

comparing the output hashes with the masked first part of the data retrieved from the blockchain database.
The method of claim 4, wherein the masking the first part of the data by a cryptographic hashing function comprises:

adding salts into the first part of the data to obtain an intermediate first part of the data; and

putting the intermediate first part of the data into the cryptographic hashing function to obtain the masked first part of the data.
The method of claim 5, further comprising:

storing the salts together with the unmasked first part of the data in the off-blockchain database.
The method of claim 2, wherein after the storing a second part of the data, the method further comprises cross-checking the second part of the data in the off-blockchain database with the second part of the data in the blockchain database, which comprises:

comparing the second part of the data retrieved from the off-blockchain database with the second part of the data retrieved from the blockchain database.
A payment management system, comprising:

an end-user application configured to receive raw data, wherein the raw data at least comprises contract data between a target user and a provider of target goods and/or target services, and payment record data of the target user associated with the contract dada;

an artificial intelligence-powered credit analytical engine configured to generate credit data for the target user based on at least the contract data and the payment record data; and

an application programming interface-enabled middleware configured to:

mask at least a first part of at least one of the contract data, the payment record data and the credit data by a cryptography method;

store the masked first part of at least one of the contract data, the payment record data and the credit data in a blockchain database; and

store the first part, as unmasked first part, of at least one of the contract data, the payment record data and the credit data, in an off-blockchain database.
The payment management system of claim 8, wherein the application programming interface-enabled middleware is further configured to:

store a second part of the contract data in both the blockchain database and the off-blockchain database, wherein the second part of the contract data is different from the first part of the contract data.
The payment management system of claim 9, wherein the application programming interface-enabled middleware is further configured to:

mask the entire payment record data and the entire credit data by the cryptography method;

store the masked payment record data and the masked credit data in the blockchain database; and

store the entire payment record data as unmasked payment record data and the entire credit data as unmasked credit data, in the off-blockchain database.
The payment management system of claim 8, wherein the application programming interface-enabled middleware is further configured to:

mask the entire contract data, the entire payment record data and the entire credit data by the cryptography method;

store the masked contract data, the masked payment record data, and the masked credit data in the blockchain database; and

store the entire contract data as unmasked contract data, the entire payment record data as unmasked payment record, and the entire credit data as unmasked credit data, in the off-blockchain database.
The payment management system of claim 10, wherein the application programming interface-enabled middleware is configured to mask at least the first part of the contract data, the entire payment record data and the entire credit data by a cryptographic hashing function.
The payment management system of claim 12, wherein the application programming interface-enabled middleware is further configured to:

add salts into the first part of the contract data, the entire payment record data and the entire credit data to obtain an intermediate first part of the contract data, an intermediate payment record data, and an intermediate credit data respectively; and

put the intermediate first part of the contract data, the intermediate payment record data, and the intermediate credit data into the cryptographic hashing function to obtain the masked first part of the contract data, the masked payment record data, and the masked credit data respectively.
The payment management system of claim 13, wherein the application programming interface-enabled middleware is further configured to:

store the salts together with the unmasked first part of the contract data, the unmasked payment record data and the unmasked credit data in the off-blockchain database.
The payment management system of claim 14, wherein the application programming interface-enabled middleware is further configured to:

cross-check the unmasked first part of the contract data, the unmasked payment record data and the unmasked credit data with the masked first part of the contract data, the masked payment record data and the masked credit data respectively,

wherein the cross-checking the unmasked first part of the contract data, the unmasked payment record data and the unmasked credit data comprises:

putting the unmasked first part of the contract data, the unmasked payment record data and the unmasked credit data, and corresponding salts into the same cryptographic hashing functions as the cryptographic hashing function used to mask the first part of the data, the payment record data and the credit data respectively to obtain output hashes; and

comparing the output hashes with the masked first part of the contract data, the masked payment record data and the masked credit data retrieved from the blockchain database respectively.
The payment management system of claim 15, wherein the application programming interface-enabled middleware is further configured to:

cross-check the second part of the contract data,

wherein the cross-checking the second part of the contract data comprises:

comparing the second part of the contract data retrieved from the off-blockchain database with the second part of the contract data retrieved from the blockchain database.
The payment management system of claim 8, wherein

the artificial intelligence-powered credit analytical engine is further configured to generate a fraud alert indicating a fraud level with description based on fraudulent and/or suspicious activities done by the target user, and

the application programming interface-enabled middleware is further configured to:

mask at least a first part of the fraud alert data by a cryptography method;

store the masked first part of the fraud alert data in the blockchain database; and

store the first part of the fraud alert data as unmasked first part of the fraud alert data and an second part of the fraud alert data in the off-blockchain database, wherein the first part of the fraud alert data is different from the second part of the fraud alert data,

or, the application programming interface-enabled middleware is further configured to:

mask the entire fraud alert data by a cryptography method;

store the masked fraud alert data in the blockchain database; and

store the fraud alert data, as unmasked fraud alert data, in the off-blockchain database.
The payment management system of claim 8, wherein the artificial intelligence-powered credit analytical engine is further configured to generate a credit report data indicating the comprehensive credit overview of the target user based on the data stored in the off-blockchain database; and

the application programming interface-enabled middleware is further configured to:

mask at least a first part of the credit report data by a cryptography method;

store the masked first part of the credit report data in the blockchain database; and

store the first part of the credit report data as unmasked first part of the credit report data and an second part of the credit report data in the off-blockchain database, wherein the first part of the credit report data is different from the second part of the credit report data,

or, the application programming interface-enabled middleware is further configured to:

mask the entire credit report data by a cryptography method;

store the masked credit report data in the blockchain database, and

store the credit report data, as unmasked credit report data, in the off-blockchain database.
The payment management system of claim 8, the artificial intelligence-powered credit analytical engine is further configured to:

generate an initial credit score data based on a provided payment method, tenancy information, company search results and criminal record check; and

assign the initial credit score data to the target user, and

the application programming interface-enabled middleware is further configured to:

mask at least a first part of the initial credit score data by a cryptography method;

store the masked first part of the initial credit score data in the blockchain database; and

store the first part of the credit report data as unmasked first part of the initial credit score data and an second part of the initial credit score data in the off-blockchain database, wherein the first part of the initial credit score data is different from the second part of the initial credit score data,

or, the application programming interface-enabled middleware is further configured to:

mask the entire initial credit score data by a cryptography method;

store the masked initial credit score data in the blockchain database; and

store the initial credit score data, as unmasked initial credit score data, in the off-blockchain database.
The payment management system of claim 10, wherein the application programming interface-enabled middleware is further configured to:

allow a third-party application to retrieve the unmasked first part of the contract data, the second part of the contract data, the unmasked payment record data, and the unmasked credit data in the off-blockchain database, and retrieve the masked first part of the contract data, the second part of the contract data, the masked payment record data, and the masked credit data in the blockchain database by an application programming interface.
The payment management system of claim 8, wherein the artificial intelligence-powered credit analytical engine is further configured to recalculate the credit data when a new successful payment record or a new failed payment record occurs.
A non-transitory computer-readable storage medium storing instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1-7.