commit 0eb0ba11265e193a95c7f9ef6f42f086a3069ec0
parent 81ca8cb7ee39ef88245e8bfcaa67b1c0ff03c837
Author: Florian Dold <florian@dold.me>
Date: Sun, 4 May 2025 01:58:47 +0200
tops: procedural description of AML processes
Diffstat:
| M | deployments/tops.rst | | | 207 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- |
1 file changed, 204 insertions(+), 3 deletions(-)
diff --git a/deployments/tops.rst b/deployments/tops.rst
@@ -26,8 +26,8 @@ Regulatory requirements are set by `VQF <https://www.vqf.ch/indexen.html>`_
and detailed in their SRO-Regulation document. Our AML processes
are based on their forms ("VQF Document Nr. 902.$x").
-High-Level Processes
---------------------
+Overview of High-Level Processes
+--------------------------------
Establishing a Business Relationship
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -97,7 +97,6 @@ Terminating a Business Relationship
A business relationship is automatically considered terminated if no
transactions have been processed with the GNU Taler system for over 12 months.
-
Credit / Debit Restrictions
---------------------------
@@ -337,6 +336,208 @@ Implementation notes:
where the context is updated based on documents still required.
+
+Procedural View
+---------------
+
+This section provides a procedural view of the AML process defined by the rules
+earlier in the document. It is meant to give some further context to the rules
+and show how the rules are used in the context of Taler business processes.
+
+It only takes into account the standard rules. Decisions from the AML
+officer can lead to a deviation from the standard process/rules.
+
+Wallet User: Onboarding and Withdrawal
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1. User installs the Taler Wallet software on their device of choice.
+2. User adds the TOPS Taler Exchange to their Taler Wallet
+3. User starts withdrawal via the wallet application. This creates a new
+ (pending) transaction in the wallet. *Optionally:* If the wallet can deduct
+ that the user has to complete a KYC process for the withdrawal, it notifies
+ the user.
+4. User follows instructions to send money to the TOPS exchange
+5. The wallet waits until the exchange knows about the
+ user's wire transfer.
+5. The user's wallet checks with the exchange whether the withdrawal would
+ cross the balance threshold. The key/identifier for is the wallet ID for
+ the exchange (which is typically the reserve public key for P2P
+ transactions).
+
+ **The TOPS exchange currently has no balance limits set, thus balance limits would
+ never be crossed.**
+
+ * If the balance limit is not crossed (or the user increased the limit via KYC), continue at (6).
+ * If no KYC process is started or the KYC process fails or times out, funds
+ are automatically wired back to the customer after a reserve close
+ timeout. **Done.**
+
+6. The wallet attempts to withdraw electronic cash tokens. The exchange
+ checks the withdrawal limit based on the IBAN that the
+ customer used to transfer CHF to the exchange:
+
+ * If the customer has already successfully completed
+ the ``sms-registration`` or ``postal-registration``,
+ the withdrawal limit is 2500 CHF/month and 15000 CHF/year.
+ * Otherwise, the limit is 200 CHF per month. If this limit would
+ be crossed by the withdrawal, the wallet redirects the user to
+ the exchange's KYC page, where the user can complete the ``sms-registration``
+ or ``postal-registration``.
+ * If no limit would be crossed, continue at (7)
+ * If a limit would be crossed and the customer is not able to
+ lift it via the KYC process, funds are wired back automatically
+ after a reserve close timeout. **Done.**
+
+8. The wallet receives the (blindly signed) tokens from the exchange,
+ the withdrawal is done. **Done.**
+
+
+Wallet User: Deposit of E-Money
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This process applies when the user wants to send CHF in their Taler wallet back
+to their CHF bank account. Technically, it is the same process as the merchant
+accepting a Taler payment. However, it might be treated differently from an
+AML perspective.
+
+1. The user's wallet asks the exchange to deposit a Taler payment
+ to the user's own bank account.
+2. The exchange checks whether the users's public key is associated with the
+ users's bank account specified in the deposit permission.
+
+ Note that by default, the wallet uses a bank account that has
+ previously used for withdrawal. The withdrawal already associates
+ the reserve's public key with the IBAN used for the withdrawal.
+ Thus *usually* the right associated public key is already present.
+
+ * If the association is missing, the exchange rejects the deposit. The
+ customer must do a 1 rappen wire transfer to the exchange with a public
+ key (as shown in the wallet) in the remittance information. **Done.**
+ * Otherwise, continue at (3).
+
+
+Wallet User: Receiving P2P Payments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+*Applicable to both receiving P2P payments (push) and getting paid for P2P
+payment requests (pull).*
+
+1. The customer instructs their wallet to accept a P2P payment from another wallet.
+2. The wallet tries to receive the P2P payment.
+ The exchange checks the P2P receive (technically: ``MERGE``)
+ limit, based on the wallet ID.
+
+ * If the customer has successfully completed ``postal-registration`` or ``sms-registration``,
+ the limits are 2500 CHF / month and 15000 CHF / year.
+ * Otherwise, the limit is 0 CHF. The wallet redirects the user to the
+ exchange's KYC page, where the user can complete the ``sms-registration``
+ or ``postal-registration``.
+ * If P2P receive is below the limits (or the customer increases the limits via KYC),
+ the P2P recive can proceed. **Done.**
+ * Otherwise, the P2P payment expires and the sender's wallet reclaims the money. **Done.**
+3. The exchange checks the ``DEPOSIT`` limit of the user. The user is identified via their IBAN.
+
+ * Initally, the deposit limit is CHF 0. The user must accept the exchange's
+ terms of service on the exchange's KYC page to lift this limit to CHF 2500/month
+ and CHF 15000/year
+ * If no deposit limit would be crossed, the exchange accepts the deposit from the user.
+ Continue at (4).
+ * Otherwise the exchange rejects the payment. The response is relayed to the
+ wallet, which can (if necessary) refund coins previously deposited for the
+ same payment and then refresh used coins. **Done.**
+4. After the wire transfer deadline for the deposit has passed, the exchange
+ checks whether the wire transfer would cross the ``AGGREGATE`` threshold for
+ the merchant.
+
+ * Initally, the aggregate limit is CHF 2500/month and CHF 15000/year. If
+ that limit would be crossed, the customer must undergo a KYB process. This
+ KYB process might result in limits being increased, depending on the
+ details of the user.
+ * If no aggregation limit would be crossed, the exchange initiates the wire transfer to the user.
+ * Otherwise the exchange holds the funds until the user completes the necessary AML process.
+
+
+
+FIXME: Do withdrawal limits also apply for withdrawal from the merge reserve?
+
+Wallet User: Sending P2P Payments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+*Applicable to both sending P2P payments (push) and paying for P2P payment
+requests (pull).*
+
+There are no KYC/AML-relevant steps required for
+sending P2P payments.
+
+Merchant: Onboarding
+^^^^^^^^^^^^^^^^^^^^
+
+1. The merchant provisions a Taler merchant backend service.
+2. A keypair is generated (or imported) for the merchant.
+3. The merchant adds their (Swiss) bank account to the merchant backend
+4. The merchant backend checks the KYC status of the account with the exchange.
+5. The exchange checks if the merchant's public key is already associated with
+ the merchant's bank account.
+
+ * If not, the merchant needs to make a payment (1 rappen) to the exchange
+ with the public key in the remittance information. Continue at (4).
+ * Otherwise, continue at (6).
+
+6. If the merchant's bank account still has a deposit limit of zero, the
+ merchant needs to accept the TOPS exchange terms of service on the
+ exchange's KYC page.
+
+7. The deposit rule is lifted and the merchant can start accepting Taler payments from customers.
+ However, initially no aggregated settlement payments (wire transfers)
+ will be send from the exchange to the merchants, until the merchant
+ has completed further KYC steps (``vqf_902_1_customer`` etc.).
+8. Optionally, the merchant can (via a link in the merchant backend to the KYC page)
+ and immediately complete the further KYC process steps.
+
+Merchant: Receiving Payments from Wallets
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+1. The merchant receives a Taler payment (technically: deposit permissions) from a
+ wallet.
+2. The merchant asks the exchange to deposit the Taler payment.
+3. The exchange checks whether the merchant's public key is associated with the
+ merchant's bank account specified (as a salted hash) in the deposit
+ permission.
+
+ * If the association is missing, the exchange rejects the deposit. **Done.**
+ * Otherwise, continue at (4).
+
+4. The exchange checks the ``DEPOSIT`` limit of the merchant.
+ The merchant is identified via their IBAN.
+
+ * Initally, the deposit limit is CHF 0. The merchant must accept the exchange's
+ terms of service on the exchange's KYC page to lift this limit to CHF 2500/month
+ and CHF 15000/year
+ * If the merchant has accepted the terms of service, the deposit limit
+ is CHF 2500/month and CHF 15000/year. If that limit
+ is crossed, the merchant must undergo a KYB process. This KYB
+ process might result in limits being increased, depending
+ on the details of the business.
+ * If no deposit limit would be crossed, the exchange accepts the deposit from the merchant. **Done.**
+ * Otherwise the exchange rejects the payment. The response is relayed to the
+ wallet, which can (if necessary) refund coins previously deposited for the
+ same payment and then refresh used coins. **Done.**
+
+
+Merchant: Receiving Wire Transfers for Taler Payments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+1. The merchange receives payments from wallets.
+2. The exchange waits and aggregates payments until the first wire transfer
+ deadline set by the merchant has passed.
+3. The exchange checks whether the aggregated wire transfer would cross the
+ ``AGGREGATE`` threshold for the merchant.
+
+ * Initally, the aggregate limit is CHF 2500/month and CHF 15000/year. If
+ that limit would be crossed, the merchant must undergo a KYB process. This
+ KYB process might result in limits being increased, depending on the
+ details of the business.
+ * If no aggregation limit would be crossed, the exchange initiates the wire transfer to the merchant.
+ * Otherwise the exchange holds the funds until the merchant completes the necessary AML process.
+
AML/KYC Forms
-------------
