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

[ailsoncgt]

kyc validation

[cajubelt]

if you require idNumber, email, and identificationDocumentBack, then they shouldn't be optional fields. The question mark indicates that the field is optional.

[cajubelt]

Also, I recommend that you create a new KYC schema for these fields, rather than tacking them onto an existing one. Adding a new KYC schema is a non-breaking change, since clients can incrementally add support for new schemas without breaking their existing integrations. However, changing an existing KYC schema is generally a breaking change, and something to avoid without some compelling reason for it

[jophish]

Can you provide some more detailed information on the fields required in this schema? (For example, how phoneNumber should be formatted, what the idNumber represents and how it should be formatted, etc.) It might seem a bit pedantic but it's important that we document the exact syntax of these fields.

[ailsoncgt]

ok @jophish , I will do that.

[ailsoncgt]

@jophish I made a new commit

[cajubelt]

what kind of identity document is accepted? Any? Or just CPF cards? The description of the schema should probably go into this-- we're currently running into trouble with another KYC schema due to the ambiguity there on what document types are acceptable.

If it's CPF only, the schema should probably also be renamed.

[ailsoncgt]

@cajubelt the docs are those accepted as an official identification document in Brazil: RG, CNH, RNM

[cajubelt]

this schema name is misleading because it sounds more general than it actually is. Currently the constraints on document type, phone number and ID make this specific to Brazilian KYC checks.

[cajubelt]

all 3 of these documents have CPF on them, which the image would presumably include. Does idNumber still need to be its own field? Seems like it could be redundant, though I don't know the details of how you're doing KYC checks..

[cajubelt]

if you can drop the idNumber field, or clarify that it needs to be CPF specifically for the case where some new field like documentType is equal to RG, CNH, or RNM, then you could potentially make this schema more general / reusable across regions

[cajubelt]

which could be helpful for other providers and consumers of the FC API

[ailsoncgt]

@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]

@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]

superceded by #92