View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009577 | Taler | exchange KYC customer webui | public | 2025-02-22 21:16 | 2025-05-10 02:11 |
| Reporter | Christian Grothoff | Assigned To | sebasjm | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | immediate | Severity | block | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 1.0 | Fixed in Version | 1.0 | ||
| Summary | 0009577: VQF Form 902.1e is not right | ||||
| Description | Section 1 has two sub-parts, the customer is a (a) natural person or (b) legal entity. You cannot be both! So (a) and (b) are MUTUALLY exclusive. Thus, the SPA must first ask: Are you a (a) natural person or (b) legal entity. Default can be either, doesn't matter. Depending on which of the two (a or b) is chosen, the other part of the form (1b or 1a respectively) must be hidden and not filled in! Additionally, part 2 of the form also only applies if 1b was selected. Furthermore, part 3 does NOT belong at all into the KYC-SPA, that's *only* for AML-officers, so if an AML officer does a VQF 902.1e, they should get this. Additionally, I think it makes sense for us to offer a new "VQF 902.1-3+5" form with *only* the sections 3 and 5 for the AML officer in it, so they can file that after a customer did VQF 902.1. Next, part 4 is something we'd want the customer to fill in, but we should keep the order: natural persons first, other last, etc. Part 5 is again ONLY for the AML-officers, not some customer. Part 6 doesn't exactly apply for us, so probably just leave it out. Part 7 are other forms -- the AML officer can click those explicitly (902.4, 902.5) or we'll ask for them next (902.15, 902.9, 902.11, 902.12, 902.13) depending on how the customer filled part 4. | ||||
| Tags | No tags attached. | ||||
| child of | 0009351 | closed | Christian Grothoff | taler-exchange-helper-measure-tops-kyx-check incomplete [3d] |
| Oh, I guess it does make sense to ask the customer the question in part 3c -- Language --- which language(s) we should speak with them. But as with nationalities, this is not paper, so we should probably put up a decent list, like: https://github.com/umpirsky/language-list/blob/master/data/ak/language.txt | grep -v Ancient ;-) | |
| Under "Power of attorney arrangements", you made it a free-form, but it should be quite specifically "CR Extract" / "Mandate" / "Other" and ONLY if "Other" is checked, we get a data entry form. In the JSON you MAY represent it all as a string, or as a checkbox + string if checkbox is on "other". | |
| Under "customer type", you have "legal entity" as a choice, but that's unclear. The formulation must be exactly "operational legal entity or partnership", and the value set in the JSON should not be "LEGAL_ENTITY" but "OPERATIONAL". | |
| Actually, the question for customer type should be asked *first*. Then, if they select "natural person", you go for the 1a and 3-language part, if they select anything else, you do 1b and 2 and 3-language. | |
| why not using the ISO 639 for langs ? https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes | |
| formId "vqf-902-1" on kyc spa will use the form with the customer fields formId "vqf-902-1" on aml spa will use the complete form with all fields formId "vqf-902-1-officer" on aml spa will use the form with the officer fields (section 3 and 5) | |
| I don't care about the *specific* language list used right now, just we need a *decent* list. | |
| e953aab7a..921eadd63 | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-02-22 21:16 | Christian Grothoff | New Issue | |
| 2025-02-22 21:16 | Christian Grothoff | Status | new => assigned |
| 2025-02-22 21:16 | Christian Grothoff | Assigned To | => sebasjm |
| 2025-02-22 21:32 | Christian Grothoff | Priority | normal => urgent |
| 2025-02-22 21:35 | Christian Grothoff | Note Added: 0024128 | |
| 2025-02-22 21:39 | Christian Grothoff | Summary | VQF Form 902.1e section 1 is not right => VQF Form 902.1e is not right |
| 2025-02-22 21:39 | Christian Grothoff | Note Added: 0024129 | |
| 2025-02-22 21:45 | Christian Grothoff | Note Added: 0024130 | |
| 2025-02-22 21:48 | Christian Grothoff | Note Added: 0024131 | |
| 2025-02-22 22:09 | Christian Grothoff | Relationship added | child of 0009351 |
| 2025-02-23 09:03 | Christian Grothoff | Priority | urgent => immediate |
| 2025-03-01 20:58 | sebasjm | Note Added: 0024149 | |
| 2025-03-01 21:16 | sebasjm | Note Added: 0024150 | |
| 2025-03-01 21:38 | Christian Grothoff | Note Added: 0024151 | |
| 2025-03-01 21:56 | sebasjm | Status | assigned => informing |
| 2025-03-01 21:56 | sebasjm | Resolution | open => fixed |
| 2025-03-01 21:56 | sebasjm | Note Added: 0024152 | |
| 2025-03-28 12:11 | Christian Grothoff | Fixed in Version | => 1.0 |
| 2025-05-10 02:11 | Christian Grothoff | Status | informing => closed |
| 2026-08-23 14:17 | Florian Dold | Category | exchange KYC SPA => exchange KYC customer webui |