Re: Identity and Fineract
Thank you for your insightful email.
I have been a fan of the Linux Foundation's Hyperledger project for a while
and I think the possibilities of blockchain are enormous.
When the community has a release of Fineract CN, I think it'll be
worthwhile to experiment with this integration. As a matter of fact, Myrle
Krantz has done some work on Fineract CN / Stellar bridge which can be very
useful for your proposal.
Here is my two penny worth on the topic.
On Mon, Sep 10, 2018 at 7:31 PM James Dailey <jamespdailey@xxxxxxxxx> wrote:
> 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
> 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).
> 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.
> 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.