[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] 01/03: update DD23 requirements
From: |
gnunet |
Subject: |
[taler-docs] 01/03: update DD23 requirements |
Date: |
Sun, 17 Mar 2024 14:26:28 +0100 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository docs.
commit 8c15fb22511d8d536190aaddb720a8de82b3a8a3
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun Mar 17 12:04:44 2024 +0100
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.
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.