IntelleDoc E Signature Compatibility

E-Signature Process Flow

The diagram above outlines the high-level flow of data, resulting documents, and E-Signature platform XML file produced with each document.

The XML file produced by CSi IntelleDoc Solutions provides the signer data in the structure required by the requested E-Signature platform so that the identifying information and other details required by the e-signature transaction can be easily added by the business partner platform.

The PDF file contains rendered content from the CSi Compliance Engine output and PDF signature fields with a name and/or properties that correspond to the requirements of the e-signature platform system. The PDF also contains the DocumentRenderingTrail metadata, which is a compressed and encrypted representation of the transaction information used to produce the document.

Signer Identification

The business partner platform needs to provide a unique identifier in the transaction data for a signer in each digital signature datapoint for all active entities. This ensures that a signer who is actually performing multiple roles in the transaction will only be represented as a single signer in the e-signature platform process.

The data value that is provided should follow this simple JSON format:

{ "Signer": "12flsfu" }

Example:

<Individual>
  <JobTitle>Bank Representative</JobTitle>
  <Signature>
    <DigitalSignatureImage>
      { "Signer":"C1241EBX06x88n8" }
    </DigitalSignatureImage>
  </Signature>
</Individual>

Please note that the leaf node name for this data in the CSi Data Schema is DigitalSignatureImage. This is because previous use of this data element was dedicated to the rendering of a signature image in an output PDF, rather than actual e-signature functionality.

You can add optional values to simplify the creation of the web service call to the e-signature platform. These optional values are ignored by the IntelleDoc Solutions components, but will be added to the output e-signature provider XML file. This allows the originating system that generates the TXL to embed the correct information without an additional lookup for the required information post processing.

Example:

<Individual>
  <JobTitle>Bank Representative</JobTitle>
  <Signature>
    <DigitalSignatureImage>
      { "Signer": "C1241EBX06x88n8",
        "FullName": "Joe Banker",
        "FirstName": "Banker",
        "LastName": "Banker",
        "SSN": "123456789",
        "DOB": "10/10/2001",
        "Street": "12345 Example Street",
        "Apartment": "Example Apartment",
        "City": "Example City",
        "State": "Example State",
        "ZipCode": "Example Zip Code",
        "HomePhone": "Example Home Phone",
        "HomeEmail": "Example Home Email",
        "WorkEmail": "Example Work Email"
      }
    </DigitalSignatureImage>
  </Signature>
</Individual>

Transaction Server Update

The JobTicket that you provide to the Transaction Server should enable the appropriate option for the signature property based on the e-signature platform you use:

  jobTicket.DstFile.PdfProperties.EmbedFormFields = true;
  jobTicket.DstFile.PdfProperties.DigitalSignatureProvider = DigitalSignatureProviderType.**Name**;

DigitalSignatureProviderType.Name is replaced with the appropriate “Name” from CSi based on your e-signature platform integration. Each transaction should be rendered with one PDF per document in order to work successfully in the e-signature process.

During the rendering process, digital signature fields are embedded in the PDF at each signature location. For some e-signature platforms, a date field is also inserted to the right of the signature field. In addition, an XML file is created for every PDF with embedded signatures. The file name for the XML file is the name of the original PDF with SignatureMetadata.xml appended to it. This file contains signer information in the format required by the selected e-signature platform.

For example, the Card Application ATM Debit.pdf also generates an additional file named Card Application ATM Debit.SignatureMetadata.xml in the output directory.

Compliance Service Simple

In Compliance Service Simple, this additional property can be set as presented in the following example.

<destination>
  <properties type="pdfproperties">
    <digitalsignatureprovider>NAME</digitalsignatureprovider>
  </properties>
</destination>

E-Signature Platform Integration

The resulting PDF files in a transaction is ready for use on your e-signature platform. The corresponding XML file generated for each document will likely need additional metadata supplied to it in order to configure all settings on the e-signature platform.

Also note that if you send all document PDFs in a single call to the e-signature platform web service, you will need to merge the various XML files produced into one to be supplied with the additional metadata as a single request.

Data Integrity Metadata

A new PDF metadata item is added to each document returned when using the specific platform provider setting. This metadata item is named DocumentRenderingTrail and contains a compressed and encrypted representation of the data and CSi software versions used to produce the document. This information will be preserved by the e-signature platform process.

Below is an example of this property as viewed in Adobe Acrobat.

No action is required by the business partner platform with regard to this metadata. It functions only to preserve a clear audit trail of the production of the document and is only used in the case of legal dispute regarding a particular transaction.