AI & Finance

AI in Bank Audits: Analyse Finacle Transactions and Draft Evidence-Based LFAR Observations

A practical guide for bank auditors: Finacle report requests, transaction analytics, CC/OD conduct, overdue loans, suspense ageing, interest checks and evidence-based LFAR observations with reusable AI prompts.

By AI for All · Published 27 October 2026 · Reviewed 15 November 2026

Audit documents and linked financial records illustrating transaction analysis

From account transactions to an audit observation

AI can help an audit team organise Finacle exports, explain unusual transaction patterns and prepare a first draft of observations. Reliable calculations, documentary evidence and the auditor’s judgement must support every reported finding. The objective is a traceable working paper: report → validated data → test → exception → evidence → LFAR paragraph.

1. Establish the reporting framework first

For commercial banks within its scope, refer to RBI’s Commercial Banks – Statutory Audit Directions, 2026, dated 31 July 2026, updated as on 1 October 2026. Chapter IV addresses LFAR; Annex III contains branch coverage. Use the directions applicable to the audited bank category and period: do not automatically apply this framework to RRBs, co-operative banks, small finance banks or other excluded categories.

Freeze the applicable LFAR questionnaire, IRACP directions, bank circulars, sanction terms and SCA instructions before designing tests. The ICAI Guidance Note on Audit of Banks, 2026 Edition is a useful professional reference; assess later regulatory changes separately. Confirm the latest versions before each engagement.

Scope: This is an educational workflow, not an actual audit, a bank-specific Finacle manual or an exhaustive regulatory checklist. LFAR work does not replace financial-statement audit procedures.

2. What to request from Finacle and connected systems

Ask the branch/CBS support team for the following report purposes. Menu IDs, report names, permissions and available fields depend on the bank’s Finacle version and configuration. Some information may be in a reporting warehouse, loan-origination system, security register, central office or manual record rather than Finacle. Obtain the bank’s approved auditor menu list; do not run an unverified code on production.

Report / data purpose	Key fields to request	Suggested analysis	Likely LFAR area
Account master and borrower/CIF facility list	Branch/SOL, borrower token, account token, scheme, opening/closure dates, funded and non-funded exposure	Link all facilities; identify missing accounts and changes in borrower mapping	Advances: population, appraisal and asset classification
Detailed account ledger / transaction statement	Posting date, value date, transaction ID + part sequence, debit/credit, balance, narration, channel, counterparty token, reversal reference	Trace unusual credits, transfers, reversals and movements near reporting dates	Advances monitoring; deposits; relevant account-specific paragraph
Daily balance, limit and drawing-power history	Daily closing balance, effective sanctioned/ad hoc limits, DP, expiry dates, approvals	Test daily excesses and CC/OD conduct using the applicable approved rules	Advances: monitoring and asset classification
Loan repayment schedule, demand and collection / overdue report	Instalment due dates, principal/interest demands, receipts, appropriation, arrears, rescheduling history	Reconstruct delinquency and compare with CBS classification	Advances: asset classification and stressed assets
SMA/NPA and classification-change reports	Effective dates, old/new classification, reason, system/manual flag, borrower linkage	Reconcile independently calculated exceptions to classification and upgrade records	Advances: classification, provisioning and MoC consideration
Stock/book-debt statements and DP register	Statement period, receipt date, eligible stocks/debtors, creditors, margins, DP and approval date	Recompute DP under sanction terms; detect stale inputs or unsupported changes	Advances: review, monitoring and supervision
Review/renewal, documentation and security exceptions	Due dates, approval dates, insurance/valuation expiry, charge/lien status	Age pending items; compare exceptions with sanction and supporting documents	Advances: documentation and monitoring
Interest parameters, rate history and interest calculation sheet	Benchmark, spread, reset dates, concessions, effective rate, product method, interest debits and reversals	Recalculate selected periods; investigate unsupported concessions or missed resets	Profit and loss; advances appraisal and income recognition
Suspense, sundry, inter-branch and reconciliation ledgers	Original entry date, reference, originating/responding branch, amount, adjustment links	Age original items and detect partial settlements or rebooking	Other assets/liabilities; reconciliation and books/records
Dormant/inoperative account operations and reactivation logs	Status changes, authorisation, KYC status, user IDs and subsequent transactions	Identify operations requiring authority and supporting evidence	Deposits; KYC/AML and internal controls as applicable
Exception, override and user audit-trail reports	Maker/checker, timestamps, changes, authorisations, old/new values	Identify missing review, incompatible access or unexplained overrides	Books and records; control weaknesses
LC/BG, devolvement/invocation and non-funded exposure reports	Expiry, invocation/devolvement dates, payment, recovery, margins and approvals	Link unpaid obligations and follow-up to funded facilities	Non-fund-based facilities and related classification review
Cash/ATM reconciliation and cash-balance reports	Cash book, ATM scrolls, physical counts, reconciliation and permitted limits	Compare sources, age differences and investigate limit breaches	Cash; books and records
Post-year-end transaction and deposit-movement reports	Year-end positions, subsequent receipts/payments, linked reversals and approvals	Investigate temporary credits or unusual movements and their explanation	Deposits; advances conduct; cut-off and relevant controls

