[prev in list] [next in list] [prev in thread] [next in thread]
List: mifos-developer
Subject: Re: [Mifos-developer] Identity and Fineract
From: Ed Cable <edcable () mifos ! org>
Date: 2019-02-11 17:44:57
Message-ID: CAPnWRThVUqsBipwLxJZRxwjUtky6PznUFpCge6jNxwhtys2O2w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
James, thanks for bringing this to top of mind again. I want to introduce
Rachit Kansal, a volunteer with the Mifos Initiative, who's going to be
doing some product management work and research to shine light on some of
the different directions the Fineract community could head.
He's drafting a proposal for a proof of concept around Sovrin and
Hyperledger Indy. He will share progress with that on list soon.
This white paper is a good read on the efforts led by Sovrin Foundation
around a decentralized identification system.
https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Paper.pdf
We are also going to do some exploration around Yoti which has a good
enabling environment for developers and some programs conducive to
financial inclusion.
https://www.yoti.com/developers/
This Medium post from Caribou Digital is also a nice primer on the terms,
identity, identification, and ID and how they differentiate them.
https://medium.com/caribou-digital/the-difference-between-digital-identity-identification-and-id-41580bbb7563
On Sat, Feb 9, 2019, 16:03 James Dailey <jamespdailey@gmail.com wrote:
> I'd like to raise this important issue again. We are in the space of
> financial services, and so we must express kyc/aml/cft regulations.
>
> Know Your Customer is a FUNDAMENTAL banking concept. It is currently
> supported via account opening in fineract but more needs to be done.
>
> We must also address the opportunity and the gap in formal identity if we
> are to be a serious player in financial inclusion. I don't believe fineract
> or mifos should do that function directly, but rather be able to speak to
> various identity/claims services.
>
> At times a mifos implementation will have the best information about a
> specific customer. This also relates to credit bureaus and again, the
> concept of 'identity-claims'.
>
> I'd like to suggest that we get a wiki page and then some detailed
> requirements going and develop some ticket. But, looking for someone to
> support this in coding and someone else who has a need now for this
> functionality.
>
> Jdailey67
>
> On Thu, Sep 13, 2018, 10:28 AM Ed Cable <edcable@mifos.org wrote:
>
> > James,
> >
> > 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
> > this thread.
> >
> > 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
> > started there.
> >
> > 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:
> >
> >
> https://www.huffingtonpost.in/2018/09/11/uidai-s-aadhaar-software-hacked-id-database-compromised-experts-confirm_a_23522472/
>
> >
> > See some additional replies inline.
> >
> >
> > On Mon, Sep 10, 2018 at 11:31 AM James Dailey <jamespdailey@gmail.com>
> > 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
> > >
> > >
> >
> https://github.com/apache/fineract-cn-customer/pull/7/commits/65a88b9879a46103fae440c42d1b0058909a93aa
>
> > > .
> > > It got me thinking... I was unclear if the tests are fully covering our
> > > functionality, and wonder about how we are collectively thinking about
> > > identity.
> > >
> > > 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
> > > 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).
> > >
> >
> > 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
> > > 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.
> > >
> >
> > 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
> > implementation at
> > https://gist.github.com/ankurs287/d9ef88cedcebe678f09fd555b17c7546
> >
> > and the discussion thread that Sundari started at
> >
> >
> http://mail-archives.apache.org/mod_mbox/fineract-dev/201806.mbox/%3CCAPnWRTjQHjys=vBFqkVqb7GZPo0iq7VFuGxP6sr-K0h55wK=mA@mail.gmail.com%3E
>
> >
> >
> > >
> > >
> > > 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.
> > >
> > >
> >
> https://www.hyperledger.org/blog/2017/05/02/hyperledger-welcomes-project-indy
> > > . 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.
> > >
> > > Thanks,
> > > James
> > >
> >
> >
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> >
> > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> > <http://facebook.com/mifos> <http://www.twitter.com/mifos>
> >
>
[Attachment #5 (text/html)]
<div dir="auto">James, thanks for bringing this to top of mind again. I want to \
introduce Rachit Kansal, a volunteer with the Mifos Initiative, who's going to be \
doing some product management work and research to shine light on some of the \
different directions the Fineract community could head. <div \
dir="auto"><br></div><div dir="auto">He's drafting a proposal for a proof of \
concept around Sovrin and Hyperledger Indy. He will share progress with that on list \
soon. </div><div dir="auto"><br></div><div dir="auto">This white paper is a good \
read on the efforts led by Sovrin Foundation around a decentralized identification \
system. </div><div dir="auto"><br></div><div dir="auto"><a \
href="https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Pa \
per.pdf">https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Paper.pdf</a><br></div><div \
dir="auto"><br></div><div dir="auto">We are also going to do some exploration around \
Yoti which has a good enabling environment for developers and some programs conducive \
to financial inclusion.</div><div dir="auto"><br></div><div dir="auto"><a \
href="https://www.yoti.com/developers/">https://www.yoti.com/developers/</a><br></div><div \
dir="auto"><br></div><div dir="auto">This Medium post from Caribou Digital is also a \
nice primer on the terms, identity, identification, and ID and how they differentiate \
them.</div><div dir="auto"><br></div><div dir="auto"><a \
href="https://medium.com/caribou-digital/the-difference-between-digital-identity-ident \
ification-and-id-41580bbb7563">https://medium.com/caribou-digital/the-difference-between-digital-identity-identification-and-id-41580bbb7563</a><br></div><div \
dir="auto"><br></div><div dir="auto"><br></div></div><br><div \
class="gmail_quote"><div dir="ltr">On Sat, Feb 9, 2019, 16:03 James Dailey <<a \
href="mailto:jamespdailey@gmail.com" target="_blank" \
rel="noreferrer">jamespdailey@gmail.com</a> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">I'd like to raise this important issue again. We are in \
the space of<br> financial services, and so we must express kyc/aml/cft \
regulations.<br> <br>
Know Your Customer is a FUNDAMENTAL banking concept. It is currently<br>
supported via account opening in fineract but more needs to be done.<br>
<br>
We must also address the opportunity and the gap in formal identity if we<br>
are to be a serious player in financial inclusion. I don't believe fineract<br>
or mifos should do that function directly, but rather be able to speak to<br>
various identity/claims services.<br>
<br>
At times a mifos implementation will have the best information about a<br>
specific customer. This also relates to credit bureaus and again, the<br>
concept of 'identity-claims'.<br>
<br>
I'd like to suggest that we get a wiki page and then some detailed<br>
requirements going and develop some ticket. But, looking for someone to<br>
support this in coding and someone else who has a need now for this<br>
functionality.<br>
<br>
Jdailey67<br>
<br>
On Thu, Sep 13, 2018, 10:28 AM Ed Cable <<a href="mailto:edcable@mifos.org" \
rel="noreferrer noreferrer" target="_blank">edcable@mifos.org</a> wrote:<br> <br>
> James,<br>
><br>
> Thanks for starting up this topic on-list (I only just saw it now upon<br>
> Isaac's reply). I will try to forwards this along to others who have \
been<br> > conversing on related topics of eKYC, verification via selfies, etc. I \
will<br> > also get some of my volunteers assisting on the AML/CFT front involved \
in<br> > this thread.<br>
><br>
> Thank you also for bringing up our conversations with the INDY at OSCON, I<br>
> will re-engage with Joyce so we can carry forward the conversations we<br>
> started there.<br>
><br>
> The discussion around identity and looking at claim-based systems and<br>
> decentralized identities are all the more relevant as systems like Aadhar<br>
> continue to get hacked and sensitive data gets exposed:<br>
><br>
> <a href="https://www.huffingtonpost.in/2018/09/11/uidai-s-aadhaar-software-hacked-id-database-compromised-experts-confirm_a_23522472/" \
rel="noreferrer noreferrer noreferrer" \
target="_blank">https://www.huffingtonpost.in/2018/09/11/uidai-s-aadhaar-software-hacked-id-database-compromised-experts-confirm_a_23522472/</a><br>
><br>
> See some additional replies inline.<br>
><br>
><br>
> On Mon, Sep 10, 2018 at 11:31 AM James Dailey <<a \
href="mailto:jamespdailey@gmail.com" rel="noreferrer noreferrer" \
target="_blank">jamespdailey@gmail.com</a>><br> > wrote:<br>
><br>
> > Hi Devs -<br>
> ><br>
> > I'd like to raise an issue with regard to how Fineract 1.x and the \
new<br> > > Fineract-CN treats the concept of Identity.<br>
> ><br>
> > I was recently looking at Isaac's work on<br>
> ><br>
> ><br>
> <a href="https://github.com/apache/fineract-cn-customer/pull/7/commits/65a88b9879a46103fae440c42d1b0058909a93aa" \
rel="noreferrer noreferrer noreferrer" \
target="_blank">https://github.com/apache/fineract-cn-customer/pull/7/commits/65a88b9879a46103fae440c42d1b0058909a93aa</a><br>
> > .<br>
> > It got me thinking... I was unclear if the tests are fully covering our<br>
> > functionality, and wonder about how we are collectively thinking about<br>
> > identity.<br>
> ><br>
> > So, there has been a lot of work done recently on Digital Identity and<br>
> > Credentials globally. I think we should have as part of our thinking \
and<br> > > structure of the identity service:<br>
> ><br>
><br>
> For these components and sub-components of Identity you are starting to<br>
> flesh out below, it'd be great to synthesize into a requirements/spec \
doc<br> > on the. Fineract wiki.<br>
><br>
> ><br>
> > 1. Issuing authority (this could be any relevant civil authority \
such<br> > as<br>
> > Federal Government, State Department, Provincial Gov't), any \
private<br> > or<br>
> > non-profit but recognized entity (e.g. University), and also any<br>
> > commercial<br>
> > entity that has a pre-existing relationship including Bank, Mobile<br>
> > Provider, Microfinance Entity, or even Facebook/WeChat/Alibaba.<br>
> > When dealing with the unbanked, or underbanked, a form of digital<br>
> > identity may be self-issued or issued on the spot, and be trusted \
up<br> > to<br>
> > a<br>
> > point (see KYC below).<br>
> ><br>
> > 2. Credentials and Forms of verification - this could be a \
separate<br> > > concept in Fineract of [one to many] relationship where \
Fineract CN<br> > > stores<br>
> > that information or simply notes that multiple sources of \
verification<br> > > of<br>
> > identity or "claims" have been verified. For example, a \
person my<br> > > present<br>
> > a paper form from the local utility company showing they are a<br>
> customer.<br>
> > Or, for example, a person may be verified by the mobile provider \
as<br> > > being<br>
> > on that network with that specific IMEI (device) and that specific<br>
> > telephone number. I think it is important to treat such forms as<br>
> > security<br>
> > tokens (encrypted).<br>
> ><br>
><br>
> Javier is working with a customer who want to do selfie-based eKYC for<br>
> online account sign-ups. Some community members are quite expert on eKYC<br>
> processes as part of the loan origination workflow. I'll have those \
inputs<br> > be voiced here.<br>
><br>
> ><br>
> > 3. Claims - there have been attempts at the W3C (world wide web<br>
> > consortium) related to the issue of verification of digital \
identity,<br> > to<br>
> > describe these as "claims" where an individual may have \
multiple<br> > > sources in<br>
> > the formal and informal sectors by which they can claim identity. \
I<br> > > think<br>
> > of Claims as IssuingAuthority+Verified, but that may be<br>
> > oversimplification. Please see<br>
> > <a href="https://www.w3.org/TR/verifiable-claims-use-cases/" \
rel="noreferrer noreferrer noreferrer" \
target="_blank">https://www.w3.org/TR/verifiable-claims-use-cases/</a> .<br> > \
><br> > > 4. Relationship with KYC and AML/CFT - In Mifos and now in \
Fineract we<br> > > have a set of requirements around the relationship \
between the<br> > validity<br>
> > of<br>
> > the identity against regulations dealing with "know your \
customer" and<br> > > "anti-money-laundering" (inbound \
flows) and "counter the financing of<br> > > terrorism" \
(outbound flows). These requirements generally start with<br> > > KYC<br>
> > where the levels are generally thought of as KYC-0 (e.g. we don't \
know<br> > > much<br>
> > about them, but the authorities allow us to transact up to $300 \
per<br> > > month),<br>
> > KYC-1, KYC-2, up to KYC-3 (e.g.they have a formal and verified<br>
> identity<br>
> > credential from the national biometric system and they have up to \
the<br> > > limit<br>
> > of banking rules) In Fineract, I believe that what needs to be<br>
> stored<br>
> > is<br>
> > the initial authorized level of KYC, the record of how much is<br>
> expected<br>
> > to<br>
> > be transacted and then a calculated actual amount transacted so \
that<br> > > exceptional transactions can be flagged, and the movement \
from one KYC<br> > > level to another. It is common in banking at least \
to have a SAR<br> > > (Suspicious Activity Report) based on a comparison \
of expected<br> > > transactions<br>
> > and actual. The banking sector has been practicing this for a \
long<br> > time<br>
> > and rules are understood.<br>
> ><br>
><br>
> I will get Shabbir our CFT/AML expert to chime in on this thread and<br>
> advance his thinking on the generic framework-level components we could<br>
> implement to assist with compliance. As you also might already know, Ankur<br>
> as part of his GSOC project for the mobile wallet, worked on incorporating<br>
> into the front-end some of the elements of tiered KYC. You can see his<br>
> implementation at<br>
> <a href="https://gist.github.com/ankurs287/d9ef88cedcebe678f09fd555b17c7546" \
rel="noreferrer noreferrer noreferrer" \
target="_blank">https://gist.github.com/ankurs287/d9ef88cedcebe678f09fd555b17c7546</a><br>
><br>
> and the discussion thread that Sundari started at<br>
><br>
> <a href="http://mail-archives.apache.org/mod_mbox/fineract-dev/201806.mbox/%3CCAPnWRTjQHjys=vBFqkVqb7GZPo0iq7VFuGxP6sr-K0h55wK=mA@mail.gmail.com%3E" \
rel="noreferrer noreferrer noreferrer" \
target="_blank">http://mail-archives.apache.org/mod_mbox/fineract-dev/201806.mbox/%3CCAPnWRTjQHjys=vBFqkVqb7GZPo0iq7VFuGxP6sr-K0h55wK=mA@mail.gmail.com%3E</a><br>
><br>
><br>
> ><br>
> ><br>
> > At OSCON we also learned about INDY, which is part of the Hyperledger<br>
> > project, and deals with Identity using some new distributed ledger \
based<br> > > tools. I think it would be interesting to create a proof of \
concept<br> > where<br>
> > we link our identity service to the Indy code.<br>
> ><br>
> ><br>
> <a href="https://www.hyperledger.org/blog/2017/05/02/hyperledger-welcomes-project-indy" \
rel="noreferrer noreferrer noreferrer" \
target="_blank">https://www.hyperledger.org/blog/2017/05/02/hyperledger-welcomes-project-indy</a><br>
> > . This builds out the concept of a globally accessible public \
utility<br> > for<br>
> > decentralized identity.<br>
> ><br>
> > What would be a useful next step on this? Hoping for comments and<br>
> > exploration of requirements.<br>
> ><br>
> > Thanks,<br>
> > James<br>
> ><br>
><br>
><br>
> --<br>
> *Ed Cable*<br>
> President/CEO, Mifos Initiative<br>
> <a href="mailto:edcable@mifos.org" rel="noreferrer noreferrer" \
target="_blank">edcable@mifos.org</a> | Skype: edcable | Mobile: +1.484.477.8649<br> \
><br> > *Collectively Creating a World of 3 Billion Maries | *<a \
href="http://mifos.org" rel="noreferrer noreferrer noreferrer" \
target="_blank">http://mifos.org</a><br> > <<a href="http://facebook.com/mifos" \
rel="noreferrer noreferrer noreferrer" \
target="_blank">http://facebook.com/mifos</a>> <<a \
href="http://www.twitter.com/mifos" rel="noreferrer noreferrer noreferrer" \
target="_blank">http://www.twitter.com/mifos</a>><br> ><br>
</blockquote></div>
Mifos-developer mailing list
mifos-developer@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic