Quale modalità di integrazione Shufti è più adatta al tuo stack? API, SDK e client web spiegati.

Secondo il report State of the API 2024 di Postman, il 43% degli sviluppatori identifica l'integrazione delle API come l'attività di sviluppo che richiede più tempo. Per i team che aggiungono la verifica dell'identità a un prodotto regolamentato, una scelta di integrazione errata non solo rallenta la consegna, ma crea anche lacune di conformità che si rivelano costose da colmare in seguito.

Shufti offre cinque diverse modalità di integrazione, ciascuna progettata per una diversa combinazione di requisiti tecnici, vincoli di implementazione e tempistiche di messa in produzione. Questa guida illustra come ogni modalità si adatta meglio allo scenario, consentendo al team di prendere una decisione una volta per tutte e procedere con la messa in produzione.

Perché il binario SDK o API non coglie il punto?

La maggior parte dei contenuti sulla verifica dell'identità rivolti agli sviluppatori inquadra la decisione di integrazione in termini binari: SDK o API. Questa impostazione ignora altre tre modalità che esistono proprio perché non tutti i prodotti sono servizi di backend e non tutti i team hanno a disposizione settimane di tempo per lo sviluppo.

L'architettura di integrazione di Shufti è costruita attorno alla distribuzione reale di prodotti che necessitano di verifica: app native per dispositivi mobili, flussi di onboarding basati sul web, stack di conformità senza codice e implementazioni aziendali con requisiti di sovranità dei dati. Ogni modalità si adatta a uno di questi contesti. L'API RESTful non è intrinsecamente migliore del client web; è più adatta a un tipo specifico di team che sviluppa un tipo specifico di prodotto.

Le cinque modalità di integrazione di Shufti

1. API RESTful

L'API RESTful di Shufti offre al tuo backend il controllo completo sul flusso di lavoro di verifica. Il tuo server invia una richiesta di verifica, Shufti la elabora e i risultati vengono restituiti in modo asincrono tramite webhook (payload HTTP POST consegnati al tuo endpoint una volta completato il controllo). Lo stesso endpoint API copre tutti i prodotti Shufti: verifica dei documenti, corrispondenza facciale, AML screening, KYB e altri ancora.

Utilizza questa opzione quando: hai bisogno di verifica server-to-server, elaborazione batch o stretto accoppiamento con il tuo livello di orchestrazione esistente. Gli ingegneri backend delle aziende fintech e dei servizi finanziari in genere scelgono questa strada quando la logica di verifica deve risiedere all'interno della loro gestione del ciclo di vita dell'utente anziché sul lato client. Il livello di complessità tecnica è il più elevato tra le cinque modalità, ma lo è anche il grado di controllo. Oltre l'83% dei carichi di lavoro aziendali si basa sulle API per la comunicazione dei dati e l'automazione.e l'API di Shufti è progettata per integrarsi in tale infrastruttura fin dal primo giorno.

2. SDK per dispositivi mobili

SDK per dispositivi mobili di Shufti Sono disponibili per Android, iOS, Flutter, React Native e Cordova. Gestiscono l'acquisizione di documenti, il rilevamento della vitalità e la biometria facciale direttamente sul dispositivo, trasmettendo i risultati elaborati alla pipeline di verifica di Shufti.

Utilizzalo quando: stai creando un'applicazione mobile nativa e la qualità dell'acquisizione biometrica è una priorità. Gli SDK mobili accedono direttamente alla pipeline della fotocamera del dispositivo, il che significa che possono rilevare attacchi di iniezione e presentazione della fotocamera a un livello che i canali basati su browser non possono eguagliare. Ciò si allinea con i principi di garanzia dell'autenticatore in NIST SP 800-63Bche riconoscono l'accesso nativo al dispositivo come il canale più efficace per la verifica biometrica. L'SDK gestisce l'esperienza utente di acquisizione; la tua applicazione gestisce il flusso della sessione.

3. Client Web (Pagina di verifica personalizzata / iFrame)

Il client web ospitato di Shufti è un flusso di verifica predefinito che si integra in una sessione del browser tramite iFrame. Shufti Gestisce l'interfaccia utente, l'acquisizione di documenti e dati biometrici e la consegna dei risultati. Al termine della verifica, riceverai un webhook, senza dover creare o gestire autonomamente l'interfaccia utente di verifica.

