Overview

Snapdocs supports the handling of closings where the borrowers are either representing other people and entities or being represented by other people. This guide is meant to detail how to build to the Snapdocs Connect APIs via an integration in a way that handles the top three use cases; Power of Attorney signings, signing on behalf of a Trust, and signing when the entity involved in a Business entity such as an LLC.

The primary hurdle in handling these use cases takes place at Closings Creation via the integration, ensuring that data that comes across will support the eSign requirements for all signers.

Special Callouts:

• First, Snapdocs always supports a Wet Closing in these use cases 100% of the time. Our customers get the benefit of a single process for engaging settlement to perform the closing in person, and there are no added hurdles to the transaction.
• A hybrid transaction supports one "shared" signer email address. In scenarios where there are more than one "shared" email address across signers, the closing type should be updated to "wet_only".
• Lastly, it’s recommended to implement POA, Trust and LLC closing submissions after you’ve successfully set up basic closing creation.

Snapdocs Hybrid Requirement

Snapdocs connect requires a borrower object for each persona signing on the closing or required to view and interact with the transaction. When the loan involves POA, Trusts, or LLCs then it may not align with the LOS construct of “loan borrower” objects. This may result in a mapping between the LOS and Snapdocs APIs to ensure Snapdocs receives one row per persona.

Once we have the appropriate number of personas to send over, we also need to understand the signing details. Snapdocs supports a Closings Create endpoint, borrower object field called signature_name which needs to match the value the persona is signing as. When no signature name is provided, we are expecting the signer is signing as

First_Name + Middle_Name + Last_Name + Suffix

However in the case of a POA, for example, we may see something in a format such as

[Borrower full name] by [Signer Name], POA

It is crucial to understand how your LOS and Doc Prep determine signature names, as this calculation must be replicated when sending data to Snapdocs.

Please note that many of these use cases are not yet supported for eNote or RON (Full eClose) transactions. Please work with your Snapdocs team to validate if you can send any transactions as anything more than Hybrid before selecting eNote or RON closing types.

Example LOS Images

While Loan Origination Systems (LOS) vary, most include the concept of borrowers or co-borrower pairs. For each borrower there are a number of fields filled out differently when the loan is designated as a POA, Trust, or LLC / Business Entity transaction. It is expected that the integrator knows their LOS well and to understand how to map from their object to the requirement of a single row per signer persona for the Snapdocs APIs.

This guide leverages images that correspond to an example LOS and how it represents the Loan Borrowers screens and objects in the cases of POA, Trust, and LLC.

In our example LOS, we have checkboxes for borrower designations, and buttons that will bring up secondary popup screens with extra information for each special type of signer situation. Walking through the use cases we will assume we have checked the boxes and are editing the POA, Trust, and Business details.

Snapdocs UI Output

We submitted POAs, Trustees, and LLCs with similar signing names in a Snapdocs environment, and it results in a borrowers list like in this screenshot. Once submitting correctly with borrower details, no further change is needed to support POA, Trust, and LLC Hybrid closings.