E-signature
Identitetsverifiering för e-signering, innan någon signerar
En signatur är bara så tillförlitlig som identiteten bakom den. ShieldIDs API för verifiering av undertecknares identitet bekräftar att en verklig person, med sin egen myndighetsutfärdade legitimation, är den som slutför dokumentet – med kontrollen införd i registret vid sidan av själva signaturen.
Problemet
”De klickade på länken” är inte detsamma som ”de signerade”
De flesta e-signeringsplattformar bekräftar att någon öppnade ett e-postmeddelande och skrev ett namn. Det är autentisering av en inkorg, inte identifiering av en person.
En e-postlänk bevisar en inkorg, inte en person
Alla som kan öppna e-postmeddelandet – en delad inkorg, ett vidarebefordrat meddelande, ett kapat konto – kan klicka sig vidare och skriva ett namn i en signaturruta.
Dokument av högt värde kräver mer än en kryssruta
Ett hyresavtal, ett låneavtal, en förlikning eller en fullmakt får verkliga konsekvenser. Ett ”jag godkänner” som skrivits av en overifierad part är en svag grund för något som betyder så mycket.
När det ifrågasätts senare finns det ofta inget att visa upp
Om en undertecknare senare hävdar att någon annan signerade å dennes vägnar visar de flesta e-signeringars granskningsloggar en IP-adress och en tidsstämpel – inte en myndighetsutfärdad legitimation som kontrollerats mot ett levande ansikte.
Ett praktiskt exempel
Ett kommersiellt hyresavtal, redo för två signaturer
Fiktivt, för att visa flödets uppbyggnad. Ingen verklig hyresgäst, hyresvärd eller något verkligt hyresavtal är inblandat.
Dokumentet skickas
En fastighetsförvaltare skickar ett kommersiellt hyresavtal för signering via sin e-signeringsplattform. Innan signeringsskärmen visas omdirigerar plattformen hyresgästen till en ShieldID-verifieringssession kopplad till just det dokumentet.Registrering på undertecknarens telefon
Hyresgästen fotograferar körkortets fram- och baksida och genomför en kort guidad livenessutmaning. Streckkoden och de tryckta fälten korskontrolleras; det levande ansiktet matchas mot porträttet i dokumentet.Bedrägerisignaler körs i varje session
Kontroller av förfalskning (anti-spoof), deepfake, mask och dokumentmanipulation körs automatiskt – inte en inställning som e-signeringsplattformen måste komma ihåg att aktivera för ett dokument av högre värde.Tillbaka till dokumentet, verifierat
ShieldID skickar tillbaka hyresgästen till plattformens retur-URL med resultatet bifogat och levererar samma resultat via signerad webhook. Först nu låter plattformen signeringssteget gå vidare.Två register, sida vid sida
E-signeringsplattformens egen granskningslogg visar signaturhändelsen. ShieldIDs Activity Ledger visar identitetskontrollen som föregick den – vem som verifierades, vad motorn rapporterade och när – en post som endast kan läggas till och som upprätthålls av databasen.
Det som är viktigast före en signatur
Bekräfta personen, inte bara inkorgen
Varje kontroll nedan körs vid varje verifiering, oavsett vilket dokument det gäller.
Ansiktsmatchning och liveness
Bedrägerisignaler
Aktivitetslogg
Signerade webhooks och en retur-URL
Bevakningslistkontroll
För tvister och revisioner
När en signatur ifrågasätts finns identitetskontrollen också i registret
En undertecknare bestrider senare ett dokument. En processjurist ber om bevis på vem som faktiskt signerade. En tillsynsmyndighet granskar din kundidentifieringsakt. Identitetskontrollen bakom signaturen är där samtalet börjar.
Endast tillägg, upprätthållet av databasen
Poster kan läggas till. De kan inte redigeras eller raderas – varken av dig eller av ShieldID. Det är en egenskap hos själva databasen.
Identitetskontrollen, skild från signaturhändelsen
ShieldIDs liggare registrerar verifieringen som genomfördes före signeringen – vem som kontrollerades, vad motorn rapporterade, när – som en egen post, skild från e-signeringsplattformens egen registrering av klicket.
Sökbar på aktör, åtgärd, utfall och datum
Hämta exakt de poster som en tvist eller en granskning kräver, i stället för att manuellt rekonstruera en tidslinje från två olika system.
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
Ett verifieringssteg, före signering
Hostad verifieringssida
Signerade webhooks
Ett REST API
Sandbox, faktureras aldrig
Redan i produktion
Detta är vad som körs bakom Trust Ledger
ShieldIDs verifiering av undertecknares identitet är vad som driver Trust Ledger, Crown Stack Systems egen e-signeringsprodukt – samma dokumentkontroller, ansiktsmatchning, liveness och Activity Ledger som beskrivs på den här sidan, i drift i verkliga signeringsflöden i dag, inte bara som en plan.
Integritetsnoteringar
En undertecknares ID hanteras med samma omsorg som dokumentet som signeras
Ett dokument som är värt att signera är ofta värt att skydda identiteten bakom lika noggrant.
- Hostat på våra egna servrar i Kanada
- ID-bilder, extraherade fält och resultat behandlas och lagras på ShieldIDs egna servrar i Kanada, inte hos en publik molnleverantör och inte i ett datacenter i USA.
- Rensas efter kort tid
- ID-bilder rensas automatiskt, som standard efter sju dagar, och det går att konfigurera; verifieringsposten finns kvar längre än bilderna.
- Krypterat
- Födelsedatum lagras krypterat och ID-bilder är krypterade i vila.
- Byggt med integritet som standard
- Minimal insamling, ett kort lagringsfönster och ett sökbart åtkomstregister, de kontroller som gör att "vi verifierade undertecknaren" blir mer än en rad i dina villkor.
Jämfört med det manuella sättet
Vad en ID-kontroll tillför före en klicka-för-att-signera-lösning
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 |
|---|---|---|---|
| Bekräftar en verklig person, inte bara en inkorg | Ja | Oftast | Nej |
| Liveness-utmaning, inte ett stillbild eller en kryssruta | Ja | Oftast | Nej |
| Offentlig legitimation läses och korskontrolleras | Ja | Oftast | Nej |
| Identitetskontroll förd in i en sökbar post | Ja | Erbjuds inte kunden | Endast IP-adress och tidsstämpel |
| Kopplas till ett specifikt dokument eller kuvert | Ja | Oftast | n/a |
| Sandbox som aldrig faktureras | Ja | Ibland | n/a |
Invändningar
Vad ett plattformsteam frågar innan det här steget läggs till
”Verifierar inte vårt e-signeringsverktyg redan identiteten?”
De flesta förlitar sig på en e-postlänk, en SMS-kod eller ett skrivet namn – bevis på att någon kontrollerar en inkorg eller ett telefonnummer, inte bevis på vem personen är. ShieldID lägger till en faktisk kontroll av offentlig legitimation och ett levande ansikte.
”Kommer ett extra steg att sinka signeringen?”
Det är ett enda värdbaserat steg, på undertecknarens egen telefon, som läggs en gång före signeringsvyn. Hur ofta det upprepas för en återkommande undertecknare är en policy som plattformen själv bestämmer, inte något ShieldID tvingar fram för varje dokument.
”Är ID-baserad signering ett juridiskt krav?”
Det beror på jurisdiktion, dokumenttyp och juridisk rådgivning – vi ger inga juridiska råd. Det ShieldID tillför är starkare bevis på vem som låg bakom signaturen, vilket är användbart oavsett om det är obligatoriskt eller inte.
”Kan vi använda detta bara för våra mer värdefulla dokument?”
Ja – anropa ShieldID för de dokument som behöver det och hoppa över det för resten. Det är ett steg som läggs till i ett specifikt signeringsflöde, inte en strömbrytare för allt eller inget på hela plattformen.
Det här ser du
Vet vem som signerade, och visa hur du vet det.
Undertecknare styrker vilka de är innan de signerar. Resultatet följer med kuvertet: varje fält som lästs från ID-handlingen och varje kontroll för sig.
Frågor
Raka svar för e-signeringsplattformar.
Kom igång
Lägg till en identitetskontroll före nästa signatur
Skapa en sandbox-session, genomför en verifiering på din egen telefon och se vilken post den skriver innan en enda verklig undertecknare har kommit i kontakt med den.
Sandbox-sessioner debiteras aldrig.