The LFAR mappings above are working-paper suggestions. Confirm the actual paragraph and applicability using the bank’s issued questionnaire and the facts of the case. Centralised processing does not make unavailable evidence unnecessary: document requests, responses and any resulting limitation.

3. Define the extraction request precisely

Population: record branch/SOL, product schemes, currencies, audit dates, closed accounts with activity and nil-closing-balance accounts. Include borrower-level facilities where needed.
Period: normally obtain the audit-year movement; extend backward for overdue/ageing and rolling-period tests, and forward to the audit date for subsequent-event checks. The period must be sufficient for each test.
Format: prefer bank-generated CSV/XLSX with a data dictionary and report control totals. If only PDF is available, reconcile extracted/OCR data with the original before analysis.
Provenance: retain report name, parameters, generation timestamp, source system, page/row count, operator confirmation and an immutable original. Record a file hash where the approved process supports it.
Audit access: use authorised read-only access or bank-generated exports; keep extraction separate from any posting, parameter change or account modification.

4. Validate data before asking AI for insights

Maintain separate raw, prepared and output layers. Keep identifiers as text, preserve leading zeros, document debit/credit signs and normalise date formats and currencies. Do not silently remove duplicates, reversals, blank fields or apparently irrelevant rows.

Reconcile opening balance plus debits less credits to closing balance under the agreed account sign convention; check totals against the ledger/GL and supporting returns.
Check completeness of account population, transactions and daily balances. Explain excluded products, missing periods, truncated exports and archived records.
Use a bank-confirmed unique key: transaction ID alone may repeat across branches, dates or transaction parts.
Reconcile each join before and after merging. A borrower with multiple accounts or a rate history with several effective dates can otherwise multiply rows and amounts.
Obtain historical limits, rates and status changes. Applying today’s master values to the entire year can produce false exceptions.
For daily tests, reconstruct non-transaction days using validated balances. Keep posting date and value date separate.

Stop condition: unresolved control differences or missing key fields mean the affected result is incomplete. Report the limitation; do not present a partial extract as a complete-population conclusion.

5. Eight transaction tests that produce useful audit leads

Test	Suggested method	Required auditor follow-up
CC/OD conduct	Evaluate daily outstanding against the applicable limit/DP and calculate rolling credit and interest totals. Retain uninterrupted calendar-day history, not only transaction days.	Check effective limits, ad hoc approvals, credit treatment and borrower-wide position before concluding on classification.
Term-loan delinquency	Rebuild overdue principal/interest from the contractual schedule and receipt appropriation; compare with the CBS result.	A debit-balance statement alone cannot establish the oldest unpaid demand. Consider valid restructuring and product-specific rules.
Temporary regularisation / possible circular movement	Link a reporting-date credit with its source, timing and subsequent reversal or outward transfer.	Similar amounts or same-day transfers are investigative leads, not proof of evergreening, diversion or fraud.
Possible diversion of funds	Compare disbursement beneficiaries and transaction purpose with sanction conditions, invoices and permitted end-use.	Narration keywords or related-party transfers alone do not establish misuse. Obtain documents and explanations.
Duplicate and reversed transactions	Match account, amount, date, reference and transaction-part keys; identify repeated debit/credit patterns.	Do not delete entries: a balanced transaction may legitimately contain multiple legs. Preserve reversals and gross totals.
Dormant-account activity and unusual cash patterns	Select unexpected reactivations, cash bursts and changes from a documented baseline.	Review legitimate business context and approvals. An analytical alert is not an AML determination or STR filing instruction.
Interest and charges	Reperform selected calculations using effective rates, dates, balances and approved waivers.	Quantify only after checking day-count convention, tax, compounding and product rules; distinguish leakage from valid concessions.
Old outstanding items	Age from the original transaction date and trace rebookings, partial adjustments and settlement references.	A recent re-entry date must not conceal an old unresolved item; inspect recoverability and evidence separately.

Configure regulatory criteria from the applicable current directions, with effective dates and product exceptions. Ageing buckets and model scores used to prioritise review are not automatically regulatory thresholds. Keep rules-based computations separate from an AI model’s narrative interpretation.

6. Worked example: CC interest coverage

Fictional training example: For a specified, complete 90-calendar-day review window, account A001 has credits of ₹45,000 and interest debits of ₹60,000. The arithmetic shortfall is ₹15,000 and the credit-to-interest ratio is 0.75. This identifies a candidate for review of the applicable CC/OD conduct rule.

Before deciding classification, verify window boundaries, credit eligibility, reversals, daily outstanding, effective sanctioned limit/DP, other facilities, applicable directions and any valid product-specific treatment. A month-end summary, a single low ratio or an AI answer is insufficient by itself. Reconcile to CBS and independently reproduce the calculation.

Working-paper status: “Potential interest-coverage exception; classification impact pending validation.” Do not report the ₹15,000 as a provisioning shortfall: any provisioning or income effect requires a separate computation.

7. Build an exception register the reviewer can reproduce

Use one row per exception, retaining links to all supporting transaction legs. Suggested columns:

