Identity and Fineract
Hi Devs -
I'd like to raise an issue with regard to how Fineract 1.x and the new
Fineract-CN treats the concept of Identity.
I was recently looking at Isaac's work on
It got me thinking... I was unclear if the tests are fully covering our
functionality, and wonder about how we are collectively thinking about
So, there has been a lot of work done recently on Digital Identity and
Credentials globally. I think we should have as part of our thinking and
structure of the identity service:
1. Issuing authority (this could be any relevant civil authority such as
Federal Government, State Department, Provincial Gov't), any private or
non-profit but recognized entity (e.g. University), and also any commercial
entity that has a pre-existing relationship including Bank, Mobile
Provider, Microfinance Entity, or even Facebook/WeChat/Alibaba.
When dealing with the unbanked, or underbanked, a form of digital
identity may be self-issued or issued on the spot, and be trusted up to a
point (see KYC below).
2. Credentials and Forms of verification - this could be a separate
concept in Fineract of [one to many] relationship where Fineract CN stores
that information or simply notes that multiple sources of verification of
identity or "claims" have been verified. For example, a person my present
a paper form from the local utility company showing they are a customer.
Or, for example, a person may be verified by the mobile provider as being
on that network with that specific IMEI (device) and that specific
telephone number. I think it is important to treat such forms as security
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
4. Relationship with KYC and AML/CFT - In Mifos and now in Fineract we
have a set of requirements around the relationship between the validity of
the identity against regulations dealing with "know your customer" and
"anti-money-laundering" (inbound flows) and "counter the financing of
terrorism" (outbound flows). These requirements generally start with KYC
where the levels are generally thought of as KYC-0 (e.g. we don't know much
about them, but the authorities allow us to transact up to $300 per month),
KYC-1, KYC-2, up to KYC-3 (e.g.they have a formal and verified identity
credential from the national biometric system and they have up to the limit
of banking rules) In Fineract, I believe that what needs to be stored is
the initial authorized level of KYC, the record of how much is expected to
be transacted and then a calculated actual amount transacted so that
exceptional transactions can be flagged, and the movement from one KYC
level to another. It is common in banking at least to have a SAR
(Suspicious Activity Report) based on a comparison of expected transactions
and actual. The banking sector has been practicing this for a long time
and rules are understood.
At OSCON we also learned about INDY, which is part of the Hyperledger
project, and deals with Identity using some new distributed ledger based
tools. I think it would be interesting to create a proof of concept where
we link our identity service to the Indy code.
. This builds out the concept of a globally accessible public utility for
What would be a useful next step on this? Hoping for comments and
exploration of requirements.