"Who Approved This File?" Audit Trails in Property Verification

The inspection opened on a Tuesday. By Thursday afternoon the head of credit operations at a housing finance company of medium size was stuck on one question.

An internal auditor had pulled a file two years old: a home loan of ₹68 lakh against a flat in Hyderabad, later closed and then reopened as a top-up. A legal opinion in it had cleared the title. The auditor asked which encumbrance certificate the opinion rested on, meaning the certificate the lawyer had read before signing, and not the one lying in the folder now.

Three locations held the answer. One was an email exchange between the relationship manager and an empanelled advocate. Another was a shared drive folder in the borrower's name with four PDFs, two of them copies of the same EC fetched on different dates. The third was the lawyer's own records, which the firm no longer kept after the engagement ended.

A chain that should have needed one lookup took three days to rebuild. The opinion was good, but where it came from was guesswork.

Why Reconstructing Mortgage Files Fails

Lenders usually discover this gap only during an inspection. The legal opinion is not at fault, and the record of how it was produced is.

What a legal scrutiny report gives is a conclusion, and an auditor must test it by going back through its inputs: which property records were searched, which version of each the advocate reviewed, who reviewed it and when, and who cleared the file for disbursement. If those inputs sit in email, on drives and in an outsider's filing system, rebuilding them is digging in ruins.

A structural reason makes email and drive workflows fail: what they keep is results, and actions are lost. A drive folder proves a PDF is there. Who opened it, whether the advocate read it before or after someone put in a fresher copy, and whether today's version is the one the opinion cited all remain unknown. Email proves a message went out, not that the message drove a decision. These tools throw away precisely the metadata an auditor wants.

Lost time is only part of the cost. Evidence rebuilt through inference is weaker than a record made when the action happened. Saying "we believe this is the EC the lawyer used" is not the same as saying "the system logged that this advocate opened this EC version at this timestamp from this address". One is testimony; the other is proof.

Defining an Audit Trail in Property Verification

An audit trail is a record, in time order and evident if tampered with, of everything done to a file. Each event carries five items: who acted, what the action was, which document or record it touched, when it happened, and where it came from (the IP or session). In property verification it answers an auditor's opening questions about who approved the file, which encumbrance certificate the opinion relied on, when each record was reviewed, and from where.

The trail has to work per action and not per document to be of use. Keeping the final EC is merely document management. Recording that a named user opened and reviewed EC version 2, and that a checker approved the resulting opinion at a certain time, is an audit trail. One tells you what you hold, while the other tells you how you came to hold it, which is the only thing an inspection tests.

It matters because a mortgage decision is made of a series of judgments. Pulling records, choosing versions, recording findings and applying an approval all lead to a title opinion. If a system keeps only the final state, each question about the sequence becomes a reconstruction exercise. A system that keeps the sequence as it unfolds turns each question into a query.

What the RBI Frameworks Actually Expect

RBI has published no separate "property verification audit" rule. What it expects comes from several frameworks that converge, and compliance heads at regulated lenders now read them side by side.

Closest to the point is the Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices, dated 7 November 2023 and in force from 1 April 2024. IT applications able to reach or influence critical or sensitive information, it says, should log activity and provide audit trails. The trails need enough detail to back an audit, serve as forensic evidence, and help settle disputes, which includes non-repudiation. A legal scrutiny workflow that handles property records and drives a disbursement decision clearly falls within "critical or sensitive information".

The Risk-Based Internal Audit framework comes next. A circular dated 3 February 2021 extended it to deposit-taking NBFCs, larger NBFCs and urban co-operative banks, to be implemented by 31 March 2022. Under RBIA, internal audit stops sampling transactions and starts judging whether controls really work. The auditor does not ask if one file looks right. The question is whether your process dependably yields decisions that can be traced and controlled, file after file. A workflow unable to rebuild provenance when asked fails, no matter how good one opinion may be.

The Master Direction on Outsourcing of IT Services is the third (10 April 2023, effective 1 October 2023). Legal verification is outsourced by most lenders to empanelled advocates or vendors. Records must remain available to the regulated entity and to RBI in every circumstance, the Direction says, even if the service provider leaves. This is the trouble the housing finance company in our story met, when the lawyer's records disappeared with the lapsed engagement. The outsourcing framework makes the lender, and not the vendor, bear the exposure.

