Account-type underwriting · 2,686 words

RBI Commercial Entity Rules: Current vs Savings Accounts in Bank Statement Analysis

Product eligibility, CC/OD, and GST-style turnover analysis all depend on whether the account is Savings or Current. This guide translates commercial-entity practice into a statement-analysis control (Law 5).

Indian savings accounts are a retail product. Current accounts are a commercial product. When a statement named “X Enterprises” or “Y Pvt Ltd” is parsed as Savings because a header said SB, every downstream ratio warps: you will apply PL FOIR to a trading book, or you will miss CC/OD eligibility. FinAnalyser Law 5 exists so the parser does not participate in that warp.

Substance: names that are commercial

• Pvt Ltd, Limited, LLP, LLC
• Enterprises, Traders, Trading Co, Exports
• HUF in a business context (policy-dependent)
• Hospital, Clinic, Pharmacy as a going concern
• Manufacturing, Textiles, Agencies

If those tokens appear as the account title and the PDF never says “Savings Account,” classify Current. If the PDF explicitly says Savings Account, keep Savings and raise a policy exception for the credit officer — do not silently relabel against the bank’s own print.

Why credit desks care

Worked example: HDFC 5020 and savings codes

Some HDFC prefixes historically map to savings products. A prefix is a hint, not a waiver of Law 5. If the title is commercial and the statement does not say Savings Account, Current wins. If both commercial title and explicit Savings Account exist, emit Savings plus an exception flag — that file needs a human.

Business transacted on genuine savings accounts

Proprietors often run GST sales through personal SB. That is a conduct and product issue. BSA should still compute operational cashflow (Law 6 contra out) and bounce taxonomy. Do not call it a clean salaried PL. Recommend Current/CC product. Watch for structuring just below reporting thresholds.

CA and 44AB angle

Tax audit bank recon must know which ledger is business. Mis-tagged savings hides turnover. Pair this guide with the 44AB cornerstone. Tally Prime ledgers named “Bank OD” against a parsed Savings account is a recon red flag.

How FinAnalyser implements Law 5

AccountExtractor.extractAccountType reads title tokens and explicit savings phrases. HDFC parser may override on known savings prefixes when the title is retail. Commercial tokens without explicit savings → Current. The Excel cover should show the decided type and the evidence snippet.

Desk checklist

1. Read account title before product pitch.
2. Search PDF for “Savings Account” / “SB A/C” explicit lines.
3. If commercial + no explicit savings → Current path (BL/CC/OD).
4. If commercial + explicit savings → exception to credit.
5. Never force PL FOIR on a trading SB without disclosure.

How wrong products get opened

Branch incentives, incomplete KYC constitutions, and “we’ll convert later” create savings accounts in commercial names. Years later a LAP RM inherits the PDF. Your BSA must surface the mismatch, not bless it. Ask for a bank letter if the customer insists the product is savings for a Pvt Ltd — that letter is credit evidence, the header alone is not.

Payment banks and SFBs add more product codes. Paytm/Airtel/FINO statements may not look like Finacle at all. Still apply name-substance rules when a commercial string appears. Universal extract plus Law 5 is the backstop.

CC/OD eligibility and savings tags

Working-capital products assume current/CC/OD. If your extract says Savings, the RM may not even pitch CC. That is a lost file or a mis-sold PL. Flag Current. Let credit decide. Silence is the bug.

AML-adjacent patterns (not a SAR engine)

High-velocity commercial activity on SB, round-sum cash, and mule-like in-and-out can be AML-relevant. FinAnalyser is not your FIU filing system. It is the statement layer that should not hide the velocity behind a savings label. Escalate per your ML policy.

Constitutions: proprietor, partnership, company, LLP

Proprietors legally can hold savings; the issue is business velocity on that savings. Partnerships and companies should be on current. LLPs are commercial. HUFs used for business sit in a grey zone your policy must name. The parser’s job is to emit title tokens and explicit savings language. The credit policy’s job is to map constitution to product. When both are silent, you get LAP on SB with GST inflows and a surprise at sanction.

Foreign-owned India entities and project offices add more titles (Branch Office, Project Office). Treat as commercial. Payment-bank wallets used as “the business account” are still not a scheduled-bank current account for CC/OD. Say so in the note.

Evidence snippets to store

Store the PDF line that says Savings Account — or the absence. Store the title line with Enterprises/Pvt Ltd. Store the product code if printed (e.g. HDFC prefixes). That triad is the Law 5 audit trail. Without it, a later reviewer cannot see why you pitched BL.

When to keep Savings anyway

Explicit Savings Account on a commercial title: keep Savings, flag exception, ask bank letter. Salary account of a director who is also a shareholder: may be genuine SB; do not relabel Current just because the name includes Pvt Ltd if the title is the person’s name. Title parsing must distinguish “Ravi Kumar” employed at a Pvt Ltd from “Ravi Kumar Enterprises.”

Why underwriting follows substance, not the SB header

Indian savings accounts are a retail liability product. Current accounts are a commercial liability product. RBI’s product and KYC architecture assumes banks will onboard customer types onto suitable products. Practice on the street is messier: proprietors run GST sales through personal SB, partnership firms still hold old savings, and a Pvt Ltd title sometimes prints on a savings product code because onboarding never finished. Your job as a statement analyst is not to prosecute the bank. Your job is to stop applying personal-loan FOIR to a trading book, and to stop missing CC/OD eligibility because a header said SB. FinAnalyser Law 5 is that control: commercial names (Traders, Enterprises, Pvt Ltd, LLP and similar) classify Current unless the statement explicitly says Savings Account. If both a commercial title and explicit Savings Account language exist, keep Savings and raise an exception — do not silently relabel against the bank’s own print. Credit officers can override. Parsers that quietly flip types without a flag create un-auditable files.

