0. Executive summary (1 pagina)

Il Campania Mobility Wallet è un’infrastruttura regionale di bigliettazione e pagamento per la mobilità integrata, concepita come wallet del cittadino (digitale e/o card fisica su richiesta) e wallet turista anonimo (stile Oyster), abilitando:

• Pay‑as‑you‑go su TPL regionale (ferro, metro, bus, funicolari, marittimo dove convenzionato) e servizi integrati (parcheggi, micro‑mobility, navette, escursioni/musei).
• ABT con best fare e fare capping calcolati centralmente.
• Borsellino ricaricabile (anche cash) + crediti pubblici separati (welfare/incentivi).
• Clearing multi‑operatore trasparente e auditabile.
• Layer dati + AI per incentivi dinamici, riduzione evasione, customer care e ottimizzazione servizio.

La proposta è “go big, start smart”: visione ampia e innovativa, ma delivery per fasi con un pilota misurabile e KPI sociali “a contratto”.

1. Obiettivi pubblici e vantaggi sociali

1.1 Obiettivi pubblici

1. Semplificazione: un solo strumento di accesso (app/card) e una sola logica tariffaria percepita.
2. Inclusione: accesso anche per chi non usa smartphone o non ha carta bancaria (card + cash top‑up).
3. Equità: tariffe più eque tramite capping e profili (ISEE/studenti/senior/disabilità/famiglie).
4. Intermodalità: incentivi automatici per Park&Ride e first/last mile.
5. Attrattività turistica: pass integrati trasporto + cultura/escursioni.
6. Efficienza e legalità: meno contante, meno evasione, migliore riparto ricavi, dati per pianificazione.

1.2 KPI sociali prioritari

• Inclusione non‑digitale: % utenti che accedono tramite card fisica + rete ricariche; tempo medio emissione/assistenza.
• Equità (ISEE): riduzione spesa media (o aumento corse) per cluster ISEE, con tetti di spesa (cap) dedicati.
• Aree interne: incremento accessi intermodali (extraurbano + last‑mile) e riduzione tempi percepiti di accesso ai nodi.
• Accessibilità: KPI su UX assistita (lingua, disabilità visive/uditive, semplicità).

2. Esperienza utente e “wallet mode”

2.1 Residenti (account nominativo)

• Onboarding via app o sportello; token: app + card (anche entrambe).
• Profili/agevolazioni come entitlements (diritti digitali) attivati una volta e verificati periodicamente.
• Best fare/capping automatici; trasparenza (spesa, risparmio da cap, crediti usati).

2.2 Turisti (anonimo operativo)

Obiettivo: “come Oyster” = semplice, immediato, senza burocrazia.

• Attivazione in app o presso punti fisici (aeroporto/porto/stazioni) con borsellino pre‑caricato.
• Bundle (48h/72h/7gg) + sconti musei/escursioni; rimborsi con regole semplici.
• Compliance by design: soglie, limiti e controlli antifrode; upgrade a light‑account oltre soglie.

3. Principi architetturali (anti lock‑in, anti fallimento)

1. ABT first: tariffazione nel back‑office, token “stupidi” ma sicuri.
2. Interoperabilità: API pubbliche/versionate, standard dove possibile, adattatori per legacy.
3. Privacy‑by‑design: pseudonimi, minimizzazione, separazione identità↔token.
4. Resilienza offline: fallback e riconciliazione.
5. Misurabilità: KPI tecnici e sociali nativi nel data platform.
6. Sicurezza: gestione chiavi, anti‑replay, audit, monitoraggio e incident response.

4. Architettura di riferimento (high level)

4.1 Componenti principali

Back‑office ABT

• Identity & Entitlements (profili, agevolazioni, family/group)
• Event Ingestion Hub (online/offline buffering, deduplica, firma eventi)
• Fare Engine (best fare, capping, correzioni e dispute)
• Payments Orchestrator (borsellino + eventuali metodi esterni)
• Clearing House (riparto ricavi, audit, settlement)
• Incentives & Rules Engine (P+R, last‑mile, off‑peak, campagne)
• Partner Marketplace (catalogo servizi convenzionati + settlement)
• Customer Care & Dispute (workflow, SLA, rimborsi)
• Observability & Security (logging, anomaly detection, incident response)

Data Platform & AI

• Data lake/warehouse (eventi, corse, KPI)
• ML: antifrode, domanda, suggerimenti, incentivi dinamici
• AI responsabile: explainability, fairness, audit

4.2 Flusso eventi (semplificato)

1. Validatore genera evento (tap/scan) con token pseudonimo + firma dispositivo.
2. Event Hub valida, deduplica, normalizza e arricchisce (linea, stop, zona, contesto).
3. Fare Engine costruisce journey e applica regole/capping.
4. Addebito su Money Ledger e/o consumo crediti su Public Credit Ledger.
5. Clearing House calcola riparto e produce settlement per operatori e partner.
6. Data platform calcola KPI e alimenta incentivi/AI.

5. Token: card chip + app (anti‑frode, velocità, inclusione)

5.1 Card fisica (chip contactless)

Raccomandazione: card chip contactless (standard trasporto) per velocità di validazione, robustezza e sicurezza. Nota: “chip contactless” è spesso chiamato impropriamente NFC; non richiede smartphone.

5.2 App (QR dinamico / device binding)

• QR dinamico a rotazione (anti‑screenshot/anti‑replay), con firma e TTL breve.
• Device binding opzionale e revoca token in caso di frode o furto.

5.3 Token per turista anonimo

• Token anonimo operativo con limiti (saldo massimo, rimborsi, recupero credenziali).
• Upgrade possibile (light account) per assistenza o superamento soglie.

6. Borsellino e crediti pubblici (separati per design)

6.1 Due ledger separati

