Trust and compliance · 2026-08-18
AI Projects at Turkey's Tax and Public Oversight Authorities: Explainability and Data Control in Financial Risk
Compare the Turkish Revenue Administration's tax-loss analysis and the Public Oversight Authority's financial-failure project across data, explainability, access, on-premises deployment, bias, and drift.
The two problems being solved
The Revenue Administration project aims to analyse carried-forward losses in corporate tax returns together with other institutional data, estimate the expected loss, explain deviations, and suggest corrections. The specification treats this as development of original explainable models rather than only a software interface.
The Public Oversight, Accounting and Auditing Standards Authority project aims to forecast financial failure and identify companies whose ratios diverge materially from their sector. Both projects prioritise risk for authorised review; model output is analytical evidence, not a final ruling.
Tax: reading structured data and free text together
The tax specification records roughly 1.2 million corporate taxpayers, only 35,000 fully reviewed over the previous three years, and 2,500 penalised in 2024. The project expects about 500,000 annual returns together with e-invoice, e-archive, e-ledger, property, and assessment and collection data.
Financial statements and declared amounts are structured, while return notes contain free text. Both must be analysed together. Free-text processing requires separation of identity and trade-secret fields, while structured variables need period and source-system alignment.
Oversight: sector-specific failure and anomaly models
The EFR system holds financial statements from 2018 onward. The specification describes about 30 GB of annual data, 22 main sectors, 272 subsectors, and financial ratios for identifying risky companies. It sets a minimum Macro F1 of 70 percent for each subsector, allowing a move to the parent group with institutional approval when failure examples are insufficient.
That rule exposes rather than hides data imbalance. A high accuracy value can be misleading when failure examples are scarce. Macro F1 gives classes equal weight, but sample counts and uncertainty should still be reported by sector.
| Area | Tax-loss analysis | Public-oversight financial analysis |
|---|---|---|
| Primary output | Expected loss estimate and deviation factors | Financial failure and sector anomaly risk |
| Data | Returns, e-documents, e-ledgers, property, and collection systems | EFR statements, NACE sectors, and financial ratios |
| Method | Regression and explainable risk models | Clustering, probabilistic methods, ML/DL, and transformers |
| Performance | Institutional tests for estimates and explanations | At least 70% Macro F1 across 272 subsectors |
| Integration | PostgreSQL, Sybase, XML, and institutional REST services | FinAP, EFR, SBG through REST, SOAP, gRPC, or ODATA |
| Deployment | Existing institutional access, limit, and resilience rules | Internal isolation, AD, immutable logs, and penetration testing |
What explainability needs to show
In the tax project, the factors behind a gap between predicted and declared loss should be visible. In the oversight project, financial ratios are compared with prior periods and sector averages. The explanation should be calculated evidence, not persuasive text invented freely by a model.
Each explanation should identify data period, source system, model version, and influential variables. An authorised user should be able to return from the model result to the official record and reproduce the result with the same data and version.
Authorisation, immutable logs, and minimisation
Combining many financial sources creates a sensitive profile not present in any single system. Users should see only companies or taxpayers within their assignment, while bulk export, training-data preparation, and administration use separate roles.
The oversight specification explicitly requires immutable central logs, Active Directory authentication, OWASP Top 10 controls, an independent penetration test, and TS ISO/IEC 27001 processes. Logs should capture event, user, time, model version, and result identifier without becoming an uncontrolled second copy of raw financial reports.
Bias and model drift need joint monitoring
The oversight specification calls for bias analysis under ISO/IEC TR 24027, risk management guided by ISO/IEC 23894, and alignment with ISO/IEC 42001 principles. Sector size, region, period, or missing data may increase false positives in a subgroup while an aggregate F1 score hides the effect.
Because the specification requests an MLOps architecture that can retrain on current data, drift monitoring is an implementation inference from the requirement. Distribution changes should trigger validation and human approval before a retrained model is promoted automatically.
Where an LLM gateway can and cannot be used
The oversight system is explicitly isolated, so LLMTR's external API cannot replace its core financial-risk model. Tax returns and e-document data also remain inside institutional security and service boundaries; those raw records should not be assumed eligible for an external model.
General text work or approved evaluation sets stripped of personal and commercial data may support model comparison. LLMTR has no prompt or response field in its usage schema, stores API keys as hashes, and supports per-key controls, but the selected upstream provider's processing policy remains a separate review.
Source and responsibility boundary
This article is based on the corporate tax-loss and public-oversight AI-supported financial-analysis specifications published in June 2026. It makes no unsupported claim about application results, contract parties, or live deployment.
The content is a technical analysis and does not constitute legal advice. Processing tax and financial-reporting data, assigning weight to model output, and using external services belong to the relevant institution's data owners, information-security, compliance, and legal teams.
Frequently asked questions
What will the Revenue Administration AI project estimate?
It aims to estimate expected carried-forward corporate tax losses from returns and related e-document data and explain likely causes of deviations.
What is the Public Oversight Authority's performance target?
At least 70 percent Macro F1 for each of 272 NACE subsectors, with approved grouping where failure examples are statistically insufficient.
Do these projects require a large language model?
No. The specifications consider regression, clustering, probabilistic algorithms, machine learning, deep learning, and transformers according to the problem.
Why is explainability necessary in financial risk analysis?
It allows authorised users to inspect the periods, sources, and variables behind a risk result and verify it against the official record.
Can tax or public-oversight data be sent to LLMTR's API?
The oversight core is isolated and tax data remains within institutional controls. Raw returns or financial reports cannot be assumed eligible for an external API; the institution must decide.