Banking audit trails without the fiction

Rs 14,356 crore, and a missing entry

In January 2018, Punjab National Bank disclosed that Rs 14,356 crore had been siphoned out of one of its Mumbai branches over seven years. The mechanism, as the CBI later established, was not exotic. PNB employees issued fraudulent Letters of Undertaking through the SWIFT messaging network on behalf of companies owned by Nirav Modi and Mehul Choksi. Those SWIFT messages were never recorded in PNB’s Core Banking System. For seven audit cycles, the two ledgers disagreed and no one noticed.

PNB is the most expensive Indian example, but the failure mode is universal. Yes Bank’s 2020 collapse began when an RBI Asset Quality Review found NPAs under-reported by roughly seven times against internal audit books; a follow-up identified an additional Rs 3,277 crore in unreported bad loans. Wells Fargo paid $3 billion to the DOJ, SEC and OCC over fabricated customer accounts — with the OCC still issuing personal fines to former executives as recently as January 2025. The common thread is not weak controls. It is the assumption that the bank’s own database is the source of truth about what the bank itself did.

A regular relational database is a perfectly good record of state. It is a terrible record of what was true at a particular moment. Any DBA with write access can amend history. Any privileged service account can drop a row. Most enterprise audit-log tables are themselves writable. This is not a hypothetical problem — in 2023, a JPMorgan unit paid $4 million after admitting it had deleted approximately 47 million electronic communications that should have been retained. The records were there, until they weren’t.

What regulators actually require in 2026

The regulatory framework around banking audit trails has hardened sharply in the last 24 months. Four documents matter for any Indian or globally-operating bank or NBFC:

RBI Master Direction on IT Governance (November 2023, effective April 1, 2024)

The RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices requires regulated entities to maintain audit trails of IT assets “to serve as forensic evidence and assist in dispute resolution.” The framing matters — the regulator no longer treats audit logs as an operational nicety. They are forensic artefacts, with the evidentiary burden that implies. For NBFCs, the direction is specific that audit trails must cover any outsourced administrative activity and must be preserved long enough to be useful to an investigator.

DPDP Act 2023 (operational since November 2025)

The Digital Personal Data Protection Act, 2023 carries penalties of up to Rs 250 crore per violation for failure to implement reasonable security safeguards, and up to Rs 200 crore for failure to notify breaches — even when no actual harm occurred. The Data Protection Board of India became operational on November 13, 2025; substantive compliance obligations come into force on May 13, 2027. For banks, “reasonable security safeguards” will be interpreted in the context of what is technically achievable. By 2027, “our database has audit logging enabled” will not survive a serious enforcement inquiry.

BCBS 239 (twelve years in, mostly unfulfilled)

The Basel Committee’s Principles for effective risk data aggregation and reporting — BCBS 239 — have been in force since 2013. The Bank for International Settlements’ most recent progress report found that of 31 globally systemically important banks (G-SIBs), only 2 are fully compliant with all 14 principles. The average compliance score barely moved between 2019 and 2022. The European Central Bank has elevated this to a top supervisory priority for 2025-2027. The implication: the audit trail problem at the world’s most resourced banks is unsolved, and supervisors know it.

SOX Section 404 (still the global yardstick)

Sarbanes-Oxley Section 404 requires retention of audit-trail records for seven years with tamper-proof storage and criminal penalties for destruction. The current standard guidance for ensuring log immutability under SOX is cryptographic hashing (SHA-256) plus Write-Once-Read-Many storage. Anything weaker is a finding waiting to happen. The cost of meeting SOX is not small: Protiviti’s SOX compliance survey puts annual SOX spend at around $1.4 million for $10-20B-revenue enterprises and $2.1 million for those above $20B.

The audit-trail layer your database can’t honestly provide

Reduced to its essence, every one of those frameworks is asking the same question: Can you prove that the record you are showing the auditor today is the same record you held on the date you say you held it? Databases are bad at this for a structural reason. A database is a mutable state machine, and the people who maintain it have write access by definition. The audit log is itself a table in that database. The backups are in the same custody chain. There is no point in the stack at which the bank can credibly say “not even we could have changed this.”

