Transaction Settings for Digital Lending

OneSpan Sign has created a Digital Lending Solution that can store a loan or other related document (e.g., contract, chattel paper) in a digital vault.

Certain REST API settings associated with a OneSpan Sign transaction can specify which document should be vaulted, and in which organization and vault it should be stored. After a document's authoritative copy is vaulted, it is replaced in OneSpan Sign's database by either a watermarked non-authoritative copy (default) or a blank document.

Creating a transaction or template with the REST API always involves certain standard settings — see Java SDK.

If you want to view all existing calls, see our interactive Open API Specification. From there you can download the YAML file for our REST API, search for specific endpoints in that API, and even try a few calls yourself.

Whenever an attempt to eDeposit documents in an eOriginal vault fails, OneSpan Sign sends a notification to the Sender of the associated transaction via a Callback Event.

Using an eOriginal Vault for Digital Lending Transactions

Currently, the use of Optional Signatures with eOriginal is not supported. By default, when using eOriginal, documents are vaulted as soon as the last signature has been signed by the last signer. However, when using optional signatures it is possible to complete a transaction without completing all signature fields. In this case, the document would not be vaulted.

If you want to store a document in an eOriginal vault, the first thing you need to do is to ask our Support Team to enable this functionality for your account.

To instruct OneSpan Sign to store a document in an eOriginal vault, integrators must add to the transaction's data field the vaulting_data JSON field described below.

• eOriginal vaults a lending document from a OneSpan Sign transaction together with the transaction's Audit Log.

• As of the 11.37 release of OneSpan Sign, if a transaction has multiple loan documents: (1) an eOriginal vault can store all those documents for the transaction; (2) eOriginal's Audit Trail lists all events related to the transaction and its multiple documents.

vaulting_data

This field should be a Base-64-encoded JSON string. When the field is decoded, the parameters in the following table can be viewed.

Vaulting Data cannot exceed 4000 characters.

Example

Here is an example of a Base64-decoded "vaulting_data" value:

{
        "postRegisterOption":"watermark_doc",
        "vaultTransactionTypeName":"OneSpan Sign eTest",
        "vaultCredentials":{
        "username":"SampleUsername",
        "orgName":"SampleOrganization",
        "apiKey":"ok0Sample0ApiKey0Just0An0Example",
        "endpoint":"previewondemand"
        },
        "documentsToVault":[
        {
        "documentId":"DocumentName01",
        "loanId":"loanId_001",
        "loanAmount":"99999",
        "lender":"ABC Corporation",
        "type":"Loan Contract"
        },
        {
        "documentId":"DocumentName02",
        "loanId":"N/A",
        "loanAmount":"0",
        "lender":"N/A",
        "type":"Ancillary"
        }
        ]
        }

Updating Vaulting Data for an in-flight transaction

Vaulting data can be updated for inflight transactions provided they meet the following criteria:

• The transaction must already contain vaulting data. If vaulting data was missed during transaction creation, it may be added to a DRAFT transaction via PUT /api/packages/{packageID}.

• The transaction must be in a SENT or COMPLETED status.

• The transaction cannot have an “eDepositComplete” status

To update vaulting data for an inflight transaction use the following endpoint:

HTTP Request

PUT /packages/{packageId}/eOriginalVault/vaultingData

Request Payload

{
"data": {
"vaulting_data":"BASE64 value"
}