Välj språk
Fintech och utlåning
Identitetsverifiering av låneansökare som körs i webbläsaren eller appen, fångar en lånad eller syntetisk identitet innan den når kreditbedömningen och skriver varje kontroll till ett register som du kan lämna till en tillsynsmyndighet eller revisor. Körs på våra egna servrar i Kanada, aldrig i ett publikt moln. Sandbox-sessioner faktureras 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 Social Security-nummer som alla stämmer på pappret. Dokumentet bakom dem är en stulen eller köpt identitet, eller fält som sytts ihop 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, däribland OFAC, ä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 vi inte har förtjänat. Det som går att verifiera i dag: egenhanterad drift på våra egna servrar i Kanada, inte i ett publikt moln, automatisk radering av bilder, krypterade bilder i vilolage och en liggare där poster bara kan läggas till och som går att läsa i produkten.
"Uppfyller detta vårt Customer Identification Program eller våra AML-skyldigheter?"
ShieldID ger en dokumenterad, upprepbar identitetskontroll med ett register bakom sig, underlag som ditt kundidentifieringsprogram kan använda. Om det uppfyller en specifik regulatorisk metod är något ditt eget efterlevnadsprogram och din juridiska rådgivare avgör; vi lämnar ingen juridisk rådgivning, och vi påstår inte att det 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 kommer från en delstat vi sällan ser?"
Det läses fält för fält mot sin egen streckkod i stället för att avvisas direkt, och täckningen omfattar alla 50 delstater, District of Columbia och fem amerikanska territorier. Det är precis där regelbaserade skannrar tenderar att låsa ute riktiga sökande.
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.