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