Loan management software development: the borrower side

A loan management system (LMS) services a loan after payout: the loan account, the repayment schedule, interest, payments, arrears and closure. A loan origination system (LOS) takes the loan from application to payout, and the borrower's app or portal is a third layer that talks to both but is neither. Loan management software development, as we do it, means building that third layer and connecting it to the lender's core system. Application and payout are covered on our lending software development page.

The main risk in loan management is a balance or a schedule that does not match the agreement. In our projects the loan book, interest, the repayment schedule and loan statuses stay in the client's core system, and the app shows what that system holds.

We have built and developed Aasa24, the lending app of Aasa Polska, since May 2023. Since January 2026 we have been building the mobile app of AvaFin Poland. Both companies are loan institutions supervised by the Polish Financial Supervision Authority (KNF).

A borrower portal is the part of loan management the customer uses: it shows what is owed and when, and lets the borrower act on it.

Aasa24

In Aasa24 the borrower pays an installment, makes an early repayment, takes a payment holiday (in the app since November 2023) or refinances (since August 2024), with no call to the contact center. The agreement, the repayment schedule and the repayment history can be downloaded as PDFs.

Several rules keep the screens in line with the loan. The app shows an installment as paid according to rules agreed with Aasa, the Pay button appears only when there is something to pay, and the schedule lists only active installment plans. The loan list can be filtered by status, with the filter running in Aasa's core system. For the credit card in the app, a repayment screen shows the minimum amount due.

AvaFin

The account area of the AvaFin app shows the amount to repay, the due date or the delay, the loan history with documents, and repayment and extension offers. A loan extension has its own path: the customer requests it, follows its progress and can cancel it. Some extension types ask for a document or a guarantor's statement, added from the camera or from files.

Payment and extension run in AvaFin's own webview inside the app. The app takes the customer to that step and refreshes the status when they come back.

Every borrower screen depends on the loan's state, so the list of states is the contract between the core system and the app. Aasa24 turns more than 40 application and loan states into plain messages.

The AvaFin app handles 18 loan states, and each one has its own view on the home screen and on the loan screen. They include open, in extension, overdue with and without an extension, with a bailiff, in court, sold, assigned to another creditor, rejected and in acceptance. In AvaFin the loan state matrix is the single source of truth for screen design.

A borrower app takes repayments through a payment gateway and verifies the borrower's bank account. In Aasa24 repayments go through the Autopay payment gateway. The integration handles a change in the amount due and receives payment notifications over a secured channel.

AvaFin customers verify a bank account by logging in to their bank through Kontomatik, using open banking, or with a verification transfer through Autopay. The check runs at registration and in the loan application.

A lending app connects to the core lending system through an API between that system and the app's backend.

In Aasa24 the backend is ours: Django, PostgreSQL and Celery on AWS, with infrastructure in Terraform. It takes loan data, statuses and calculator parameters from Aasa's core system and shows the customer's data from that system in the app. When the core system is unavailable, the app handles it without losing the customer's data. Aasa's team changes calculator parameters, documents and messages in an admin panel, with no new release in the app stores.

In the AvaFin app the core system decides the order of the loan application steps, and the app displays them. Calculator prices come from the same pricing engine as the core system, so the app and the core system price a loan the same way.

For the borrower, arrears are handled in the app: the screens with the amount due, the payment, the extension and the payment holiday. That is our part of debt collection; we have not built a collection system or a contact strategy engine.

CCD2, Directive (EU) 2023/2225, applies through national rules from November 20, 2026 (Article 48). As of October 2026, Poland has not published a new act implementing it. After payout, CCD2 asks lenders to offer forbearance before enforcement, to detect payment difficulties early and to refer borrowers to debt advice (Articles 35 and 36). In a borrower app that means a help path and forbearance options before the case moves on.

We have not run a CCD2 implementation project, and we do not describe the apps we build as CCD2-compliant.

We build the app and keep developing it after launch. On Aasa24 the same core team has worked since 2023: 3-4 mobile developers, plus backend, DevOps, QA and a project manager. The first public release of Aasa24 came in November 2023, less than 6 months after work started. Since then, a new version has shipped every 3-4 weeks on average, and every pull request goes through code review.

New projects start with a free discovery workshop, which gives you an MVP scope, a roadmap and an estimate of cost, timeline and team.