Great progress.  I’d encourage others to check this out .

Sent from Gmail Mobile

On Thu, Jul 30, 2026 at 2:44 PM Edward Kang <[email protected]> wrote:

>
> Hi everyone!
>
>
> I would like to share some progress on the new consumer-facing layer for
> Fineract that is being worked on/demoed as apart of GSoC 2026. To give some
> context, the project’s goal is to implement the functionality of the old
> self-service API without the security vulnerabilities. We aim to implement
> this by adding features like Attribute Based Access Controls (ABAC), 2FA,
> an independent auth layer, etc.
>
> https://github.com/apache/fineract-consumer-facing
>
> In my last email, I mentioned we implemented an auth layer, ABAC, 2FA with
> some basic functionality like savings, loans, and transfers.
>
> Since then, we’ve managed to complete a few major items.
>
>
> *Auditing*
>
> First, the auditing feature was implemented, where we handle frontend/BFF
> layer auditing concerns with the philosophy that we do not overlap with
> Fineract’s existing auditing on core banking services.
>
> In addition to auditing, we also added application rate limiting that
> applies per user and is configurable. This is to prevent malicious actors
> from overloading our database by hitting audit endpoints repeatedly.
>
> I would also like to mention that it is recommended to think about
> deploying this application with other services in tandem. After researching
> preventative measures to consumer-facing attacks like DDoS and
> network-based rate limiting for public endpoints like registration, I
> realized that we likely need our consumer facing app to be deployed behind
> network level protections provided by services like, but not necessarily,
> WAF, API Gateway, and Shield (in AWS terms).
>
> https://github.com/apache/fineract-consumer-facing/pull/78
>
>
> *Modularity and CQRS enforcement*
>
> Second, a refactor was done to better employ modularity and clean code
> practices within our codebase.
>
> Spring Modulith was added to ensure features are relatively
> self-contained. Most modules are set as closed except for data and
> services, ensuring cross referencing is done purely through approved
> channels. Shared infrastructure is kept open for modules to use, however.
> We also handle dependency inversion violations with a port/adapter
> methodology.
>
> ArchUnit was added to further enforce our CQRS split by checking that
> command-side file references are not made in the query-side and vice versa.
>
> https://github.com/apache/fineract-consumer-facing/pull/72
>
>
> *User Profile and Password Reset*
>
> Third, we added User profile and Password resets to keep in line with the
> self-service API’s functionality.
>
> Notably, the write endpoints for user profile pictures were left out. This
> is to prevent users from being able to directly change their backoffice
> Fineract photos, which can be a source of identity fraud.
>
> https://github.com/apache/fineract-consumer-facing/pull/55
>
>
> *Beneficiaries and ABAC Improvements*
>
> Fourth, we added the Beneficiaries feature to restrict transfers to
> approved users. This adds another layer of security.
>
> ABAC resource checks were also refactored. To improve performance of ABAC
> resource checks, we decided to cache largely unchanging items like accounts
> owned. The main tradeoff is that we lose some time to update our caches
> when new accounts are created/deleted. However, every action in our
> consumer-facing app speeds up.
>
> To do this, an L1/L2 cache was implemented. The first cache (L1) exists
> in memory on the same node as the ABAC check. This allows us to check for
> account ownership quickly in memory without a roundtrip. When ownership
> data exists in another server (for multi-node setups), it is important for
> us to have a shared Valkey cache as well. When the same-server check fails,
> we proceed to check our distributed cache.
>
> https://github.com/apache/fineract-consumer-facing/pull/39
>
> If there are any recommendations, questions, or places where I am wrong,
> please feel free to advise!
>
> Sincerely,
>
> Edward
>
> --
> Edward E. Kang
> [email protected]
> 972-768-6940
>

Reply via email to