Ideas on KYC Implementation

Question

I am about to implement a KYC solution on Multichain, part of a few things we are doing, and would like some feedback:

1. Create a chain called "KYC"
2. Add a stream called KYC (or leave as root)
3. Add publishers who are recognized as able to do KYC for customers or merchants
4. Publishers write a stream with the key being a a hash of the user full name and email, or the company name, country code and registration number, and the data being their company name followed by KYC1, KYC2, KYC3 for users and KYCA, KYCB etc for merchants. the KYC code would be standard to show what level of KYC was done. Would be nice if I could have another field to separate the publisher name and the KYC status
5. API provided so any company can check on KYC status of a user, so they don't have to do it again. User has to provide their name and email so that can be checked against the hash.
6. KYC Publishers have access to the blockchain explorer if needed.

I don't see a need for encryption of data in this case - what we are doing is putting up simple virtual identities that can be checked by KYC publishers or companies that we give access via the API - we could charge a tiny amount for finding a valid KYC status that can go to the publisher to help offset or pay for costs of doing the KYC in the first place (This would be done via the API, no in blockchain)

So that's a simple setup, if there is anything anyone can add to improve on it?

Answer 1

we have just completed a KYC solution. we used addresses for each actor and streams to represent the trail. We used a SQL database to store process flow and anchored data into the chain. Multichain was great for this.
The approach vs yours is that we have a stream per publisher and addresses for all


I cannot comment on your business model or pricing.

Comments

Interesting, I will have to check your method as well...with what I proposed I would have a stream for a user, which could be checked by searching the key, and the publisher stream can be seen from his account address.

Answer 2

This is the approach we could recommend – using a stream and having the keys of stream items represent the identify of the entities on which KYC is being done. You don't need a separate field for the publisher because the publisher is signing the transaction anyway, and their address is shown with each stream item. And if you want to map publisher addresses to publisher names, you could use a separate stream for that.

Note also that you can always put compound objects in the payload of stream items, e.g. JSON converted from text to hex. MultiChain 2.0 will support JSON directly, so this approach would give you an easy transition.