Author:Hengky MulyonoA deposit monitoring dashboard for a national commercial bank. The bank offers a deposit product to customers of a partner bank through the partner's digital banking app. The dashboard shows which deposits are active, which are close to maturity, how much interest is due and how the portfolio is growing, and produces the reports the team needs for reconciliation.
The first page shows funds under management, the number of deposits and customers, the average per customer and the average interest rate, with a comparison against the previous month and year.
Two charts show the funds the bank has to prepare and the funds already received for the coming and past days. A growth view shows the trend of the whole portfolio.
Reports can be filtered by date, term, amount, renewal type, status, opening date and maturity date, then exported to Excel. The team uses them for reconciliation and for tracking achievement against the quota.
Every deposit carries a status: active, broken early, paid out, or matured but not yet payable. Interest payments have their own status, so the team can see what has been paid and what is pending.
Access is set per role, accounts are managed from one menu and every action is recorded in an activity log that can be searched. In-app reminders flag deposits that are about to mature.
This is a deposit monitoring dashboard we built for a national commercial bank. The bank sells an online deposit product to the customers of a partner bank through the partner’s digital banking app. The dashboard gives the bank’s team one place to follow those deposits, from opening to maturity, and to prepare the reports they need.
This write-up covers why the bank needed it, what the dashboard does, how the data reaches it and how the work was approached.
The partnership gave the bank access to a large base of digital customers. Customers of the partner bank could open the bank’s deposit product from the partner’s app, at a more attractive rate than they were used to. That worked well for customers and for growth, but it meant every deposit lived in two worlds: the customer saw it in the partner’s app, and the bank recorded it in its own systems.
The bank’s team needed to know how many deposits were running, which were about to mature, how much interest was due and whether the numbers matched what the partner reported. Without a dashboard, that meant compiling raw data into spreadsheets for every reconciliation and every progress report.
The dashboard is a web application with a summary view, a report page and the tools to manage who can see what. It is organised into these modules:
| Module | What it does |
|---|---|
| Settings and security | Roles, permissions, user accounts and the application’s security settings. |
| Data intake | Pulls deposit data, ledger data, payouts and interest payments from the bank’s own sources into the dashboard. |
| Dashboard | Summary figures, charts by term, customer and deposit type, portfolio growth, latest transactions and the status of each deposit. |
| Reports | Detailed transaction, growth, interest rate and maturity reports, with a period filter and Excel export. |
| Notifications | In-app reminders for approaching maturity and automatic renewal. |
| Audit trail | A log of user and system activity. |
Reconciliation depends on everyone reading a deposit’s status the same way, so the dashboard uses four of them.
| Status | Meaning |
|---|---|
| Active | The deposit has been issued and is running. |
| Broken early | The customer closed the deposit before its maturity date. |
| Paid out | The deposit matured and the funds were sent to the customer’s account. |
| Matured but not payable | The deposit reached maturity, but the destination account could not receive the funds. |
Every figure on the dashboard can be opened, so a question about a total leads straight to the individual transactions.
| Step | What happened |
|---|---|
| Specification | The deposit journey in the partner’s app (open, break early, pay out at maturity, update the destination account) was documented first. The dashboard was defined as the monitoring layer on top of it. |
| Build | Settings and security, data intake, the dashboard, reports, the audit trail and notifications were delivered as one web application on the bank’s own infrastructure. |
| Scope control | The timeline was short, so a few items were scheduled for a later stage and the first release concentrated on monitoring and reporting. |
| Handover | The bank received the specification, test and migration documents, a user guide and the source code, with a warranty and a maintenance period after go-live. |
The team now has one view of the deposit portfolio instead of a set of spreadsheets. Reports that used to be compiled by hand come from filters and an export button, maturity no longer depends on someone remembering a date, and the activity log shows who looked at or changed what.
If your team follows a financial product across more than one system, our fintech software development page describes how we approach projects like this one.
DISCLAIMER:
To protect client confidentiality, all data displayed, including names, numbers, identifiers, values, and the length, structure, and format of such data, has been replaced with fictitious data, randomized, or obscured, and does not reflect any client's actual data or systems. No inference about any client's actual data, systems, or business information should be drawn from these materials. Any resemblance to actual persons, organizations, or data is purely coincidental.
See more digital solutions built to improve operations, customer experiences, and business growth across industries.
We're ready to help you deliver high-performing websites, boost your business visibility in search engines, and build digital platforms tailored to your specific needs.