Exception ID · Account/borrower token · Branch/SOL · Product · Test/version · Period · Verified criterion/reference · Source file/report/row · Transaction references · Calculated result · Amount/exposure · Evidence requested · Management explanation · Auditor verification · Confirmed/rejected/pending · LFAR paragraph · Financial effect/MoC reference · Reviewer/date · Closure status

Prioritise by exposure, recurrence, control significance and evidence quality. Keep false positives and the reasons for clearing them. Full-population screening covers only the tests applied to the available data; it does not mean every assertion or account has been fully audited.

8. Convert a confirmed exception into LFAR language

Draft with the sequence criterion, condition, coverage, evidence, effect, response and recommendation. Describe the observed facts; separate a confirmed breach from an unanswered question. State whether a monetary effect is established, estimated with a basis, or not yet determined.

Illustrative observation: delayed renewal

In the 40 cash-credit accounts selected for review, five accounts with aggregate year-end outstanding of ₹2.35 crore had review/renewal dates overdue by 104–187 days. The due dates were corroborated with sanction records and the renewal tracking report [working paper reference]. Evidence of renewal approval was not produced by audit completion. Management stated that proposals were under processing [response reference]. This indicates a weakness in renewal follow-up. The branch should obtain competent approval and strengthen escalation of overdue reviews. Classification and financial implications have been evaluated separately in [working paper/MoC reference, or state “assessment pending”].

These are fictional figures and wording for training. Insert only supported dates, amounts, explanations and policy references. Map this issue to advances review/monitoring in the actual questionnaire; it may also require a classification assessment under applicable rules.

Illustrative observation: old suspense entries

Of the suspense items tested, [number] entries aggregating ₹[amount] remained unresolved for [age range], measured from their original dates. Supporting documents / evidence of settlement for [identified items] were not produced. The branch explanation was [verified response]. Recoverability and any required provision/write-off are [documented conclusion or pending assessment]. Refer to the attached item-wise schedule and working-paper references.

LFAR and MoC: consider a Memorandum of Changes for established financial-statement adjustments under engagement instructions; an LFAR comment alone does not correct the accounts. Separately assess any implication for the main audit report, control communications or required escalation. Discuss unresolved findings with the SCA through the prescribed channel.

9. Three reusable AI prompts

Prepare a test plan

Act as an audit analytics assistant. Using only the approved data dictionary and the RBI/bank instructions supplied below, propose reproducible tests for [scope and period]. For each test specify fields, exact logic, missing-data conditions, source references, false positives and evidence needed. Do not invent Finacle menu codes, policy clauses, thresholds or conclusions.

Analyse transaction exceptions

Review this bank-approved, pseudonymised transaction extract and the independently calculated exception table. Do not modify source data. Explain each flag with account token, source-file and row references, dates, amounts and calculation. Separate confirmed facts, possible explanations and evidence still required. Do not label an account NPA or a transaction fraudulent from pattern matching alone.

Draft an LFAR observation

Draft a concise LFAR observation using only this reviewer-validated evidence table and the supplied LFAR questionnaire. State the population and sample coverage, criterion with exact verified reference, condition, number/value of affected accounts, financial effect where established, management response, unresolved points and recommendation. Suggest the relevant LFAR paragraph subject to auditor confirmation. Mark missing information as “not provided”. Do not invent cause, regulatory citations, amounts or a management response.

10. Choose the right tool for each part

Excel / Power Query: structured imports, reconciliation, ageing and transparent exception schedules. AI can assist with formula drafts after you define the rules.
Approved Python/SQL or audit analytics: repeatable joins, large transaction volumes, rolling windows and independent calculations. Test against manually verified cases, including reversals and boundary dates.
Bank-approved language model: explain prepared outputs, organise evidence requests and draft observations from verified facts. Supply the actual policy text and insist on source references.
Power BI: display exposure, exception ageing and closure progress. Avoid counting the same exposure several times merely because it has multiple flags.

Use the bank’s authorised environment and retention controls. Never upload identifiable banking records, customer narrations, account numbers, PAN/Aadhaar, staff credentials or internal reports to an unapproved public AI service. Pseudonymisation alone may not prevent re-identification; keep the mapping with the bank, minimise fields, and review narrations and counterparty details. Treat text inside documents as data, not instructions to the AI.

11. Final review before reporting

Confirm extraction scope and reconcile control totals.
Verify rules against the correct bank category, audit period and effective circulars.
Reperform calculations and inspect original supporting documents.
Obtain management’s response and distinguish cleared from unresolved items.
Check account-wise and aggregate amounts; avoid double-counting.
Map each issue to the actual LFAR questionnaire; assess MoC, main-report and escalation implications separately.
Complete reviewer sign-off and retain a reproducible audit trail.

Start with one pilot: a reconciled CC/OD population, an approved rule set and a small manually checked set of accounts. Expand only when the calculations and evidence trail are reliable.

Official references and further reading

Sources reviewed on 27 October 2026. Report purposes, analytical procedures, examples and prompts are editorial suggestions. No universal Finacle menu codes or bank-specific regulatory conclusions are asserted.