NBFC Loan & Collection Analytics
on Apache Superset
For a non-banking financial company, we built the BI layer: data synthesised from its Oracle lending database into a PostgreSQL reporting store, and served as parameter-based Superset dashboards embedded in its own application.
- 4
- Reporting modules: loan, outstanding, collection, analytics
- Oracle
- Source lending database
- Postgres
- Synthesised reporting store
- Superset
- Dashboards embedded in the client app
Client name withheld under NDA. Figures on this page are illustrative.
The client
A non-banking financial company (NBFC) whose loan accounts, disbursements, repayment schedules and collections are recorded in an Oracle database. Its name is withheld under a non-disclosure agreement.
Lending teams, branch managers and management all need the same few answers, at different levels of detail: what was disbursed, what is outstanding and how overdue it is, and how much of what fell due was collected.
The brief
Those answers sit across many tables in the lending database. A single outstanding report needs loan, schedule and receipt data joined together, overdue amounts bucketed by days past due, and totals rolled up by branch and product.
The client wanted that reporting inside its own application, refreshed on a schedule for the period being reviewed, with room to add new reports without rebuilding the pipeline each time. And reporting load had to stay off the database the lending operation runs on.
The approach
We separated reporting from the system of record. Scheduled synthesis jobs read the tables each report needs from Oracle, apply the business rules, and write the results into a PostgreSQL database that Apache Superset uses as its reporting store.
Superset sits on top of that store with shared datasets and metrics, so loan, outstanding and collection figures are defined once and every dashboard agrees. Its dashboards are embedded in the client’s application, so staff see them where they already work.
Each run is parameter based. The reporting period and as-of date are inputs to the run, so the existing dashboards refresh for the new period, the periodic reports are generated from the same data, and a new report is a new Superset chart rather than a new pipeline.
How the data flows
Data leaves the Oracle lending database once per cycle, is shaped into reporting tables in PostgreSQL, and only then reaches Superset. Dashboards never query the system of record.
Table and job names are generalised. The client's schema is covered by the NDA.
One refresh cycle
The same five steps run on every scheduled cycle. Because each run is driven by parameters, a new period or a re-run for a past date is a change of input, not new code.
- 01
Trigger
A scheduled run starts with its parameters: the reporting period and the as-of date.
- 02
Extract
Only the tables and rows the period needs are read from the Oracle database.
- 03
Synthesise
Rows are joined, business rules applied, overdue amounts bucketed and totals aggregated.
- 04
Load
Results are written to the PostgreSQL reporting tables that Superset reads.
- 05
Refresh & report
Existing dashboards refresh for the new period, and the periodic reports are generated.
The reporting modules
Four modules, each a set of Superset dashboards embedded in the client's application. Pick a module to see the kind of view it gives.
- MSME loans38%
- Vehicle loans27%
- Personal loans21%
- Gold loans14%
Real dashboards are not published here. Portfolio, branch and collection figures are the client's confidential data.
What we delivered
The BI layer end to end, from the first read of the Oracle tables to the dashboards inside the client’s application.
- Oracle data extraction
- Scheduled reads from the lending tables each report needs.
- Data synthesis layer
- Joins, business rules, days-past-due bucketing and aggregation to report grain.
- PostgreSQL reporting database
- Reporting tables shaped for Superset, kept apart from the lending system.
- Superset datasets and metrics
- Shared definitions, so every dashboard reports the same numbers.
- Loan module
- Disbursement volumes, amounts, ticket sizes and product mix.
- Outstanding module
- Principal outstanding by days-past-due bucket, branch and product.
- Collection module
- Demand against collection, efficiency and bucket-wise recovery.
- Analytic reports
- Portfolio analysis built on the same synthesised data.
- Parameter-based periodic refresh
- Existing dashboards refreshed and reports generated for each period.
- Embedded dashboards
- Superset dashboards inside the client’s own application.
Before and after
The change is where reporting now happens: in its own store, on a schedule, and inside the application rather than beside it.
Before
- Loan, outstanding and collection data spread across many Oracle tables
- Each report needed its own joins and business rules
- Reporting load competing with the lending database
- Period-end figures assembled for each review
After
- One synthesised reporting store in PostgreSQL
- Metrics defined once in Superset and shared by every dashboard
- Dashboards refreshed per period through parameters
- Reports embedded in the application staff already use
- New reports added as Superset charts, not new pipelines
Reporting from a lending database?
Tell us where your loan, outstanding and collection data lives today. We will map the synthesis jobs, reporting store and Superset dashboards it would take, and what to build first.
We sign an NDA before the first technical conversation, as we did with this client.