commit 8c15fb22511d8d536190aaddb720a8de82b3a8a3
parent 657f5135d0d8b8d5af2d6ed3c24738c86db7a54d
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sun, 17 Mar 2024 12:04:44 +0100
update DD23 requirements
Diffstat:
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git 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.
