[taler-exchange] branch master updated: update flow documentation for process to reject initial deposit based on KYC/AML state (#9040)

[gnunet]

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

grothoff pushed a commit to branch master
in repository exchange.

The following commit(s) were added to refs/heads/master by this push:
     new e11fc05b8 update flow documentation for process to reject initial 
deposit based on KYC/AML state (#9040)
e11fc05b8 is described below

commit e11fc05b8715de3d90710f15dc21171142360bd4
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Sep 5 12:09:43 2024 +0200

    update flow documentation for process to reject initial deposit based on 
KYC/AML state (#9040)
---
 doc/flows/int-pay.tex | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/doc/flows/int-pay.tex b/doc/flows/int-pay.tex
index 2968c4c2e..004998b64 100644
--- a/doc/flows/int-pay.tex
+++ b/doc/flows/int-pay.tex
@@ -30,12 +30,19 @@
     \begin{callself}{wallet}{Review offer}{}
     \end{callself}
     \mess[0]{wallet}{Pay {(Coins)}}{merchant}
+    \prelevel
     \mess[0]{merchant}{Deposit {(Coins)}}{exchange}
+    \begin{sdblock}{KYC/AML required?}{}
+    \begin{callself}{exchange}{Figures~\ref{fig:proc:kyc}, 
\ref{fig:proc:aml}}{}
+    \end{callself}
+    \end{sdblock}
     \begin{sdblock}{Acceptable account?}{}
     \mess[0]{exchange}{{Refuse deposit}}{merchant}
-    \mess[0]{merchant}{{Refund purchase}}{wallet}
+    \prelevel
+    \mess[0]{merchant}{{Fail purchase}}{wallet}
     \end{sdblock}
     \mess[0]{exchange}{{Confirm deposit}}{merchant}
+    \prelevel
     \mess[0]{merchant}{Fulfill order}{wallet}
     \begin{callself}{exchange}{Aggregate transactions}{}
     \end{callself}
@@ -53,8 +60,12 @@
 \end{figure}
 
 {\bf Internal note:} The exchange refusing a deposit immediately based on
-unaccaptable merchant accounts may not be fully implemented (this is a very
-recent feature, after all); especially the merchant then automatically
-refunding the purchase to the customer is certainly missing.  However,
-the entire situation only arises when a merchant is incorrectly configured
-and in violation of the terms of service.
+unaccaptable merchant accounts can depend both on the target account
+(e.g. wire method not supported) or on the legitimization state of the
+merchant's target account (including lack of KYC authorization wire
+transfer, failure to accept terms of service, failure to provide KYC
+data, or some kind of AML/KYC rule being violated).  However, in general
+the merchant backend will know if it has performed some mandatory sign-up
+process and can thus avoid the entire situation by only offering exchanges
+where the merchant is in good standing in its contracts.  The central
+bug for supporting this in the merchant is \#9052.

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