Vai al contenuto
XSIS
Una mano che tiene un terminale di pagamento bancario senza fili, in primo piano

Imprese e integrazioni

Connettività bancaria, tesoreria e ISO 20022

Pagamenti in uscita, estratti conto in entrata, riconciliati automaticamente in ogni valuta

I team di tesoreria ridigitano ancora i pagamenti e abbinano gli estratti conto a mano

Molti team di tesoreria inseriscono i pagamenti nei portali bancari, raccolgono estratti conto in formati diversi da ciascuna banca e riconciliano i conti su fogli di calcolo a fine mese. Ogni passaggio manuale è un ritardo, un costo e un’occasione di frode o errore.

Le banche stanno anche passando a ISO 20022, lo standard internazionale per i messaggi finanziari, che trasporta dati strutturati più ricchi rispetto ai vecchi formati SWIFT MT. I sistemi che non sanno produrlo e leggerlo restano indietro rispetto alle proprie banche.

Che cosa cambia per Lei

  1. Elaborazione senza intervento manuale

    I pagamenti approvati escono dall’ERP come file firmati o chiamate API e gli estratti conto tornano in una forma che l’ERP abbina da solo.

  2. Una chiusura più rapida

    Riconciliazione multivaluta che gira ogni giorno, invece di caricamenti CSV manuali e rettifiche su fogli di calcolo a fine mese.

  3. Ogni eccezione con una persona

    Pagamenti respinti e righe non abbinate finiscono in una coda delle eccezioni con il motivo, mai persi in una casella di posta.

Che cosa consegniamo

  • Host-to-host e connettività bancaria diretta

    Connessioni su SFTP, EBICS e SWIFT e API di open banking e bancarie dirette, scelte per banca e per Paese.

  • Generazione dei file di pagamento

    File di pagamento ISO 20022 pain.001 costruiti dalle Sue distinte di pagamento, validati rispetto alla variante di ciascuna banca e firmati o cifrati come richiede.

  • Gestione di stati e rifiuti

    Rapporti di stato pain.002 riletti, così ogni pagamento risulta accettato, respinto o in attesa, con il codice di motivo della banca.

  • Acquisizione degli estratti conto

    Estratti conto di fine giornata camt.053 e MT940 e report infragiornalieri raccolti, controllati per lacune e duplicati e caricati nell’ERP.

  • Messaggistica interbancaria per banche e fintech

    Messaggi pacs per bonifici e il loro stato tra istituti finanziari, collegati ai libri mastri del core banking.

  • Riconciliazione multivaluta

    Regole di abbinamento che chiudono automaticamente le partite aperte tra valute e conti e inviano il resto a una coda delle eccezioni.

  • Evidenze dei test bancari e manuali operativi

    I casi di test di ciascuna banca eseguiti e registrati per i Suoi revisori, e avvisi per file mancanti, bonifici falliti e chiavi o certificati in scadenza.

Come lavoriamo

  1. Mappare banche e flussi

    Elenchiamo le Sue banche, i conti, i tipi di pagamento e i passaggi manuali attuali e concordiamo quali flussi vengono prima.

  2. Specificare ogni formato

    Partiamo dalla guida all’implementazione di ciascuna banca e scriviamo la mappatura, compresi firma, cifratura e denominazione dei file.

  3. Costruire i connettori

    Costruiamo esportazione dei pagamenti, importazione degli stati, importazione degli estratti conto e abbinamento, con test automatizzati per ogni formato.

  4. Collaudare con ogni banca

    Eseguiamo i casi di test concordati nell’ambiente di test della banca e correggiamo ciò che la sua validazione rifiuta.

  5. Andare in produzione banca per banca

    Passiamo una banca alla volta, con il processo attuale pronto come riserva finché il nuovo non è dimostrato.

  6. Monitorare e assistere

    Osserviamo bonifici, chiavi e scadenze dei certificati e pianifichiamo i cambi di formato annunciati dalle banche.

Da ERP a banca: pagamenti in uscita, estratti conto in entrataI pagamenti approvati escono dall’ERP come file ISO 20022 firmati su un canale host-to-host. Rapporti di stato ed estratti conto tornano per la stessa via e sono riconciliati con le partite aperte. Rifiuti e righe non riconciliate arrivano al Suo team con il motivo allegato.ERPERPCicli di pagamento,partite aperte, libromastroXSISLivello diintegrazioneMappatura,validazione, firma epianificazioneGatewayCanale bancariosicuroHost-to-host SFTP,EBICS o API bancariaBancaBancaPagamenti e gestionedella liquiditàServizioMotore diriconciliazioneRegole diabbinamento etolleranzePersoneTeam tesoreria efinanzaEsamina rifiuti edisallineamenti1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002 RJCT910

