fiatconnect / specification

FiatConnect API Specification
28 stars 21 forks source link

feat: Brazilian standard require idNumber, back document and email fo… #85

Closed ailsoncgt closed 1 year ago

ailsoncgt commented 1 year ago

kyc validation

ailsoncgt commented 1 year ago

@jophish I made a new commit

ailsoncgt commented 1 year ago

@cajubelt in my new commit I removed idNumber. I confirmed that it is not actually required. About the field you suggested, documentType, for our purpose it would be a dead field, because it will not be evaluated in real time for the KYC result. And without it, the scheme is open for other providers to receive other types of documents. I indicated the RG, RNM and CNH because they are the documents accepted in Brazil and consequently by our KYC provider. But the provider already recognizes the document type at the time of submission.

jophish commented 1 year ago

@ailsoncgt I believe the intent of the documentType field is to disambiguate, for the client what kind of document is required. For example, if documentType could be one of RG, RNM, or CNH, then you, as a provider can set allowedValues to ["RG", "RNM", "CNH"], which indicates to the client that the user must submit one of those documents, and the client can then provide the specific means to the end-user to do so. If another provider wants to re-use this schema, but only supports, say, RG, then they can set their allowedValues field for documentType to just ["RG"]. If another provider comes along and wants to add support for a new document type, they can do so by extending the list of valid document types and setting their allowedValues field as required.

TLDR, documentType is important in order to allow providers to extend this schema, so that clients can communicate to end-users exactly what kind of document(s) the provider is requesting.

cajubelt commented 1 year ago

superceded by #92