Pakistan’s New Bank Data System Is Really About Algorithmic Tax Surveillance

 

Pakistan’s Section 165AB introduces algorithmic cross-matching of high-value banking data with tax records, shifting tax enforcement toward automated financial scrutiny.

A businessman in Karachi can move Rs150 million through his bank account without being Rs150 million richer.

I see this distinction clearly because I work around banking transactions. Money moves for reasons that have little to do with personal wealth. A distributor may collect large sales proceeds and then send most of that money back to manufacturers. An importer may move even larger sums simply because the goods he buys are expensive.

Pakistan's tax system is now preparing to look at such flows differently.

Under Section 165AB of the Income Tax Ordinance, banks and Electronic Money Institutions must electronically report prescribed information when deposits or withdrawals exceed Rs100 million during a six-month reporting period. The Rs100 million figure is not a minimum account balance. It concerns transaction flows across any or all accounts maintained by the account holder during the reporting period.

The information will not necessarily land on a tax officer's desk first.

A computer system can examine it before a human officer does.

The shift from human review to machine screening may prove more important than the threshold itself.

Pakistan Is Moving Beyond the Tax Notice

Pakistan's tax administration has traditionally relied on taxpayer declarations and withholding records. Officials also obtain information from other institutions when they investigate discrepancies.

Section 165AB points toward a different model.

The Finance Act 2026 inserted the provision into the Income Tax Ordinance. It requires banking companies and Electronic Money Institutions to electronically upload specified information for what the law describes as algorithmic cross-matching of tax and banking information.

The reporting periods run from July 1 to December 31 and from January 1 to June 30. Banks report after each six-month period.

The information includes opening and closing balances, as well as total credits. Peak credits and relevant transaction details also form part of the reporting framework.

The important change is not simply that banks are supplying another dataset.

The government is building a mechanism that allows financial behaviour to be compared automatically with information already held by the tax system.

What Section 165AB Actually Does

Some social-media posts have described the development as a new digital banking system launched by the State Bank of Pakistan.

That description is misleading.

The Central Data Hub used for tax cross-matching sits within FBR's tax architecture and is maintained through Pakistan Revenue Automation Limited, or PRAL. Banks and Electronic Money Institutions provide the required information.

SBP has a separate role within Pakistan's broader financial-data infrastructure. It already operates regulatory reporting systems such as the Data Acquisition Portal, and banks have been moving steadily toward more direct digital submission of regulatory information.

So digital reporting itself is not new.

The new element is the link between high-value banking activity and automated tax-risk analysis.

During the initial cross-matching stage, the banking information is not supposed to be visible to Income Tax Authorities. The system compares financial data with tax information electronically.

If the system identifies a significant mismatch, the relevant information can move into FBR's Compliance Risk Management process for further action through the National Faceless Centre.

That distinction matters.

The algorithm is not supposed to declare anyone guilty of tax evasion. It identifies a discrepancy that may deserve examination.

Rs100 Million of Bank Flow Is Not Rs100 Million of Income

This is where the policy becomes more complicated.

Imagine a Karachi distributor whose accounts receive Rs120 million during six months.

Most of that money may not represent profit. A large portion may return to manufacturers through inventory payments. Wages and operating expenses consume more of it.

The account may show enormous turnover while the business earns a modest margin.

Anyone who reads commercial bank statements learns this quickly.

Account turnover measures movement. It does not automatically measure income.

A useful tax-risk model therefore has to understand more than transaction size.

Banking data tells the government what moved.

Tax data tries to explain what the movement meant economically.

Those are different questions.

A wholesaler, importer or manufacturer can process very large amounts while earning a relatively small percentage on those flows. If an algorithm treats banking turnover as an approximation of income, legitimate businesses could generate false risk signals.

A sophisticated model should compare financial flows with declared turnover and the nature of the taxpayer's business. It should also consider other tax information before escalating a case.

A mismatch can be important.

It is not proof.

Banking Secrecy Has Changed

Section 165AB also changes the balance between banking confidentiality and tax enforcement.

The law contains a non-obstante clause. In plain language, the reporting requirement applies even where certain confidentiality protections in other laws would otherwise conflict with it.

The provision specifically refers to the Banking Companies Ordinance 1962, the State Bank of Pakistan Act 1956 and the Protection of Economic Reforms Act 1992.

Parliament has therefore made a deliberate choice.

For information covered by Section 165AB, banking confidentiality cannot prevent the required electronic reporting for tax cross-matching.

The law also contains restrictions on access during the initial matching process. Legal access and confidentiality are not necessarily contradictory.

The harder questions concern implementation.

The published framework explains the reporting architecture more clearly than every operational detail about retention, access logging and system governance. Those controls will matter once implementation matures.

Who can retrieve raw banking information?

How is access recorded?

How long should sensitive financial records remain available within the system?

A powerful data architecture needs equally strong controls around the people who can use it.

Algorithms Can Reduce Discretion. They Can Also Scale Mistakes.

There is a strong case for automated tax-risk assessment.

Pakistan cannot investigate every taxpayer manually. Human audits consume enormous administrative resources, and individual discretion can create inconsistency.

Software can examine volumes of data that no tax officer could process alone.

But automation creates a different institutional risk.

A human officer can make a bad judgment in one file.

A bad rule inside an algorithm can reproduce the same mistake across thousands of accounts.

Suppose the system learns that high banking turnover combined with comparatively low taxable income represents increased risk.

For some taxpayers, that may be a valuable signal.

For a low-margin distributor, it may simply describe a normal business model.

Technology does not remove judgment from tax administration.

It moves some of that judgment into software rules.

The quality of those rules therefore matters as much as the quantity of data flowing into the system.

Taxpayers also need a practical way to explain legitimate transactions when an automated system produces a false signal. An efficient risk engine becomes much less efficient if genuine businesses spend months proving that normal commercial flows were not undeclared income.

Karachi Will Feel the Difference

I think about the commercial accounts I see around Karachi.

Importers near the port can move large sums because international trade requires them to. Distributors operating across the city may receive and send substantial amounts within days.

A figure that looks extraordinary on a salary account can look completely ordinary inside a commercial current account.

The computer sees the number first.

A sound compliance system must understand the economic activity behind it.

If Pakistan gets that balance right, algorithmic matching can help FBR identify serious discrepancies without depending entirely on manual searches through banking records.

If it gets the balance wrong, legitimate businesses may spend their time explaining why turnover is not income.

The distinction sounds elementary until software forgets it.

Then an elementary mistake becomes an institutional one.

The Tax Officer Is No Longer the Only Gatekeeper

The most important number in this story may not be Rs100 million.

The deeper change is the reporting architecture itself.

Pakistan is moving from a document-centred model of tax enforcement toward a data-centred one. Banks increasingly submit structured information electronically. Tax authorities can use automated systems to identify inconsistencies before an officer begins a conventional investigation.

Once institutions build the pipes, what travels through them can change more easily than the infrastructure itself.

That is why Section 165AB deserves attention beyond wealthy account holders.

The debate is no longer only about what powers an FBR officer possesses.

It is also about how risk models work, what information enters them and what happens after a machine identifies a discrepancy.

Pakistan needs better tax enforcement.

It also needs systems intelligent enough to distinguish legitimate commercial activity from undeclared income.

Somewhere inside a server, a taxpayer's banking behaviour will increasingly be compared with the story told by his tax return.

No officer may have opened the account statement yet.

The algorithm may already have noticed the difference.