Really interested in this. There's a use case I'm currently confronted with 
where we need to prevent customers having multiple accounts. There are two 
possible unique identifiers we could use, National ID Numbers which people are 
comfortable sharing or Bank verification Numbers which they aren't happy to 
share. We don't have the programming competence to incorporate this but we'd be 
interested in developing this an making it available to the community 

Sent from my iPhone

> On 4 Jul 2020, at 15:00, Awasum Yannick <yannickawa...@gmail.com> wrote:
> 
> 
> 
> 
>> On Sat, Jul 4, 2020 at 1:12 PM Ankit Muellner <an...@muellners.org> wrote:
>> Awesum, 
>> Clearly, this issue is a lifecycle goal. More third party services come 
>> under the community's radar, more integrations take place. Therefore, I 
>> foresee this on the CN branch.
>> 
>> Now Identification is not only limited to KYC and authentication. There are 
>> usually multiple data pointers with which a client account in any Core 
>> banking is identified with. Scores of personalised third party services have 
>> API endpoints with which Fineract platform can consume their use case 
>> specifics.
>> 
>> Categorically & unfortunately, Asewum, we don't have an Identity service. A 
>> sustainable & stable identity service in context to Fineract as a financial 
>> platform(and keeping up with the 2020 era) is to be able to ascertain/verify 
>> self user or client creation as accurately as what they claim it to be.
>> Example- A client creation requires their unique ID no. which can be matched 
>> with Govt issued Database or if a client creation requires their existing 
>> bank account access, which can be securely taken through say Yodlee. (since 
>> there are countable such services which Fineract does not need to keep a 
>> track of- we need to create a sequential, secure, interop seamless framework 
>> to integrate them)
>> 
>> Just to avoid ambiguity, this thread is contextual to scores of third party 
>> services where Identification is one use case. Let's call these 'Widgets' 
>> for simplicity.
>> 
>> As far as the list of examples I shared, there are much more examples. The 
>> community needs to bring this on the development roadmap.
>>  
>> Just to give you a fundamental challenge here- Either partners notice that 
>> they can use few of these services and attempt to integrate or these service 
>> provider also come forward, having noticed Fineract initiative. A good 
>> example is Lokyata which is an external third party service for our 
>> conversation purposes. However, their team is unable to find a definitive 
>> seamless integration framework with Fineract platform.
>> This is true with other examples as well. 
>> 
>> Now some of these 'Widgets' can be used with Fineract at the infrastructure 
>> level, but as Fineract becomes more platformified, it will be critical to 
>> bring these services under one seamless framework.
>> 
> 
> 
> Will you like to create issues around these features with as much details as 
> possible and maybe send a few PRs? That way, maintainers can have a bit more 
> context in code and see examples on how this will help.
> 
> 
>>> On Fri, Jul 3, 2020 at 2:24 PM Awasum Yannick <awa...@apache.org> wrote:
>>> Hi Ankit,
>>> 
>>> I am trying to understand what you are saying here. Maybe some questions 
>>> will make me understand better.
>>> 
>>>> On Fri, Jul 3, 2020 at 10:14 AM Ankit Muellner <an...@muellners.org> wrote:
>>>> Hello everyone,
>>>> 
>>>> At the community level, we must explore the possibility of creating a 
>>>> seamless framework for third party services integration at both functional 
>>>> and non functional levels:
>>>> 1. For both open and closed source services
>>>> 2. For freemium and paid services
>>> 
>>> Are you talking here about FIneract 1.x or Fineract CN? Fineract CN
>>> 
>>>> 
>>>> The use case examples are Identification, Credit decisioning APIs, Account 
>>>> scoring, portfolio management, USSD, SMS.
>>>> Past e.g Fineract has already tested the Twilio SMS API and many partners 
>>>> deploy this.
>>> 
>>> Fineract 1.x and Fineract CN has basic services for Identification (do you 
>>> mean KYC or authentication here? ). KYC, authentication is not all. Check 
>>> out these examples use cases.
>>> 
>>> Both platforms have a basic way to manage Loan Portfolios and SMS 
>>> messaging? Are these not enough? What is your experience using them and 
>>> some draw backs?
>>>> There are examples such as 
>>>> Accern API, 
>>>> HID Global Identification, 
>>>> Lokyata product API, 
>>>> Yodlee 
>>>> Plaid
>>>> Alloy
>>>> Difitek
>>>> 
>>>> This framework makes the Fineract platform more extensible with use of 
>>>> case specific third party services and better orchestration of deployments.
>>>> 
>>> 
>>> Are you trying to gather requirements around implementing a service that 
>>> will allow integration with the above APIs? Which of these are more 
>>> important to you?  
>>>> Fineract does have external services integration with web hooks and 
>>>> developers can of course explore integrations at API level for individual 
>>>> use cases. However, a standardized framework is broadly missing to create 
>>>> the integration workflows as simple as a non technical person using his 
>>>> key to access these services on Fineract platform.
>>>> 
>>>> Now, it is imperative that we look at tokenization, security, interop 
>>>> feasibility of such third party services one by one, and keep adding them.
>>> 
>>> I keep hearing that the Identity service in Fineract CN needs enhancements 
>>> and I have no idea why? People who have seen the draw backs of this 
>>> service, if you can please explain to some of us the problems currently 
>>> being faced?
>>> 
>>>  
>>>> 
>>>> If as a partner organisation, you have already deployed such integrations, 
>>>> I would request your comments here.
>>>> Any thoughts. I can aid this thread by documenting Jira issues on fineract 
>>>> board upon your views here.
>>>> -- 
>>>> Ankit Müllner
>>>> Muellners Europe 
>>>> +4581929792
>>>>               
>>>> This mail is governed by Muellners®  IT policy.
>>>> The information contained in this e-mail and any accompanying documents 
>>>> may contain information that is confidential or otherwise protected from 
>>>> disclosure. If you are not the intended recipient of this message, or if 
>>>> this message has been addressed to you in error, please immediately alert 
>>>> the sender by reply e-mail and then delete this message, including any 
>>>> attachments. Any dissemination, distribution or other use of the contents 
>>>> of this message by anyone other than the intended recipient is strictly 
>>>> prohibited. All messages sent to and from this e-mail address may be 
>>>> monitored as permitted by applicable law and regulations to ensure 
>>>> compliance with our internal policies and to protect our business. E-mails 
>>>> are not secure and cannot be guaranteed to be error free as they can be 
>>>> intercepted, amended, lost or destroyed, or contain viruses. You are 
>>>> deemed to have accepted these risks if you communicate with us by e-mail.
>> 
>> 
>> -- 
>> Ankit Müllner
>> Muellners Europe 
>> +4581929792
>>               
>> This mail is governed by Muellners®  IT policy.
>> The information contained in this e-mail and any accompanying documents may 
>> contain information that is confidential or otherwise protected from 
>> disclosure. If you are not the intended recipient of this message, or if 
>> this message has been addressed to you in error, please immediately alert 
>> the sender by reply e-mail and then delete this message, including any 
>> attachments. Any dissemination, distribution or other use of the contents of 
>> this message by anyone other than the intended recipient is strictly 
>> prohibited. All messages sent to and from this e-mail address may be 
>> monitored as permitted by applicable law and regulations to ensure 
>> compliance with our internal policies and to protect our business. E-mails 
>> are not secure and cannot be guaranteed to be error free as they can be 
>> intercepted, amended, lost or destroyed, or contain viruses. You are deemed 
>> to have accepted these risks if you communicate with us by e-mail.

Reply via email to