CIG ANAC and tender bonds: the automatic validation workflow

Anyone managing surety bonds attached to Italian public tenders knows that CIG (Italian Tender Identifier) is not a formality: it is the key linking the bond certificate to a specific public contract. Without the correct CIG, the bond is not enforceable against the contracting authority; with the wrong CIG, the error may surface only at call time, when it is too late to fix. This article describes how a vertical surety PAS handles the bond-issuance workflow tied to the CIG, with focus on automatic validation via the ANAC API at issuance.

What CIG is and why it matters for bonds

CIG is the 10-character alphanumeric code that ANAC (Italian Anti-Corruption Authority) assigns to every public-tender procedure in Italy. Introduced by L. 136/2010 for financial-flow traceability, CIG uniquely identifies the tender, links all payments and guarantees to the specific contract, and enables anti-corruption monitoring on public procurement.

For tender surety bonds, CIG is central for three reasons:

• Contract identification. The certificate must contain the CIG in its text: a bid bond without a CIG traceable to the tender is not considered valid by the contracting authority. The same applies to the performance bond.
• Flow traceability. Bond premium and (any) calls are payments subject to L. 136/2010 traceability: CIG appears in the bank-transfer reference and legally identifies the contract they refer to.
• Notice consistency. Tender base amount, duration, contracting authority: all data the bond must reflect are published by ANAC against the CIG. A bond stating a discrepant amount is formally challengeable.

The issuance flow: from request to certificate

In a vertical surety PAS, issuing a bid bond against a CIG follows a standardised flow. The difference between a generalist platform and a vertical one lies exactly here: the vertical one automates checks that would otherwise be delegated to manual underwriting.

Step 1 — Request input

The broker or agent enters the request indicating: guaranteed principal, CIG, declared tender base amount, beneficiary (contracting authority), type (bid or performance), duration.

Step 2 — CIG validation via ANAC API

The system queries the BDNCP (National Public Contracts Database) in real time and retrieves: CIG existence, status (active, suspended, cancelled), registered contracting authority, official base amount, tender object, CPV (Common Procurement Vocabulary). API-returned data is the authoritative source: in case of discrepancy with what the principal declared, it prevails.

Step 3 — Principal verification

On the guaranteed principal, parallel checks are performed: AML/sanctions screening, tax ID/VAT number validation via Italian Tax Agency, credit-rating retrieval (in evolved PAS, integration with Cerved or CRIF to assess post-call regress risk).

Step 4 — Premium calculation

Based on amount, duration, principal's risk class, tender type, the premium is calculated applying the insurer's IVASS-approved tariffs. Quotation is automatic for amounts within the underwriter's authority threshold; above threshold it enters a senior-approval workflow.

Step 5 — Certificate generation

The certificate is composed from a parameterised template integrating: registry data, tender data (retrieved from ANAC), standard line clauses (first demand, prior waiver of objection, jurisdiction), duration and release. The template is IVASS-approved for that insurer and that line.

Step 6 — Signing and delivery

The certificate is signed with FEQ (qualified electronic signature) by the insurer, time-stamped by an AgID-qualified TSA (Actalis, InfoCert or equivalent), and delivered as PDF/A to the broker for presentation to the contracting authority. A copy is sent for decade-long preservation to the AgID-accredited Preservation Provider.

ANAC API integration in practice

BDNCP querying happens via web service exposed by ANAC. The syntax is simple (HTTPS request with CIG as parameter, structured XML/JSON response), but the value is not in technical complexity: it is in what you do with the returned data.

A vertical PAS natively handles four cases that a generalist platform leaves to the underwriter:

• Non-existent CIG. Issuance blocked, error shown to the broker with precise message and verification suggestion (typo? tender from another central?). Never issued against a ghost CIG.
• Cancelled or suspended CIG. Strong warning, explicit underwriter confirmation required, motivation logged for audit.
• Declared amount vs ANAC discrepancy. If the broker declares EUR 100,000 but ANAC reports EUR 150,000 as base amount, the system warns and proposes the ANAC value as default. The final bond amount is calculated on the ANAC basis, except for explicit override (e.g. tender split into lots, principal bidding only on one lot).
• Contracting authority not consistent. If the broker declares as beneficiary "Municipality of Rome" but the tender is run by "Lazio Central Procurement Office on behalf of the Municipality", the system proposes the official ANAC name, avoiding formal challenges at call time.

The 5 most common errors and how to avoid them

1. CIG mistyped. Confusion between 0 and O, 1 and I, 5 and S. The CIG check digit helps intercept mechanical errors, but validation against ANAC is the only one catching CIGs that are syntactically correct but refer to different tenders.
2. Wrong-tender CIG. Happens when the principal participates in multiple simultaneous tenders and gives the broker the wrong CIG. Tender-object comparison validation is the antidote: if the bond is for a cleaning contract but the CIG points to a construction one, the system warns.
3. Disproportionate bond amount. For the bid bond, typically 2% of the base amount (reducible to 1% for ISO/EMAS-certified operators); for the performance one, a % varying with award discount. A vertical PAS calculates these amounts automatically from ANAC + principal data.
4. Inconsistent duration. The bid bond must cover offer validity (typically 180 days from submission deadline), extendable if foreseen in the notice. The performance bond covers the full contract duration + a warranty period. Mismatches create cover gaps.
5. Incorrect beneficiary. Often the contracting authority formally named in the notice is a municipality union, a central procurement office, an in-house company: not the single entity the principal "sees". The ANAC API returns the correct formal name.

What changes for the performance bond

The described flow applies to the bid bond issued attached to the offer. The performance bond (issued after award, before contract signing) has some specifics:

• Amount proportional to award discount. The % increases with the discount offered in tender, to counterbalance the risk for the contracting authority. The ANAC API allows retrieving the award amount (after tender closes) to automatically calculate the performance bond.
• Progressive release. For public-works contracts, the performance bond is progressively releasable based on approved SAL (work-progress instalments). The policy back-office module handles partial releases with document generation and technical-exposure update.
• Duration linked to acceptance testing. The performance bond does not expire at end of works but at testing approval, which can be delayed for years. Evolved PAS track testing status via integration with the principal's management system or via manual input.

In summary

CIG is the technical-legal core of bonds attached to Italian public tenders. A vertical surety PAS natively handles validation against ANAC, proposes authoritative values as default, intercepts the most common errors before the certificate is issued. The value is not in the single check (trivial): it is in the composition of all checks in a workflow that significantly reduces the risk of contested call.