LDA KYC requirements

[riclas]

In order to facilitate the creation of a uniform KYC process via fiatlink here is the required data to be collected from a client of a portuguese VASP:

Photography *
Full name *
Signature *
Date of birth *
Nationality stated on the identification document *
Type, number, expiration date and issuing entity of the identification document *
Tax identification number or, when there is no tax identification number, the equivalent number issued by a competent foreign authority
Profession and employer, if any (in case of unemployment or retirement, we must collect information about the last profession held)
Full address of permanent residence and, when different, tax residence
Country of Birth
Other nationalities not included in the identification document

• These elements must be proven by presenting valid identification documents.

We collect a photo of the ID document front and back and a selfie of the user, all live, no stored photos accepted

[aljazceru]

@riclas are you collecting this yourself or are you using a 3rd party service to do kyc?

[riclas]

we use a third party service to collect the photo of the document and selfie, the rest we collect on our website.

[Amperstrand]

An interesting question is what the workflow for fiatlink should look like.

A wallet would first make a call to /session to request a session. This gives the wallet a session_id, or an identify.

A broker might be required to tie the session_id to a real-world identity.

One way to to do this would be to initially use low limits. For example allow the user to buy a symbolic amount of bitcoin or a low risk amount of fiat. The amount could for example be somewhere between 10 000 sats and 1000 euro.

The purpose of this initial transaction is both that it allows a user to onboard quickly, but also that it allows the broker to tie the session-id with metadata about the name (possibly address or card number) of the bank account uses to pay for the purchase.

Now that the broker is able to tie the session_id to a name, they can collect additional documentation as required and adjust the limits. One of the endpoints (maybe the /verify endpoint) could have a URL where the user is directed to log in and/or answer questions as required.

If the broker is not allowed to let the session_id to place orders for whatever reason, attempts to access /quote or /order could result in an error message telling the user that they need to /verify the session again.

So an error message could be something like:

Please go to brokerservice.com/session_id to continue using this fiatlink service. At this URL, the broker could collect required information and then activate the session_id again.

Another thing is that some bank accounts might be able to accept bitcoin because the owner of the bank account is a customer with the broker. So for example if a mobile phone provider is a customer of the broker, their IBAN number might be on a whitelist of accounts that the broker can make payments to without having to know the identity of the payer. In this case, you should be able to use fiatlink without a KYC'ed sessionid to say "please pay $42 to T-Mobile IBAN X with message "customer number X", and given IBAN X is whitelisted because T-Mobile is a KYC'ed customer of the broker, this payment might be possible to make because the KYC is part of the transaction (T-mobile knows who customer X is).

So a call to fiatlink to get a quote to pay $42 to T-mobiles account might be successful whereas a call to fiatlink to pay $40000 to an unknown account might require KYC from the sender. Different fiatlink providers might allow different payments because provider A knows that this is the account belonging to T-mobile and provider B does not or has different regulatory rules.