1. Money Ledger: saldo ricaricabile (cash/online), usato per servizi a pagamento.
2. Public Credit Ledger: crediti regionali/comunali (bonus, campagne) vincolati a categorie e modalità.

6.2 Ricariche cash e rete territoriale

Elemento sociale chiave: rete capillare di ricarica (tabacchi/edicole/sportelli) per includere unbanked e anziani.

6.3 Compliance e partner regolato

Per ridurre rischio e tempi: componente “stored value” con partner regolato, mantenendo policy pubblica su tariffe, incentivi e profili sociali, e portabilità contrattuale (anti lock‑in).

7. Fare engine: best fare, capping, profili, casi difficili

7.1 Best fare e capping

• Calcolo a fine giornata/settimana/mese (secondo regole).
• Trasparenza: “sei già in cap”, “hai risparmiato X”.

7.2 Profili sociali (entitlements)

• Attivazione/revoca governate, con audit e verifiche periodiche.
• Family/group: capping famiglia e anti‑passback.

7.3 Tap‑out e incomplete journeys

• Gate/ferro: tap‑in/out dove presente.
• Bus: tap‑in obbligatorio; tap‑out opzionale con inference (geofence/linea/stop), correzione utente entro finestra e policy anti‑abuso (scoring, controlli, limiti).

7.4 Dispute e rimborsi

• Workflow standard: correzione viaggio, contestazione addebito, rimborsi per disservizio.
• Regole chiare e comunicabili (essenziale per fiducia).

8. Clearing house e settlement (cuore politico‑tecnico)

8.1 Perché è critico

Senza clearing credibile, gli operatori non cooperano e l’integrazione fallisce.

8.2 Metodi di riparto (da definire in Fase 0)

• OD matrix su tap‑in/out
• quote zonali per tratte bus (con coefficienti)
• regole specifiche per servizi ancillari (parcheggi/micro‑mobility/cultura)

8.3 Audit e trasparenza

• Report mensili, controlli incrociati, campionamenti e tracciabilità delle regole applicate.

9. Ecosistema “tutto incluso” (parcheggi, micro‑mobility, musei, escursioni)

9.1 Parcheggi & Park&Ride

• Sconto automatico o crediti mobilità se parcheggio→TPL entro X minuti.
• Incentivi calibrati per ridurre congestione e aumentare accesso ai nodi.

9.2 Micro‑mobility (first/last mile)

• Credito last‑mile legato a viaggio TPL (policy pubblica misurabile).
• Riduzione barriere in aree con scarsa capillarità.

9.3 Cultura/escursioni

• Voucher/bundle nel wallet; un checkout; settlement separato.
• Sconti condizionati (es. sconto museo se arrivi in TPL).

10. Data platform & AI (innovazione con i piedi per terra)

10.1 AI Mobility Companion (per utenti)

• Suggerimenti proattivi (meteo, eventi, disservizi).
• Alternative più sostenibili/economiche con trasparenza (“perché te lo suggerisco”).
• Notifiche: “sei già in cap”, “sconto P+R attivo”, “credito last‑mile disponibile”.

10.2 AI per Regione e operatori

• Antifrode: anomalie, pattern evasione, abuso correzioni, replay QR.
• Demand forecasting: picchi per eventi/stagionalità; supporto a pianificazione servizio.
• Ottimizzazione rete: analisi interscambi e colli di bottiglia; simulazioni incentivi.
• Customer care assistito: triage richieste e risposta guidata (con audit e policy).

10.3 AI responsabile e GDPR

• DPIA e policy; logging delle decisioni automatiche.
• Fairness (non penalizzare aree/cluster sociali).
• Opt‑in per funzionalità “companion” dove opportuno.

11. Sicurezza, privacy e resilienza (requisiti minimi)

11.1 Privacy‑by‑design

• Token pseudonimo; separazione identità; minimizzazione e retention.
• Accesso dati per pianificazione in forma aggregata/anonimizzata.

11.2 Sicurezza tecnica

• Gestione chiavi e firma eventi (device trust).
• Anti‑replay (QR dinamici), revoca token, black/grey lists.
• Protezione API, rate limiting, monitoraggio e incident response.

11.3 Offline & continuità

• Buffer eventi su device e sync; strategie di fallback per categorie di servizio.

12. Governance e procurement (opzioni)

Modello A — Regione owner + outsourcing ops

Pro: massimo controllo su policy sociali/dati/KPI. Contro: richiede PMO forte.

Modello B — Consorzio tariffario regionale integratore

Pro: neutralità, ruolo naturale su clearing. Contro: potenziamento tech/cyber.

Modello C — PPP/concessione con KPI stringenti

Pro: rapidità e trasferimento rischio. Contro: lock‑in (mitigare con API e exit plan).

13. Roadmap (proposta)

Fase 0 (8–12 settimane)

Tavolo inter‑assessorile + studio fattibilità + requisiti gara + KPI sociali + baseline.

Fase 1 (6–9 mesi) — Pilota misurabile

Area metropolitana + nodi; Park&Ride + micro‑mobility; turista anonimo; primi bundle cultura.

Fase 2 (12–24 mesi) — Scala regionale

Estensione regionale; clearing completo; rete ricariche; ampliamento convenzionati e incentivi.

Fase 3 (24–36 mesi) — Maturità

Ottimizzazione AI, automazione rimborsi, marketplace completo, miglioramento continuo.

14. Prossimi passi

1. Mandato a costituire tavolo inter‑assessorile (Trasporti, Turismo, Welfare, Innovazione).
2. Avvio Fase 0 con deliverable e timeline.
3. Scelta 3 KPI sociali “a contratto”.
4. Scelta perimetro pilota (territorio + operatori + nodi + 3–5 convenzionati chiave).