[taler-docs] 03/03: update DD23 requirements

[gnunet]

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

grothoff pushed a commit to branch master
in repository docs.

commit e5cdc25062f0941d5ad9f8e4e8a3b2c6671abc68
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun Mar 17 14:26:18 2024 +0100

    update DD23 requirements
---
 design-documents/023-taler-kyc.rst | 38 ++++++++++++++++++++++++++++++++------
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/design-documents/023-taler-kyc.rst 
b/design-documents/023-taler-kyc.rst
index 18f867bf..44275a94 100644
--- a/design-documents/023-taler-kyc.rst
+++ b/design-documents/023-taler-kyc.rst
@@ -81,13 +81,23 @@ Finally, we need to produce statistics:
 * 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
 =================
 
@@ -95,15 +105,29 @@ 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 mode (normal, held on staff, held on user, frozen)
+* The specific operational state (normal, held on staff, held on user, frozen)
   the account is to transition to
-* What to show to the user (normal, information required, pending, etc.)
-* For a user:
+* 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 run (if any) and measures on failure
+  * 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 data provided in the 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
@@ -123,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.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.