Advanced Features

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

• Forced Login
• Evidence Summary & Audit Trail
• Knowledge-Based Authentication (KBA)
• OFAC Blacklist
• Fast Track
• Bulk Sending
• In Person Notarization

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 Signer Experience). 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 any time. It is available to the sender, both as an individual download and as part of the completed transaction.

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.

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.

The Audit Trail is directly embedded in signed documents.

The e-Witness module is available to customers in on-premises environments where OneSpan Sign was deployed manually (not using Docker containers). This module enables those 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.

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.

Once a signer has answered three out of four KBA questions correctly, they can click Login to begin signing documents.

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).
• OneSpan Sign uses LexisNexis to provide KBA authentication for signers in the USA
• A signer's KBA results are stored as part of a package's Electronic Evidence.
• Supported languages include English.

LexisNexis

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

• First name, Last name (required)
• House Name (optional)
• House Number (optional)
• Flat Number (optional)
• City (required)
• State (required): Must be 2 capital letters
• Zip Code (required): Must be 5 digits
• Social Security Number (optional): You can require all nine digits to be entered, no digits, or just the last four digits.
• Date of birth (optional): 8 digits only (MMDDYYYY)

Note the following:

• If a signer fails to authenticate using LexisNexis KBA, the sender will need to create a new transaction if they want to re-attempt KBA authentication.

OFAC Blacklist

The Office of Foreign Assets Control (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 ensure that our customers comply with OFAC's sanctions by screening the IP addresses of users who connect to OneSpan Sign.

The results of an OFAC check can be seen in the Evidence Summary.

Fast Track

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

This rest of this section discusses:

• Signing URLs
• Sending URLs

There is more to Fast Track than this section describes. To learn more, 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 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. That's because the sender must identify Signer 1, Signer 2, etc.
• When a sender distributes a package, they don't need to have a OneSpan Sign account, or be logged into OneSpan Sign .
• A 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:

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 packages with minimum effort by using:

• An eligible template, which will be used to create the packages. 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
• Sample CSV File
• Validation Process
• Video Tutorial

CSV Header Format

This section describes the following aspects of the CSV file's header format:

• One Placeholder
• Multiple Placeholders
• Invalid 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 required 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:

• Required Fields
• AUTH Field
• Field Values

Required Fields

The fields FIRST_NAME, LAST_NAME, and EMAIL are required, 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 the following for that Role:

• At least one AUTH_PROMPT/AUTH_CHALLENGE pair has been specified.
• There is a 1-to-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 there is at least one prompt for that Role. 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

In Person Notarization

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

Although OneSpan Sign's notarization process is completely electronic, in some situations all signers must be in the physical presence of a Notary. This is called In-Person Notarization, or IPEN.

The following sections describe various aspects of IPEN:

• Creating an e-Notary Account
• Signing and Notarizing Documents
• e-Journals

Creating an e-Notary Account

A notary must be given a OneSpan Sign account in which e-Notary is enabled. To arrange this, notaries 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

When preparing an IPEN transaction, note the following prerequisites:

• When the transaction in this procedure was created, it was flagged as requiring notarization.
• The transaction's signers do not include groups.
• The notary has verified each signer's credentials, and has noted the type of credential each signer provided.
• The notary signer cannot have the Change Signer feature enabled.
• 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) .

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

1. The notary begins the signing process by logging into their OneSpan Sign account, and selecting the relevant transaction.
2. The notary passes control of the device to the first signer, who signs all Signature Fields 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 transaction.

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 an electronic log that a notary is required to keep to record information related to each notarization they perform via IPEN.

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