Välj språk
Fintech och utlåning
Identitetsverifiering av låneansökande som körs i webbläsaren eller appen, upptäcker lånade eller syntetiska identiteter innan de når kreditgivningen och skriver varje kontroll till en post som kan lämnas till en tillsynsmyndighet eller revisor. Driftas i en infrastruktur som vi kontrollerar. Sandbox-sessioner debiteras aldrig.
Problemet
En kreditprodukt som godkänner på några minuter behöver en identitetskontroll som hänger med, utan att bli en manuell granskningskö.
Ett namn, ett födelsedatum, en adress och ett SIN som alla stämmer på papperet. Dokumentet bakom är en stulen eller köpt identitet, eller fält ihopsatta från flera verkliga personer.
Varje ansökan som teamet inte kan godkänna automatiskt blir en person som öppnar en PDF, kisar på ett foto-ID och gissar. Det är långsamt, ojämnt mellan granskare och skalar inte med marknadsföringsbudgeten.
Månader efter att ett lån har bokförts frågar någon hur låntagarens identitet bekräftades. ”Vi tittade på ett foto av körkortet” är inte ett svar som en compliance-ansvarig vill behöva ge två gånger.
Ett praktiskt exempel
Fiktivt, för att visa flödets utformning. Ingen verklig sökande, långivare eller lån förekommer.
Det som är viktigast vid kreditgivning
Varje kontroll nedan körs vid varje verifiering. Ingenting är en betalnivå som man måste komma ihåg att slå på.
För tvister och revisioner
Ett kreditärende öppnas på nytt: en låntagare bestrider ett avslag, en granskare tar stickprov på en fjärdedel av ansökningarna, en intern revision frågar vem som gjorde vad. Aktivitetsregistret är där det samtalet börjar.
Poster kan läggas till. De kan inte redigeras eller raderas, varken av teamet eller av ShieldID. Det är en egenskap hos själva databasen, inte en policy som någon i tysthet kan åsidosätta.
Varje post registrerar aktören (en person eller en API-nyckel), åtgärden, utfallet och tidsstämpeln, så att frågan ”vem verifierade den här sökanden och vad rapporterade motorn” får ett direkt svar i stället för en rekonstruerad gissning.
Filtrera på aktör, åtgärd, utfall eller datumintervall för att hämta exakt de poster som en compliance-granskning eller en låntagartvist behöver, i stället för att exportera allt och maskera för hand.
I dag registrerar liggaren godkända och misslyckade verifieringsutfall, inloggningar och aktivitet med API-nycklar samt granskningsexporter. Händelser per visning och per nedladdning för ID-bilder, en dedikerad beslutshändelse, rensningskvitton och en CSV-export i självbetjäning för ditt team kommer snart.
Integrationsalternativ
De flesta kreditgivningsteam börjar med det värdbaserade flödet på den punkt där de annars skulle be om en dokumentuppladdning, och går över till API:et när volymen motiverar det.
Rakt på sak
Värt att säga rakt ut, eftersom en köpare inom fintech kommer att fråga.
Det besvarar en fråga väl: är detta en verklig person som håller i sin egen äkta myndighetsutfärdade ID-handling. Det ligger under kreditreglerna, kreditupplysningen och den egna bedrägerimodellen, inte i stället för dem.
Sanktions- och bevakningslistekontroller är tillgängliga för konton som lägger till dem. De ingår inte som standard i alla abonnemang.
ShieldID verifierar inte bankkonton eller inkomst i dag, den funktionen är på väg. Om ert program behöver den nu, kombinera ShieldID:s identitetskontroll med er befintliga leverantör av bank- eller inkomstverifiering.
Integritetsnoteringar
En låneansökandes ID är känsligt i sig. Så här går det till med det, exakt.
Jämfört med det manuella sättet
En jämförelse på kategorinivå, inte ett påstående om någon specifik leverantör.
| Funktion | ShieldID | Typisk IDV för storföretag | Manuella kontroller |
|---|---|---|---|
| Dokumentet läses och korskontrolleras mot ansökan | Ja | Oftast | Granskarens eget omdöme |
| Livenessutmaning, inte bara en statisk selfie | Ja | Oftast | Nej |
| Varje bedrägerisignal rapporteras för sig | Ja | Ofta i nivåer | Spåras inte |
| Enhetlig standard för varje granskare, varje skift | Ja | Oftast | Nej |
| Activity Ledger som endast kan utökas och går att söka i vid en tvist | Ja | Erbjuds inte kunden | En e-posttråd, om man har ttur |
| I den sökandes egen takt, ingen manuell kö att vänta i | Ja | Oftast | Nej |
| Sandbox som aldrig faktureras | Ja | Ibland | n/a |
Invändningar
”Var är SOC 2- och ISO-märkena?”
Vi har dem inte ännu, och vi visar inte upp sådana som vi inte har förtjänat. Det du kan verifiera i dag: egenhanterad drift, inte offentligt moln, automatisk bildrensning, krypterade bilder i vila och en liggare som endast kan utökas och som du kan läsa i produkten.
”Uppfyller detta våra skyldigheter om identitetsverifiering enligt FINTRAC eller AML?”
ShieldID ger dig en dokumenterad, upprepbar identitetskontroll med ett register bakom sig. Om den uppfyller en viss regulatorisk metod är något som ditt eget compliance-program och dina juridiska rådgivare avgör – vi ger inte juridisk rådgivning och vi säger inte att något redan är avbockat.
”Vårt bedrägeriteam vill ha verifiering av bankkonton också.”
Finns inte i ShieldID i dag, men är på väg. Kombinera tills vidare ShieldID:s identitetskontroll med ert befintliga verktyg för bank- eller inkomstverifiering. Vi låtsas inte täcka detta nu.
”Vad händer om sökandens ID är obekant – till exempel en nyanländs utländska körkort?”
Dokumentet läses fält för fält i stället för att avvisas direkt, och det är precis där regelbaserade skannrar brukar stänga ute riktiga sökande. Du ser vad som verifierades och vad som inte gjorde det, per fält.
Det här ser du
Låntagaren verifierar sig under ansökan. Ditt team ser varje fälts källa och varje kontroll för sig, inte ett enda poängvärde att lita på eller ignorera.
Frågor
Kom igång
Skapa en sandbox-session, kör en verifiering på din egen telefon och se posten som skrivs till aktivitetsregistret.
Sandbox-sessioner debiteras aldrig.