Engineering an enterprise-scale personal-finance platform

What this is

An anonymised look at the core systems we built for a large Indian personal-finance app: the backend, the data pipeline and the security underneath. The app gives people one view of their money across bank accounts, investments, deposits and loans, with automatic insight into their spending and regular payments. The client owns the brand, the mobile and web apps, the product and the licences behind it. Our part was the engineering underneath: collecting data on India’s Account Aggregator framework with the person’s consent, an AI analytics pipeline run with proper MLOps, and the security and compliance work a regulated platform needs.

The shape of the system

The platform has three jobs, and they are kept apart so that none gets in the way of the others:

• The consent and data engine talks to the Account Aggregator gateways, tracks every person’s consent, waits for banks and depositories to reply, and decrypts the incoming data in memory.
• The analytics pipeline cleans transaction text that looks different at every bank, then runs models that sort spending into categories, spot regular payments and flag unusual ones, all under MLOps control.
• The security and compliance core keeps personal identity apart from financial records, encrypts sensitive fields, deletes data when consent ends, and keeps an audit log that cannot be edited.

Collecting data with consent

Collecting data from Indian banks and depositories is never a simple question and answer. Some institutions reply in seconds, others take much longer, and some time out at the busy morning hour. So the engine is built to wait well:

• Callbacks and queues, not waiting. When a person approves a request, the system records the signed consent, asks for a data session and hands the job to background workers. They wait for the Account Aggregator’s callback before collecting the data, so the app never freezes waiting for a slow bank.
• Encrypted from end to end. Account Aggregator gateways cannot read the data passing through them. For each fetch the engine creates fresh encryption keys. The data arrives encrypted from the bank, is decrypted only inside an isolated worker, and is then checked against the official data formats.
• Consent checked at every step. A consent can be pending, active, paused, revoked or expired. Before every scheduled refresh the system checks that it is still valid. If the person pauses or revokes it, in the client’s app or in their Account Aggregator app, queued fetches stop at once and the compliance rules for that account run.
• One bank down does not stop the rest. If a person links four bank accounts and one bank is down for maintenance, the other three update straight away. The fourth is marked delayed and retried later, within the gateway’s rate limits.

The analytics, and the MLOps behind it

Bank statements are messy. The same kind of payment looks different at every bank, and a raw line full of reference numbers means nothing to a person until it is cleaned up. The pipeline works in two stages, with no large generative model doing basic bookkeeping:

• Rules first. A fast rules engine removes reference numbers, bank codes and payment type labels, and pulls out a clean merchant or counterparty name.
• Small, fast models next. They assign a spending category, find income, spot regular payments such as loan instalments, insurance premiums and bills, and flag unusual spikes or duplicate charges.

A model that quietly gets worse when a bank changes its statement format would lose people’s trust overnight, so the models run under a proper MLOps workflow:

• No personal details in the models. Names, account numbers and phone numbers are swapped for internal codes before any transaction reaches them.
• Unsure means safe. Every prediction carries a confidence score. Below the threshold, the transaction gets a safe general category and an anonymised pattern is queued for review, instead of a guess.
• New models prove themselves first. A new version runs quietly alongside the live one on real traffic, and replaces it only after it does better without breaking categories that were already right.
• Daily drift checks. If a large bank changes its statement format, the share of uncategorised transactions rises, and the team is alerted the same day.

Security and compliance, built in from the start

On a regulated financial platform in India, security and compliance cannot be added just before an audit. They are part of the database design and the network from day one:

• Identity kept apart from money. Name, mobile number, PAN and email live in a separate vault with tightly controlled access. The analytics and transaction databases hold only internal IDs, and sensitive fields are encrypted, with the keys held in the cloud provider’s key management service.
• Every message checked. Each incoming message from the Account Aggregator network is checked against its digital signature before it is accepted, so fake or replayed messages are turned away.
• Data deleted when consent ends. When a consent expires or is revoked, a background job deletes or anonymises the raw financial data according to the client’s retention policy, and records proof that it did.
• An audit log that cannot be edited. Every consent request, notification, data fetch and deletion is written to a log that can only be added to. When an auditor asks what happened to a consent on a given date, the answer is a clear timeline.
• Data stays in India. Servers, databases, queues and backups all run in Indian cloud regions, on private networks with tightly limited access, ready for regular security testing (VAPT).

How we worked

Two senior developers designed the architecture, the encryption flows, the separation of data and the MLOps setup, and reviewed every change that touched security or financial data. Two junior developers built the data parsers, the rules for each institution’s format, the automated tests and the monitoring dashboards under their guidance. Before going live, the whole Account Aggregator flow was tested against sandbox institutions, including expired and revoked consents, banks timing out, and badly formed data. The build took nine months.

The result

The platform is live in production. Every day it runs Account Aggregator consent flows, encrypted data fetches and automated analytics for a large number of retail users, with room to grow.

What it demonstrates

This is enterprise-grade fintech engineering: consent-first data aggregation, a genuine AI pipeline with the operational discipline to keep it trustworthy, and the security and compliance a regulated platform lives by, all built to scale. The client owns the product, the advice, and every registration behind it. We build the technology. It is the same standard we bring to the AI and analytics work and the wider software we build for other clients.

This is an anonymised account of client work. The client's identity and product details have been removed. We build technology. We do not provide investment advice, we do not make financial recommendations, and any advice offered inside the product belongs to the client, who holds the registrations for it.

← All case studies