more KYC thoughts

1 files changed, 68 insertions, 14 deletions

diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst
index 21df9d43..01e3ec7f 100644
--- a/design-documents/023-taler-kyc.rst
+++ b/design-documents/023-taler-kyc.rst
@@ -143,6 +143,46 @@ For the different *measures*, we define:
     (renew documents, resume normal operation, etc.)
 
 
+We need some customer-driven interactivity in KYB/KYC process, for example the
+user may need to be given choices (address vs. phone, individual vs. business,
+order in which to provide KYC data of beneficiaries). As a result, the
+exchange needs to serve some "master" page for measures where the user is
+shown the next step(s) or choices (which person to collect KYC data on,
+whether to run challenger on phone number of physical address, etc.).
+That page should also potentially contain a form to allow the customer to
+directly upload documents to us (like business registration) instead of to
+some KYC provider. This is because KYC providers may not be flexible
+enough.
+
+Similarly, the AML staff will need to be able to trigger rather complex
+KYB/KYC processes, like "need KYC on X and Y and Z" or "phone number or
+mailing address" or "please upload form A/T/S".  Here in particular it
+should be possible to request not only filled forms, but arbitrary
+documents.
+
+
+Documentation
+^^^^^^^^^^^^^
+
+* We must define risk-profile (902.4, 905.1)
+* We must document the specific setup, likely not just the INI file
+* We probably should have some key AMLA file attributes, such as:
+
+  * File opened, file closed (keep data for X years afterwards!)
+  * low-risk or high-risk business relationship
+  * PEP status
+  * business domain
+  * authority notification dates (possibly multiple) with
+    voluntary or mandatory notification classification
+
+* There must be a page with an overview of AMLA files with opening
+  and closing dates and an easy way to determine for any day the
+  number of open AMLA files
+
+* Technically, we also need a list of at-risk transactions and of
+  frozen transactions, but given that we can really only freeze
+  on an account-basis, I think there is nothing to do here
+
 
 Terminology
 ^^^^^^^^^^^
@@ -287,21 +327,14 @@ Configuration Options
 The configuration specifies a set of providers, one per configuration section:
 
 [kyc-provider-$PROVIDER_ID]
-# How expensive is it to use this provider?
-# Used to pick the cheapest provider possible.
-COST = NUMBER
 # Which plugin is responsible for this provider?
 LOGIC = PLUGIN_NAME
-# Which type of user does this provider handle?
-# Either INDIVIDUAL or BUSINESS.
-USER_TYPE = INDIVIDUAL
-# Which checks does this provider provide?
-# List of strings, no specific semantics.
-PROVIDED_CHECKS = SMS GOVID PHOTO
+# Which check does this provider provide?
+PROVIDED_CHECK = SMS
 # Plus additional logic-specific options, e.g.:
 AUTHORIZATION_TOKEN = superdupersecret
 FORM_ID = business_legi_form
-# How long is the check considered valid?
+# How long is the data from this check considered valid?
 EXPIRATION = DURATION
 
 The configuration also specifies a set of legitimization
@@ -312,10 +345,8 @@ requirements, one per configuration section:
 # Must be one of WITHDRAW, DEPOSIT, P2P-RECEIVE
 # or WALLET-BALANCE.
 OPERATION_TYPE = WITHDRAW
-# Required checks to be performed.
-# List of strings, must individually match the
-# strings in one or more provider's PROVIDED_CHECKS.
-REQUIRED_CHECKS = SMS GOVID
+# Required measure to be performed.
+REQUIRED_MEASURE = SWISSNESS
 # Threshold amount above which the legitimization is
 # triggered.  The total must be exceeded in the given
 # timeframe. Can be 'forever'.
@@ -326,6 +357,29 @@ THRESHOLD = AMOUNT
 TIMEFRAME = DURATION
 
 
+Finally, the configuration specifies a set of measures,
+one per configuration section:
+
+[aml-measure-$MEASURE_NAME]
+# Program to run on the context and check data to
+# determine the outcome and next measure.
+PROGRAM = /bin/true
+# Check to run as part of this measure. Optional.
+CHECK = CHECK_NAME
+# Form to show to the user as part of this measure.
+FORM = FORM_NAME
+
+For each FORM_NAME, there then must be
+
+* A HTML template (Mustach) that is instantiated with the
+  JSON form context to produce a page to be shown to the user
+* A helper program (named after the form) that can:
+
+  * Generate a list of required context attributes
+    for the helper (!)
+  * Validate and convert an input JSON with context
+    attributes into the JSON form context
+
 
 Exchange Database Schema
 ^^^^^^^^^^^^^^^^^^^^^^^^