Le nuove linee guida di pagoPA e la responsabilità dell’ente pubblico

Fra la disattenzione generale, sul finire di aprile 2024, sono apparse sulla Gazzetta ufficiale le nuove “Linee guida per l’effettuazione dei pagamenti a favore delle pubbliche amministrazioni e dei gestori di pubblici servizi“, che definiscono le regole di cornice per pagamenti elettronici tramite pagoPA verso la pubblica amministrazione. In effetti, nemmeno la società PagoPA spa sembra essersene accorta, tant’è che sui siti che raccolgono la documentazione sui prodotti gestiti dalla società pubblica si fa ancora riferimento alle linee guida pubblicate nel 2018. Personalmente, io ne sono venuto a conoscenza grazie all’attenzione di alcuni funzionari pubblici abituati alla condivisione.

Il confronto in sintesi

In estrema sintesi, ecco le novità:

• si formalizza il passaggio di competenze sulla piattaforma dall’Agenzia per l’Italia digitale alla società PagoPA spa;
• si esplicita chiaramente la possibilità di concordare forme di pagamento diverse con il debitore straniero e con il debitore privo delle disponibilità strumentali per utilizzare la piattaforma;
• si impone agli enti creditori di garantire la continuità operativa e si prevedono sanzioni per chi non la garantisce;
• per i prestatori di servizi di pagamento che omettono o ritardano i riversamenti, che non si adeguano alle evoluzioni tecnologiche o che non garantiscono i livelli minimi di servizio sono previste sanzioni, pagamento di interessi e interventi della Banca d’Italia in veste di organismo di vigilanza sul settore;
• sparisce del tutto la mai utilizzata facoltà dei prestatori di servizi di pagamento di fare riversamenti singoli e non cumulativi;
• tutti gli enti creditori devono attivare tutti i quattro modelli di pagamento (modalità di avvio del pagamento) previsti dalle specifiche;
• si adegua il linguaggio a quello delle specifiche attuative del nodo dei pagamenti (SANP) che dal 2018 a oggi hanno subito notevoli cambiamenti (es.: la “ricevuta telematica” ha cambiato forma e nome),

e le conferme:

• pagoPA è la modalità unica di pagamento per tutti i pagamenti verso la p.a. e vi si possono affiancare (non sostituire) solo: F24, domiciliazione bancaria, forme di pagamento espressamente previste dalla legge e non ancora integrate in pagoPA e il pagamento presso la banca cassiera/tesoriera;
• permane l’obbligo per chi possiede un conto corrente postale per qualsiasi motivo, di abilitare la sezione bollettino postale degli avvisi pagoPA;
• le ricevute telematiche (o quel che ne resta, visto che adesso sono incorporate nel corpo della busta SOAP) vanno conservate a norma, così, “di botto”, senza passare dalla fase di registrazione e gestione documentale;
• per ogni pagamento ricevuto – dopo la riconciliazione – occorre emettere un documento di ricevuta con valore di quietanza, dotato di contrassegno elettronico ed eventuale marca da bollo, e metterlo a disposizione del debitore o recapitarglielo al suo domicilio digitale.

La lettura delle linee guida offre però lo spunto per una riflessione che va oltre lo specifico dei pagamenti elettronici gestiti con pagoPA e si può estendere ad altri fronti della trasformazione digitale.

La continuità operativa e la responsabilità dell’ente creditore

Dalle Linee guida:

6. Continuità operativa
[…]Gli enti creditori sono tenuti alla continuità operativa h24 affinché ogni prestatore di servizio di pagamento possa sempre erogare i propri servizi di pagamento agli utenti, pena il pagamento da parte degli stessi enti creditori delle sanzioni che saranno indicate a tal fine nell’allegato B – Specifiche attuative del Nodo dei pagamenti-SPC, previa fattura da parte della società PagoPA S.p.a.
Sarà cura della PagoPA S.p.a., determinare e condividere preventivamente i parametri per la rilevazione anche a campione degli enti creditori passibili di tali sanzioni.

8.3.3. Intermediari per la connessione al Nodo dei pagamenti-SPC.
Gli enti creditori, nonché i PSP che abbiano sottoscritto gli accordi di cui al paragrafo precedente, si possono avvalere di uno o più soggetti terzi che, in nome e per conto del soggetto aderente, si occuperanno di gestire le attività di interconnessione all’infrastruttura Nodo dei pagamenti-SPC, mantenendo inalterate le singole responsabilità nei confronti degli utilizzatori finali.

A una lettura che guarda al di là della mera situazione di pagoPA, emergono tre aspetti che vale la pena sottolineare, con piccole considerazioni a margine.

Il principio generale della responsabilità del “committente”

Va notato, in primo luogo, che gli obblighi riguardano tutti e soli aspetti di funzionamento dell’infrastruttura tecnologica dalla parte dell’ente creditore, anche se questa è tenuta e gestita, il più delle volte, da un partner tecnologico sui cui sistemi l’amministrazione cliente non ha alcun controllo. In secondo luogo, i partner tecnologici sono in qualche modo autorizzati a interagire con il nodo pagoPA dalla società che lo gestisce e che tiene anche un elenco ufficiale dei soggetti autorizzati a fornire tale servizio. Eppure, se per qualche motivo il server del partner tecnologico va giù, la colpa è dell’ente creditore, della pubblica amministrazione cliente del fornitore ICT.

