Method, apparatus, and computer-readable medium for secured multi-lateral data exchange over a computer network

1. A method for secured, multi-lateral, assured data transfer over a computer network for the exchange of data D 1 related to qualifying transactions, the method being accomplished by a distributed computing system including a distributed ledger platform and a data host platform, the method comprising:

(a) transferring, from a sending party to a receiving party, access rights to D 1 , the transferring including:

the sending party generating an encryption key, K 1 , and encrypting D 1 with K 1 using a symmetric encryption algorithm to create encrypted data D 1 *;

the sending party transmitting D 1 * to the data host platform, wherein the data host platform cannot access D 1 ;

the sending party receiving a pointer to D 1 * , the pointer a universal resource identifier D 1 *ID that corresponds to D 1 *;

the sending party encrypting K 1 with a public key of the receiving party using an asymmetric encryption algorithm to create an encrypted key K 1 *;

the sending party signing an Issue transaction via a WalletRegistry smart contract on a distributed ledger platform to create an AuthToken, that is a transferrable non-fungible token on a distributed ledger that expresses a data structure containing D 1 *ID, K 1 *, and other data such as access policies; and

transferring the AuthToken to a cryptographic wallet associated with the receiving party; and

(b) accessing D 1 by the receiving party, the accessing including:

the receiving party signing an Access transaction via the WalletRegistry smart contract on the distributed ledger platform resulting in the creation of a session ID, S 1 ;

the receiving party sending an access request for D 1 * to the data host platform including S 1 and D 1 *ID;

the data host platform validating the request platform by calling the WalletRegistry smart contract on the distributed ledger platform which consults data authorization policy for validation;

in response to the validating, the data host, encrypting D 1 * with the public key of the recipient using asymmetric encryption, resulting in D 1 **, and sending D 1 ** to the receiving party; and

the receiving party decrypting D 1 ** using the receiving party's private key using asymmetric encryption resulting in D 1 *, decrypting the encryption key K 1 * with the receiving party's private key using asymmetric encryption resulting in K 1 , and decrypting the escrowed data D 1 * with the encryption key K 1 using symmetric encryption resulting in D 1 to thereby gain access to the data D 1 .

2. The method of claim 1 , wherein D 1 includes personally identifying information (PII) related to participants in regulated financial transactions between financial intermediaries including an Originating Virtual Asset Service Provider (VASP), a Beneficiary VASP, and as least one regulator and wherein steps (a) and (b) are conducted a first time and a second time to accomplish a first transfer/access process and a second transfer/access process and wherein:

the first transfer/access process is between the Originating VASP as the sending party and the at least one regulator as the receiving party with D 1 being PII associated with the owner of the originating wallet in a transaction, the transfer resulting in the registration of the originating wallet as a certified address;

the second transfer/access process is between the Beneficiary VASP as the Sender and the Regulator as the receiving party with D 1 being PII associated with the owner of the beneficiary wallet in a transaction, the transfer resulting in the registration of the originating wallet as a certified address; and

wherein, receiving parties access the data required to meet regulatory requirements after a qualifying transaction occurs.

3. The method of claim 2 , wherein steps (a) and (b) are conducted a third time and a fourth time to accomplish a third transfer/access process and a fourth transfer/access process and wherein:

the third transfer/access process is between the Originating VASP as the sending party and the Beneficiary VASP as the receiving party with D 1 being PII associated with the owner of the originating wallet in a transaction; and

the fourth transfer/access process is between the Beneficiary VASP as the sending party and the Originating VASP as the receiving party with D 1 being PII associated with the owner of the beneficiary wallet in a transaction.

4. The method of claim 1 wherein steps (a) and (b) are conducted 4 times to accomplish a first transfer/access process, a second transfer/access process, a third transfer/access process and a fourth transfer/access process and wherein:

the first transfer between the Originator as the sending party and the Originating VASP as the receiving party with D 1 being PII associated with the owner of the originating wallet in a transaction, the transfer resulting in the registration by the Originating VASP of the originating wallet as a certified address;

