update DD23 requirements

1 files 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.