Re: Identity and Fineract
Thanks for starting up this topic on-list (I only just saw it now upon
Isaac's reply). I will try to forwards this along to others who have been
conversing on related topics of eKYC, verification via selfies, etc. I will
also get some of my volunteers assisting on the AML/CFT front involved in
Thank you also for bringing up our conversations with the INDY at OSCON, I
will re-engage with Joyce so we can carry forward the conversations we
The discussion around identity and looking at claim-based systems and
decentralized identities are all the more relevant as systems like Aadhar
continue to get hacked and sensitive data gets exposed:
See some additional replies inline.
On Mon, Sep 10, 2018 at 11:31 AM James Dailey <jamespdailey@xxxxxxxxx>
> 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:
For these components and sub-components of Identity you are starting to
flesh out below, it'd be great to synthesize into a requirements/spec doc
on the. Fineract wiki.
> 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
> 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
> 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
> that information or simply notes that multiple sources of verification
> identity or "claims" have been verified. For example, a person my
> 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
> on that network with that specific IMEI (device) and that specific
> telephone number. I think it is important to treat such forms as
> tokens (encrypted).
Javier is working with a customer who want to do selfie-based eKYC for
online account sign-ups. Some community members are quite expert on eKYC
processes as part of the loan origination workflow. I'll have those inputs
be voiced here.
> 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
> 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
> 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
> where the levels are generally thought of as KYC-0 (e.g. we don't know
> about them, but the authorities allow us to transact up to $300 per
> 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
> of banking rules) In Fineract, I believe that what needs to be stored
> the initial authorized level of KYC, the record of how much is expected
> 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
> and actual. The banking sector has been practicing this for a long time
> and rules are understood.
I will get Shabbir our CFT/AML expert to chime in on this thread and
advance his thinking on the generic framework-level components we could
implement to assist with compliance. As you also might already know, Ankur
as part of his GSOC project for the mobile wallet, worked on incorporating
into the front-end some of the elements of tiered KYC. You can see his
and the discussion thread that Sundari started at
> 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.
President/CEO, Mifos Initiative
edcable@xxxxxxxxx | Skype: edcable | Mobile: +1.484.477.8649
*Collectively Creating a World of 3 Billion Maries | *http://mifos.org