Advanced Features

The following features are not of interest to most OneSpan Sign Application users. However, each feature can be very useful to certain advanced users:

Forced Login

Force Login is a OneSpan Sign account setting. When enabled, it ensures that when a signer with a OneSpan Sign account clicks the URL in an email invitation, they are directed to the OneSpan Sign login page (instead of directly accessing the Signing Ceremony). The signer is thus forced to authenticate themselves with their password before they are permitted to view or sign documents.

Evidence Summary & Audit Trail

For every signed transaction, OneSpan Sign captures an extensive Evidence Summary and Audit Trail.

The Evidence Summary can be downloaded and viewed at any time. It is available to all transaction participants, both as an individual download and as part of the completed package.

Evidence Summary documents are highly customizable. You can: (1) customize the logo image; (2) customize the text of every label (title, footer, section titles, and fields); (3) customize the Evidence Summary’s filename; (4) hide/show any of the following elements: logo, title, footer; (5) hide/show any of the following sections: Transaction, Sender, Document, Recipients, Audit Trail. To learn more, contact our Support Team.

The Audit Trail is directly embedded in signed documents. The sender can even add to documents a QR code that points to a secure URL from which the associated Audit Trail can easily be accessed.

The e-Witness module enables OneSpan Sign customers to review a signer's entire session, including: (1) every displayed page; (2) the sequence of actions performed by the signer (entering the transaction, authenticating the signer's identity, approving consent forms, signing documents); (3) the date and time of each event.

Email the Evidence Summary & Documents

When the feature Email the Evidence Summary & Documents is enabled, once a transaction is complete, a PDF of the Evidence Summary is emailed to the transaction owner.

This feature can be configured so the email includes not only the Evidence Summary, but also PDFs of all the transaction's documents.

Knowledge-Based Authentication (KBA)

Knowledge-Based Authentication (KBA) is an Authentication Method that asks a signer dynamically generated questions, based on information in the signer's personal Credit Report.

KBA should be considered when it's important to reduce the risk of identity fraud, or when a signer is unknown (e.g., a new account opening).

Note the following features of KBA:

  • It can co-exist with other Authentication Methods (e.g., email or SMS).
  • A signer's KBA results are stored as part of a transaction's Electronic Evidence.
  • Supported languages include English and Spanish in the U.S., and English and French in Canada.

OneSpan Sign uses the following organizations to provide that authentication for signers in the USA and Canada, respectively:

Equifax USA

To add a signer by KBA authentication using Equifax USA, the package owner must provide the following personal information about the signer:

  • First name, Last name, Address, City: Latin characters only
  • Time at address in years (optional). Enter a value of 0 if the time at the present address is less than 1 year.
  • Home phone: Maximum of 10 digits
  • Date of birth: 8 digits only (MMDDYYYY)
  • Driver 's license: Maximum of 30 digits
  • State: Must be 2 capital letters
  • ZIP: Must be 5 digits
  • SSN: Must be 9 digits

Equifax Canada

To add a signer by KBA authentication using Equifax Canada, the package owner must provide the following personal information about the signer:

  • First name, Last name, Address, City: Latin characters only
  • Time at address in years (optional). Enter a value of 0 if the time at the present address is less than 1 year.
  • Home phone: Maximum of 10 digits
  • Date of birth: 8 digits only (MMDDYYYY)
  • Driver 's license: Maximum of 30 digits
  • Province: Must be 2 capital letters
  • Postal Code: Must be 6 characters, and must include 3 letters (either UPPER CASE or lower case is accepted) and 3 digits.
  • SIN: Must be 9 digits

Once a signer has answered all KBA questions correctly, they can click Submit to begin signing documents.

OFAC Blacklist

The Office of Foreign Assets Controlhttps://www.treasury.gov/about/organizational-structure/offices/pages/office-of-foreign-assets-control.aspx (OFAC) prohibits US citizens, businesses, and financial institutions from engaging in business or financial transactions with persons or entities in certain foreign countries.

When the OFAC Blacklist feature is enabled, we screen the IP addresses of users who connect to OneSpan Sign to ensure that our customers comply with OFAC's sanctions.

Fast Track

The Fast Track feature enables you to quickly send package templates for signing.

This rest of this section discusses:

To learn more about Fast Track than this section explains, please contact your OneSpan Sign Sales Representative.

Signing URLs

