Banking & Fintech Acronyms in India: PSS, AUA, KUA, NPCI & More

Sit in enough audit rooms and you learn to spot the moment a founder loses the plot. It usually arrives about twenty minutes in, when someone from the RBI regional office asks a straight question: are you a payment aggregator or a payment gateway, and where is your PA authorisation. The room goes quiet. The CTO says the word gateway. The compliance head says aggregator. The lawyer says something about a partnership with a bank. Three answers, one company, and none of them line up with the licence on file.

Acronyms are not trivia in Indian fintech. They are the difference between holding customer funds legally and running an unauthorised payment system that RBI can shut down with a single directive. Half the compliance failures I see do not start with a technical control gap. They start with a founder who genuinely did not know that AUA and KUA are two different UIDAI roles, or that PPI money sitting in an escrow is governed by a completely separate master direction from the one covering their lending book. So let us do the unglamorous thing properly: define the terms that actually decide your audit scope, and say what each one costs you if you get it wrong.

You cannot read a fintech acronym in isolation. Each one belongs to a regulator, and the regulator decides the rulebook, the audit cadence, and who can revoke your ability to operate. Before you learn a single product acronym, know whose door you are standing at.

Notice NPCI is not a regulator in the legal sense. It is a not-for-profit company owned by banks. But if you run on UPI, NPCI procedural guidelines and its audit requirements govern your day-to-day operations as tightly as any RBI direction, and NPCI can suspend your access. Treat its circulars as binding, because in practice they are.

PSS stands for the Payment and Settlement Systems Act, 2007. This is the single most misunderstood acronym in Indian fintech, and it is the one that quietly determines whether a large chunk of your business is legal. The Act says that no person may operate a payment system in India without authorisation from RBI. That is it. Simple sentence, enormous consequences.

A payment system, under the Act, is any system that enables payment between a payer and a beneficiary, involving clearing, payment or settlement. If your platform sits in the flow of money between a customer and a merchant, and money passes through an account you control, you are very likely operating a payment system. That triggers the need for authorisation, most commonly as a Payment Aggregator. Founders who skip this step are not just non-compliant on a control; they are running an unauthorised payment system, which is an offence under the Act and carries the risk of a wind-down directive.

What actually happens: a D2C brand builds a slick checkout, holds settlement money for two days in its own current account before paying merchants, and calls it a tech feature. Eighteen months later a bank partner runs a review before renewing the nodal account, flags that funds are being pooled without a PA licence, and freezes settlements. The brand now has merchant money it cannot legally move and a customer base it cannot refund on time. That is a PSS Act problem, and no amount of ISO certification fixes it.

PA is Payment Aggregator. PG is Payment Gateway. They are governed by the RBI Guidelines on Regulation of Payment Aggregators and Payment Gateways, and the distinction is the whole game.

The net-worth numbers are real and they bite. A PA must have a minimum net worth of Rs 15 crore at application and Rs 25 crore by the end of the third financial year. Founders who assumed a gateway-lite path suddenly discover they need a capital plan, an escrow arrangement, a board-approved information security policy, and a System Audit Report from a CERT-In empanelled auditor before RBI will even process the application.

NPCI runs the plumbing that most Indian fintech products are built on. You will meet these acronyms the moment you integrate, and each one drags its own compliance obligations behind it.

On UPI specifically, know your role. A PSP (Payment Service Provider) is the bank-sponsored entity that connects to the UPI switch. A TPAP (Third-Party Application Provider) is the app that offers the UPI interface to users, riding on a PSP bank. If you build a UPI app, you are almost certainly a TPAP, and NPCI has explicit requirements around data localisation, on-soil storage of UPI transaction data, and periodic audits. Getting your role wrong here means you cannot answer the most basic audit question about who is accountable for what.

If you touch Aadhaar, UIDAI defines exactly what you are allowed to do through a set of roles, and the security obligations differ sharply between them. Confusing them is one of the fastest ways to fail a UIDAI audit.

The security consequence is concrete. UIDAI requires that Aadhaar numbers be stored only in a reference-key form, tokenised, and that any stored Aadhaar data live in an encrypted Aadhaar Data Vault with strict HSM-backed key management. UIDAI mandates a compliance audit by an empanelled auditor, and its aims and objects around information security are non-negotiable. I have seen a KYC-heavy lender store raw Aadhaar numbers in a logging table because a developer added debug logging that was never removed. That single line of code is a reportable UIDAI breach and a personal-data exposure under the DPDP Act in the same stroke.

Some acronyms are not products; they are what you are. And what you are decides which master direction you live under for the rest of your regulated life.

Here is the uncomfortable structural truth of Indian fintech: in most partnership models, the RE, the bank or NBFC, holds the licence and therefore the liability, while the fintech holds the product and the customer. When the audit comes, the RE will push every control obligation it can onto you contractually. If you are an LSP riding on a bank's NBFC, your security posture is not just your problem; it is the audit finding that lands on your partner's desk and threatens the partnership itself.

Once your entity type and product are settled, a second layer of acronyms defines what you actually have to prove. These are the ones that generate the artefacts an auditor asks for.

Do not confuse a SAR with a VAPT. A VAPT tells you whether an attacker can break in. A System Audit Report tells RBI whether your entire control environment, governance, escrow reconciliation, data localisation, incident response and merchant onboarding, meets the payment-system requirements. Both are needed, and they are not substitutes for one another.

Founders always ask for the number. There is no single number, but there are honest ranges. These are indicative Indian-market figures for a mid-sized fintech, and they move with scope and firm.

The costs that hurt are never the audit fees. They are the remediation. A PA applicant who discovers, mid-SAR, that reconciliation between the escrow and the settlement ledger is manual and unauditable will spend far more rebuilding that flow than they ever paid the auditor. Budget for the fix, not just the finding.

If you do nothing else after reading this, run your product through the list below. Every item maps to a question a real examiner or partner-bank auditor will ask.

Go back to that quiet audit room. The founder who freezes on PA versus PG is not stupid; they are just discovering, in public, that a word they used loosely on a pitch deck was actually a regulatory declaration. Every acronym in this glossary is a small contract with a regulator. Use the right one and the audit is a formality. Use the wrong one and you find out during an examination, which is the most expensive possible time to learn.

At CyberSigma we sit on the auditor side of that table as CERT-In empanelled assessors and PCI QSAs, and we do this hands-on, mapping your fund flows and data flows to the exact directions that govern them before RBI or a partner bank does it for you. If you want a second pair of eyes on which of these acronyms actually apply to your build, we are happy to have that conversation early, when it is cheap to fix.