Building Your eClose Integration

eClose Integration APIs

ICE Mortgage Technology Point of Sale Framework provides the following APIs to build your eClose integration:

• Create Package Event - Creates an eClose package event. A synchronous webhook listener allows the Delivery Partner integration to hook into package creation and observe data, replace email content, and add a link to the portal.
• Create Session - Creates the Delivery Room session and UI that point of sale recipients will use to view, provide electronic consent, electronically sign, and complete eClose packages.

📘

Postman Collection

The Encompass eClose Integration APIs are included in the 22.3 Developer Connect postman collection. See Testing with Postman to learn how to download and import the collection.

Domain Package Model

This section describes the domain concept needed to interpret the package model used.

Groups

A group represents a logical container of packages identified by a namespace and an ID.
Certain capabilities impact across the entire group, though most are specific to a package.
Borrower consent and authentication have group behavior; the individual topic (that is the documentation topic represented by the name: consent/authentication) will cover their scopes.

Recipients

A recipient is an individual who needs the package. In this context, the recipient would be the borrower, coborrower and non-borrowing owners. All recipients will have at least one task.
Recipients may need to consent and/or authenticate based on the package configuration. All recipient notifications are done via email.
Every recipient is expected to have a unique full name.

Consent
Consent to do business electronically is gathered to meet ESIGN/UETA requirements and individual lender requirements.

Status
Electronic consent status. Consent can be either Accepted or Declined by the recipient. During the loan process, recipients can change their minds and Accept or Decline the consent agreement at any time. If Accepted, then Declined, the recipient will need to Accept again before doing another task, but it does not invalidate previous actions; the entire history is retained.
The eDelivery service underlying the Point of Sale Framework provides a flexible consent model to support different situations.
Status includes the following attributes:

• Verbiage - The consent verbiage is set at the group level and used for all recipients. The owner can provide customizations to be sent at creation. The Consent Verbiage is not currently available in the structure or via an API.
• Model - The consent model can be seen in the group consent settings. Possible models are:
  • Group - For all packages in the group, consent is obtained prior to task execution for all recipients once. When this model is used, relevant consents are copied to packages from the group as each package is created.
  • Package - Obtains consent for each package even though the package consent will still apply to the group, which may be obtained separately.
• Access Control - The consentAccessControl setting stored on the group recipient’s delivery system when electronic consent is needed from a recipient.
  • Require - The application obtains consent from the recipient prior to task execution.
  • Optional - The application allows package actions to be completed since they are reading the data, but actual task actions such as review, sign, and upload documents may only be done after consent / authentication (per relevant setting).
  • Block - The application does not allow consent to be recorded for the recipient.

Authentication
Authentications represent audit information obtained by an application from a recipient to track that the person is actually the intended recipient for the package.
Authentication includes the Type attribute. Possible values are:

• AuthCode - Indicates a separate code was shared implicitly or explicitly with the recipient from the portal link and then verified after login.
• SMS - Indicates that a code was generated and sent to the phone number on record which was then verified after login.
• SSO - Indicates that recipient verification is expected to be implemented by the SSO identity provider and the only evidence was the SSO authentication.

Packages

A package is a set of documents sent to one or more recipients. Documents in a package have tasks assigned to them. A task represents the action a recipient is expected to perform with the document. For example, a document task could be for the recipient to review, print, upload, or eSign documents.

Documents
A document is a container representing one or more files and information about the task assigned to it. One or more documents can be in the same task. If consent or authentication is required to view the document, it must be provided prior to starting the task.

Document Type
Type of document. Possible values are:

• eSign - Indicates documents are required to be electronically signed, or documents that are presented with other documents that are being electronically signed.
• Information - Indicates documents that are provided just for informational purposes.
• InPersonWetSign - Indicates documents that need to be wet signed at a table with an agent.
• WetSign - Indicates documents that need to be downloaded, signed, and returned (usually via upload or fax with Coversheet).
• Needed - Indicates documents (or files) that must be provided by the recipient.
• Coversheet - Fax coversheet that is return with faxed documents. The Coversheet includes a barcode which route to the loan.

TaskType
Tasks are actions or flows that are expected to be executed by one or more package recipients.
Possible values for TaskType are:

• eSign - Tasks containing documents that must be electronically signed.
• Review - Tasks containing documents that must be reviewed like Information an InPersonWetSign.
• WetSign - Tasks containing documents that must be downloaded and physically signed.
• Upload - Tasks containing documents that represents files that need to be provided by the recipient.

A document will only be assigned to one task, and it can be correlated by the taskId on the document.
There may be multiple tasks of the same type but the task ID will always be different; the ID should only be used for correlation purposes.

PackageLifecycle

Packages and tasks support lifecycle capabilities with optional routing order, release, completion, and expiration.
All capabilities are bound by the most restrictive values. For example, a package will not be sent to a borrower unless both the routing order and release date have been met.

• Routing order is a sequential value where higher values cannot start until lower values are completed.
• Recipients with the same values will execute in parallel.
• Email will not be sent to the recipient until their order is ready.
• Release ScheduledDate is when the package is available to the recipient (recipients.release.scheduledDate).
• No date indicates the package will be released immediately.
• Recipient task completable earliest date (recipients.taskStatuses.completable.earliestdate)
• No date indicates the task can be completed immediately upon release.
• Package expiration dates indicate that all recipient tasks of a type must be completed by that date or the package will expire UNLESS a recipient has disableExpiration flagged -if so that recipient is excluded during calculation.
• Immediate releases / completion is the default - no release / completable date set.
  All lifecycle statuses impact a recipient's task status property:
• Incomplete - Indicates there are no current lifecycle states blocking the task and it can be done.
• Restricted - Indicates that the task cannot currently be completed
• Completed - Indicates the task has already been completed.

Notifications

Various notifications are sent during execution. Many notifications are sent transparently behind the scenes. The following points highlight only the notifications that are explicitly relevant or illustrate metadata in the event.

• When a package is ready, the Created Email notification will be sent to the recipient.
• A package is considered ready when all routing and scheduling conditions have been met. This notification allows the recipient to access the package.
• When a task is ready for a recipient, another copy of the Created Email notification is sent to the recipient. This only happens when the task earliestDate exists and is passed. earliestDate is currently only used for eSign.
• notViewed date and recipients are set according to the provided date; a Not Viewed notification will be sent to the sender if any of the referenced recipients have not viewed the package by the notViewed date.
• A Viewed notification will be sent to the sender as soon as any recipient who is not the sender views the package.

Integration with Encompass

Encompass integrates with the package model using the loans groupNamespace with its loan GUID as the groupId. This means that the group is equivalent to a loan for Encompass. While packages are created for various flows, the CreatePackageEvent will only be sent for eClosing at this time.