Client Case Study · NBFC

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.

Engagement at a glance
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.

NBFC reporting data flowLoan, disbursement, repayment, collection, customer and branch tables in the client's Oracle database are extracted by scheduled synthesis jobs, which join them, apply business rules, bucket overdue amounts by days past due and aggregate them. The results are loaded into a PostgreSQL reporting database used by Apache Superset. Superset serves parameter-based dashboards embedded in the client application, and generates periodic reports.SOURCESYNTHESISREPORTING STOREANALYTICSCONSUMERSOracle databaseLending system of recordLoan accountsDisbursementsRepayment schedulesReceipts & collectionsCustomersBranches & productsSynthesis jobsScheduled, parameterised1Extract source tables2Join related tables3Apply business rules4Bucket by days past due5Aggregate to report grainPostgreSQLSuperset reporting DBLoan factsOutstanding snapshotsCollection factsShaped for reporting, sodashboards stay fast and thelending system stays untouchedApache SupersetDashboards & reportsDatasets & metricsParameter filtersScheduled reportsLoan · Outstanding ·Collection · Analyticreport modulesEmbeddeddashboards inside theclient's applicationVia Superset embeddingPeriodic reportsRefreshed each cyclefor the chosen periodNew reports in SupersetSCHEDULE & PARAMETERSEach periodic run takes the reporting period, as-of date and other parameters, and refreshes the dashboards that use them.

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.

  1. 01

    Trigger

    A scheduled run starts with its parameters: the reporting period and the as-of date.

  2. 02

    Extract

    Only the tables and rows the period needs are read from the Oracle database.

  3. 03

    Synthesise

    Rows are joined, business rules applied, overdue amounts bucketed and totals aggregated.

  4. 04

    Load

    Results are written to the PostgreSQL reporting tables that Superset reads.

  5. 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.

Representative layout with illustrative data - not client data
Loan dashboard
ParametersReporting period:MonthlyAs-of date:30 SepBranch:All branchesProduct:All productsRefreshed by the last scheduled run
Loans disbursed
1,248
+6.4% this month
Amount disbursed
₹48.6 Cr
+4.1% this month
Average ticket
₹3.9 L
per loan
Active loans
18,420
+1.8% as of date
Disbursement trend (₹ Cr)
NovDecJanFebMarAprMayJunJulAugSepOct
Disbursement by product
4products
  • 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.