Page Comparison

PLEASE NOTE: This is just a draft idea, exploring some possibilities of the FIO protocol. It is NOT final or even suggesting at this time a path for FIO to take.

The traditional financial world, for better or for worse, works with verified identity through KYC (Know Your Customers) and AML (Anti-Money Laundering) compliance requirements. Even though this is only 0.1% effective at preventing crime, it is the reality we live in today (until we change it). Some examples of the problem:

...

And yet, if FIO wants to help the billions of unbanked people who want access to decentralized open finance tools while also providing a decentralized (as opposed to centralized or federated) solution for those who still have to play the KYC/AML game, we should look at creating verified FIO handlesaddresss. Depending on the need, this may end up driving the decentralized business strategy for the FIO Protocol which benefits all participants as the network effect grows. Billions of people and the many thousands of organizations that want to serve them have a problem FIO is uniquely positioned to solve.

Problem

I want to interact with a real human being, not someone claiming to be someone else (or 1,000 someone else's). I don’t want to store the KYC or profile information for that human on my servers. I may not want to do KYC at all and just want verification that some other organization I trust did do KYC. If I do KYC, I want a mechanism to, with the permission of the human, expose aspects of that KYC to third parties, and be rewarded for it.

Imagine how much we could improve the credit process if Equifax, Experian, and TransUnion were decentralized and the data they collect was in our control?

Solution

I’ll walk through an example to explain how FIO might help with this situation.

John Doe controls the FIO Handle address john@doe via their private key.

...

With data decrypted as:

...

{
	"account": "abcdefghijkl",
	"fio_handleaddress": "john@doe",
	"data": ["first_name", "last_name", "date_of_birth", "country_of_citizenship", "country_of_residence"]
}

{
	"account": "abcdefghijkl",
	"fio_handleaddress": "john@doe",
	"data": ["John", "Doe", "1/1/1980", "United States", "Puerto Rico"]
}

...

...

with data being:

...

Upon login to Organization D, if any of the validations used for verification have been updated for liveness, a new, updated record can be saved for that organization.

Useful Data

Some organizations presumedly want additional information about the user like their name or maybe their country, email, age, income, purchasing preferences, etc. Each time this information is requested, instead of giving it to the company which would then have to store it in a central location which becomes a target for data breaches and GDPR concerns, it can be stored encrypted on chain.

...

{
	"vouchers": [{
		"validator_account": "bbbbbbbbbbb",
		"validator_fio_handleaddress": "kyc@b",  
		"vouchers_index": 0
	}, {
		"validator_account": "bbbbbbbbbbb",
		"validator_fio_handleaddress": "kyc@b",  
		"vouchers_index": 1
	}]
}

...

{
	"data": [{
			"first_name": {
				"profile_index": 0,
				"scope": "abcdefghijkl", 
				"value": "John",
				"value_secret": "5K7H5Ai2m86VFd3AByrX1d3R6Wbwv6dajJ4CvWHs3fCtkYVJ6yW",
				"vouchers": [{
					"validator_account": "bbbbbbbbbbb",
					"validator_fio_handleaddress": "kyc@b",
					"vouchers_index": 1,
					"voucher_secret": "5K3ztTvNeKrydGFLVPXYJJm5AzhXgo995B4kQtXXdvBZxVqssAb"
				}, {
					"validator_account": "dddddddddddd",
					"validator_fio_handleaddress": "kyc@d",
					"vouchers_index": 3,
					"voucher_secret": "5KNygU3Qw8UdzXo5qBNouzk6Tyo8A5qf9yUDc2kYHPPA8SWf6yh"
				}]
			}
		},
		{
			"last_name": {
				"profile_index": 1,
				"scope": "abcdefghijkl", 
				"value": "Doe",
				"value_secret": "5KQFBfLWZPSvt4Z3GRh4Qv54UoLh1pfup7vnDV6dMZLCfCd786T",
				"vouchers": [{
					"validator_account": "bbbbbbbbbbb",
					"validator_fio_handleaddress": "kyc@b",
					"vouchers_index": 1,
					"voucher_secret": "5K3ztTvNeKrydGFLVPXYJJm5AzhXgo995B4kQtXXdvBZxVqssAb"
				}, {
					"validator_account": "dddddddddddd",
					"validator_fio_handleaddress": "kyc@d",
					"vouchers_index": 3,
					"voucher_secret": "5KNygU3Qw8UdzXo5qBNouzk6Tyo8A5qf9yUDc2kYHPPA8SWf6yh"
				}]
			}
		}, {
			"email": {
				"profile_index": 3,
				"scope": "abcdefghijkl", 
				"value": "john.doe@example",
				"value_secret": "5KSXxW9Uhiwuzf8ZfiC6yjeCaw94prVQHGmRyPR151hsmgxUzUx",
				"vouchers": [{
					"validator_account": "bbbbbbbbbbb",
					"validator_fio_handleaddress": "kyc@b",
					"vouchers_index": 1,
					"voucher_secret": "5K3ztTvNeKrydGFLVPXYJJm5AzhXgo995B4kQtXXdvBZxVqssAb"
				}]
			}
		}
	]
}

...

Ideally we could add a “request for request” which would allow the validator to say “Send me a request for this amount so I can pay you for releasing this information to this organization.” The micro payment amount the organization pays to the validator when requesting the information would be more than the micro payment made to the person and the difference would be the validator’s profits.

Conclusion

This plan outlines a way for users to selectively validate their identity and personal information with multiple KYC vendors who don’t have to store the information on their local servers. Organizations requesting information can do so directly from the individual and receive a key to decrypt that information from the chain anytime they want it. They can also request validation of that information from the KYC provider that validated it. The user has the control to selectively expose which validators have verified their information and who can access that information in the future. The security focus of the validation company can now be entirely about key management instead of data management.

...