[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Identity and Fineract

Hi Devs -

I'd like to raise an issue with regard to how Fineract 1.x and the new
Fineract-CN treats the concept of Identity.

I was recently looking at Isaac's work on
It got me thinking... I was unclear if the tests are fully covering our
functionality, and wonder about how we are collectively thinking about

So, there has been a lot of work done recently on Digital Identity and
Credentials globally.  I think we should have as part of our thinking and
structure of the identity service:

   1. Issuing authority (this could be any relevant civil authority such as
   Federal Government, State Department, Provincial Gov't), any private or
   non-profit but recognized entity (e.g. University), and also any commercial
   entity that has a pre-existing relationship including Bank, Mobile
   Provider, Microfinance Entity, or even Facebook/WeChat/Alibaba.
   When dealing with the unbanked, or underbanked, a form of digital
   identity may be self-issued or issued on the spot, and be trusted up to a
   point (see KYC below).

   2. Credentials and Forms of verification - this could be a separate
   concept in Fineract of [one to many] relationship where Fineract CN stores
   that information or simply notes that multiple sources of verification of
   identity or "claims" have been verified.  For example, a person my present
   a paper form from the local utility company showing they are a customer.
   Or, for example, a person may be verified by the mobile provider as being
   on that network with that specific IMEI (device) and that specific
   telephone number. I think it is important to treat such forms as security
   tokens (encrypted).

   3. Claims - there have been attempts at the W3C (world wide web
   consortium) related to the issue of verification of digital identity, to
   describe these as "claims" where an individual may have multiple sources in
   the formal and informal sectors by which they can claim identity.   I think
   of Claims as IssuingAuthority+Verified, but that may be
   oversimplification.  Please see
   https://www.w3.org/TR/verifiable-claims-use-cases/ .

   4. Relationship with KYC and AML/CFT - In Mifos and now in Fineract we
   have a set of requirements around the relationship between the validity of
   the identity against regulations dealing with "know your customer" and
   "anti-money-laundering" (inbound flows) and "counter the financing of
   terrorism" (outbound flows).  These requirements generally start with KYC
   where the levels are generally thought of as KYC-0 (e.g. we don't know much
   about them, but the authorities allow us to transact up to $300 per month),
   KYC-1, KYC-2, up to KYC-3 (e.g.they have a formal and verified identity
   credential from the national biometric system and they have up to the limit
   of banking rules)   In Fineract, I believe that what needs to be stored is
   the initial authorized level of KYC, the record of how much is expected to
   be transacted and then a calculated actual amount transacted so that
   exceptional transactions can be flagged, and the movement from one KYC
   level to another.  It is common in banking at least to have a SAR
   (Suspicious Activity Report) based on a comparison of expected transactions
   and actual.  The banking sector has been practicing this for a long time
   and rules are understood.

At OSCON we also learned about INDY, which is part of the Hyperledger
project, and deals with Identity using some new distributed ledger based
tools.  I think it would be interesting to create a proof of concept where
we link our identity service to the Indy code.
.   This builds out the concept of a globally accessible public utility for
decentralized identity.

What would be a useful next step on this?  Hoping for comments and
exploration of requirements.