For most founders, "compliance" means sanctions screening, know-your-customer checks, transaction monitoring, and perhaps a capital adequacy ratio if you have recently been through a licence application.
But when a regulator asks you to trace a specific unit of money, screening logs and policy documents will not answer the question. Your ledger has to show the balance before the movement, the posting that changed it, the balance after it, and the evidence that the funds matched the outside world.
We’ve written before about the questions your ledger needs to answer: what was the balance before, what changed it, and what was the balance after? Those questions vary in legal wording, but the system underneath them is remarkably consistent. Regulators expect four things from a ledger: a current register, an immutable journal, documented reconciliation, and retrievable records.
Keep a current account register
If you strip the legal language, the first thing every regulatory environment wants is a register that stays current after every movement and identifies who holds what.
Mexico's Ley Fintech comes close to defining a licensed electronic payment funds institution (IFPE) by this alone: Articles 22–23 require an electronic account register updated for every issuance, transfer, and withdrawal rather than reconciled after the fact.
India's prepaid payment instrument (PPI) escrow rules also rely on the same capability. The "outstanding balance in the books" that the Reserve Bank of India (RBI) checks against escrow is only meaningful if the books can produce that number for the day being examined.
Your ledger needs to support point-in-time account history: given an account and a timestamp, it should return the opening balance, every posting in the interval, and the closing balance, without reconstructing the result from backups or institutional memory.
Preserve an append-only journal
The second requirement is a journal that remains trustworthy when it is questioned.
The U.S. Office of the Comptroller of the Currency's (OCC) guidance on electronic records is specific about this: integrity means no unauthorized modification, and one control it lists is removing write access from a record the moment it is captured.
Across the border, Mexico does not treat this as a guideline. Article 128 of Mexico’s Fintech Law (Ley Fintech) criminalizes tampering with accounting records before retention ends, with prison and a fine attached.
To make this happen, your ledger has to have an append-only or immutable history. Regulators expect mistakes to remain visible through the original posting, the correcting entry, when each was created, and who or what created it. This means you correct errors in your ledger by adding a new entry, instead of changing the old one.
Reconcile the ledger to safeguarded funds
The third requirement is evidence that the number in your ledger agrees with the money held outside it.
India’s RBI requires PPI issuers to keep escrow funds at least equal to outstanding customer balances each day, and to report any shortfall to its Department of Payment and Settlement Systems (DPSS) immediately, not at the next audit.
Meanwhile, Article 10 of the EU’s revised Payment Services Directive (PSD2) sets a different deadline. Customer funds must not be commingled, and anything not already safeguarded must be settled by the end of the following business day. The Dubai Financial Services Authority (DFSA) asks the same question at a different cadence, monthly for most companies holding client money and daily for money-services companies.
A reconciliation control only counts if it leaves a trail. Each run should record your ledger balance, the external balance you checked it against, when you ran the check, any variance, and how you cleared it.
Produce records on demand
The fourth requirement is the ability to retain records and hand them over on someone else's timeline.
In the US, regulators can require prompt access to records on request (12 U.S.C. § 481), and OCC guidance expects record systems to keep data accessible, with no auto-deletion or encryption that makes records unretrievable.
In Dubai, if the DFSA asks for records, you may have as little as three business days to produce them. The exact retention period depends on where you’re licensed in the UAE, but the practical rule is constant: don’t let records become inaccessible before you’re allowed to delete them.
You can’t let retrieval depend on someone’s memory. Your system should be able to export the account history, journal entries (including corrections), and reconciliation evidence for the requested period within the regulator’s deadline, without a manual scramble. If it takes two weeks to assemble, it’s still, functionally, a finding.
How ledger gaps become regulatory findings
A ledger gap becomes material when your team cannot show when a discrepancy started, which accounts it affected, whether customer funds remained protected, and what corrected it.
Say a daily reconciliation identifies a shortfall. If the system retains the run, its inputs, the variance, and the correcting entries, your team can show that the control detected the problem, when the detection happened, and how it was resolved. If only the current balances remain, the team has to reconstruct the event from database exports, processor reports, and spreadsheets.
That reconstruction is where an operational gap becomes a control finding. Different snapshots can disagree, manual corrections can obscure the original state, and the answer can change between the regulator's first request and the next one. The issue is no longer only the shortfall. The regulator also has to decide whether the records themselves can be trusted. Depending on the jurisdiction and relationship, that can lead to a remediation plan, additional licence scrutiny, or a bank partner pausing activity while the discrepancy is investigated.
Make the regulator's request a normal query
A ledger that meets the pattern lets you sleep. If it doesn’t, the risk is operational, but it shows up as a compliance finding, because you can’t produce trustworthy records on demand.
So make the pattern non negotiable. Use these as go-no-go checks:
- Given an account and timestamp, can it return the balance and every posting that produced it?
- Given a posting, can it return the immutable original, every correction, and who or what created each entry?
- Given a date, can it return the reconciliation inputs, result, variance, and resolution?
- Given a regulatory period, can it export that evidence without rebuilding it from backups or spreadsheets?
If any answer depends on a production snapshot, an analyst's spreadsheet, or the memory of the person who built the system, the property is not part of the ledger yet.
When these tests pass, a regulator's request becomes a normal query rather than an emergency reconstruction project.
Blnk is designed around this pattern, with an immutable ledger, current, running balances, historical balances, balance snapshots, audit logging, scoped access and reconciliation runs recorded with their results, so you can pull evidence from the same system that produced the numbers.