Utilizzalo quando: hai bisogno di un flusso di onboarding basato sul web e vuoi evitare di creare e mantenere un'interfaccia utente di verifica. Questo è in genere il percorso più veloce per i prodotti web: l'integrazione richiede giorni anziché settimane, gli obblighi di gestione dei dati ai sensi Articolo 32 del GDPR La gestione avviene lato Shufti e non è necessaria la creazione di un SDK per dispositivi mobili. Il livello di difficoltà tecnica è da basso a medio.

4. Journey Builder

Costruttore di viaggi è il configuratore di flussi di verifica senza codice di Shufti. I team di conformità e i responsabili delle operazioni possono assemblare flussi di lavoro di verifica in più fasi (controllo dei documenti, corrispondenza facciale, AML screening, verifica dell'indirizzo) da un'interfaccia visiva, senza scrivere una riga di codice.

Utilizzalo quando: devi implementare o iterare rapidamente un flusso di verifica e la capacità di ingegneria è il vincolo, non la fattibilità tecnica. È anche la scelta giusta per i team che necessitano di più flussi specifici per il mercato: diversi paesi, diversi tipi di documenti, diverse watchlist AML, tutti configurabili indipendentemente. Libreria Journey Builder Include flussi preconfigurati che coprono oltre 30 mercati. Tempo di messa in produzione: da poche ore a un giorno per la prima implementazione.

5. On-premise

La soluzione di implementazione On-Premises di Shufti esegue l'intero stack di verifica all'interno della tua infrastruttura. Nessun dato di verifica esce dal tuo ambiente. Si applica la stessa interfaccia API RESTful e mantieni il pieno controllo sul livello di elaborazione, sulla residenza dei dati e sulla tracciabilità delle operazioni.

Utilizzare questa opzione quando: la sovranità dei dati è un requisito imprescindibile. Banche e istituzioni finanziarie in giurisdizioni con rigidi obblighi di residenza dei dati, o imprese soggette a normative settoriali che limitano il trasferimento dei dati nel cloud, utilizzano questa soluzione. Il tempo di implementazione è il più lungo tra le cinque modalità, ma il livello di sicurezza è anche il più elevato: l'esposizione dei dati nel cloud viene completamente eliminata.

Scegliere la modalità giusta: un quadro pratico

Due domande restringono rapidamente la scelta.

• Innanzitutto, dove risiede il tuo prodotto? Le app native per dispositivi mobili utilizzano il Mobile SDK. I prodotti basati sul Web utilizzano di default il Web Client o l'API RESTful. I team senza personale di sviluppo possono iniziare con Journey Builder. Le aziende soggette a normative che impongono la residenza dei dati necessitano di una soluzione On-Premises.
• In secondo luogo, quanto tempo di sviluppo è disponibile? Se la tempistica si misura in ore, Journey Builder è l'opzione più realistica. Da pochi giorni a una settimana: client Web o API. Da una a due settimane: API o SDK mobile. Implementazione aziendale a tempo indeterminato: locale.

I team che integrano la verifica dell'identità (KYC) in un prodotto finanziario spesso iniziano con il client Web per una rapida messa in produzione conforme, per poi migrare all'API una volta che il flusso di lavoro principale è stato collaudato. Una guida più ampia alla pianificazione di questo ciclo di vita è disponibile in Integrazione KYC Strategie per un onboarding agevole e conforme alle normative.

Utilizzo simultaneo di più modalità

L'utilizzo di più di una modalità di integrazione Shufti in un singolo prodotto è comune e previsto dall'architettura. Un'applicazione per servizi finanziari potrebbe eseguire il Web Client per l'onboarding basato su browser, il Mobile SDK all'interno della sua app nativa e l'API RESTful per il ricontrollo AML in background, con tutti e tre connessi alla stessa piattaforma, dashboard e dati di conformità. Per un'analisi più approfondita del funzionamento del livello API all'interno di un contesto più ampio servizi di verifica dell'identità pila, vedi API KYCChe cos'è, come funziona, integrazione e casi d'uso.