Ci può stare, basta saperlo (e, magari tutelarsi, come diciamo più avanti). Una riflessione è d’obbligo: se sulla pubblica amministrazione si riversa la responsabilità della mancata disponibilità di un sistema informatico sul quale non ha controllo alcuno (non lo vede proprio) e dei cui disservizi può accorgersi solo a seguito delle doglianze di qualche utente, cosa si può dire delle responsabilità circa le caratteristiche funzionali dei software che acquista?

In altri termini, se il fornitore non è direttamente responsabile di tenere accesso e raggiungibile il suo server, perché dovrebbe essere responsabile dell’aderenza dei suoi software e dei suoi servizi alla normativa generale e speciale? Mi riferisco alla gestione documentale (CAD e dintorni, con le questioni di valore giuridico-probatorio dei documenti prodotti e della loro gestione) e, in generale, all’aderenza alla normativa che regola gli affari a presidio dei quali quei software sono utilizzati (tributi, gare d’appalto^[1]A ben vedere, anche la tanto nota e discussa certificazione delle piattaforme di e-procurement guarda solo ad aspetti di comunicazione di dati verso la banca dati nazionale dei contratti pubblici e … Continue reading, calcolo di tariffe ecc.).

Clausole di tutela nei contratti con i fornitori

Alla luce di quanto sopra, un contratto con un partner tecnologico non può che prevedere la clausola espressa, chiara e incontrovertibile per cui il partner tecnologico si accolla tutte le sanzioni e le conseguenze derivanti dalla mancanza di continuità operativa dei sistemi che mette a disposizione. Più in generale, il partner non può non farsi carico del mancato rispetto degli SLA (Service Level Agreements, accordi di livello di servizio minimi) imposti dalla (forzata) adesione dell’ente creditore all’universo pagoPA. In altri termini gli SLA previsti dal contratto che regola il rapporto fra partner tecnologico ed ente creditore devono assorbire in toto quelli imposti dalla piattaforma e, ovviamente, si devono prevedere penali ad hoc, che coprano le sanzioni che PagoPA spa potrebbe comminare all’ente.

In realtà, non solo il partner tecnologico pagoPA, ma tutti i fornitori di software e sistemi che sono coinvolti in esigenze di pagamento dovrebbero essere sensibilizzati e “inchiodati” alla propria parte di responsabilità in caso di mancanza di continuità operativa del sistema di pagamenti pagoPA dell’ente. Infatti, la tendenza del momento, sacrosanta e assecondata anche dagli sviluppi della piattaforma SEND per le notifiche digitali, è quella di attualizzare l’importo del pagamento pagoPA in tempo reale al momento dell’avvio del pagamento stesso. Questo vuol dire che, in pochi millesimi di secondo, si devono attraversare più sistemi e più banche dati (riferibili all’ente creditore) per garantire il buon esito del pagamento. Se un solo componente non risponde, la continuità operativa viene meno.

Certo, chi frequenta la pubblica amministrazione, specie quella locale, specie quella piccola, sa che – teorie normative e abc del diritto a parte – è praticamente impossibile imporre clausole che non siano quelle dei “contratti” chiusi proposti dai fornitori, che, spesso e volentieri, sono a loro volta descrizioni sommarie di cosa il fornitore stia vendendo e poco altro. Nel caso di pagoPA, poi, è ben frequente che alla pubblica amministrazione venga proposto un software gestionale che genera esigenze di pagamento e che, per evitare integrazioni, si porta dietro – lo dice un inciso in qualche periodo – anche l’integrazione con un partner tecnologico di fiducia del fornitore del software: così l’ente creditore accumula partner tecnologici di cui sa poco o niente e, alla fine, non può che incrociare le dita che qualcosa non si inceppi…

Non una scusa per soluzioni al ribasso

Quanto sopra potrebbe scoraggiare e dissuadere dall’implementare automazioni spinte per quanto riguarda attualizzazione e gestione dei pagamenti in genere. Non deve essere così, anzi, la presenza di standard di qualità da rispettare con sanzioni annesse dovrebbe essere la spinta a migliorare la qualità informatica e la disponibilità dei sistemi, così da porre le basi per realizzare integrazioni sempre più efficaci e complete fra sistemi. Rinunciare alle funzioni che facilitano il lavoro della pubblica amministrazione e che, in ultima analisi, migliorano la qualità dei servizi che eroga, limitarsi al “compitino” per adempiere agli obblighi normativi e mettersi al riparo da punizioni, rischia di essere controproducente se non, addirittura, diabolico.

La necessità di garantire la continuità operativa, soprattutto quando questa attraversa più sistemi, dovrebbe portare a definire standard di interazione semplici e lineari anche fra sistemi sotto la responsabilità di soggetti diversi, che, alla fine, è quello di cui tanto si sente la mancanza, non solo per i pagamenti elettronici.

Foto di Gerd Altmann da Pixabay