blob: aba65a9a97c83dd81f99dcca72cfaa6ba606392f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
DD 023: Taler KYC
#################
Summary
=======
This document discusses the KYC processes supported by Taler.
Motivation
==========
Requirements
============
Taler needs to run KYC checks in the following circumstances:
* Customer withdraws money over a monthly threshold
* exchange triggers KYC
* key: IBAN
* Wallet receives (via refunds) money over a monthly threshold
* this is a client-side restriction
* key: reserve public key (generated, long-term)
* Wallet receives money via P2P payments
* key: reserve (=KYC account) public key
* Merchant receives money above a monthly threshold
* key: IBAN
Proposed Solution
=================
The new taler-kyc-ledger component keeps track of a mapping between an
identifier (as a payto URI?) and a KYC status (yes-merchant, yes-customer, no,
progress (with resume link)). Different identifiers might be mapped by the
bank's KYC provider to the same legal user entity.
Identifier:
* IBAN
* reserve / account
What info do we look at to determine if threshold is crossed / being crossed?
[ ... ]
FIXME: Who keeps track of the threshold?
* since the kyc-ledger might be run by the bank and
not the exchange, the thresholds could/should be kept by
the exchange
* kyc-ledger vs kyc-provider
Alternatives
============
None unless we want regulatory compliance?
Drawbacks
=========
Discussion / Q&A
================
(This should be filled in with results from discussions on mailing lists / personal communication.)
|
