Dear Apache Fineract Community,
My name is Deepak Kumar. I am introducing myself as a GSoC 2026
contributor applicant.
── Background ──────────────────────────────────────────────────
I am a backend software engineer with 4.9 years of professional
experience in Java, Spring Boot, Apache Kafka, PostgreSQL, and AWS.
My most significant role was as the sole engineer on the Quartz
Gateway security and messaging module for the ASX CHESS Replacement
project — one of the largest post-trade infrastructure modernisation
programs in Asia-Pacific, processing millions of trade settlements
per day.
In that role I shipped:
• SCIM 2.0 provisioning APIs (/Users, /Groups) with ETag-based
optimistic concurrency, atomic transactions, and SailPoint +
ForgeRock integration — reducing manual onboarding time by 80%
• SAML 2.0 SSO with full assertion validation, session fixation
prevention, and CSRF protection — passed external ASX security
audit with zero identity-related findings
• Kafka consumer service with DLQ handling, idempotency via
unique database constraints, and offset commit discipline
guaranteeing zero message loss under pod restarts
• LIMIT/OFFSET paginated alerts API that resolved a production
OutOfMemoryError under 1,00,000 record load at ASX
── Why FINERACT-2439 ───────────────────────────────────────────
The BFF Self-Service API project is a direct match for my
production experience.
I have read the mailing list discussion carefully. James's point
about the separate identity layer — end-user auth completely
decoupled from Fineract's internal m_appuser — is the right call.
I implemented exactly this boundary at ASX: external participants
(brokers) authenticated against a dedicated layer that called
internal settlement services using service accounts, never
exposing internal credentials to the consumer boundary.
My proposal will be built around:
• Spring Authorization Server as the BFF's own OAuth 2.1 server
• Separate consumer user database (PostgreSQL + Liquibase)
• Service account self-provisioning against Fineract on startup
• Idempotency keys on POST /transactions and POST /loans
• Resilience4j circuit breaker on all outbound Fineract calls
• Testcontainers integration test suite
── First Contribution — FINERACT-2441 ──────────────────────────
I will be picking up FINERACT-2441 (fineract-client-feign test
migration) this week as my first codebase contribution before
the proposal deadline.
── A Few Questions for the Community ───────────────────────────
Before finalizing my proposal, I would value mentor guidance on:
1. For the BFF module — is the preference a new Gradle submodule
within the Fineract monorepo (similar to fineract-provider),
or a completely separate repository with its own artifact?
2. On the service account setup — should the BFF self-provision
a dedicated Fineract service account on first boot, or is
manual operator configuration the preferred approach for
the POC scope?
3. For FINERACT-2441 — is there a preferred starting point
(specific test class or module) that would deliver the
most value for the migration effort?
GitHub: https://github.com/Dpk376
Thank you for the incredible work on Fineract. I look forward
to contributing meaningfully.
Warm regards,
Deepak Kumar S S
[email protected]