the second transfer between the Beneficiary as the sending party and the Beneficiary VASP as the receiving party with D 1 being PII associated with the owner of the beneficiary wallet in a transaction, the transfer resulting in the registration by the Beneficiary VASP of the originating wallet as a certified address;

the third transfer between the Originating VASP as the sending party and the Beneficiary VASP as the receiving party with D 1 being PII associated with the owner of the originating wallet in a transaction;

the fourth transfer between the Beneficiary VASP as the sending party and the Originating VASP as the receiving party with D 1 being PII associated with the owner of the beneficiary wallet in a transaction; and

wherein receiving parties access the data to meet regulatory requirements.

5. The method of claim 1 , wherein the process for generating or validating a session ID S 1 in the Wallet Registry smart contract includes:

retrieving, interpreting, and enforcing an access policy, if assigned the to AuthToken, to determine whether to initiate the access session, where the policy may include rules regarding the qualifying attributes of a transaction, sending party, receiving party, or other context.

6. The method of claim 1 , wherein each non-fungible digital token is expressed as a data structure that contains:

AuthTokenlID (a unique token identifier),

AccessKey (K 1 * above),

DataID (D 1 *ID),

PolicyID (for identifying a policy to be applied/enforced by policy engine),

Source (Owner of data),

Client Wallet Address (or account identifier),

Data Verification Entity.

7. The method of claim 1 , further comprising retrieving, interpreting, and enforcing an access policy, assigned the to AuthToken, to determine prior to the access step, wherein the policy includes one or more of rules regarding the qualifying attributes of a transaction, a sending party, a receiving party, and transaction context.

8. An apparatus for secured, multi-lateral, assured data transfer over a computer network for the exchange of data D 1 related to qualifying transactions, the apparatus including a distributed ledger platform and a data host platform, the apparatus comprising:

at least one computer processor; and

at least one memory device having instructions sotred thereon which, when executed by the at least one processor cause the apparatus to accomplish the method of:

(a) transferring, from a sending party to a receiving party, access rights to D 1 , the transferring including:

the sending party generating an encryption key, K 1 , and encrypting D 1 with K 1 using a symmetric encryption algorithm to create encrypted data D 1 *;

the sending party transmitting D 1 * to the data host platform, wherein the data host platform cannot access D 1 ;

the sending party receiving a pointer to D 1 *, the pointer a universal resource identifier D 1 *ID that corresponds to D 1 *;

the sending party encrypting K 1 with a public key of the receiving party using an asymmetric encryption algorithm to create an encrypted key K 1 *;

the sending party signing an Issue transaction via a WalletRegistry smart contract on a distributed ledger platform to create an AuthToken, that is a transferrable non-fungible token on a distributed ledger that expresses a data structure containing D 1 *ID, K 1 *, and other data such as access policies; and

transferring the AuthToken to a cryptographic wallet associated with the receiving party; and

(b) accessing D 1 by the receiving party, the accessing including:

the receiving party signing an Access transaction via the WalletRegistry smart contract on the distributed ledger platform resulting in the creation of a session ID, S 1 ;

the receiving party sending an access request for D 1 * to the data host platform including S 1 and D 1 *ID;

the data host platform validating the request platform by calling the WalletRegistry smart contract on the distributed ledger platform which consults data authorization policy for validation;

in response to the validating, the data host, encrypting D 1 * with the public key of the recipient using asymmetric encryption, resulting in D 1 **, and sending D 1 ** to the receiving party; and

the receiving party decrypting D 1 ** using the receiving party's private key using asymmetric encryption resulting in D 1 *, decrypting the encryption key K 1 * with the receiving party's private key using asymmetric encryption resulting in K 1 , and decrypting the escrowed data D 1 * with the encryption key K 1 using symmetric encryption resulting in D 1 to thereby gain access to the data D 1 .