Question 1

Do you connect to our live systems?

Accepted Answer

No. NIRNAE has no integration with treasury systems, PFMS, banking rails or any departmental database, and requests no credentials or network access. The department exports the records it wishes to have examined and submits those files. Nothing else is visible to the engine.

Question 2

Is this legally permissible for a department to use?

Accepted Answer

Because no live access is involved, the engagement is analysis of records the department already holds and already controls, performed on its written instruction. Data-sharing terms, the scope of records and the retention window are agreed in writing before anything is submitted. Departments handling restricted records can run the engine on their own infrastructure.

Question 3

Is NIRNAE already deployed in a government department?

Accepted Answer

Not yet. NIRNAE is in pre-deployment. Current engagements are supervised pilots on exported or anonymised datasets, run alongside a department's existing audit process rather than in place of it. We would rather state that plainly than imply an installed base that does not exist.

Question 4

What does a first engagement actually involve?

Accepted Answer

A briefing on a sample or anonymised dataset, then a pilot on a scoped set of departmental records — typically one scheme, one district or one financial year. The output is reviewed against what your officers already know, so the department can judge the hit rate before anything wider is considered.

Question 5

How is NIRNAE procured, and do you already hold any of our data?

Accepted Answer

We hold nothing. NIRNAE has no pre-existing access to any departmental record, and no data reaches us until a department sends a written request and agrees the scope, the records and the retention window. Engagement begins with a briefing on sample or anonymised data; procurement follows the department's own route, and can be scoped to a single pilot before anything wider is considered.

Question 6

What happens to our data after the pilot?

Accepted Answer

It is retained only for the engagement window agreed in writing and then deleted, with deletion confirmed back to the department. It is never used for another engagement, never shared, and never used to train a public model.

Question 7

What file formats can a department submit?

Accepted Answer

Spreadsheet and data exports in .xlsx, .xls, .csv and .json. These are the formats treasury systems, PFMS-style portals and departmental accounting software already produce, so nothing new has to be built to use NIRNAE.

Question 8

Which records are most useful to send?

Accepted Answer

Payment registers, bill books, sanction and work orders, vendor or supplier masters, beneficiary lists and utilisation certificates. More context produces stronger findings, but a single payment register is enough to begin.

Question 9

What is the minimum a dataset must contain?

Accepted Answer

A date, an amount and a payee or vendor identifier per row. Sanction head, work location, bill number and approving authority are optional and each one unlocks additional tests.

Question 10

Our column names are non-standard. Is that a problem?

Accepted Answer

No. Columns are mapped at ingestion, and several files are merged into one working ledger. No schema change, systems integration or IT project is required on the department's side.

Question 11

Can several years or several departments be analysed together?

Accepted Answer

Yes. Multi-year and multi-department datasets are merged before analysis, which is what allows repeat vendors, recurring beneficiaries and cross-scheme diversion to surface at all.

Question 12

What kinds of malpractice does NIRNAE surface?

Accepted Answer

Patterns that are visible in transaction data: payments split below sanction ceilings, vendors sharing identifiers and bidding as a ring, duplicate or non-measurable billing, March-end fund dumping, same-day sanction and payment, vendors located far from the work, entities registered days before a large award, expenditure booked to the wrong head, and value passed through intermediaries who performed no work.

Question 13

What can NIRNAE not do?

Accepted Answer

It cannot verify that physical work happened on the ground, prove intent, or establish criminal liability. It cannot see records the department has not supplied, and it does not replace a statutory audit, an inspection or a vigilance inquiry. Every finding is an indicator for verification, not a conclusion.

Question 14

Will it produce false positives?

Accepted Answer

Yes, and that is expected of any screening system. Because each finding carries the figures behind it, an officer can dismiss an explained case in minutes rather than investigating it. The purpose is to rank where scrutiny should go first.

Question 15

Does the output name individuals as guilty?

Accepted Answer

No. Output is written as audit observation and recommended verification against entities and transactions. NIRNAE holds no statutory authority and issues no determination of wrongdoing.

Question 16

What does a reviewer actually receive?

Accepted Answer

A ranked list of entities and transactions. Each entry carries a severity score, the agent or agents that raised it, the exact transactions involved, the arithmetic behind the flag and the verification step recommended next.

Question 17

Can a finding be re-derived by hand?

Accepted Answer

Yes, and that is the standard we hold. Every flag states the transactions, the totals and the comparison that produced it, so a reviewing officer or audit committee can reproduce the calculation without access to the system.

Question 18

Is the output usable in an audit para or inspection note?

Accepted Answer

It is written for that purpose: factual, in audit language, with the supporting figures attached. Departments typically use it as the working paper behind a para, an inspection note or a reference to a vigilance cell.

Question 19

How are linked entities shown?

Accepted Answer

Related firms and beneficiaries are grouped into a single cluster with the identifiers that connect them listed, so a network of nominally separate parties reads as one beneficiary in the brief.

Questions audit officers ask first

What we accept, what we can prove, and what we will not claim

Detects

What it does not do

Access, legality and current stage

Inputs we accept

What we can and cannot detect

How evidence is presented for reviewers

Interested?