Fast Track uses a Signing URL to send a package template directly to all signers. Upon navigating to the Signing URL, a signer is prompted to input their own credentials (first name, last name, and email address). The signer is not authenticated through email, so it is important to ensure that the URL is sent only to the intended recipient.

A Signing URL can be used to save and bookmark a package for future use.

Sending URLs

Fast Track also uses a Sending URL to ask a sender to distribute a package template directly to one or more signers. Upon navigating to the Sending URL, the sender is asked to specify the first name, last name, and email address of each signer. Signers will be notified via email that documents can be signed. Note that:

  • If you are using more than one signer placeholder, you must use a Sending URL for the Fast Track feature because the sender must identify Signer 1, Signer 2, etc.
  • The sender doesn't need to have a OneSpan Sign account, or to be logged into OneSpan Sign when they distribute the package.
  • The Sending URL can even be used to send a package template to a third-party sender, who will then be the one to specify the signers' credentials.

A Sending URL can be used to save and bookmark a package for future use.

Obtaining a Sending URL

Prerequisites

  • Fast Track is enabled on your account.
  • The template selected in Step 2 below contains a placeholder recipient, a document, and a Signature Field for the placeholder recipient.

Action

To obtain a Sending URL for subsequent distribution:

  1. In the Templates Folder, click Templates. The Templates page appears.
  2. Click the template you want to send via Fast Track. That template's page appears.
  3. In the Global Navigation Toolbar, click Fast Track. A Sending URL is provided that you can copy and send to anyone. The URL recipient will be responsible for entering the first name, last name, and email address of each signer.

Bulk Sending

The Bulk Send feature enables users to create and distribute multiple transactions with minimum effort by using:

  • An eligible template, which will be used to create the transactions. A template is "eligible" if it has:
    • At least one document other than the Consent Agreement
    • At least one placeholder Role
    • At least one Signature Field (not necessarily for the placeholder Role)
  • A CSV file, which contains signer information for all placeholder Roles. Once you upload the CSV file, there may be a slight delay while the packages are created and sent.

This rest of this section discusses:

CSV Header Format

This section describes the following aspects of the CVS header format:

One Placeholder

For packages with one placeholder Role, the header row in a CSV file must have the following format:

<PlaceholderRoleName> FIRST_NAME LAST_NAME EMAIL AUTH_TYPE AUTH_PROMPT AUTH_CHALLENGE FieldId1 FieldId2

Note that:

  • The string <PlaceholderRoleName> will not appear in the file. Instead, it will be the name of a placeholder Role. Similarly, the strings <FieldId1> and <FieldId2> will not appear in the file. Instead, they will be field ID names.
  • <PlaceholderRoleName>, FIRST_NAME, LAST_NAME, and EMAIL are required fields. All others are optional.

In the CSV file format, the headers would appear as follows:

<PlaceholderRoleName>,FIRST_NAME,LAST_NAME,EMAIL,AUTH_TYPE,AUTH_PROMPT,AUTH_CHALLENGE,FieldId1,FieldId2

Multiple Placeholders

If your packages contain more than one placeholder Role, you must append a set of header fields for each additional role. All required fields must be present for each placeholder Role. For example, a header containing just the required fields for two placeholder Roles could look like this:

PlaceholderOne FIRST_NAME LAST_NAME EMAIL PlaceholderTwo FIRST_NAME LAST_NAME EMAIL

Invalid Header Format

The column of the placeholder Role name defines the start of a Role Block. Each Role Block must contain all mandatory fields, but the order of header columns in each Role Block doesn't matter.

For example:

  • This is valid:
PlaceholderOne EMAIL LAST_NAME FIRST_NAME PlaceholderTwo FIRST_NAME EMAIL LAST_NAME
  • This is not valid:
PlaceholderOne EMAIL LAST_NAME FIRST_NAME EMAIL PlaceholderTwo FIRST_NAME LAST_NAME

Sample CSV File

Here is a sample CSV file for a package with two signers:

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,,,,

Validation Process

OneSpan Sign validates the header row before validating any other row in a CSV file. If something is wrong with the header row, an error message is sent. If the header row is verified as valid, OneSpan Sign proceeds to validate the other rows.

The rest of this section discusses the validation of:

Mandatory Fields

The fields (FIRST_NAME, LAST_NAME, and EMAIL) are mandatory, so they cannot be left blank.

AUTH Field