The regulator’s natural response is to require external attestation: external auditors, log custodians, WORM appliances, third-party archives. That works, expensively, and adds another custody chain to trust. The SEC’s off-channel-communications enforcement sweep has produced over $2 billion in fines since 2021 — $1.1 billion across 16 firms in September 2022, $549 million across 11 firms in August 2023, $393 million across 26 firms in August 2024. JPMorgan alone paid $200 million in 2021 for recordkeeping failures. In every one of these matters the substantive misconduct was secondary; the firm could not credibly produce the records it was required to retain.

Cryptographic anchoring is the structurally different answer to the regulator’s question. The bank still holds the record. But the bank also publishes a one-way fingerprint of that record to a venue it does not control — a public blockchain — at the moment the record is created. Years later, the bank produces the record and the fingerprint. The fingerprint is verifiable by anyone, against the immutable history of the public chain. If the record has been edited, even by one byte, the fingerprint will not match. The bank does not have to be trusted; the math does the work.

The Anchora pattern

Anchora is a multi-chain anchoring service that exposes this pattern as three REST endpoints. The bank’s application hashes a record (locally, in hash-only mode — the PII never leaves the bank’s network), sends the hash to Anchora, and receives back a transaction reference, a Merkle proof, and an on-chain anchor. To verify, the bank rebuilds the hash from whatever it has now and asks Anchora (or any Polygon node) to confirm the proof. Three calls, no wallet management, no gas accounting, no Solidity.

Step 1 — Anchor a loan-decision package at issuance

Take an NBFC issuing a personal loan. At the moment the credit decision is made, the application hashes the decision package — applicant identity hash, bureau score, decision rule version, approving officer, timestamp, sanctioned amount — and sends only the hash to Anchora:

// Hash the loan decision package locally — PII never leaves the bank
import { createHash } from 'crypto';

const decision = {
  applicantIdHash: 'b3a1...c92f',   // SHA-256 of PAN
  bureauScore: 742,
  ruleEngineVersion: 'v4.11.2',
  approvingOfficer: 'EMP-208731',
  decision: 'APPROVED',
  sanctionedAmount: 450000,
  decidedAt: '2026-05-29T11:08:22Z'
};

const hash = createHash('sha256')
  .update(JSON.stringify(decision))
  .digest('hex');

// Send only the hash to Anchora — hash-only mode, GDPR/DPDP-friendly
const response = await fetch(
  'https://api.anchora.co.in/v1/anchor/hash',
  {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.ANCHORA_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      hash: hash,
      collection: 'loan-decisions',
      metadata: { loanId: 'LN-2026-05-441208' }
    })
  }
).then(r => r.json());

// response.recordId, response.status === 'QUEUED'

The hash is queued. Within roughly 30 seconds an Anchora worker batches up to 256 hashes into a Merkle tree and writes the root to Polygon. Each record gets its own Merkle proof allowing it to be verified independently, without revealing the other 255.

Step 2 — Batch-anchor high-volume events

For high-frequency flows — transaction logs, KYC updates, IoT-style fraud-detection events — the batch endpoint accepts up to 100 records per call:

curl -X POST https://api.anchora.co.in/v1/anchor/batch \
  -H "Authorization: Bearer dcp_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "records": [
      { "hash": "a1b2...e7f8", "collection": "swift-out", "metadata": { "msgRef": "FT26052901" } },
      { "hash": "9c4d...2b3a", "collection": "swift-out", "metadata": { "msgRef": "FT26052902" } },
      { "hash": "7e1f...8d09", "collection": "swift-out", "metadata": { "msgRef": "FT26052903" } }
    ]
  }'

On Polygon, batching 256 records into one transaction takes the per-record cost to ~$0.000007 — roughly 99.9% lower than writing each record on-chain individually. A million anchored records cost about $7 a year, before any volume discount.