This is not a substitute for a legal opinion on whether a particular entity may hold a savings account. It is an underwriting control aligned with commercial-entity practice. Product eligibility, GST-style turnover analysis, cheque-velocity interpretation, and 44AB bank-book scope all change when the account is commercial. A “clean” salaried FOIR on X Enterprises SB with daily inward cheques is a category error. A LAP pitched as retail housing on the same book is a category error. Flag the mismatch early so the RM can ask for a current-account letter, a product switch, or a different program.

Constitutions and the grey zones your policy must name

Proprietors legally can hold savings; the issue is business velocity on that savings. Partnerships and companies should be on current. LLPs are commercial. HUFs used for business sit in a grey zone your policy must name — silent HUF+GST+cheques is how scrutiny surprises you. Foreign-owned India entities, branch offices and project offices are commercial. Payment-bank wallets used as “the business account” are still not a scheduled-bank current account for CC/OD. Salary account of a director who is also a shareholder may be genuine SB when the title is the person’s name; do not relabel Current just because the employer is a Pvt Ltd. Title parsing must distinguish “Ravi Kumar” employed at a Pvt Ltd from “Ravi Kumar Enterprises.” Hospitals, clinics and pharmacies as going concerns are commercial even when the doctor also has a personal SB — parse both, do not mix FOIR.

How mis-tags warp every ratio downstream

If you tag a trading book as Savings, you will treat turnover like salary, apply ABB like surplus cash, treat cheques like retail, and skip GST-versus-bank recon that a CA would have caught. If you tag a genuine salary SB as Current because the employer name appeared in narration, you will pitch BL to a software employee and lose the file. The cost is not theoretical. Channel partners lose weeks when scrutiny returns a file for “account type mismatch” after the customer already signed. Store the PDF line that says Savings Account — or the absence. Store the title line with Enterprises/Pvt Ltd. Store the product code if printed (HDFC prefixes are a hint, not a waiver). That triad is the Law 5 audit trail. Without it, a later reviewer cannot see why you pitched BL.

Business on a genuine savings account — conduct, not a parser rewrite

Proprietors often run GST sales through personal SB. That is a conduct and product issue. BSA should still compute operational cashflow with Law 6 contra excluded, and should still split bounces. Do not call it a clean salaried PL. Recommend Current/CC product. Watch for structuring just below reporting thresholds. High cheque velocity on SB with GST-like receipts is a commercial book; inward returns on that book are trade payables failing — treat with SME seriousness, not with “customer bounced a personal cheque.” PMJDY and basic savings products used as a till are still not a working-capital account. Say so in the note.

OD against savings, overdraft sweep, and “flexi” products confuse juniors. An OD limit on an SB does not make the customer a current-account commercial borrower by itself. Combined with Enterprises title and GST inflows, it is a hint to stop the PL path. Combined with a personal name and CMS, it may be a salary account with an emergency limit — count utilisation per policy, do not relabel the constitution. HDFC and other prefixes historically map to savings products; a prefix is a hint. If the title is commercial and the statement does not say Savings Account, Current wins. If both exist, emit Savings plus exception. That file needs a human.

CA, 44AB and Tally named “Bank OD” against parsed Savings

Tax-audit bank recon must know which ledger is business. Mis-tagged savings hides turnover. Tally Prime ledgers named Bank OD against a parsed Savings account is a recon red flag. Pair this guide with the 44AB cornerstone. The article assistant should not “fix” the type in Excel to make Tally match. Fix the evidence trail, then the books.

1. Read account title before the product pitch.
2. Search the PDF for explicit Savings Account / SB A/C language.
3. If commercial + no explicit savings → Current path (BL/CC/OD).
4. If commercial + explicit savings → exception to credit, keep Savings on the extract.
5. Never force PL FOIR on a trading SB without disclosure.
6. Put title snippet + savings snippet + decided type on the Excel cover.

KYC onboarding leftovers and why BSA must not launder them

Banks onboard in a hurry. A partnership deed arrives after the savings kit was issued. A Pvt Ltd gets a director’s personal SB reused as “the company account” because the current-account file is stuck in operations. None of that makes the statement a retail PL book. If GSTIN, invoice-like UPI, and cheque velocity sit on that SB, your credit note must say commercial activity on a savings product — exception, not silence. If the bank later converts the product, re-parse; do not keep last month’s Savings tag because the Excel was already emailed. Account type is evidence-dated. The extract should show the snippet from this PDF, not from institutional memory.

CC/OD eligibility conversations fail when the analyst is still in FOIR-head. Working-capital desks want operating credits after Law 6, installment-date ABB, and inward payable defaults. They do not want a 42% FOIR computed on GST inflows labelled salary. Conversely, a software employee with a genuine SB and a maxed lifestyle OD is still a PL conversation with an obligation treatment — not an automatic current-account SME. The cost of mixing those two files is a week in scrutiny and a customer who already signed elsewhere. Law 5 exists so the parser refuses to participate in the mix. Your policy names the grey zones. The software emits the evidence.