Comunicazioni oggettive — Italy’s monthly cash return to the UIF, and the January 2026 change

Comunicazioni oggettive are the Italian return nobody briefs you on: a monthly cash file to the UIF that you owe whether or not anything looked suspicious, and that you owe even in the months when you have nothing to report. Italian AML conversations start and end with the SOS. Sitting alongside it is a purely mechanical obligation: aggregate cash movements on objective criteria, transmit them in XML through Infostat-UIF, and do it by the 15th of the second month after the observation month. Banks, Poste Italiane, payment institutions and e-money institutions are all in scope, including EU branches and EU contact points. This piece sets out the scope, the threshold arithmetic, the file, the deadline mechanics and what changed for January 2026.

1. What a comunicazione oggettiva is — and what it is not

The obligation sits in Article 47 of Legislative Decree 231/2007 as amended, and the operating rules come from the UIF’s Istruzioni in materia di comunicazioni oggettive of 28 March 2019, supplemented by FAQ dated 17 October 2019 that carry most of the practical answers. The UIF’s framing is the important part: obliged entities transmit data on operations selected on objective criteria, periodically, independently of any assessment of suspicion.

That word — objective — separates this return from everything else in the Italian AML stack. A SOS is filed because an analyst formed a view; a comunicazione oggettiva is filed because a threshold was crossed. There is no discretion, no narrative, and no defence in saying the cash activity was fully explained.

2. Who is in scope, including branches and contact points

The UIF states the population directly: banche, Poste italiane, istituti di pagamento e istituti di moneta elettronica — and, expressly, incluse le succursali e i punti di contatto comunitari. For a cross-border payments group that sentence resolves the question that usually costs the most time.

The population is defined by category, not by whether you handle cash: a firm with no cash operations is still an obliged sender, and reaches the exemption route in section 6 rather than falling outside the perimeter.

3. The threshold arithmetic

The trigger is cash operations of €10,000 or more executed in the course of a calendar month, reached even through several individual operations of €1,000 or more. Four rules govern how you get there, and each is a place where implementations go wrong:

• Truncate, then add. Amounts are truncated to whole euro before the monthly total is computed — not rounded, and not truncated after summing.
• Only the cash leg counts. Where an operation is part cash, only the cash component enters the aggregate; the file carries the total amount and the cash component as separate fields.
• Aggregate per subject, across roles. A person’s operations are summed even where they appear in different capacities — customer in one, executor for a company in another.
• Each operation is reported once, even where it pushes two different subjects over the threshold.

A short list is excluded outright by the FAQ: ATM withdrawals with cards issued by foreign banks, and technical cash movements between a bank and Banca d’Italia, between group banks and the parent, and between banks and outsourced cash handlers. Cash mandates and reversals between public administrations and customers are in.

4. Three worked examples

Facts: a customer makes two cash deposits in one calendar month, of €7,000.40 and €2,999.80, and nothing else.

What the rule says: truncation happens first, so the amounts become €7,000 and €2,999 for a monthly total of €9,999.

What the practitioner does: nothing — and documents why. A system that rounds to the nearest euro, or truncates only the final sum, produces €10,000 and files a communication never owed. The over-report is the defect that survives longest, because nothing rejects it.

Facts: three cash operations in one month — €3,000 on an individual’s account; €5,000 on a company account with a different individual as executor; €7,000 on that company account with the first individual as executor.

What the rule says: aggregation is per subject and across roles, so the €7,000 operation counts towards both totals — but it enters the file once regardless of how many subjects it pushed over the threshold.

What the practitioner does: builds the selection logic in two passes — one aggregating per subject to decide whether an operation set is reportable, one de-duplicating operations before writing the XML. Collapsing this into a single pass either loses the cross-role aggregation or emits the same operation twice.

Facts: a joint-account holder deposits €5,000 in cash on their own account, and the file assigns subject-type code 01, “customer and executor”.

What the rule says: where the same person is attached to one operation in more than one capacity, the operation counts once for that subject’s total — not twice because two roles are recorded.

What the practitioner does: checks that the aggregation key is the subject, not the subject-role pair. It is the most common source of a phantom threshold breach in testing, and it only surfaces if somebody reconciles the file back to the ledger.

5. The file, and how it is transmitted

Each operation carries a unique identifier within the communication, the execution date as YYYYMMDD, the analytic causale, a debit/credit sign (D for dare, an outflow, A for avere, an inflow), a currency code, the euro amount and the cash component — all consistent with Banca d’Italia’s specific provisions on AML record-keeping. The relationship type and identifier are required where the operation moved a continuing relationship. One field pair is not for you: the branch ABI/CAB attributes are required only for banks and Poste Italiane, so a payment or e-money institution leaves them empty. The operation identifier need only be unique inside its own communication, and no operation may travel without at least one subject attached.

