Core Banking, Loan Processing and Accounting

A core banking platform that keeps account changes, approval decisions and financial records connected.

This core banking system case study covers a platform that treats a repayment as an account operation. Each operation carries an approval history and an accounting effect, and loan and deposit administration share that same model. Each institution still sets its own products and permissions. It keeps its own database and business date.

The challenge

A caller can lose the response after a repayment has already gone through. A retry must recover that result without posting the repayment twice. At the same time, daily processing or another staff request may be changing the same account. Those two cases call for different controls.

What we built

Every change moves through a command service, which first logs the request and confirms the caller has permission. Under maker-checker approval, one staff member raises a change and a second one approves it. Until then, the pending work waits in the command history.

Staff manage repayment schedules, allocations and rescheduling. They also handle loan delinquency, along with deposit products and the transfers between accounts. Accounting posts journal entries against product mappings. A correction creates a linked reversal and keeps the earlier entry in place.

Keep the repayment and its accounting together

The repayment handler checks loan state, the transaction date and working-day rules before it allocates funds across installments. It saves the loan change, accounting effect and business event in one transaction. An outbox holds that event for later broker delivery, and external publishing has to be enabled when it is needed. A webhook for an operation inside a larger batch waits for the batch to commit. A later rollback therefore does not publish a success hook through this path.

Recognise a retry, then coordinate new work

Completed commands keep their responses on record. A stable retry key fetches the result that the earlier command already produced. Uniqueness holds across the action, entity and key. A different operation needs a new key.

Version checks then catch competing changes made to the same account record. Savings transfers take stronger account locks in a fixed order, and loan updates respect the end-of-day locks. Daily processing follows the institution's stated business date rather than the server clock alone. Close-of-business work can be split across workers. A failed step leaves its error and lock on the loan, so an operator can resolve it before processing goes on.

Project success

The account history ties together the requested change, the approval and the posting. A repayment's accounting entries commit with the loan update, and a repeated request can recover its response. Unfinished daily work also has an identifiable state. That state holds the loan, the failed step and the lock that stopped it. It stays available for investigation and resolution.

Technology stack

Backend

Java, Spring Boot, Jersey

Persistence

EclipseLink, Liquibase

Supported databases

PostgreSQL, MariaDB, MySQL

Batch processing

Spring Batch

Messaging

Kafka or ActiveMQ, Avro