From Dependency to Autonomy: Building an In-House E-signing Service

In today’s digital age, the ability to securely sign documents online is not just a convenience; it’s a necessity. For fintech startups and other businesses, e-signing services are an integral part of operations. While many companies rely on third-party services, there’s a growing realization that an in-house solution can offer more control, flexibility, and cost savings.

In this article, we’ll delve into how to build an e-signing microservice. We’ll cover open-source tools and technologies used in building this service offering. In addition, we will cover a use case of the iCreditWorks startup, which transitioned to its own in-house e-signing service.

Compliance with the E-sign Act and Regulatory Standards

E-sign Act overview

Before diving into the technical aspects of building an in-house e-sign service, it’s crucial to understand the legal landscape governing electronic signatures. The Electronic Signatures in Global and National Commerce (E-sign) Act, enacted in 2000, plays a pivotal role in this domain.

The act provides a general rule of validity for electronic records and signatures for transactions in or affecting interstate or foreign commerce. The Act ensures that electronic signatures hold the same weight and legal effect as traditional paper documents and handwritten signatures.

Compliance measures

Our in-house e-signing service is meticulously designed to adhere to the stipulations of the E-sign Act. We ensure that:

• All electronic signatures are uniquely linked to the signatory.
• Once a document is signed, it becomes immutable, ensuring that no alterations can be made post-signature. This strict adherence guarantees the integrity and authenticity of the signed document.
• The signatory is provided with a clear and concise way to do business electronically.
• The signatory has the intent to sign the document.

The case for building an in-house e-signing service

Building an in-house e-signing service is not merely a technical decision but a strategic one. It involves evaluating the cost-effectiveness, operational efficiency, and customization possibilities that such a service brings compared to third-party e-signing services. In this section, we will delve into the compelling reasons that make a case for building an in-house e-signing service.

1. Cost Efficiency: Relying on external third-party services often incurs a per-signature fee. When dealing with a large volume of documents, these costs can accumulate rapidly. For iCreditWorks, this was a pivotal consideration, as it significantly reduced the loan application expenses.
2. Reduced External Dependencies: If a product offering hinges on numerous external APIs - with e-signing being one of them - having an in-house solution eliminates one external dependency, streamlining operations.
3. Enhanced UI Customizations: The user interface (UI) possibilities for mobile apps or web browsers are confined to the capabilities offered by third-party services. iCreditWorks, for instance, wanted granular UI branding, a feature that the external partner did not easily support.

After understanding the compelling reasons and strategic advantages of having an in-house e-signing service, let’s transition into the architectural and technological aspects. In the following section, we will unveil the foundational elements and the tech stack of the e-signing microservice by looking at the case study of iCreditWorks.

Case study - iCreditWorks

Background: iCreditWorks aims to modernize and streamline the lending process at the point where sales occur, making it more efficient and customer-friendly. Currently, iCreditWorks caters to dental financing and expanding to other industry verticals.

Challenge: The third-party e-signing service they relied on charged a fee of $0.70 for each digital signature. Considering their estimated 100,000 funded loans annually, this translated to a substantial expense of $70,000. Additionally, the external vendor’s platform limited their customization options, preventing iCreditWorks from achieving a consistent brand look and feel across their digital platforms.

Solution: Recognizing the dual challenges of cost and branding, iCreditWorks took the step to develop an in-house e-signing microservice. By transitioning to an in-house solution, iCreditWorks achieved cost savings, enhanced branding, and operational efficiency.

Documents processed: iCreditWorks has successfully processed a large number of agreement documents. This volume encompasses a diverse range of documents, from customer agreements pertaining to loan applications to intricate network provider agreements. This showcases the reliability of the in-house e-signing service, and it also highlights the capability to adeptly manage a variety of document types.

Transitioning to in-house solutions isn’t just about cost-saving. It’s about gaining control and flexibility, and ensuring that the user experience aligns with the brand’s vision.

Building an in-house e-signing microservice

Choosing a microservice architecture for the e-signing service was driven by several key considerations. This architectural style offers modularity, making the application easier to develop, test, deploy, and scale. It allows for the independent deployment of services, enhancing agility and resilience. Furthermore, microservices enable technology diversity, allowing us to choose the best technology stack for each service’s unique requirements, thereby optimizing performance and maintainability. Another key factor was to build this as a horizontal capability service to be leveraged across different business units.

Tech stack

When building any microservice, especially with critical business functionalities, it’s essential to choose a tech stack that’s robust, scalable, and has wider community support. The e-signing microservice is built on the following technology stack:

1. Spring Boot with Java
2. Generating and Securing PDFs
3. Cloud Storage (AWS S3 or Azure Blob)
4. Database (MySQL). If the database is hosted on Azure, you could use Azure Database for MySQL. However,  if it’s on AWS, you could use Amazon RDS for MySQL.

Figure 1: E-sign Tech Stack

Spring Boot

This is a standard REST API interface developed in Java using the Spring Boot framework. Spring Boot provides rapid development capabilities and wider community support. There are two main APIs: one to fetch the initial document for signing and another to post the signature, which then returns the signed document.

