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.)