Hi Edward This is a rather big topic, once you dig into it.
First, what is the role of Fineract in the "Onboarding flow"? If we assume Fineract is the source of onboarding fidelity, then all biometrics, including images of faces, fingerprints, etc could logically be part of the customer PII. This is likely the case in some smaller institutions that originated this functional requirement. That is, for a small institution, they don't want or need something more expensive or complicated than a photo in the system associated with the Customer (aka "client") - uploaded by the Bank Employee or Agent - that allows them to "validate" in person that they are speaking to the correct person. Note that the validation of the photo is done by a privileged user and is thus subject to controls. Second, I think the question is more about "what is the use case?" IF the photo is part of a biometric validation in the Authentication flow, then it doesn't belong in the Fineract system, it belongs in a separately secured component. If the photo is part of the KYC process, then a record of that handshake or exchange (ie. that there was a photo and it was validated) is the necessary thing although storing the biometric in Fineract is probably ok, but not mandatory, in that case. I believe that the common pattern in modern banking systems is to carefully permission access to such PII, but there is a hang over from earlier manual systems even at larger institutions. In many banking operations that I've seen over the years, you would collect a photo of the person and attach it to their physical file. This made it possible for the Bank teller or lending agent to perform a human-validation of the person standing in front of them. In that case, the photo belonged in the back end system (Fineract) when they digitized to allow for multi-branch operations. So I think part of the issue is that patterns are shifting and authentication via biometric data has become a huge topic: i.e. Your fingerprints, you image, your voice, your walking gait, all of which can now be mimicked/faked by AI. One other data point: Back when the project was looking at a new architecture called "CN" (cloud native), we had this pattern in the link. It might be useful to take a look. https://izakey.github.io/fineract-cn-api-docs-site/customer/ After understanding all of the input, you and your mentor should discuss and pick an approach that is "safe for now" and go with the POC of this with some assumptions. Thanks, James On Thu, Jul 16, 2026 at 1:22 PM Edward Kang <[email protected]> wrote: > Hello everyone! > > I am working through an issue right now that I was hoping to get some > experienced eyes on. > > I am currently working on the consumer-facing side of Fineract as apart of > GSoC 2026, where I ran into an issue setting/viewing client profile > pictures in Fineract. The deprecated self service API actually let you set > this picture yourself. The problem I am having is that I am concerned about > the security implications of this. *Mainly, I am wondering if the profile > picture is used for backoffice or field KYC. * > > For example, if a client goes to a bank, is the profile picture used as an > identity verification step? If this is the case, I am leaning towards not > including "write" capability on profile pictures, as this could invite > potential for identity fraud. > > I think the ways we can proceed are: > 1) Replicate the old self-service project and allow clients to change > their own pictures in Fineract. This implies that it is enough that the > authenticated user is the one to change their profile picture. > 2) Allow "read-only" for Fineract client profile pictures on the > consumer-facing side. > 3) Setup a profile picture unique to the consumer-facing app. This > eliminates the identity fraud issues in the backoffice. > > What does everyone think about this issue? > > -- > Edward E. Kang > [email protected] > 972-768-6940 >