Generating and securing PDFs

To generate PDF documents, we use headless Chrome. In Java, there’s a Maven package that serves as a wrapper for the Chrome dev tools, named chrome-devtools-java-client. To secure the PDFs, we employ an external third-party certificate. For iCreditWorks, the certificate is sourced from Entrust.

Cloud storage

It’s essential to store generated documents, user signatures, and published templates for documents that need signatures. All of these are stored in the cloud. If AWS is the cloud provider, AWS S3 is used. Alternatively, for Azure, Azure Blob storage is the choice. Additionally, Google Cloud Platform (GCP) also offers robust storage solutions like Cloud Storage, which could be integrated as per the organization’s needs.

Database

The database is mainly for state storage between the APIs. It also stores document-related artifacts and the payload sent with the initial request. The current GitHub implementation uses MySQL as the database, but it can be replaced with any other relational database like MS SQL Server, Postgres, or Oracle. We can use NoSQL databases like MongoDB as well.

E-signing flow and API endpoints    

There are primarily two endpoints, which ensure a straightforward process for the user, from document generation to signing.

1. Generate documents for signing
2. Post-signature and get a signed document

We will delve into the above two steps in detail below, and we will start first with generating documents. Generating documents is the initial step in the e-signing process, where business-specific legal documents are created using predefined templates and dynamic data. This section will detail the process, from fetching and populating templates to converting them into ready-to-sign PDF documents.

Generate documents for signing

The e-sign service uses templates to create business-specific legal documents for signing. At iCreditWorks, there’s a specific process to publish a template, but that process is beyond the scope of this article. The assumption here is that the template has already been published and is stored on cloud storage. These templates are HTML files with static content and templated variables (e.g., {{CustomerAddressCity}}, {{CustomerAddressState}}, {{CustomerAddressZip}}). These tokenized variables are replaced with actual values at runtime.

Implementing tokenized variables within templates facilitates dynamic content creation, catering to diverse business needs. Additionally, it provides versatility by supporting various document types through distinct templates.

API Endpoint

POST {{baseUrl}}/api/e-sign/v1/document/{contentType}

Request Body

{
    "docCode": "GEN-MPN-01",
    "contextId": "LN-1000109-01",
    "localePreference": "en-US",
    "fields": {
        "CurrentDate": "09/03/2023",
        "UserAcctId": "LN-1000109-01",
        "CustomerFullName": "John Doe",
        "CustomerAddressLine": "1100 Fox Run Dr",
        "CustomerAddressCity": "Iselin",
        "CustomerAddressState": "NJ",
        "CustomerAddressZip": "08050"
    }
}

The "fields" are dynamic variables that must be filled in the HTML template during document generation.

The following steps occur under the hood of the API endpoint:

Figure 2: Generate document

1. Fetch the template from cloud storage based on the provided template code.
2. Populate the HTML template by replacing variable tokens with the dynamic values provided.
   
   Code snippet for replacing tokenized variables.
    

   private String pattern = "\\{\\{([\\w]+)\\}\\}";
   
   Pattern pattern = Pattern.compile(this.pattern, Pattern.CASE_INSENSITIVE);
   Matcher matcher = pattern.matcher(messageTemplate);
   while (matcher.find()) {
       String messageToken = matcher.group();
       String fieldName = messageToken.substring(2, messageToken.length() - 2);
       String fieldValue = normalizedFieldMap.get(fieldName);
       if (fieldValue != null) {
           if (fieldValue.contains("$")) {
               fieldValue = fieldValue.replace("$", "\\$");
           }
           matcher.appendReplacement(messageBuffer, fieldValue);
       } else {
           matcher.appendReplacement(messageBuffer, "");
       }
   }

3. Use headless Chrome to convert the HTML file into a PDF document.
4. Store the generated HTML and PDF document in cloud storage.
5. Save the document metadata and other data in the database to maintain the state for that document request.
6. The API returns an HTML response, but it can also return a PDF, depending on the requirement. The API also provides a document a universal unique identifier (UUID) in the response header, which can be used for subsequent API calls.

Post-signature and get signed document

API Endpoint

POST {{baseUrl}}/api/e-sign/v1/document/signature/{{eSignDocumentUUID}}/html

Request Body (form- Data):
Key: "signature"
Value: "User’s signed image"
The following steps occur under the hood of the API endpoint:

Figure 3: Get Signed Document

This is the core of the e-signing process, where the main actions occur. Here’s what happens step by step:

