API di open banking
Open banking: dati dei conti e pagamenti tramite API bancarie
Informazioni sui conti e avvio di pagamenti tramite API bancarie regolamentate e aggregatori, con gestione di consensi e token.
Blueprint
Scorra lateralmente per vedere l’intero disegno.
Open banking: dati e pagamenti con il consenso del cliente
Il cliente concede il consenso, il connettore conserva i token e ogni chiamata alla banca è autorizzata e registrata. Quando il consenso scade o viene revocato, l’app lo richiede di nuovo al cliente invece di fallire in silenzio.
- Flusso principale
- Asincrono
- Percorso di eccezione
Il flusso in 7 passi
Il flusso, passo per passo
- Da Cliente a La Sua applicazione o piattaforma: Concede il consenso (flusso principale).
- Da La Sua applicazione o piattaforma a Connettore open banking: Richieste sui conti e di pagamento, tramite REST/JSON (flusso principale).
- Da Connettore open banking a API bancarie o aggregatore: Chiamate API autorizzate, tramite OAuth 2.0 · FAPI · REST (flusso principale).
- Da API bancarie o aggregatore a Connettore open banking: Saldi, transazioni e stato dei pagamenti, tramite REST/JSON · webhook (asincrono).
- Da Connettore open banking a ERP o libro mastro: Transazioni normalizzate, tramite REST/JSON (flusso principale).
- Da API bancarie o aggregatore a Connettore open banking: Consenso scaduto o revocato, tramite HTTP 401 · 403 (percorso di eccezione).
- Da Connettore open banking a La Sua applicazione o piattaforma: Al cliente viene chiesto di rinnovare il consenso (percorso di eccezione).
Panoramica
L’open banking consente a un’applicazione di leggere i conti di un cliente e di avviare pagamenti tramite API bancarie regolamentate, con il consenso del cliente. Abilita l’aggregazione dei conti, le verifiche di sostenibilità per il credito, i checkout pay-by-bank e le viste di tesoreria su più banche.
Il progetto di riferimento inserisce un connettore di open banking tra la Sua applicazione e le banche, direttamente o tramite un aggregatore autorizzato. Il connettore gestisce il percorso del consenso, custodisce i token in modo sicuro, chiama le API bancarie secondo standard come Berlin Group NextGenPSD2 o lo UK Open Banking Standard e converte i dati di ogni banca in un unico modello coerente.
Il consenso non è permanente, e il progetto lo prevede. Quando un consenso scade o viene revocato, al cliente viene chiesto di rinnovarlo, invece che l’applicazione perda i dati senza avvisare. Ogni chiamata è autorizzata, registrata e collegata al consenso che l’ha resa possibile.
Come funziona il flusso
Il cliente concede il consenso
Il cliente sceglie la propria banca, vede quali dati sono condivisi e per quanto tempo, e si autentica presso la banca, che reindirizza alla Sua applicazione.
La Sua applicazione chiede
La Sua applicazione richiede saldi, transazioni o un pagamento tramite l’API del connettore, mai direttamente alla banca.
Il connettore chiama la banca
Il connettore usa i token memorizzati per effettuare chiamate autorizzate all’API della banca o all’aggregatore, seguendo il profilo di sicurezza richiesto dalla banca.
Arrivano dati e stato
Saldi, transazioni e stato dei pagamenti tornano come risposte o webhook, e il connettore li normalizza in un unico modello valido per tutte le banche.
Usare i dati
Le transazioni normalizzate alimentano il Suo prodotto, i Suoi modelli di rischio o il Suo ERP per le posizioni di liquidità e la riconciliazione.
Quando qualcosa fallisce
Un consenso scade o viene revocato
La banca rifiuta la chiamata. Il connettore segna il consenso come non più valido e la Sua applicazione chiede al cliente di rinnovarlo, spiegandone il motivo.
Un pagamento viene rifiutato
Lo stato e il motivo indicati dalla banca tornano tramite l’API o un webhook, e il cliente e il Suo team operativo vedono subito l’esito.
Una banca limita l’accesso
Le banche limitano la frequenza con cui si possono leggere i dati senza il cliente presente. Il connettore pianifica gli aggiornamenti entro questi limiti e rallenta quando la banca lo segnala.
L’API di una banca non è disponibile
Le chiamate vengono ritentate con attese crescenti, l’ultimo dato valido è mostrato con la sua data, e viene inviato un avviso se l’interruzione prosegue.
Standard e sistemi
- Standard e canali bancari
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- Integrazione
- REST
- Webhooks
- Identità e accesso
- OAuth 2.0
- OpenID Connect
Domande e risposte
Conviene collegarsi alle banche direttamente o tramite un aggregatore?
Un aggregatore offre molte banche tramite un’unica API e gestisce le differenze di ciascuna, con un costo per chiamata o per connessione. Le connessioni dirette danno più controllo e possono adattarsi a un numero ridotto di banche importanti. Molti prodotti partono da un aggregatore e aggiungono connessioni dirette in seguito. Confrontiamo le opzioni in base alle banche e ai Paesi di cui ha bisogno.
Serve un’autorizzazione per usare l’open banking?
Le informazioni sui conti e l’avvio di pagamenti sono attività regolamentate in molti Paesi. O la Sua azienda detiene l’autorizzazione, oppure opera tramite un fornitore autorizzato che la detiene. Quale delle due si applica dipende dal Suo Paese e dal caso d’uso, e i Suoi consulenti legali e di conformità dovrebbero confermarlo. Realizziamo l’integrazione per il percorso che sceglie.
Come viene gestito il consenso del cliente?
Il cliente vede quali dati sono condivisi, per quale finalità e per quanto tempo, e si autentica presso la propria banca. Il connettore memorizza il consenso e i relativi token in forma cifrata, e ogni chiamata è collegata a un consenso valido. I clienti possono revocare il consenso, e il connettore smette di chiamare quella banca per loro quando lo fanno.
Quali banche e quali Paesi sono coperti?
La copertura dipende dalle norme della regione e dalle API delle banche. L’Unione europea e il Regno Unito hanno una copertura ampia con PSD2 e lo UK Open Banking Standard. Altrove la copertura varia, e gli aggregatori colmano parte delle lacune. Verifichiamo la copertura per le banche usate dai Suoi clienti prima che Lei si impegni su un progetto.
L’open banking sostituisce le connessioni bancarie host-to-host?
Non per la maggior parte del lavoro di tesoreria aziendale. I canali host-to-host gestiscono file di pagamento in lotti ed estratti conto completi dei conti aziendali. L’open banking si adatta ai prodotti rivolti ai clienti, ai saldi in tempo reale e ai pagamenti singoli. Molte aziende usano entrambi: host-to-host per i propri pagamenti e open banking per i propri clienti.
Come vengono protetti i dati dell’open banking?
Token e registrazioni dei consensi sono cifrati a riposo, solo il connettore può usarli, e ogni chiamata è registrata con il consenso che la sostiene. Raccolgiamo solo i dati necessari alla finalità e stabiliamo per quanto tempo vengono conservati. A questi dati si applicano norme sulla protezione dei dati come il GDPR, e progettiamo insieme al Suo responsabile della protezione dei dati.
Inizi con una conversazione, non con un contratto.
Ci racconti che cosa deve costruire, collegare o proteggere. Un architetto lo esamina con Lei e poi consiglia da dove iniziare.
Che cosa succede dopo
Concordare un orario
Il nostro team Le invia un’e-mail per concordare un orario per la sessione.
Sessione di preconsulenza
Una sessione di preconsulenza online gratuita di 30 minuti: esaminiamo i Suoi obiettivi, i Suoi sistemi e i Suoi vincoli.
Revisione di preparazione
Nell’ambito di una revisione di preparazione gratuita di 48 ore, un architetto principal verifica il Suo progetto rispetto alla definizione di «pronto» in 6 punti e raccomanda il Track più adatto.
Scelta del Track
I progetti con perimetro definito ricevono una proposta vincolante entro 3–5 giorni lavorativi. I progetti in fase di concept iniziano nel Blueprint Studio. Un sistema in produzione che non funziona, non è documentato o richiede integrazione inizia con una diagnosi di 1–2 settimane. Il Blueprint Studio e la diagnosi hanno ciascuno un compenso fisso, indicato nella proposta.