INFOSTAT — the Banca d’Italia reporting channel
In Italy, “we sent the file” and “we filed the return” are two different statements. INFOSTAT draws a hard line between a private workspace, where a firm can key, import and validate data for as long as it likes, and the moment of consegna, when the data becomes an official submission. Everything that goes wrong for a newly authorised payment or e-money institution sits either side of that line: an enrolment that took six weeks nobody budgeted, or a file that was diagnosed clean and never delivered. This piece sets out how the channel works — the enrolment chain, the calendar, the two submission modes, the three classes of error, and how corrections and confirmations differ.
1. What INFOSTAT is
INFOSTAT is the Banca d’Italia’s platform for collecting information. It sits at infostat.bancaditalia.it, and it does two jobs: it supports the preparation and transmission of segnalazioni owed to the Bank, and it distributes the return flows the Bank produces from the data it collects — those reach reporters through a separate /flussiweb address.
It is a channel rather than a return. The obligations are defined by the reporting rules for each survey, and the platform exposes each one as a rilevazione with its own periods, formats and validation logic. The Bank is explicit that functions may be switched off for a given exchange where its rules do not contemplate them — so the interface for one survey will not necessarily match the next.
One distinction matters immediately, because it doubles the enrolment work. Anti-money-laundering reporting does not travel through this portal. The Unità di Informazione Finanziaria operates its own Infostat-UIF portal, with its own partner registry and adherence process, for suspicious transaction reports, aggregate AML data, objective communications and the gold declarations. A firm entering the Italian market needs both, and neither enrolment shortens the other.
2. The enrolment chain
Access is granted in three steps that must happen in order, and only the last is quick.
| Step | What happens | Who acts |
|---|---|---|
| 1. Partner accreditation | The Bank assigns the reporting entity a Codice Partner; the entity returns a completed accreditation form signed by its representative, including digitally | The firm’s legal representative |
| 2. Registration of the Gestore delle Abilitazioni | One named individual becomes the entity’s authorisation manager, either by entering a PIN issued by the Bank or by being named in the accreditation form | A designated employee |
| 3. Authorisation of other operators | Each further operator registers, requests a delega, and the Gestore grants it | The Gestore |
The form normally reaches the Bank by certified email — PEC to res@pec.bancaditalia.it, subject “MODULO PER l’UTILIZZO DI INFOSTAT” — or by fax to the number the documentation gives. It carries the entity’s identifying information, a named contact for accreditation problems, telephone numbers and email addresses, and whatever else the specific exchange requires.
The PIN route is the one that generates elapsed time. Where it applies, the Bank generates a secret code on receiving the accreditation form and sends it by secure post to the entity’s registered office. The entity hands it to the operator responsible for INFOSTAT security, who registers and enters the PIN to become Gestore. For a branch whose registered office is a company-formation address, that is a physical dependency in the middle of a regulatory timeline. The alternative — naming the Gestore in the accreditation form, with that person’s username already created — avoids the PIN entirely, and is worth asking for.
Authentication is username and password plus a one-time password sent to the mobile number in the user’s profile. The Gestore’s job does not end at go-live: the same person revokes access for operators who stop using the platform, and periodically reviews the entity’s enabled accounts.
3. The scadenzario
Once inside, the entry point is not a file upload but a calendar. The scadenzario shows, for a selected partner and calendar year, every survey the entity owes and the months in which the deadlines fall. It can be read as a grid, with surveys on the rows and months on the columns, or as a chronological agenda.
Hovering over a highlighted cell reveals the reference accounting date, the date from which work on that submission is permitted, and the date by which it must be sent. The middle one is what project plans miss. A submission cannot be prepared in the platform before its window opens, however ready the data is, and the functions for an unopened cell are visibly present but disabled.
Selecting an open cell reveals two families of functions: Funzionalità Data Entry, where the survey supports online preparation, and Funzionalità Upload file, for firms that build the file themselves. Where a survey expects several flows at different accounting dates sharing one deadline, the agenda lists them individually while the grid aggregates them — so the agenda is the safer view.
4. Data entry and upload
The data entry service is a private workspace. Data can be entered, changed and checked across as many sessions as the firm wants, and no official interaction occurs until delivery. It supports editing, import and export, a diagnostic run, official delivery, confirmation handling, and consultation of messages exchanged with the Bank.
The upload service is for entities that produce the flow with their own procedures. The message must respect the format defined for that specific survey; the upload function checks that and, where the format does not match, produces a scarto — a rejection message placed on the site and also emailed to the reporter. For supervisory reporting, the file format specification sits in Tomo I of Circolare 154 of 22 November 1991 together with the Bank’s manual on information-exchange arrangements.
One more asymmetry between the two modes catches teams that mix them. Data entry does not support sending correction batches against data already delivered, whichever mode delivered it. To correct through data entry, the firm restores the last delivered dataset using the import function, edits it, and sends a complete replacement submission. Confirmations, by contrast, have their own dedicated function in both modes.
5. Diagnostico, consegna, and the three classes of rilievo
The diagnostico is a preliminary check the firm can run without limit before delivering. It returns messages with the error reports attached, in exactly the same form as delivery does, and those reports are for the firm’s internal use only. Where there are no errors, the diagnostic returns a positive confirmation — which, notably, official delivery does not.
Two categories of control run. Formal controls test the correctness of individual observations. Deterministic controls test coherence between the parts of a submission, and that category includes trend checks comparing the data against earlier periods and cross-checks comparing it against other surveys. The Bank repeats all of these after delivery and reserves the right to run further ones.
Errors are reported as rilievi, in three classes:
| Class | What it tests | What the report gives you |
|---|---|---|
| Da Archiviazione | That the uploaded message is in the expected format: variable and item codes, header coherence (partner id and accounting date), and control values — record sequence number, record type, total record count | The whole offending line, with the value that caused the error highlighted. Does not arise on data-entry submissions |
| Formali | Values assigned to classification variables — format, membership of the permitted list published in the survey’s instructions, and incompatibility with related variables | The rilievo identifier and every variable in the record structure, with the error described against the ones affected |
| Deterministici | Coherence between parts of the submission | The identifier, a description of the aggregates compared, and the calculated amounts — with the previously reported amounts in brackets where the same rilievo appeared in an earlier report |
After official delivery the Bank runs its own verification and posts the resulting rilievi in INFOSTAT, also sending them to the reporter’s mailbox. The firm answers in one of two ways: it rectifies the submission, or it sends a conferma — a formal statement that the flagged figure is correct as reported. Confirmations apply to deterministic rilievi, are selected item by item in a dedicated panel, and can carry explanatory notes. Rectifications and confirmations must be sent separately, and rectifications cannot be run through the diagnostic.
One more control is worth knowing: where a survey admits it, upload offers a segnalazione nulla o negativa option that files a nil return for the whole survey with no file attached.
6. Three scenarios
Scenario one: the PIN in the post. A firm authorised in Italy plans its first supervisory submission for a quarter-end eight weeks away and treats portal access as an IT task for the final fortnight. Facts to rule: partner accreditation precedes everything, and where the PIN route applies the code travels by secure post to the registered office. What the reporting lead does: start accreditation the week authorisation is granted, ask whether the Gestore can be named directly in the form, and confirm someone at the registered office is expecting the envelope. The failure mode is a correct file and no account to send it from.
Scenario two: diagnosed, not delivered. An analyst prepares a return in data entry, runs the diagnostic, gets the positive feedback message and closes the ticket. Facts to rule: data entry is a private workspace, no official interaction occurs until consegna, and delivery with no rilievi returns no positive message at all. What the team does: make the completion criterion the delivery step, not the diagnostic, and treat “no message after delivery” as the normal successful outcome rather than as silence to chase. Outcome: the return is filed. The failure mode is a clean diagnostic mistaken for a receipt.
Scenario three: the correction that arrived as a rectification. A firm restates a full period after finding a mapping error affecting several items. Facts to rule: a second submission that replaces the first in full is an Invio, not a Rettifica; through data entry, correction is only possible as a complete replacement, restored via the import function. What the analyst does: import the last delivered dataset, edit at source rather than in the output, use the change-preview function before sending, and set the delivery flag to Invio. Outcome: one authoritative version of the period. The failure mode is a partial rectification file that leaves the Bank holding a blend of two datasets.
7. Planning around the channel
For a payment institution or IMEL entering Italy, three things belong on the critical path well before the first deadline. Enrolment on INFOSTAT for statistical and supervisory reporting. A separate enrolment on Infostat-UIF for AML reporting, with its own administrator and referent roles. And a named Gestore delle Abilitazioni with a named deputy, because in this design the authorisation manager is a single point of failure by construction.
Technical requirements are modest but real: the platform expects a current Chrome or Firefox and a minimum screen resolution, over HTTPS. For access problems the Bank publishes a help desk at rdvi.helpdesk@bancaditalia.it, with a separate address for problems with self-registration itself.
Do suspicious transaction reports go through INFOSTAT?
No. AML reporting — suspicious transaction reports, aggregate AML data, objective communications and gold declarations — goes to the Financial Intelligence Unit through the separate Infostat-UIF portal, which has its own partner registry, its own adherence step and its own administrator and referent roles.
What is the difference between diagnostico and consegna?
The diagnostic is a private check that can be run as often as the firm wants and produces reports for internal use only. Consegna is the official submission. Nothing has been filed until consegna, whatever the diagnostic returned.
Why did we get no confirmation after delivering?
Because there were no rilievi. The Bank does not return a positive feedback message where delivered data raises no errors — that message exists only in the diagnostic. Silence after delivery is the good outcome.
Can we correct part of a submission?
It depends on the mode and the survey. Upload can carry a rectification file for the part being changed, or a full resubmission, according to what that survey allows. Data entry cannot send rectification batches at all — correcting through data entry means restoring the last delivered dataset and sending a complete replacement.
What is a conferma?
A formal reply to a deterministic rilievo stating that the reported figure is correct as it stands. Items are selected individually in a dedicated panel and can carry an explanatory note. Confirmations and rectifications must be sent separately.
8. What to do, today
- Start partner accreditation as soon as the Italian entity is authorised, and ask whether the Gestore delle Abilitazioni can be named in the form so the posted PIN is not on the critical path.
- Appoint a deputy Gestore. One authorisation manager with no backup is a single point of failure the design does not mitigate.
- Run the Infostat-UIF enrolment as a parallel workstream, not as a follow-on. It is a different portal with a different registry.
- Read the scadenzario for the work-permitted date, not only the deadline, and build the internal close calendar against the earlier of the two.
- Make delivery, not the diagnostic, the completion criterion in the reporting procedure — and document that no news after delivery is success.
- Write the Invio / Rettifica / Conferma decision into the correction procedure explicitly, with the rule that a full replacement is an Invio.
- Check whether each survey admits a nil return before building a machinery to file empty files.
Related: Reporting channels compared across the EU · Banca d’Italia Segnalazioni — the reporting matrix · The Italian reporting calendar for a payment firm · Testing a new return before first submission