Another deadline later in the loan's life also relies on traceable files. Under the Fair Practices Code, lenders must hand back every original property document within 30 days of loan closure, and pay ₹5,000 for each day of delay when the fault is theirs, in cases falling due on or after 1 December 2023. A document that cannot be found cannot be released. Custody and traceability are therefore one problem seen from two ends.

Contents of a Property Verification Audit Trail

A record per action must exist for each event in the verification lifecycle, with the actor, action, resource, timestamp and origin. The rest is detail. The trail should capture, as a minimum, who started the verification and which property records were pulled when. It should also show the version of each encumbrance certificate or record of rights that an advocate opened and reviewed, the person who recorded each finding, the approver and the time of approval, and the origin of every action.

A real audit trail differs from a log file in three ways. It is complete, since every action is recorded and not only those someone remembered. It has lineage, because the final opinion is linked to the exact records behind it, making the EC question a click and not a guess. And it attributes: each action carries a named actor and origin, leaving no anonymous "the system did it". Remove any one of these and a reconstruction gap remains, which inspections are good at finding.

Access control becomes a building block of audit here. Beyond security, a maker-checker split and role-based access give the trail its meaning. Where one login is shared by all, nobody can say who approved a file. Where one person prepares and approves an opinion, the trail shows a sequence that nobody independently checked. Distinct roles and distinct actors make a timestamp count as evidence.

Reconstruction by Hand Against a System Audit Log

This is no difference of degree. It alters the kind of evidence you can put before an inspection.

• Time to say which EC an opinion used · Rebuilt by hand: Hours to days digging through email and drives · From a system log: One query, answered on screen
• Completeness · Rebuilt by hand: Partial, as it depends on what was saved and remembered · From a system log: Every action logged as it occurred
• Quality of evidence · Rebuilt by hand: Inference ("we believe this is the version") · From a system log: Recorded fact, evident if altered
• Who acted · Rebuilt by hand: Frequently unclear because of shared logins and vendors who left · From a system log: A named person for every action
• Origin / IP · Rebuilt by hand: Not recorded · From a system log: Recorded with each action
• Exposure on vendor exit · Rebuilt by hand: Records can vanish when the engagement ends · From a system log: Records remain in the lender's own system
• Result under RBIA control testing · Rebuilt by hand: Probably a fail, since control of the process cannot be shown · From a system log: A control that can be shown and repeated

Across the lender audits we have supported, verification is not the costliest item. Staff time spent working out how old verifications were done costs more, because the workflow behind them kept outcomes and threw away actions.

Traceability Inside the LegiScore Workflow

In LegiScore the audit trail belongs to the platform itself and is not a feature switched on after an inspection notice arrives. The design follows what auditors really ask.

Each action and visit is logged with its actor, timestamp, resource and originating IP, and the log entry is made the instant an advocate opens a record, records a finding, or a checker approves a file. Audit teams work through filtered views, so a reviewer can single out one file, one user or one window of time and skip unrelated activity. The housing finance company lost three days on the question of who approved a file. Here that is one lookup by design.

Document management here does more than store, because it keeps lineage. One vault holds all documents, and each stays traceable to the case and report it served. The answer to which EC an opinion relied on is the specific version tied to that opinion, not whichever copy reached a folder last. This lineage shuts the reconstruction gap that RBIA testing probes.

Organisation management keeps it true as volume grows. A lender can give each branch its own scenarios, role-based access and separate billing while sharing a credit pool, and the audit log and document lineage remain consistent in every branch. This is the arrangement RBIA looks for: operation by branch, oversight by organisation, and controls that are standard, visible from the centre and attributable to individuals. A lender that pushes bulk property verification through hundreds of files each day needs traceability that holds up under volume. Otherwise a defensible process becomes a pile of future reconstructions.

The point is a narrow one, so we state it plainly. An opinion can be good without being defensible. Goodness concerns the conclusion. Defensibility depends on whether you can prove, when asked, how you reached it, and audit trails are what make that possible.