Files go through the Infostat-UIF portal, survey OGG, in XML validated against the published schema — message.xsd for file-level information, cube.xsd for the observations. The header carries the survey name (always OGG), the sender’s partner code, an initialDate equal to the last calendar day of the reference month, and a type attribute worth reading twice. SUBSTITUTION is a complete send that replaces whatever the same sender previously submitted for that reference date. INTEGRATION is a set of corrections, and it is the only mode carrying the DELETE, INSERT and PARTIAL_KEY_DELETE data segments that remove or add individual observations. Choosing SUBSTITUTION when you meant a small correction silently discards everything else filed for that month. Subjects attach to each operation with a role code, and for customers the internal identifier (NDG), the SAE economic sub-group and the ATECO code are mandatory.

6. The deadline, the rilievi trap, and nil returns

The window opens on the first day of the month following the reference month and closes on the 15th of the second following month — January’s operations can be sent from 1 February and must arrive by 15 March, rolling to the next non-holiday day where the 15th is a public holiday.

What catches firms is what “arrive” means. The UIF is explicit that the communication must be transmitted free of rilievi by the deadline. A rilievo — formal or confirmable — causes the corresponding observation, meaning the operation together with its associated subjects, to be discarded, and a communication carrying rilievi is not correctly acquired. The FAQ states plainly that rilievi must be corrected by the same date.

Nil returns are mandatory: obliged senders transmit a communication every month even with nothing to report. The exemption is narrow and must be asked for — it is available to senders carrying out no cash operations at all, or exclusively cash operations below €1,000. Registered senders request it by free-form attestation sent by PEC to the UIF’s certified mailbox, quoting the sender code (the six-digit ABI code for banks and Poste Italiane, the company’s codice fiscale otherwise) and the ground relied on; firms not yet registered claim it at registration through the dedicated field on cash activity. If the position changes, a fresh attestation is owed and normal filing resumes.

7. What changed for accounting dates from January 2026

The data-content specification and the XML technical instructions now exist in parallel versions, split at the January-2026 accounting date. Comparing them, the substantive changes are two.

First, ATECO 2025 replaces ATECO 2007. Banca d’Italia and the UIF adopted the Istat reclassification from 1 January 2026, confirmed in the UIF’s communication of 24 July 2025 after an earlier notice of 4 April 2025. For comunicazioni oggettive the ATECO field is replaced by a new ATECO2025 field starting with the communication for January 2026 — the one due by 15 March 2026 — carrying four-digit codes, with three digits permitted only where the sender does not hold that level of detail. Substitutive or corrective communications for activity executed up to the end of December 2025 must instead keep ATECO 2007 coding in the original ATECO field, so both code sets have to stay resolvable for as long as you might restate an old month.

Second, the relationship identifier for non-SEPA cash transfers is now specified: where the operation is a cash transfer to a non-SEPA country and so has no IBAN, the identifier is the BIC plus the foreign account number in the documented format instead.

That second change arrived through the automatic-controls revision, worth revisiting as a set. Announced on 14 May 2024 and operative from 7 October 2024, it made ATECO and SAE mandatory for subjects in a customer role, required a counterparty subject on transfer-type operations, tightened codice fiscale checks to sixteen alphanumeric characters for Italian-born natural persons and eleven non-zero digits for Italian legal persons, and relaxed the branch ABI/CAB check so a code valid for at least one day in the reference month is accepted rather than only the code valid on the last day. Observations failing any of them are flagged and not acquired.

8. FAQ

9. What to do, today

• Confirm in writing whether your Italian presence is a branch, a contact point or an authorised institution — all three are in scope, and none is exempt for being small.
• Test the threshold logic against truncation-first arithmetic and cross-role aggregation, using cases that land at €9,999 and €10,000, before trusting a production month.
• Move your internal cut-off earlier than the 15th so a full rilievi correction cycle fits inside the statutory window.
• If you handle no cash, or none at or above €1,000, file the exemption attestation rather than assuming silence is compliance — and set a trigger to withdraw it if the business changes.
• Keep both ATECO 2007 and ATECO 2025 mappings live, routed by the accounting date of the month being reported rather than by today’s date.

Related: How to file a SOS with the UIF via Infostat-UIF · The Archivio Unico Antiriciclaggio · The Italian AML framework beyond the UIF