[taler-docs] branch master updated (657f5135 -> e5cdc250)

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a change to branch master
in repository docs.

    from 657f5135 DD46: move token_types to top level to reduce duplication
     new 8c15fb22 update DD23 requirements
     new 7bdff12a update DD23 requirements
     new e5cdc250 update DD23 requirements

The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 design-documents/023-taler-kyc.rst | 88 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 86 insertions(+), 2 deletions(-)

diff --git a/design-documents/023-taler-kyc.rst 
b/design-documents/023-taler-kyc.rst
index d34241d7..44275a94 100644
--- a/design-documents/023-taler-kyc.rst
+++ b/design-documents/023-taler-kyc.rst
@@ -44,11 +44,92 @@ 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)
+
+For this high-level monitoring, we need certain designated critical events to
+be tracked in the system statistics:
+
+  * account opened
+  * set to high risk
+  * set to low risk
+  * suspicious activity report filed with authority
+  * account frozen
+  * account unfrozen
+  * account closed
+
+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
 =================
 
+We allow certain **conditions** to trigger a single specific **measures**.
+For the different measures, we define:
+
+* Who has to do something (AML staff, user, nobody)
+* The specific operational state (normal, held on staff, held on user, frozen)
+  the account is to transition to
+* Specification of required context inputs (w. templating, e.g. amount set 
dynamically)
+* What state to show to the user (normal, information required, pending, etc.)
+* For user-interactive states:
+
+  * Web page template with instructions to render
+  * The check to set up (if any) and measure on failure
+  * An external helper to run on success to determine the next measure
+    based on context and data provided in the measure
+
+* For (AML) staff-interactive states the UI provides the ability to:
+
+  * file forms and upload documentation (without state transition)
+  * decide on next measure (providing context); here, the exchange needs
+    to expose the list of available measures and required context for each
+
+* Non-interactive measures (normal operation, account frozen) need:
+
+  * Expiration time (in context)
+  * Measure to trigger upon expiration, again with context
+    (renew documents, resume normal operation, etc.)
+
+
+
 Terminology
 ^^^^^^^^^^^
 
@@ -66,6 +147,8 @@ Terminology
 
 * **Logic**: Logic refers to a specific bit of code (realized as an exchange 
plugin) that enables the interaction with a specific *provider*.  Logic 
typically requires *configuration* for access control (such as an authorization 
token) and possibly the endpoint of the specific *provider* implementing the 
respective API.
 
+* **Measure**: Describes the possible outgoing edges from one state in the 
state machine (including how to show the current state).
+
 * **Provider**: A provider performs a specific set of *checks* at a certain 
*cost*. Interaction with a provider is performed by provider-specific *logic*.
 
 * **Type of operation**: The operation type determines which Taler-specific 
operation has triggered the KYC requirement. We support four types of 
operation: withdraw (by customer), deposit (by merchant), P2P receive (by 
wallet) and (high) wallet balance.
@@ -103,8 +186,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.