Da ERP a banca: pagamenti in uscita, estratti conto in entrata

I pagamenti approvati escono dall’ERP come file ISO 20022 firmati su un canale host-to-host. Rapporti di stato ed estratti conto tornano per la stessa via e sono riconciliati con le partite aperte. Rifiuti e righe non riconciliate arrivano al Suo team con il motivo allegato.

  • Flusso principale
  • Asincrono
  • Percorso di eccezione
Il flusso in 10 passi

Il flusso, passo per passo

  1. Da ERP a Livello di integrazione: Ciclo di pagamenti approvato, tramite REST/JSON · IDoc (flusso principale).
  2. Da Livello di integrazione a Canale bancario sicuro: File di pagamento firmato e cifrato, tramite ISO 20022 pain.001 · OpenPGP (flusso principale).
  3. Da Canale bancario sicuro a Banca: Consegnato alla banca, tramite SFTP H2H (flusso principale).
  4. Da Banca a Canale bancario sicuro: Rapporti di stato ed estratti conto, tramite pain.002 · camt.053 · MT940 (asincrono).
  5. Da Canale bancario sicuro a Livello di integrazione: Raccolto e validato, tramite SFTP H2H (asincrono).
  6. Da Livello di integrazione a Motore di riconciliazione: Righe dell’estratto conto, tramite camt.053 (asincrono).
  7. Da Motore di riconciliazione a ERP: Voci riconciliate registrate, tramite REST/JSON (flusso principale).
  8. Da Livello di integrazione a Team tesoreria e finanza: Pagamenti rifiutati, con il codice di motivo, tramite pain.002 RJCT (percorso di eccezione).
  9. Da Motore di riconciliazione a Team tesoreria e finanza: Righe non riconciliate: un disallineamento di riconciliazione (percorso di eccezione).
  10. Da Team tesoreria e finanza a ERP: Corretto e inviato di nuovo (percorso di eccezione).
Open banking: dati e pagamenti con il consenso del clienteIl 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.PersoneClienteServizioLa Suaapplicazione opiattaformaTesoreria, credito ocontabilitàXSISConnettore openbankingConsenso, token enormalizzazione deidatiBancaAPI bancarie oaggregatoreInformazioni sui contie avvio dei pagamentiERPERP o libro mastroPosizione di liquiditàe riconciliazione12REST/JSON3OAuth 2.0 · FAPI · REST4REST/JSON · webhook5REST/JSON6HTTP 401 · 4037

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

  1. Da Cliente a La Sua applicazione o piattaforma: Concede il consenso (flusso principale).
  2. Da La Sua applicazione o piattaforma a Connettore open banking: Richieste sui conti e di pagamento, tramite REST/JSON (flusso principale).
  3. Da Connettore open banking a API bancarie o aggregatore: Chiamate API autorizzate, tramite OAuth 2.0 · FAPI · REST (flusso principale).
  4. Da API bancarie o aggregatore a Connettore open banking: Saldi, transazioni e stato dei pagamenti, tramite REST/JSON · webhook (asincrono).
  5. Da Connettore open banking a ERP o libro mastro: Transazioni normalizzate, tramite REST/JSON (flusso principale).
  6. Da API bancarie o aggregatore a Connettore open banking: Consenso scaduto o revocato, tramite HTTP 401 · 403 (percorso di eccezione).
  7. Da Connettore open banking a La Sua applicazione o piattaforma: Al cliente viene chiesto di rinnovare il consenso (percorso di eccezione).

Standard, formati e canali

Costruiamo dalla guida all’implementazione di ciascuna banca, non solo dallo standard. Citare un prodotto non implica una partnership con il suo fornitore.

Standard e canali bancari
  • ISO 20022
  • pain.001
  • pain.002
  • camt.052
  • camt.053
  • camt.054
  • MT940
  • MT942
  • Swift
  • EBICS
  • SFTP (H2H)
  • OpenPGP
  • PSD2
  • Berlin Group NextGenPSD2
  • UK Open Banking Standard
  • FAPI

Risultati in produzione

Per una banca Tier-1 del GCC e un conglomerato regionale, abbiamo collegato SAP S/4HANA alle infrastrutture bancarie regionali tramite ISO 20022. I pagamenti sono firmati, le eccezioni finiscono nella coda delle eccezioni e la riconciliazione tra i suoi conti bancari è automatica.

Come iniziare

