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.
An Asset & Liabilities Management system for a national commercial bank. It helps the risk team calculate and report liquidity ratios and interest rate risk in line with regulator requirements. Data from several sources is imported and validated, calculations run from configurable templates, and every report goes through staged approval before it is published.
Data goes through import, validation, filtering and a ready-to-use stage. Each data load shows its status, so records with problems are visible and can be cleaned up before anyone calculates with them.
Data and reports are checked against balance sheet data automatically and marked as matched or not matched. The result can be exported or printed for the archive.
Reports are calculated from validated data and the active template. They can be recalculated or run for an earlier date, and they are published once approved.
Changes to data and reports take effect only after someone else approves them. The approver sees what was added, edited or deleted, a rejection needs a reason, and an overview lists everything still waiting.
Liquidity ratio results appear on daily or monthly dashboards. A risk monitoring module adds liquidity risk indicators and a dashboard of its own.
The interest rate risk reports and the Liquidity Gap report follow the same workflow, so the team handles every report the same way.
Every activity is logged, and access is set per role, so each user only sees and works on the parts their role covers.
Report components and calculation rules are set through templates. When the regulator changes a rule, the template is updated and the system does not have to be rebuilt.
This is an Asset & Liabilities Management system we built for the risk team of a national commercial bank. It brings the bank’s liquidity and interest rate risk reporting into one application. Data from several source systems is imported and checked, reports are calculated from templates the team can adjust, and every report is approved before it is published.
This write-up covers why the bank needed it, what the system does, how a report moves through it, and how it grew.
Banks have to calculate and report liquidity ratios and interest rate risk to the regulator on a fixed schedule. For this bank, much of that work depended on spreadsheets. How long a report would take was hard to predict, a wrong data set or a wrong method could slip through, and there was little record of who had changed what.
The data itself was part of the problem. It came from several source systems with uneven quality, and matching it to the balance sheet was done by hand. The bank wanted one system that processes the data, runs the calculations the same way each time, keeps a history of every change and shortens the time it takes to prepare a report.
A few terms come up throughout the system. LCR, the Liquidity Coverage Ratio, shows whether a bank holds enough liquid assets to cover its short-term cash needs. NSFR, the Net Stable Funding Ratio, looks at how stable the bank’s funding is over a one-year horizon. The Liquidity Gap compares cash coming in and going out across time ranges. IRRBB, short for Interest Rate Risk in the Banking Book, covers interest rate risk on the loans and deposits a bank holds. ILAAP, the Internal Liquidity Adequacy Assessment Process, is where the bank assesses its liquidity, including liquidity within the day.
The system is organised into these modules:
| Module | What it does |
|---|---|
| Master data and access control | Reference data, user accounts, roles and access rights. |
| Data source quality | Import, validation and filtering of data from several source systems before it is used in a report. |
| Report templates | Templates that define the components of each report, which the team can adjust. |
| Liquidity reporting | LCR, NSFR, Liquidity Gap and intraday liquidity reports prepared under the regulator’s rules. |
| Interest rate risk reporting | The IRRBB reports. |
| Risk dashboard and monitoring | Dashboards that summarise liquidity risk indicators. |
| Approval and activity log | Approval of data and reports, and a full log of activity. |
Each report follows the same path, which is what lets the team work the same way across every report.
Every step is logged, so the bank can see who made a change, who approved it and when.
The system was delivered in phases. The regulator updated its rules along the way, and the team found things to improve once they used it every day, so each phase was scoped as an enhancement of the same application.
| Phase | What was added |
|---|---|
| First phase | Access control, master data, data quality for each source, report templates, the liquidity and interest rate risk reports, a risk dashboard and the activity log. |
| Second phase | Calculations adjusted to the regulator’s updated rules, balance sheet reconciliation, bulk deletion of invalid data, change details on the approval screen and an overview of items waiting for approval. |
| Third phase | Additional liquidity modules, risk monitoring with its own dashboard, a check for approved data that still contains invalid records, reorganised menus, reference data managed in the app with approval, and validation settings that users manage themselves. |
Because calculation rules sit in templates, a rule change does not have to wait for redevelopment.
The calculations now run the same way every time, instead of depending on whoever built the spreadsheet. Reconciliation against the balance sheet happens inside the system, and the approval history is stored next to the report it belongs to. Reference data that used to be edited directly in the database now goes through the same maker and approver steps as everything else.
If your team runs regulatory reporting on spreadsheets, our fintech software development page describes how we approach projects like this one.
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.
