commit 28a751c24afd5acc9ad904145120397b6a7e1e7d
parent 326967b3e7937762a443dff9ad83788b8d3a3808
Author: Christian Grothoff <christian@grothoff.org>
Date: Tue, 22 Jul 2025 00:19:45 +0200
elaborate on compliance rule semantics
Diffstat:
2 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/manpages/taler-exchange.conf.5.rst b/manpages/taler-exchange.conf.5.rst
@@ -415,8 +415,10 @@ The following options must be in "[kyc-rule-$RULE_NAME]" sections.
OPERATION_TYPE = WITHDRAW
Operation that triggers this rule.
- Must be one of WITHDRAW, DEPOSIT, MERGE, BALANCE,
- CLOSE, AGGREGATE, TRANSACTION or REFUND.
+ Must be one of AGGREGATE, BALANCE, CLOSE, DEPOSIT, MERGE,
+ REFUND, TRANSACTION or WITHDRAW
+ See the Exchange KYC/AML Operator Manual for the
+ operations these refer to.
NEXT_MEASURES
Space-separated list of next measures to be performed.
diff --git a/taler-kyc-manual.rst b/taler-kyc-manual.rst
@@ -534,8 +534,8 @@ condition triggers:
[kyc-rule-$RULE_NAME]
# Operation that triggers this rule.
- # Must be one of WITHDRAW, DEPOSIT, MERGE,
- # AGGREGATE or BALANCE.
+ # Must be one of AGGREGATE, BALANCE, CLOSE, DEPOSIT, MERGE,
+ # REFUND, TRANSACTION or WITHDRAW
OPERATION_TYPE = WITHDRAW
# Space-separated list of next measures to be performed.
@@ -574,6 +574,61 @@ condition triggers:
# Set to YES to enable the rule (default is NO)
ENABLED = NO
+The operation types of KYC rules refer to the following scenarios:
+
+ * **AGGREGATION**: Triggered when an exchange is about to do an
+ wire transfer to a merchant. Such wire transfers typically have
+ aggregated multiple smaller deposits, and thus enforcing KYC rules
+ at aggregation time is more efficient than checking individual
+ deposits. Plus, checking at the aggregation level is likely to
+ render structuring inherently ineffective.
+ Enforced by the exchange.
+
+ * **BALANCE**: Triggered whenever the balance of a wallet is increased.
+ Can only be used with a timeframe of zero, as this is about the absolute
+ amount that can be stored at any time in a compliant wallet.
+ Enforced by the wallet.
+
+ * **CLOSE**: Triggered when a reserve is closed (explicitly by a wallet
+ or implicitly by timeout). Use with caution, as this may prevent
+ an exchange from returning funds that were not withdrawn to users.
+ Enforced by the exchange.
+ (Note: This rule is so far not used in production
+ anywhere, thus likely not tested well yet.)
+
+ * **DEPOSIT**: Sets a limit on the amount that can be deposited by
+ a merchant into their bank account. Can be used with a timeframe
+ of zero to effectively set another transaction limit that additionally
+ only applies to deposits (and not P2P payments), or with a non-zero
+ timeframe to limit the amount a merchant can deposit over time.
+ Usually used with a limit of zero to enforce merchant onboarding
+ prior to first payment processing. Inefficient to enforce limits
+ later, usually for merchants that have been onboarded **AGGREGATION**
+ limits should be set instead.
+ Enforced by the exchange.
+
+ * **MERGE**: Triggered when a user received digital cash from another
+ wallet.
+ Enforced by the exchange.
+
+ * **REFUND**: Limit on the amount that can be refunded per
+ transaction by a compliant merchant to a compliant wallet.
+ Can only be used with a timeframe of zero, as this is about
+ the amount that can be funded on an individual purchase.
+ Enforced both wallet-side and merchant-side (enforcement by
+ the exchange could be implemented in the future, but is
+ tricky as the exchange sees refunds per coin and not per
+ purchase).
+
+ * **TRANSACTION**: Refers to all transactions of a wallet where digital
+ cash is spent. Can be used with a timeframe of zero to set a transaction
+ limit, or with a non-zero timeframe to limit the spending rate over time.
+ Applies to spending money both in P2P and merchant transactions.
+ Enforced by wallets and merchants.
+
+ * **WITHDRAW**: Triggered when a user withdraws digital cash from their
+ bank account. Enforced by the exchange.
+
Configuration of AML programs
-----------------------------
