update DD23 requirements

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