AUTH_TYPE, AUTH_PROMPT, and AUTH_CHALLENGE together constitute the "AUTH field" for a given Role Block.

The value assigned to AUTH_TYPE must be NONE, CHALLENGE, or SMS. The validation process for AUTH_PROMPT and AUTH_CHALLENGE depends on the value assigned to AUTH_TYPE, as explained in the rest of this section.

If AUTH_TYPE = NONE for a particular Role, OneSpan Sign does not try to validate AUTH_PROMPT or AUTH_CHALLENGE for that Role. That's because they're not used (see the sample CSV file above).

If AUTH_TYPE = CHALLENGE for a particular Role, OneSpan Sign verifies that for that Role:

  • At least one AUTH_PROMPT/AUTH_CHALLENGE pair has been specified.
  • There is a 1:1 mapping between prompts and challenges (i.e., for every prompt, there is a challenge — and vice versa).

OneSpan Sign reads prompt and challenge columns from left to right, which means that both of the following are valid ordering schemes:

AUTH_TYPE AUTH_PROMPT AUTH_CHALLENGE AUTH_PROMPT AUTH_CHALLENGE
CHALLENGE Question1 Answer1 Question2

Answer 2

OR

AUTH_TYPE AUTH_PROMPT AUTH_PROMPT AUTH_CHALLENGE AUTH_CHALLENGE
CHALLENGE Question1 Question2 Answer1

Answer 2

The above examples illustrate that all AUTH columns must appear in the order in which they're intended to be used. Here's another example which illustrates that concept: Answer2, Answer1, Question1, Question2 is not a valid order.

If AUTH_TYPE = SMS for a particular Role, OneSpan Sign verifies that for that Role there is at least one prompt. The verification process will examine only the first prompt, which should be used to specify the phone number to which an SMS message will be sent. The verification process ignores all other prompt and challenge parameters.

Field Values

The system checks all Java SDK for fields (e.g., minLength, maxLength).

Video Tutorial

How to Use Bulk Send in OneSpan Sign

e-Notary

Notarization occurs in many situations where documents need to be signed (e.g., transferring land or vehicles, settling insurance claims, creating liens or trusts).

Although the e-Notary process is completely electronic, during this process all signers must be in the physical presence of a notary. Indeed, notarization always involves an in-person meeting between a notary and all signers.

The following sections describe various aspects of e-Notary:

Creating an e-Notary Account

A notary must be given a OneSpan Sign account in which e-Notary is enabled. To arrange this, they should contact our Support Team.

When a notary's account is being created, their identity as a notary is profiled. That profile can include, but is not limited to:

  • Name of the notary
  • Jurisdiction (e.g., state, county) in which the notary is commissioned
  • License number of the notary
  • License expiry date

Signing and Notarizing Documents

Prerequisites

  • When the package in this procedure was created, it was flagged as requiring notarization.
  • The package's signers do not include groups.
  • The notary and all signers must be together in person, and have access to a single device that will be used by all parties to review and sign the documents (e.g., a computer or tablet) .
  • The notary has verified each signer's credentials, and has noted the type of credential each signer provided.
  • The notary signer cannot have Change Signer enabled.

Action

To e-sign and notarize the documents in a package:

  1. The notary begins the signing process by logging into their OneSpan Sign account, and selecting the relevant package.
  2. The notary passes control of the device to the first signer, who signs all Signature Blocks that require their signature. This process is repeated for each signer.
  3. To complete the process, the notary signs each document. Information from the notary's profile is automatically added to the package.

After signing and notarization is complete, the person who created the transaction (i.e., the Sender) can download copies of all signed and notarized documents. In addition, the Sender can optionally distribute the documents to all signers and the notary.

e-Journals

An e-Journal is a log that a notary is required to keep to record information related to each notarization they perform.

Most of the information required for an e-Journal entry is captured automatically during the e-signature process. However, at any point during that process, the notary can manually enter an e-Journal entry.

The information required in an e-Journal entry varies by jurisdiction, but it typically includes:

  • The notary's jurisdiction (e.g., state, county)
  • Type of document being signed (e.g. will, loan, transfer of ownership)
  • Name of the signer for whom the entry is being created
  • Type of credential used to identify the signer (e.g., driver's license, passport, birth certificate)
  • Type of signature applied by the signer
  • Date and time when notarization occurs (i.e., when the notary clicks to sign)
  • A unique sequential number that is assigned to the notarization when it occurs
Was this information helpful?
X