You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by James Dailey <ja...@gmail.com> on 2018/09/10 18:31:26 UTC
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
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:
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.
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
Re: Identity and Fineract
Posted by Sendoro Juma <se...@singo.africa>.
+1
1. KYC | AML| CFT is FUNDAMENTAL/MUST HAVE
2. Mifos/Fineract should rely on External Identity-Claim Services
The above are very strategic point that must be worked on.
Please go ahead with with Wiki Page.
Cheers
Sendoro
>
> On February 10, 2019 at 3:03 AM James Dailey <ja...@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 <ja...@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.
> >
> > >
> >
> > > > > 1. 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/ .
> > >
> > > 2. 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>
> >
> > >
Re: Identity and Fineract
Posted by James Dailey <ja...@gmail.com>.
Welcome Rachit - We really appreciate you taking this on. You've already
done a lot of work on this. Thanks.
Are you thinking we should make comments or suggested edits to the online
doc? Currently it is set as "view only".
Here are some preliminary comments:
You should use one of the internationally accepted definitions of KYC and
other terms in your requirements. I recommend the Glossary by the ITU,
published 2018.
e.g. "Know Your Customer: The process of identifying a new customer at the
time of account opening, in compliance with law and regulation. The
identification requirements may be lower for low value accounts ("Tiered
KYC"). The term is also used in connection with regulatory requirements for
a provider to understand, on an ongoing basis, who their customer is and
how they are using their account."
https://www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ECOPO-2018-PDF-E.pdf
<https://www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ECOPO-2018-PDF-E.pdf>
Broadly, after reading the document, I wonder if there are adjustments to
the schemes or authorities and the kinds of use cases that are described.
For example, I don't think University Transcript is that useful for many
people, and wonder if something like SocialMedia claim or certificate would
be better? The language is unclear on whether or not these are optional?
flexible?
In one of the use cases I read "get a loan for a car" (and being a climate
change guy immediately wanted to change that), and so, would suggest
instead: "get a loan for a Solar Home System" or "get a loan for an ebike"
or "get a loan for a new roof". Peace.
The P1 money transfer scenario - I think there is some overlap with our
existing efforts around payment flows, and we should not work at cross
purposes with this POC. I think we should look at how the payment
processor handles the lookup via the claims and perhaps re-phrase some of
those requirements here. @Edward Cable <ed...@mifos.org> please comment
on this.
thanks - great start!!!
@jdailey67
On Sun, Mar 3, 2019 at 6:49 PM Rachit Kansal <ra...@gmail.com> wrote:
> Hi everyone,
>
> My name is Rachit and I am volunteering for the Mifos initiative as a
> product manager. Sorry for the delay, I was caught up in a lot of work and
> some travelling.
>
> Just a small brief about myself, I graduated with an undergraduate degree
> in Computer Science in 2017. I have had some experience with the open
> source community as well and also successfully completed GSoC 2017 as a
> student. Since then I am working in a cloud company called Nutanix.
> Initially started off as a developer and now taking up responsibilities as
> a product manager as well.
>
> Ed had asked me to explore KYC and the Sovrin/Indy project and try to come
> up with the requirements for a PoC for the same (which we could take up for
> GSoC).Find the attached link to the requirement document for the PoC.
>
> Please provide your inputs and details that you feel should be added to it
> both from the requirements perspective as well as the developer
> perspective. Also I would request the core developers of the fineract-cn to
> chime in and maybe add details on how the interaction/integration with the
> platform would look like for the PoC to cover the scenarios mentioned in
> the document.
>
> *Requirements Document:*
> https://docs.google.com/document/d/1s-wx06l1UKfmzEL7qXOU-PfGfPPQma6flf-oGFg9OWs/edit?usp=sharing
>
> --
> Regards,
> Rachit Kansal
>
> On Mon, 11 Feb 2019 at 23:15, Ed Cable <ed...@mifos.org> wrote:
>
>> 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 <ja...@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>
>>> >
>>>
>>
>
Re: Identity and Fineract
Posted by Rachit Kansal <ra...@gmail.com>.
Hi Guys,
I have put the requirements on confluence:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103093257
I have made some minor changes as rightly pointed out by James. Please feel
free to
add or discuss more details, this document should provide a starting point
from where
we can reach a detailed plan for the project and its scope.
*I checked your document and it seems you doing this work focused on
theIndian market? Are there use cases somewhere which the Indy project
hasbeen used?*
The document is not tailor made for indian market, i just cited some
examples. This
PoC would be generic and can be used anywhere. As part of Sovrin foundation
(which
uses Indy project), once you partner as a steward then the digital identity
capabilities
can be used.
Eg:
https://blog.sovrin.org/canadas-atb-financial-joins-sovrin-network-as-a-founding-steward-9d5ffc9d3fcd
*Have you looked at the current way Fineract and Fineract CN are
handlingKYC and identity? What are the short comings?*
I am not aware of how KYC is performed currently in Fineract CN and in
which workflows is it triggered. It would be great if you could point me to
some
resources here.
*As James noted, let me get your efforts synchronized with those
developersworking on payment and money transfer related use cases so no
efforts areduplicated and we can ensure that digital identify, verification
ofidentity claims, KYC, etc gets supported as needed to facilitate
paymentsuse cases.I will invite others in the community to participate in
this discussion.*
Yes this will be great. It would be also beneficial to have the developers
who have
built the current KYC solution (in Fineract, the existing flows) to be in
the loop since
they would have better ideas on how to proceed with the integration for the
purpose
of the PoC.
--
Regards,
Rachit Kansal
On Tue, 5 Mar 2019 at 07:11, Ed Cable <ed...@mifos.org> wrote:
> Rachit,
>
> Thanks for sharing this with the community. Echoing what Awasum said, could
> you please create a page on the wiki he linked to.
>
> Let me know your Apache ID once you've created it and I will give you the
> necessary permissions to create and edit pages.
>
> You can place it under the Product Requirement section for now and then we
> can move it accordingly once we adopt a new structure for the wiki that
> James is proposing on a separate thread.
>
> As part of that wiki page, it would be helpful to have a section that
> provides an initial set of use cases and also welcomes the community to
> provide input on use cases they need digital identity solutions to better
> help support.
>
> As part of this POC and some other ongoing collaboration with Yoti, I'd
> like for institutions and individuals across the community who have digital
> needs and well-articulated use cases to volunteer to be a part of these
> pilot efforts.
>
> As James noted, let me get your efforts synchronized with those developers
> working on payment and money transfer related use cases so no efforts are
> duplicated and we can ensure that digital identify, verification of
> identity claims, KYC, etc gets supported as needed to facilitate payments
> use cases.
>
> I will invite others in the community to participate in this discussion.
>
> I will keep this thread focused on the Sovrin/Indy POC but will send a
> separate email related to Yoti including a guest blog post from Ken Banks
> and an upcoming webinar that he'll be leading for the community.
>
> On Mon, Mar 4, 2019 at 1:15 AM Awasum Yannick <aw...@apache.org> wrote:
>
> > Hi Rachit,
> >
> > Welcome to the community.
> >
> > Thanks for all the work you are doing.
> >
> > Will it be Ok if you transferred your document to Confluence? Here is the
> > link to signup and create an account:
> > https://cwiki.apache.org/confluence/signup.action
> >
> > Here is the Fineract Confluence home:
> > https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Home
> >
> > You can decide where to put your requirements. There is a section for
> > Fineract CN and others for gathering functional specs.
> >
> > This way there will be history and a point of reference.
> >
> > I checked your document and it seems you doing this work focused on the
> > Indian market? Are there use cases somewhere which the Indy project has
> > been used?
> > Have you looked at the current way Fineract and Fineract CN are handling
> > KYC and identity? What are the short comings?
> >
> > Thanks.
> > Awasum
> >
> > On Mon, Mar 4, 2019 at 3:49 AM Rachit Kansal <ra...@gmail.com>
> > wrote:
> >
> > > Hi everyone,
> > >
> > > My name is Rachit and I am volunteering for the Mifos initiative as a
> > > product manager. Sorry for the delay, I was caught up in a lot of work
> > and
> > > some travelling.
> > >
> > > Just a small brief about myself, I graduated with an undergraduate
> degree
> > > in Computer Science in 2017. I have had some experience with the open
> > > source community as well and also successfully completed GSoC 2017 as a
> > > student. Since then I am working in a cloud company called Nutanix.
> > > Initially started off as a developer and now taking up responsibilities
> > as
> > > a product manager as well.
> > >
> > > Ed had asked me to explore KYC and the Sovrin/Indy project and try to
> > come
> > > up with the requirements for a PoC for the same (which we could take up
> > for
> > > GSoC).Find the attached link to the requirement document for the PoC.
> > >
> > > Please provide your inputs and details that you feel should be added to
> > it
> > > both from the requirements perspective as well as the developer
> > > perspective. Also I would request the core developers of the
> fineract-cn
> > to
> > > chime in and maybe add details on how the interaction/integration with
> > the
> > > platform would look like for the PoC to cover the scenarios mentioned
> in
> > > the document.
> > >
> > > *Requirements Document:*
> > >
> > >
> >
> https://docs.google.com/document/d/1s-wx06l1UKfmzEL7qXOU-PfGfPPQma6flf-oGFg9OWs/edit?usp=sharing
> > >
> > > --
> > > Regards,
> > > Rachit Kansal
> > >
> > > On Mon, 11 Feb 2019 at 23:15, Ed Cable <ed...@mifos.org> wrote:
> > >
> > > > 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>
> > > >> >
> > > >>
> > > >
> > >
> >
>
>
> --
> *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>
>
Re: Identity and Fineract
Posted by Ed Cable <ed...@mifos.org>.
Rachit,
Thanks for sharing this with the community. Echoing what Awasum said, could
you please create a page on the wiki he linked to.
Let me know your Apache ID once you've created it and I will give you the
necessary permissions to create and edit pages.
You can place it under the Product Requirement section for now and then we
can move it accordingly once we adopt a new structure for the wiki that
James is proposing on a separate thread.
As part of that wiki page, it would be helpful to have a section that
provides an initial set of use cases and also welcomes the community to
provide input on use cases they need digital identity solutions to better
help support.
As part of this POC and some other ongoing collaboration with Yoti, I'd
like for institutions and individuals across the community who have digital
needs and well-articulated use cases to volunteer to be a part of these
pilot efforts.
As James noted, let me get your efforts synchronized with those developers
working on payment and money transfer related use cases so no efforts are
duplicated and we can ensure that digital identify, verification of
identity claims, KYC, etc gets supported as needed to facilitate payments
use cases.
I will invite others in the community to participate in this discussion.
I will keep this thread focused on the Sovrin/Indy POC but will send a
separate email related to Yoti including a guest blog post from Ken Banks
and an upcoming webinar that he'll be leading for the community.
On Mon, Mar 4, 2019 at 1:15 AM Awasum Yannick <aw...@apache.org> wrote:
> Hi Rachit,
>
> Welcome to the community.
>
> Thanks for all the work you are doing.
>
> Will it be Ok if you transferred your document to Confluence? Here is the
> link to signup and create an account:
> https://cwiki.apache.org/confluence/signup.action
>
> Here is the Fineract Confluence home:
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Home
>
> You can decide where to put your requirements. There is a section for
> Fineract CN and others for gathering functional specs.
>
> This way there will be history and a point of reference.
>
> I checked your document and it seems you doing this work focused on the
> Indian market? Are there use cases somewhere which the Indy project has
> been used?
> Have you looked at the current way Fineract and Fineract CN are handling
> KYC and identity? What are the short comings?
>
> Thanks.
> Awasum
>
> On Mon, Mar 4, 2019 at 3:49 AM Rachit Kansal <ra...@gmail.com>
> wrote:
>
> > Hi everyone,
> >
> > My name is Rachit and I am volunteering for the Mifos initiative as a
> > product manager. Sorry for the delay, I was caught up in a lot of work
> and
> > some travelling.
> >
> > Just a small brief about myself, I graduated with an undergraduate degree
> > in Computer Science in 2017. I have had some experience with the open
> > source community as well and also successfully completed GSoC 2017 as a
> > student. Since then I am working in a cloud company called Nutanix.
> > Initially started off as a developer and now taking up responsibilities
> as
> > a product manager as well.
> >
> > Ed had asked me to explore KYC and the Sovrin/Indy project and try to
> come
> > up with the requirements for a PoC for the same (which we could take up
> for
> > GSoC).Find the attached link to the requirement document for the PoC.
> >
> > Please provide your inputs and details that you feel should be added to
> it
> > both from the requirements perspective as well as the developer
> > perspective. Also I would request the core developers of the fineract-cn
> to
> > chime in and maybe add details on how the interaction/integration with
> the
> > platform would look like for the PoC to cover the scenarios mentioned in
> > the document.
> >
> > *Requirements Document:*
> >
> >
> https://docs.google.com/document/d/1s-wx06l1UKfmzEL7qXOU-PfGfPPQma6flf-oGFg9OWs/edit?usp=sharing
> >
> > --
> > Regards,
> > Rachit Kansal
> >
> > On Mon, 11 Feb 2019 at 23:15, Ed Cable <ed...@mifos.org> wrote:
> >
> > > 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>
> > >> >
> > >>
> > >
> >
>
--
*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>
Re: Identity and Fineract
Posted by Awasum Yannick <aw...@apache.org>.
Hi Rachit,
Welcome to the community.
Thanks for all the work you are doing.
Will it be Ok if you transferred your document to Confluence? Here is the
link to signup and create an account:
https://cwiki.apache.org/confluence/signup.action
Here is the Fineract Confluence home:
https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Home
You can decide where to put your requirements. There is a section for
Fineract CN and others for gathering functional specs.
This way there will be history and a point of reference.
I checked your document and it seems you doing this work focused on the
Indian market? Are there use cases somewhere which the Indy project has
been used?
Have you looked at the current way Fineract and Fineract CN are handling
KYC and identity? What are the short comings?
Thanks.
Awasum
On Mon, Mar 4, 2019 at 3:49 AM Rachit Kansal <ra...@gmail.com> wrote:
> Hi everyone,
>
> My name is Rachit and I am volunteering for the Mifos initiative as a
> product manager. Sorry for the delay, I was caught up in a lot of work and
> some travelling.
>
> Just a small brief about myself, I graduated with an undergraduate degree
> in Computer Science in 2017. I have had some experience with the open
> source community as well and also successfully completed GSoC 2017 as a
> student. Since then I am working in a cloud company called Nutanix.
> Initially started off as a developer and now taking up responsibilities as
> a product manager as well.
>
> Ed had asked me to explore KYC and the Sovrin/Indy project and try to come
> up with the requirements for a PoC for the same (which we could take up for
> GSoC).Find the attached link to the requirement document for the PoC.
>
> Please provide your inputs and details that you feel should be added to it
> both from the requirements perspective as well as the developer
> perspective. Also I would request the core developers of the fineract-cn to
> chime in and maybe add details on how the interaction/integration with the
> platform would look like for the PoC to cover the scenarios mentioned in
> the document.
>
> *Requirements Document:*
>
> https://docs.google.com/document/d/1s-wx06l1UKfmzEL7qXOU-PfGfPPQma6flf-oGFg9OWs/edit?usp=sharing
>
> --
> Regards,
> Rachit Kansal
>
> On Mon, 11 Feb 2019 at 23:15, Ed Cable <ed...@mifos.org> wrote:
>
> > 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>
> >> >
> >>
> >
>
Re: Identity and Fineract
Posted by Rachit Kansal <ra...@gmail.com>.
Hi everyone,
My name is Rachit and I am volunteering for the Mifos initiative as a
product manager. Sorry for the delay, I was caught up in a lot of work and
some travelling.
Just a small brief about myself, I graduated with an undergraduate degree
in Computer Science in 2017. I have had some experience with the open
source community as well and also successfully completed GSoC 2017 as a
student. Since then I am working in a cloud company called Nutanix.
Initially started off as a developer and now taking up responsibilities as
a product manager as well.
Ed had asked me to explore KYC and the Sovrin/Indy project and try to come
up with the requirements for a PoC for the same (which we could take up for
GSoC).Find the attached link to the requirement document for the PoC.
Please provide your inputs and details that you feel should be added to it
both from the requirements perspective as well as the developer
perspective. Also I would request the core developers of the fineract-cn to
chime in and maybe add details on how the interaction/integration with the
platform would look like for the PoC to cover the scenarios mentioned in
the document.
*Requirements Document:*
https://docs.google.com/document/d/1s-wx06l1UKfmzEL7qXOU-PfGfPPQma6flf-oGFg9OWs/edit?usp=sharing
--
Regards,
Rachit Kansal
On Mon, 11 Feb 2019 at 23:15, Ed Cable <ed...@mifos.org> wrote:
> 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 <ja...@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>
>> >
>>
>
Re: Identity and Fineract
Posted by Ed Cable <ed...@mifos.org>.
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 <ja...@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>
> >
>
Re: Identity and Fineract
Posted by James Dailey <ja...@gmail.com>.
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 <ja...@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>
>
Re: Identity and Fineract
Posted by Ed Cable <ed...@mifos.org>.
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 <ja...@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>
Re: Identity and Fineract
Posted by Isaac Kamga <is...@mifos.org>.
Hello James,
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.
Cheers,
Isaac Kamga.
On Mon, Sep 10, 2018 at 7:31 PM James Dailey <ja...@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:
>
> 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.
>
> 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
>