taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

commit 37b56e2b6e0c7f34c0379ef8794db90d147f9824
parent 4433eaee33cd878e3e5507b7b6d1b225169d4ca7
Author: Florian Dold <florian@dold.me>
Date:   Tue, 18 Mar 2025 16:34:06 +0100

tops

Diffstat:
Mdeployments/tops.rst | 49++++++++++++++++++++++++++++++++-----------------
1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/deployments/tops.rst b/deployments/tops.rst @@ -193,10 +193,10 @@ Properties * Customer name or internal alias. -* ``AML_ACCOUNT_ACTIVE_DEPOSIT :: Boolean`` +* ``AML_ACCOUNT_OPEN :: Boolean`` * Was this customer activated for deposit operations? - * FIXME: Who sets this when? Isn't this implied by the rules? + * We store this to know when to emit the ``ACCOUNT_OPENED`` event * ``AML_DOMESTIC_PEP :: Boolean`` @@ -205,7 +205,10 @@ Properties * ``AML_FOREIGN_PEP :: Boolean`` * Is the customer a foreign PEP? - * FIXME: What about PEP at international org? + +* ``AML_INTERNATIONAL_ORG_PEP :: Boolean`` + + * Is the customer a international org PEP? * ``AML_HIGH_RISK_BUSINESS :: Boolean`` @@ -215,16 +218,22 @@ Properties * Is the customer associated with a high-risk country? -* ``AML_NO_OPERATION_DURING_PERIOD :: Boolean`` +* ``AML_ACCOUNT_IDLE :: Boolean`` + + * The account has been marked as idle (typically by a batch process that checks + for idle accounts). - * FIXME: What does this property mean? -FIXME: Shouldn't the following be some state machine, rather than flags? +* ``AML_MROS_STATE`` -* ``AML_INVESTIGATION_ART6_COMPLETED :: Boolean`` -* ``AML_INVESTIGATION_ART6_FAILED :: Boolean`` -* ``AML_MROS_REPORTED_ART305 :: Boolean`` -* ``AML_MROS_REPORTED_ART9 :: Boolean`` + * The MROS reporting state for the account. + * Values: + + * ``NONE`` / undefined: No MROS reporting for that account + * ``REPORTED_SUSPICION_SIMPLE``: Reported under Art. 305 StGB (German "einfacher Verdacht", simple suspicion) + * ``REPORTED_SUSPICION_SUBSTANTIATED``: Reported under Art. 9 GwG (German "begründeter Verdacht", substantiated suspicion) + * ``INVESTIGATION_FAILED``: Failed according to Art. 6 GwG + * ``INVESTIGATION_COMPLETED``: Completed according to Art. 6 GwG Events ------ @@ -233,7 +242,8 @@ Account opening: * ``ACCOUNT_OPENED`` - * FIXME: When exactly does an account count as opened? + * Only after merchant passes KYC + * Wallet accounts never count as opened (no business relationship!) * ``ACCOUNT_OPENED_HIGH_RISK`` * ``ACCOUNT_OPENED_DOMESTIC_PEP`` @@ -252,14 +262,13 @@ Account closing: * Account with property ``AML_HIGH_RISK_COUNTRY`` was closed -MROS reporting: -FIXME: Incomplete? What's the difference, why is completed only there for one type of reporting? +MROS Reporting (see ``AML_MROS_STATE`` property): -* ``ACCOUNT_MROS_REPORTED_ART9``: Account reported to MROS (Art. 9 GwG) -* ``ACCOUNT_MROS_REPORTED_ART305``: Account reported to MROS (`Art. 305 StGB <https://www.fedlex.admin.ch/eli/cc/54/757_781_799/de#art_305_ter>`_) -* ``ACCOUNT_INVESTIGATION_ART6_COMPLETED`` -* ``ACCOUNT_INVESTIGATION_ART6_FAILED`` +* ``ACCOUNT_MROS_REPORTED_SUSPICION_SIMPLE`` +* ``ACCOUNT_MROS_REPORTED_SUSPICION_SUBSTANTIATED`` +* ``ACCOUNT_INVESTIGATION_COMPLETED`` +* ``ACCOUNT_INVESTIGATION_FAILED`` PIN Letter @@ -277,6 +286,8 @@ Implementation notes: * The letter is sent and generated via ``challenger`` * FIXME: How do we keep track of required documents? + if partial document collection arrives: update context (later!) + AML/KYC Forms ------------- @@ -590,6 +601,7 @@ vqf_902_1_officer FIXME: Why is all of this optional? What does this mean if the acceptance date is missing? +=> mandatory, prefill with current date .. code:: none @@ -1516,6 +1528,7 @@ Open Questions * Clarify MROS reporting according to Art 305ter Abs. 2 StGB vs Art. 9 GwG * Why is there a counter for failed investigations according to one, but not the other? + * Melderecht vs Meldepflicht * Do we use ``Boolean`` attributes or always ``'YES' | 'NO'`` to be extensible in the future? @@ -1523,6 +1536,8 @@ Open Questions * General forms question: Are attributes *first* stored and *then* validated or the other way around? If first stored: What if the AML program fails to run? +* We need a generic way to show INFO to a customer (e.g. asking for more documents) + FAQ ---