Step 3 — Verify, two years later

Two years after origination, an internal audit or a regulator asks the NBFC to prove what the credit decision was on the day the loan was sanctioned. The application reads the loan decision out of the operational store, recomputes the hash, and calls verify:

const verification = await fetch(
  'https://api.anchora.co.in/v1/verify',
  {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.ANCHORA_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      data: currentDecisionFromDb,
      hash: anchoredHashFromAudit
    })
  }
).then(r => r.json());

// verification.verified === true means the record is byte-identical
// to what was anchored on 2026-05-29. If it's false, something
// changed in your operational store between then and now.

If the bank needs to hand the regulator a portable proof — one the regulator can verify against Polygon directly, without contacting Anchora — the proof endpoint returns the Merkle proof and the block reference:

curl -H "Authorization: Bearer dcp_live_..." \
  https://api.anchora.co.in/v1/proof/b3a1c92f...e7f8

# Returns blockNumber, transactionHash, merkleRoot,
# and the proof path. Anyone with this payload can
# verify against a Polygon node — Anchora not required.

Hybrid mode: the regulator-friendly pattern

For most bank workloads, anchoring purely to a public chain is the wrong default. There are records you want kept entirely inside your jurisdictional perimeter — in a permissioned Hyperledger Fabric channel you operate — and there are records where external verifiability is the whole point. The decision is rarely all-or-nothing. Anchora’s hybrid mode anchors the same Merkle root to both a private Fabric ledger and a public chain in a single batch. The internal compliance team sees the Fabric anchor; the external auditor sees the Polygon anchor; both can confirm the same Merkle root for the same record. No reconciliation step. No two-systems-of-truth problem.

This is also the pattern Indian banks have already validated at the consortium level. IBBIC (Indian Banks’ Blockchain Infrastructure Co) — a 15-bank consortium including SBI, ICICI, HDFC, Axis, Kotak and Bank of Baroda — anchors Letters of Credit, GST invoices and e-way bills, with each member investing Rs 5 crore for a 6.66% stake. Globally, JPMorgan’s Kinexys platform (rebranded from Onyx in November 2024) has executed over $1.5 trillion in transactions since 2020 and now processes more than $2 billion per day. DBS Token Services, Citi Token Services and HSBC’s Contour-based trade-finance flow are all live. The serious question for an Indian banking CTO in 2026 is no longer “should we use blockchain rails for audit-grade records,” but “at what point does the regulator start asking why we don’t.”

What this is worth in actual money

• RBI Annual Report FY2024-25: total bank fraud value surged 194% year-on-year to Rs 36,014 crore, with loan-related (advances) frauds alone at Rs 33,148 crore — more than triple the prior year.
• UPI fraud: Rs 981 crore across 12.64 lakh cases in FY2024-25, per data tabled in the Lok Sabha. Digital payment frauds account for 56.5% of all reported banking frauds.
• SEC recordkeeping enforcement: in FY2024 alone the SEC brought recordkeeping cases producing more than $600 million in civil penalties against 70+ firms.
• Cost of one breach (banking sector): IBM’s 2024 Cost of a Data Breach Report puts the financial-services average at $6.08 million, second only to healthcare.
• e-Discovery economics: RAND’s landmark e-discovery study found roughly $18,000 per gigabyte of electronically stored information, with 68% of that consumed by manual document review. Anchored records collapse this: integrity is mathematically provable, so vastly fewer documents need eyes-on review to establish authenticity.
• Per-anchor cost of avoiding all of the above: $0.000007 per record. A million records anchored, with the integrity provable to a regulator or court, costs less than a coffee.

The audit trail is the cheapest piece of a bank’s tech stack to build correctly, and the most expensive to have built wrong. PNB, Wells Fargo and the 26 firms named in the SEC’s August 2024 sweep are not edge cases. They are what happens when the integrity layer is left to a mutable database.

What anchoring does not solve

A short, honest list:

