Les fonctionnalités suivantes ne sont pas d’intérêt pour la plupart des utilisateurs de OneSpan Sign. Cependant, chaque fonctionnalité peut être très utile pour certains utilisateurs avancés :
- Connexion forcée
- Résumé des preuves et Piste d’audit
- Authentification basée sur la connaissance (KBA)
- Liste noire de l’OFAC
- Fast Track
- Envoi en masse
- Notarisation en personne
Connexion forcée
Forcer la connexion est un paramètre OneSpan Sign de compte. Lorsqu’il est activé, il garantit que lorsqu’un signataire avec un compte OneSpan Sign clique sur l’URL dans une invitation par courriel, il est dirigé vers la page de connexion de OneSpan Sign (au lieu d’accéder directement à'lExpérience du signataire). Le signataire est ainsi obligé de s’authentifier avec son mot de passe avant d’être autorisé à visualiser ou signer des documents.
Résumé des preuves et Piste d’audit
Pour chaque transaction signée, OneSpan Sign saisit un résumé des preuves et une piste d'auditdétaillés.
Le résumé des preuves peut être téléchargé et consulté à tout moment. Il est à la disposition de l'expéditeur, à la fois sous forme de téléchargement individuel et dans le cadre de la transaction achevée.
Les documents Résumé des preuves sont hautement personnalisables. Vous pouvez : (1) personnaliser l'image du logo; (2) personnaliser le texte de chaque étiquette (titre, pied de page, titres des sections et champs); (3) personnaliser le nom de fichier du résumé des preuves; (4) masquer/afficher l'un des éléments suivants : logo, titre, pied de page; (5) masquer/afficher l'une des sections suivantes : Transaction, Expéditeur, Document, Destinataires, Piste d'audit. Pour en savoir plus, communiquez avec notre équipe de soutien.
Lorsque la fonction Email the Evidence Summary & Documents est activée, une fois la transaction terminée, un PDF du résumé des preuves est envoyé par courriel au propriétaire de la transaction. Cette fonction peut être configurée de manière à ce que le courriel contienne non seulement le résumé des preuves, mais aussi les PDF de tous les documents de la transaction.
La piste d'audit est directement intégrée dans les documents signés.
Le module e-Witness est disponible pour les clients dans des environnements sur site où OneSpan Sign a été déployé manuellement (sans utiliser de conteneurs Docker). Ce module permet à ces clients de passer en revue l'ensemble de la session d'un signataire, y compris : (1) chaque page affichée; (2) la séquence des actions effectuées par le signataire (saisie de la transaction, authentification de l'identité du signataire, approbation des formulaires de consentement, signature des documents); (3) la date et l'heure de chaque événement.
Authentification basée sur la connaissance (KBA)
L’authentification basée sur la connaissance (KBA) est une méthode d’authentification qui pose à un signataire des questions générées dynamiquement, en fonction des informations contenues dans le rapport de crédit personnel du signataire.
Après avoir répondu correctement à trois des quatre questions de KBA, le signataire peut cliquer sur Connexion pour commencer à signer des documents.
La KBA doit être envisagée lorsqu’il est important de réduire le risque de fraude à l’identité, ou lorsqu’un signataire est inconnu (par exemple, une nouvelle ouverture de compte).
Notez les caractéristiques suivantes de KBA :
- Il peut coexister avec d’autres méthodes d’authentification (par exemple, courriel ou SMS).
- OneSpan Sign utilise LexisNexis pour fournir l'authentification KBA pour les signataires aux États-Unis
- Les résultats KBA d’un signataire sont stockés dans le cadre de la preuve électronique d’un paquet.
- L'anglais fait partie des langues prises en charge.
LexisNexis
Pour ajouter un signataire par authentification KBA via LexisNexis, le propriétaire du paquet doit fournir les informations personnelles suivantes sur le signataire :
- Prénom, nom (obligatoire)
- Nom du bâtiment (facultatif)
- Numéro du bâtiment (facultatif)
- Numéro de l'appartement (facultatif)
- Ville (obligatoire)
- État (obligatoire) : Doit être de 2 lettres majuscules
- Code postal (obligatoire) : Doit comporter 5 chiffres
- Numéro d’assurance sociale (facultatif) : Vous pouvez exiger la saisie des neuf chiffres, d'aucun chiffre ou des quatre derniers chiffres uniquement.
- Date de naissance (facultatif) : 8 chiffres seulement (MMJJAAAAA)
Notez ce qui suit :
Si un signataire ne parvient pas à s'authentifier via LexisNexis KBA, l'expéditeur devra créer une nouvelle transaction s'il souhaite effectuer une nouvelle tentative d'authentification KBA.
Liste noire de l’OFAC
Le Office of Foreign Assets Control (OFAC) interdit aux citoyens, aux entreprises et aux institutions financières des États-Unis d’effectuer des transactions commerciales ou financières avec des personnes ou des entités de certains pays étrangers.
Lorsque la fonction Liste noire de l'OFAC est activée, nous veillons à ce que nos clients respectent les sanctions de l'OFAC en contrôlant les adresses IP des utilisateurs qui se connectent à OneSpan Sign.
Les résultats d'un contrôle OFAC peuvent être consultés dans le résumé des preuves.
Fast Track
La fonctionnalité Fast Track vous permet de distribuer rapidement des modèles de paquets pour signature.
Le reste de cette section traite de la question :
La fonctionnalité Fast Track ne se limite pas au contenu de cette section. Pour en savoir plus, contactez votre représentant commercial OneSpan Sign.
URL de signature
Fast Track utilise une URL de signature pour envoyer un modèle de paquet directement à tous les signataires. Lorsque vous accédez à l’URL de signature, un signataire est invité à saisir ses propres informations d’identification (prénom, nom et adresse courriel). Le signataire n’est pas authentifié par courriel, il est donc important de s’assurer que l’URL est envoyée uniquement au destinataire prévu.
Une URL de signature peut être utilisée pour enregistrer et mettre en signet un paquet pour une utilisation ultérieure.
Envoi des URL
Fast Track utilise une URL d’envoi pour demander à un expéditeur de distribuer un modèle de paquet directement à un ou plusieurs signataires. En naviguant vers l’URL d’envoi, l’expéditeur est invité à préciser le prénom, le nom et l’adresse courriel des signataires. Les signataires seront avisés par courriel que les documents peuvent être signés.
Notez que :
- Si vous utilisez plus d'un espace réservé signataire, vous devez utiliser une URL d'envoi pour la fonction Fast Track. En effet, l'expéditeur doit identifier les espaces réservés Signataire 1, Signataire 2, etc.
- Lorsqu'un expéditeur distribue un paquet, il n'a pas besoin d'avoir un compte OneSpan Sign, ni d'être connecté à OneSpan Sign.
- Une URL d’envoi peut même être utilisée pour envoyer un modèle de paquet à un expéditeur tiers, qui sera alors celui qui spécifiera les informations d’identification des signataires.
Une URL d’envoi peut être utilisée pour enregistrer et mettre en signet un paquet pour une utilisation ultérieure.
Obtention d’une URL d’envoi
Préalables
- La fonction Fast Track est activée sur votre compte.
- Le modèle sélectionné à l’étape 2 ci-dessous contient un destinataire fictif, un document et un champ de signature pour le destinataire fictif.
Action
Pour obtenir une URL d’envoi :
- Dans le Dossier de modèles, cliquez sur Modèles. La page Modèles s’affiche.
- Localisez le modèle que vous voulez envoyer via Fast Track. Cette page du modèle s’affiche.
- Dans la Barre d'outils de navigation globale, cliquez sur Fast Track. Une URL d’envoi est fournie que vous pouvez copier et envoyer à n’importe qui. Le destinataire de l’URL sera responsable de la saisie du prénom, du nom et de l’adresse courriel de chaque signataire.
Envoi en masse
La fonction d'envoi en masse permet aux utilisateurs de créer et de distribuer plusieurs paquets avec un minimum d'efforts en utilisant :
- Un modèle admissible, qui sera utilisé pour créer les paquets. Un modèle est admissible s’il possède :
- Au moins un document autre que la convention de consentement
- Au moins un rôlede remplacement
- Au moins un champ de signature (pas nécessairement pour le rôle fictif)
- Un fichier CSV, qui contient des informations sur les signataires pour tous les rôles fictifs Une fois que vous téléchargez le fichier CSV, il peut y avoir un léger retard pendant que les paquets sont créés et envoyés.
Le reste de cette section traite de la question :
Format d’en-tête CSV
Cette section décrit les aspects suivants du format d'en-tête du fichier CSV :
Un espace réservé
Pour les paquets comportant un seul rôle fictif, la ligne d’en-tête d’un fichier CSV doit avoir le format suivant :
| <PlaceholderRoleName> | FIRST_NAME | LAST_NAME | COURRIEL | AUTH_TYPE | AUTH_PROMPT | AUTH_CHALLENGE | FieldId1 | FieldId2 |
Notez que :
- La chaîne
<PlaceholderRoleName>n’apparaîtra pas dans le fichier. Il s’agira plutôt du nom d’un rôle fictif. De même, les chaînes<FieldId1>et<FieldId2>n’apparaîtront pas dans le fichier. Au lieu de cela, il s’agira de noms d’identifiants de champs. <PlaceholderRoleName>,FIRST_NAME,LAST_NAME, etEMAILsont des champs obligatoires. Tous les autres sont facultatifs.
Dans le format de fichier CSV, les en-têtes apparaîtront comme suit :
<PlaceholderRoleName>,FIRST_NAME,LAST_NAME,EMAIL,AUTH_TYPE,AUTH_PROMPT,AUTH_CHALLENGE,FieldId1,FieldId2
Espacés réservés multiples
Si vos paquets contiennent plus d’un rôle fictif, vous devez ajouter un ensemble de champs d’en-tête pour chaque rôle supplémentaire. Tous les champs obligatoires doivent être présents pour chaque rôle fictif. Par exemple, un en-tête contenant uniquement les champs obligatoires pour deux rôles fictifs pourrait ressembler à ceci :
| PlaceholderOne | FIRST_NAME | LAST_NAME | COURRIEL | PlaceholderTwo | FIRST_NAME | LAST_NAME | COURRIEL |
Format d’en-tête non valide
La colonne du nom de rôle de l’espace réservé définit le début d’un bloc de rôles. Chaque bloc de rôle doit contenir tous les champs obligatoires, mais l’ordre des colonnes d’en-tête dans chaque bloc de rôle n’a pas d’importance.
Par exemple :
- Ceci est valable :
| PlaceholderOne | COURRIEL | LAST_NAME | FIRST_NAME | PlaceholderTwo | FIRST_NAME | COURRIEL | LAST_NAME |
- Ceci n’est pas valide :
| PlaceholderOne | COURRIEL | LAST_NAME | FIRST_NAME | COURRIEL | PlaceholderTwo | FIRST_NAME | LAST_NAME |
Exemple de fichier CSV
Voici un exemple de fichier CSV pour une paquet avec deux signataires :
Signer1,FIRST_NAME,LAST_NAME,EMAIL,AUTH_TYPE,AUTH_PROMPT,AUTH_CHALLENGE,AUTH_PROMPT,
AUTH_CHALLENGE,Signer2,FIRST_NAME,LAST_NAME,EMAIL,AUTH_TYPE,AUTH_PROMPT,AUTH_CHALLENGE,AUTH_PROMPT,AUTH_CHALLENGESigner1,David,Smith,
[email protected],NONE,,,,,Signer2,Roger,Waters,[email protected],NONE,,,,
Processus de validation
OneSpan Sign valide la ligne d’en-tête avant de valider toute autre ligne dans un fichier CSV. Si quelque chose ne va pas avec la ligne d’en-tête, un message d’erreur est envoyé. Si la ligne d’en-tête est vérifiée comme étant valide, OneSpan Sign procède à la validation des autres lignes.
Le reste de cette section traite de la validation de :
Champs obligatoires
Les champs FIRST_NAME, LAST_NAME, et EMAIL sont obligatoires, ils ne peuvent donc pas être laissés vides.
Champ AUTH
AUTH_TYPE, AUTH_PROMPT, et AUTH_CHALLENGE constituent ensemble le champ « AUTH » pour un bloc de rôles donné.
La valeur attribuée à AUTH_TYPE doit être NONE, CHALLENGE, ou SMS. Le processus de validation pour AUTH_PROMPT et AUTH_CHALLENGE dépend de la valeur attribuée à AUTH_TYPE comme expliqué dans la suite de cette section.
Si AUTH_TYPE = NONE pour un Rôle particulier, OneSpan Sign n’essaie pas de valider AUTH_PROMPT ou AUTH_CHALLENGE pour ce rôle. C’est parce qu’ils ne sont pas utilisés (voir l’exemple de fichier CSV ci-dessus).
Si AUTH_TYPE = CHALLENGE pour un rôle particulier, OneSpan Sign vérifie les éléments suivants pour ce rôle :
- Au moins une paire
AUTH_PROMPT/AUTH_CHALLENGEa été spécifiée. - Il existe une correspondance 1:1 entre les invites et les défis (c’est-à-dire que pour chaque invite, il y a un défi, et vice versa).
OneSpan Sign lit les colonnes d’invite et de défi de gauche à droite, ce qui signifie que les deux schémas d’ordonnancement suivants sont valables :
| AUTH_TYPE | AUTH_PROMPT | AUTH_CHALLENGE | AUTH_PROMPT | AUTH_CHALLENGE |
| DÉFI | Question1 | Réponse1 | Question2 |
Réponse 2 |
OU
| AUTH_TYPE | AUTH_PROMPT | AUTH_PROMPT | AUTH_CHALLENGE | AUTH_CHALLENGE |
| DÉFI | Question1 | Question2 | Réponse1 |
Réponse 2 |
Les exemples ci-dessus montrent que toutes les colonnes AUTH doivent apparaître dans l’ordre dans lequel elles sont destinées à être utilisées. Voici un autre exemple qui illustre ce concept : Réponse2, Réponse1, Question1, Question2 n’est pas un ordre valide.
Si AUTH_TYPE = SMS pour un rôle particulier, OneSpan Sign vérifie qu'il existe au moins une invite pour ce rôle. Le processus de vérification n’examinera que la première invite, qui doit être utilisée pour spécifier le numéro de téléphone auquel un message texte sera envoyé. Le processus de vérification ignore tous les autres paramètres d’invite et de défi.
Valeurs des champs
Le système vérifie tous les champs du SDK Java (par ex, minLength, maxLength).
Tutoriel vidéo
Notarisation en personne
La notarisation intervient dans de nombreuses situations où des documents doivent être signés (par exemple, pour le transfert de terrains ou de véhicules, le règlement de sinistres, la création de privilèges ou de fiducies).
Bien que le processus de notarisation de OneSpan Signsoit entièrement électronique, dans certains cas, la présence physique d'un notaire s'impose pour tous les signataires. C'est ce qu'on appelle la notarisation en personne, ou IPEN pour In-Person Notarization,
Les sections suivantes décrivent divers aspects de l'IPEN :
Création d’un compte e-Notary
Un notaire doit recevoir un OneSpan Sign compte dans lequel e-Notary est activé. Pour organiser cela, notaires doivent contacter notre équipe de soutien.
Lorsque le compte d’un notaire est créé, son identité en tant que notaire est profilée. Ce profil peut inclure, mais sans s’y limiter :
- Nom du notaire
- Compétence juridique (par exemple, État américain, région) dans laquelle le notaire est mandaté
- Numéro de licence du notaire
- Date d’expiration de la licence :
Signature et notarisation de documents
Lors de la préparation d'une transaction IPEN, il convient de respecter les conditions préalables suivantes :
- Lorsque la transaction dans cette procédure a été créée, elle a été signalée comme nécessitant une notarisation.
- Les signataires de la transaction n'incluent pas les groupes.
- Le notaire a vérifié les accréditations de chaque signataire et a noté le type d’accréditation que chaque signataire a fourni.
- Le signataire notarial ne peut pas avoir la fonction Changement de signataire activée.
- Le notaire et tous les signataires doivent être ensemble en personne et avoir accès à un seul appareil qui sera utilisé par toutes les parties pour examiner et signer les documents (par exemple, un ordinateur ou une tablette).
Pour signer et authentifier électroniquement les documents d'une transaction :
- Pour commencer le processus de signature, le notaire doit se connecter à son compte OneSpan Sign et sélectionner la transaction concernée.
- Le notaire transmet le contrôle de l'appareil au premier signataire, qui signe tous les champs de signature qui requièrent sa signature. Ce processus est répété pour chaque signataire.
- Pour terminer la procédure, le notaire signe chaque document. Les informations de profil du notaire sont automatiquement ajoutées à la transaction.
Une fois la signature et la notarisation terminées, la personne qui a créé la transaction (c’est-à-dire l’expéditeur) peut télécharger des copies de tous les documents signés et notariés. En outre, l’expéditeur peut éventuellement distribuer les documents à tous les signataires et au notaire.
e-Journals
Un e-Journal est un journal électronique qu'un notaire est tenu de conserver pour enregistrer les informations relatives à chaque notarisation qu'il effectue via l'IPEN.
La plupart des informations requises pour une inscription au e-Journal sont saisies automatiquement au cours du processus de signature électronique. Toutefois, à tout moment au cours de cette procédure, le notaire peut saisir manuellement une entrée dans le e-Journal.
L’information requise dans une inscription au e-Journal varie selon la compétence juridique mais elle comprend généralement :
- La compétence juridique du notaire (par exemple, l’État/la province, la région)
- Type de document signé (par exemple, testament, prêt, transfert de propriété)
- Nom du signataire pour lequel l’entrée est créée
- Type de justificatif utilisé pour identifier le signataire (par exemple, permis de conduire, passeport, certificat de naissance)
- Type de signature appliquée par le signataire
- Date et heure de la notarisation (c’est-à-dire lorsque le notaire clique pour signer)
- Un numéro séquentiel unique qui est attribué à la notarisation lorsqu’elle se produit