From 8c15fb22511d8d536190aaddb720a8de82b3a8a3 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 17 Mar 2024 12:04:44 +0100 Subject: update DD23 requirements --- design-documents/023-taler-kyc.rst | 45 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst index d34241d7..39a414e4 100644 --- a/design-documents/023-taler-kyc.rst +++ b/design-documents/023-taler-kyc.rst @@ -44,6 +44,46 @@ Taler needs to run KYC checks in the following circumstances: * key: reserve (=KYC account) long term public key per wallet (encoded as payto:// URI) +There are many different possible KYC/AML flows: + +* In-person validation by AML staff +* Validation involving local authorities and post-office +* Online validation + * Forms to be supplied by user + * Interactive video + * Documents to be supplied +* Forms to be filled by AML staff + +Additionally, the process is dynamic and conditional upon various decisions: + +* Individual vs. business +* PEP or non-PEP +* Hit on sanctions list +* Type of business (trust, foundation, listed on stock market, etc.) +* Need for plausibilization (via documents by user or staff research) +* Periodic updates (of customer data, of sanction lists) and re-assessment + +There are also various outcomes: + +* normal operation +* normal operation but with AML staff investigating +* held, requesting customer documentation +* held, AML staff reviewing evidence +* automatically frozen until certain day (due to sanctions) +* institutionally frozen until certain day (due to order by state authority) + +Finally, we need to produce statistics: + +* number of incidents reported (voluntarily, required) +* number of business relationships at any point in time +* number of risky business relationships (PEP, etc.) +* begin/end-date of relationships (data retained for X years after end of relationship) + +As a result, we largely end up in a large state machine where the AML staff has +serious flexibiltiy while the user needs guidance as to the possible next moves +and/or to the current state of their account (where some information must not be +disclosed). + Proposed Solution @@ -103,8 +143,9 @@ Access is ``authenticated`` by also passing the hash of the payto://-URI. initiate a KYC process are not very sensitive.) Given this triplet, the ``/kyc-check/`` endpoint returns either the (positive) KYC status or redirects the client (202) to the next required stage of the KYC process. The -redirection must be for an HTTP(S) endpoint to be triggered via a simple HTTP GET. As this endpoint is involved in every KYC check at the beginning, this is also the place where we can -integrate the payment process for the KYC fee. +redirection must be for an HTTP(S) endpoint to be triggered via a simple HTTP +GET. As this endpoint is involved in every KYC check at the beginning, this +is also the place where we can integrate the payment process for the KYC fee. The specific KYC provider to be executed depends on the configuration (see below) which specifies a ``$PROVIDER_SECTION`` for each authentication procedure. -- cgit v1.2.3