Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Are there any specific money laundering / terrorist financing risks, that arise from the use of digital identity systems for CDD, other than those already mentioned in Section IV of the guidance?
    If so, how can they be addressed and by whom? Are there specific opportunities for combating money laundering / terrorist financing that are not already mentioned in the guidance?

  2. What is the role of digital ID systems in ongoing due diligence or transaction monitoring?
    a. What information do you capture under authentication at on-boarding onboarding and during authorization for account access? Who captures this data?
    b. Is the authentication data you capture relevant to ongoing anti-money laundering and counter-terrorist financing due diligence and/or transaction monitoring? If yes, how?

  3. How can digital ID systems support financial inclusion?
    a. How can digital ID systems with different assurance levels for identity proofing/enrollment and/or authentication be used to implement tiered CDD, allowing clients a range of account functionalities depending on the extent of CDD performed, and particularly in situations of lower risk? Please provide any practical examples.
    b. Have you adopted lower assurance levels for identity proofing to support financial inclusion? What additional measures do you apply to mitigate risks? Please provide any practical examples.
    c. How can progressive CDD via digital ID systems aid financial inclusion (i.e. establishing greater confidence in a customer’s identity over time)?

  4. Does the use of digital ID systems for CDD raise distinct issues for implementing the FATF record-keeping requirements?
    a. What records do you keep when you use digital ID systems for CDD?
    b. What are the challenges in meeting record-keeping requirements when you use digital ID systems for CDD?
    c. If you keep different records when using digital ID systems for on-boardingonboarding, does this impact other anti-money laundering and counter-terrorist financing measures (for example ongoing due diligence or transaction monitoring)?

...

Introductions

Presentation StMouy (Stefan):  Public consultation on FATF draft guidance on digital identity. After months of preparation FATF released guidance in digital identity. Important because it is the first time there is a concerted effort to discuss digital identity – financial regulations. No time left for comment (as of Friday) Areas of focus - where feedback is requested –  typically deals with how – a good way to stimulate financial inclusion with digital identity. Proofing is difficult, in emerging and other countries. FATF looking at ways to lower requirements for identity proofing. Balance with higher requirements for authentication. Some of the questions raised by FATF relate to what sort of risks are involved, how to mitigate risks, and whether there is any tradeoff with authentication and collection monitoring processes. 

Recommend taking a look, more refined compared to previous versions. A fairly broad overview of the current situation in many countries. If you are not familiar with the level of issues related to AML and prevention, digital identity solution operations, a good way to look at the document. Also, the document includes the decision process for regulated entities. Highlights deal with this most critical part of the report. Set up as a series of three questions. Is there a digital ID system that has been authorized in the banking or financial sector? Yes, then use. No? then do you know the assurance level of the digital ID system, you come to the third question, is that level of assurance appropriate for the level of risk associated? Something reflected in IST guidelines and Europe regulations. If there is no established level of assurance, you can't use the ID system; there is a fairly onerous requirement – effectively any digital ID system contemplating use by financial institutions in the financial sector, will one way or another obtain a level of assurance. Still, a lot of flexibility and room to maneuver. However, this is the core thinking and decision process behind the use of digital IDs. 

...

AML risk-based approached = each financial institution has to look at the customer relationship and assess what risk is involved. What is the level of assurance needed? A retired person with a stable pension is a different risk than a traveler. Also, transaction - a pizza versus high-value transactions. There are a number of factors.

...

Digital Locker Overview IDentity piece provided by Aadhaar. Started It started in Russia, evolved and stayed in India. Open-API ecosystem

...

Guidelines on what kinds of electronic documents. Needs to be unique document ID for the publisher. Must go through a partnership agreement authority. Requestor The requestor is an entity providing service to a citizen or any entity requiring documents (such as a bank). As requestor, you can access digital locker, you will have access. Apart from that, digital locker service providers. Typically unique URI for documents. It can be owned by issuers or private players who store documents. Issuer maintains own secure storage model available. Simple, only one copy, what flows is the URI. One is the issued document for which the URI is stored in the digital locker. Centralized repository with a document. A lot of legacy documents users already have. Digital lockers can provide service to upload legacy and get 'signed' with a signing service, to share documents. Sign and upload, or from a certain date onward, issuer can issue electronic documents and publish a URI. If we talk about the India stack ecosystem. We are talking about multiple transformations. 

...

Response = issuer issues document. For example, an electronic driver's license. Digital wallet interface, you see the document signed by the transfer document, it is digitally signed by the issuer. If you see the interface it says three issued document, when I click on the URI. URI is transferred, not URI. 

...