Requisiti chiari su banche e formati portano direttamente a una proposta. Più banche, più Paesi o un’interfaccia legacy non documentata di solito iniziano con il Blueprint Studio o il Brownfield Diagnostic Bridge.

Che cosa succede dopo

  1. Sessione di preconsulenza

    Una sessione di preconsulenza online gratuita di 30 minuti: esaminiamo i Suoi obiettivi, i Suoi sistemi e i Suoi vincoli.

  2. 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.

  3. 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.

  4. Consegna in cinque fasi

    Mobilitazione, sprint con dimostrazioni dal vivo, integrazione e consolidamento, collaudo e go-live, poi servizi gestiti. Dopo il lancio seguono un periodo di garanzia, poi supporto e manutenzione opzionali.

Domande e risposte

Che cos’è ISO 20022 e perché conta?

ISO 20022 è lo standard internazionale per i messaggi finanziari. I suoi messaggi XML trasportano dati strutturati, come nomi completi, indirizzi e dettagli di rimessa, che i vecchi formati SWIFT MT non possono. Banche e sistemi di pagamento vi sono passati, quindi i file di pagamento ed estratto conto costruiti su di esso si riconciliano meglio e superano più spesso i controlli di conformità.

Con quali formati e canali bancari lavorate?

Usiamo pain.001 per i pagamenti, pain.002 per gli stati, camt.052, camt.053 e camt.054 per i report sui conti e messaggi pacs tra banche. Leggiamo anche gli estratti conto MT940 e MT942 che molte banche inviano ancora. Il trasporto è host-to-host SFTP, EBICS, SWIFT o API bancarie. Ogni banca ha la propria variante di ogni formato, quindi costruiamo dalla sua guida all’implementazione.

Quali sistemi ERP potete collegare alle banche?

SAP S/4HANA, Oracle Fusion Cloud ERP e NetSuite, Microsoft Dynamics 365, Odoo e Sage, oltre a sistemi di tesoreria e su misura. Dove l’ERP ha un proprio modulo di comunicazione bancaria, lo configuriamo ed estendiamo invece di costruire intorno.

Come mantenete sicuri i file di pagamento?

I file di pagamento sono firmati e cifrati come richiede ciascuna banca e viaggiano solo sul canale concordato. Chiavi e certificati sono conservati nella Sua cassaforte delle chiavi o nel Suo modulo di sicurezza hardware, mai nel codice. I file sono validati prima dell’invio e ogni trasferimento è registrato, così può tracciare chi ha approvato e inviato ogni pagamento.

Che cosa succede quando una riga di estratto conto non corrisponde?

Finisce in un elenco di revisione con i candidati probabili e il motivo della mancata corrispondenza, come un importo diverso o un riferimento mancante. Il Suo team la chiude lì e le regole possono essere corrette, così lo stesso caso corrisponderà la volta successiva. Nulla viene registrato nel libro mastro senza un abbinamento che Lei ha approvato.

Che cosa determina il ritmo di un’integrazione bancaria?

Soprattutto la banca, non il codice. Ogni banca stabilisce i propri passaggi di onboarding, le finestre di test e le approvazioni, e alcune richiedono contratti o scambi di chiavi prima di poter iniziare i test. Dopo la fase di mappatura Le forniamo un piano per banca e iniziamo a collaudare con la banca pronta per prima.

Che cosa succede quando una banca cambia formato?

Le banche annunciano i cambi di formato in anticipo, come molte hanno fatto passando da SWIFT MT a ISO 20022. Seguiamo questi avvisi per le banche che colleghiamo, valutiamo l’impatto e programmiamo la modifica e i suoi test con la banca prima della scadenza.

Pronto a costruire? Chieda una proposta.

Invii i Suoi requisiti o la Sua RFP. I nostri architetti li validano e restituiscono una proposta vincolante a perimetro fisso.

Che cosa succede dopo

  1. 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.

  2. Proposta vincolante

    Dopo la validazione architetturale senza costi, riceve una proposta vincolante a perimetro fisso entro 3–5 giorni lavorativi: milestone, architettura, struttura del team e SLA. Su richiesta firmiamo con Lei un accordo di riservatezza (NDA) prima che condivida i Suoi requisiti.

  3. Mobilitazione

    Alla firma, i nostri pod di ingegneria iniziano lo Sprint 0 entro 5–10 giorni lavorativi dalla firma del contratto.

  4. Consegna in cinque fasi

    Mobilitazione, sprint con dimostrazioni dal vivo, integrazione e consolidamento, collaudo e go-live, poi servizi gestiti. Dopo il lancio seguono un periodo di garanzia, poi supporto e manutenzione opzionali.