India has built shared rails for money and data. UPI moves payments between accounts in real time. The account aggregator framework lets people share their financial data between regulated entities with explicit, revocable consent.
These rails change what a bank or fintech has to build. The interface is defined. The competition is on reliability, consent experience and what you do with the data once a customer shares it.
What the rails give you
UPI provides a common payment layer across banks and apps. Participants connect through a sponsor bank or directly, follow the network’s specifications and handle a high volume of small, time-sensitive transactions.
The account aggregator framework, regulated by the RBI, separates three roles:
- Financial information providers — banks and other entities that hold data
- Financial information users — lenders, wealth platforms and others who want to use it
- Account aggregators — consent managers that move encrypted data between them without reading it
Consent is a structured artefact: what data, for what purpose, for how long, how often. The customer can see and revoke it.
API-first is an operating model
Many institutions still treat APIs as a wrapper around a core banking system built for branches. That shows up as timeouts, inconsistent error codes and batch-shaped data behind a real-time front door.
API-first means:
- Contracts designed before implementation, versioned and documented
- Clear, consistent error handling that apps and partners can act on
- Idempotency for anything that moves money, so retries do not double-debit
- Rate limits and backpressure that protect the core during peaks
- Sandboxes that behave like production, including failure cases
The specifications for these networks are detailed. Passing certification is necessary, but it does not make a system reliable at month-end or festival-season volumes.
Reliability is the product
On shared rails, customers do not see whose system failed. They see that the payment did not go through.
Engineering priorities that pay off:
- Reconciliation — automated matching of switch, ledger and partner records, with exceptions routed to people quickly
- Timeouts and pending states — clear handling of transactions whose final status is not yet known
- Observability — tracing a single transaction across gateway, core and network callbacks
- Capacity testing — load tests against realistic peak patterns, not averages
- Graceful degradation — when a downstream bank is slow, fail fast with a useful message
Consent as a design discipline
For financial information users, the account aggregator flow is an opportunity and a responsibility.
- Ask only for the data and duration the use case needs
- Explain the purpose in plain language before the consent screen
- Store consent artefacts and link every data fetch to one
- Delete or stop fetching when consent expires or is revoked
- Log access so audit can trace who used which data and why
India’s data protection law adds its own obligations on purpose limitation and retention. Legal and compliance teams should set the rules; engineering should make them enforceable in code.
Where AI fits
Consented financial data supports better credit decisions, cash-flow based lending for small businesses and personalised advice. It also raises the bar on explainability and fairness.
Keep models behind the same consent checks as everything else. Version the features derived from aggregated data. Make sure a credit decision can be explained in terms a customer and an auditor can follow.
Where to start
- Map every external API you expose or consume on these rails, with owners and error contracts
- Trace one transaction end to end and find where visibility breaks
- Automate reconciliation for the highest-volume flow first
- Review consent requests against the minimum data each use case needs
- Load test against your worst historical peak, then add margin
Incubics builds API platforms and data products on India’s financial rails with controls designed to support RBI and data protection requirements.