1. The API request contains the document UUID as a path variable, this documentUUID is used to fetch the state from the previous request.
2. The user’s signature image - part of the request body - is uploaded to cloud storage, and its path is saved in the database.
3. Based on the state data, a new empty template is fetched, and the templated tokenized variables are then replaced with dynamic data, which is fetched from the state data.
4. For the Uploaded user signature image URL in cloud storage, a pre-signed public URL is created. This type of URL provides time-limited access. The URL is then inserted into the template variable for the user’s signature.
   
   Below is a sample of one of the templates where the user’s signature will be inserted.
   
   
   
   
   HTML code for the template would look something like this:
    

   <tr>
       <td width="47%" height="50px" valign="bottom"
           style="border-bottom: 1px solid #333333;"><img class="signimage"
               src="{{CustomerSignature}}" alt="">
           <div style="{{DisplaySignedNameAndDate}}"><span
                   style="font-size:10px;color:#0000FF">{{CustomerFullName}}
                   ({{SignedDateTime}})</span></div>
       </td>
       <td width="6%"></td>
       <td width="47%" align="left" valign="bottom" height="50px"
           style="border-bottom: 1px solid #333333;">{{SignedDateTime}}
       </td>
   </tr>
   

   
   {{CustomerSignature}} – This variable is replaced with the Pre-Signed URL.
   
   
   
   Below is what the run time HTML looks like.

   <tr>
       <td width="47%" height="50px" valign="bottom"
           style="border-bottom: 1px solid #333333;">
           <img class="signimage"
               src="https://{{s3bucketname}}.s3.amazonaws.com/e-sign/LN-1000109/LN-1000109-01/CustomerSignature/2023-10-02T00-25-43-806.customer_signature.jpeg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20231002T002545Z&X-Amz-SignedHeaders=host&X-Amz-Expires=86398&X-Amz-Credential=AKIA46UPUH6Y5RO%2F20231002%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-ignature=a4b3404bba99ac81b39afd31427031adbe9e"><br>
           <div style="">
    <span style="font-size:10px;color:#0000FF">
      John Doe (10/01/202320:25:47 EDT)</span></div>
       </td>
       <td width="6%"></td>
       <td width="47%" align="left" valign="bottom" height="50px"
           style="border-bottom: 1px solid #333333;">10/01/2023 20:25:47 EDT
       </td>
   </tr>
   

   
   At iCreditWorks, we use the concept of a one-time token instead of a Pre-signed URL; a one-time token is appended to the URL, along with the UUID, which is associated with the signature image that has been stored in the cloud storage (AWS S3). The token in the URL can be used only once and will be short-lived. Below is a sample URL for reference:
   
   {{baseUrl}}/v1/document/157f55tt-e8d1-4f6e-90bb-dc5341bc4fa4?token=78902bed-60c2-11ee-acd2-0aa24276fac5
   
   Pre-signed URL code snippet for AWS S3

   Calendar calendar = Calendar.getInstance();
   calendar.setTime(new Date());
   calendar.add(Calendar.MINUTE,5); // Generated URL will be valid for 24 hours
   return this.awsS3Client.generatePresignedUrl(s3BucketName, documentPath, calendar.getTime(), HttpMethod.GET).toString();
   

5. After digitally signing the PDF document, both the HTML and PDF versions of the signed document are saved in cloud storage. The paths from the cloud storage are then saved in the database.
6. Once all the steps are completed, the signed HTML document response is sent to the consuming application, allowing the user to view the signed document.

Having explored the detailed steps of the e-signing process, let’s shift our focus toward the security measures that ensure the integrity and confidentiality of the signed documents in the e-signing service.

Security measures in e-signing

E-signing Certificate: The e-signing service uses a digital certificate to authenticate the identity of the signer and to provide the signer with a unique digital ID. This certificate is issued by a trusted third-party Certificate Authority (CA) and ensures the integrity and authenticity of the signed document.

Storage Security: All signed documents and associated data are encrypted in a secure cloud storage.

Handshake Protocol: The e-sign service uses a secure handshake protocol to establish a secure connection between the client and the server. This ensures that the transmitted data is encrypted and secure from any potential eavesdropping or tampering.

Channel-agnostic shared service

The e-signing microservice is designed and built as a shared service, meaning it can be seamlessly integrated into various applications or systems within the organization. This modular approach ensures consistency in e-signing across different platforms and reduces redundancy.

The e-signing service is designed to work across various channels, be it mobile, web, or any other digital platform. This flexibility ensures a consistent user experience across all touchpoints and allows for easy scalability and adaptability to emerging channels.

Conclusion

In today’s digital-centric world, businesses must continuously seek ways to enhance operational efficiency, reduce costs, and provide a seamless user experience. The transition to an in-house e-signing solution, as illustrated in our case study, not only led to significant cost savings but also provided the flexibility to tailor services to unique branding and operational needs. While third-party solutions offer convenience, there’s undeniable value in building proprietary systems that align closely with a company’s vision. As industries continue to digitize, the ability to adapt, innovate, and customize becomes paramount. Investing in in-house solutions can be a strategic move toward achieving that agility and laying the groundwork for sustained growth in the digital era.

Open-source availability

The e-signing microservice’s codebase is available on GitHub. By sharing the solution with the broader community, we aim to empower other startups and fintechs to benefit from our development efforts and to foster a collaborative environment for continuous improvement. The potential of in-house e-signing solutions isn’t limited to fintech. Various other industries can leverage the open-source solution.