• It does not prevent fraud at origination. If a bank officer enters a fraudulent loan decision into the system and anchors it, anchoring proves that that exact fraudulent decision was the one made on that date. It does not prevent the decision itself. Anchoring closes the “was history rewritten” gap; it does not close the “was the history valid in the first place” gap.
• It is not a substitute for confidentiality controls. If you want the data itself protected, use encryption in addition to anchoring. Anchora’s /v1/anchor/secure and /v1/anchor/encrypted endpoints handle the AES-256-GCM-PBKDF2 flow with client-supplied keys.
• It does not produce business-process correctness. Anchoring proves that a record is what it was. It does not prove that the underlying business rule was applied correctly. That is the auditor’s job, not the chain’s.
• It does not change the auditor’s scope. A SOX or RBI audit still has to examine controls, sampling, and segregation of duties. What it does change is the cost of proving what your systems recorded. That is normally the most expensive part of the audit. Anchored records make it minutes of work.

Getting started, concretely

1. Pick one workflow where the cost of disputed records is highest. Loan-decision packages, KYC updates, SWIFT messages and transaction logs are all good candidates.
2. Hash the record at the moment it’s created. Use /v1/anchor/hash for the strongest privacy posture — the record stays on your servers, only the SHA-256 fingerprint reaches Anchora.
3. Store the returned recordId and transactionHash next to the record in your operational store. Treat them as part of the record’s metadata.
4. For audit production, recompute the hash on the live record and call /v1/verify. For external regulator proofs, fetch /v1/proof/:hash and hand over the payload.
5. For records that should also live on a permissioned chain you control, configure the project for hybrid mode. Same hash, anchored to both Fabric and Polygon in a single batch.

The free tier is 1,000 anchors per month with no credit card required, intended for spike testing and proof-of-concept builds. For high-volume retail-banking workloads (UPI logs, transaction journals), the per-record cost remains well under $0.0001 all the way through the Scale tier. Pricing scales linearly with what you anchor; there is no idle cost.

The honest summary

The audit-trail problem is not a database problem. It is a custody problem. A bank cannot — and should not have to — convince a regulator that records inside the bank’s own custody are unaltered. Cryptographic anchoring moves the integrity check out of the bank’s custody and onto a public ledger, where it costs a fraction of a paisa per record and removes the dispute entirely. The pattern is proven at JPMorgan, DBS, Citi, HSBC, and at the IBBIC consortium of fifteen Indian banks. The window in which Indian banks can adopt it on their own timeline, before the regulator starts asking why they haven’t, is narrowing.

Anchora exists to make that adoption a three-call exercise. Three endpoints, sixty seconds to the first anchored record. If you run engineering or compliance at a bank or NBFC and the audit trail layer keeps you awake at night, please reach out.

Sources

1. Reserve Bank of India — Master Direction on IT Governance, Risk, Controls and Assurance Practices, November 2023.
2. Reserve Bank of India — Annual Report FY2024-25 (bank fraud aggregate of Rs 36,014 crore).
3. Ministry of Electronics and Information Technology — Digital Personal Data Protection Act, 2023 and Draft DPDP Rules 2025.
4. Bank for International Settlements — Progress in adopting the Principles for effective risk data aggregation and risk reporting (BCBS 239).
5. European Central Bank — Guide on effective risk data aggregation and risk reporting, May 2024.
6. U.S. Securities and Exchange Commission — Press release on August 2024 off-channel communications sweep; December 2021 JPMorgan recordkeeping action; FY2024 enforcement results.
7. Protiviti — SOX Compliance Survey 2022 (referenced for current cost ranges).
8. IBM — Cost of a Data Breach Report 2024, financial industry segment.
9. RAND Corporation — Where the Money Goes: Understanding Litigant Expenditures for Producing Electronic Discovery.
10. CoinDesk — JPMorgan Kinexys rebrand, November 2024.
11. Grant Thornton India — IBBIC analysis.
12. DBS Bank — DBS Token Services launch, October 2024.
13. Citigroup — Citi Token Services milestone, 2024.