Service: Electronic Signature
The Electronic Signature Service sends agreements to a configured third-party provider (for example, Dropbox Sign), tracks signing status, and stores the signed documents and provider evidence.
The service provides:
Signing Records: Stores the provider status and completion evidence for each agreement.
Signer Verification: Uses the provider's authentication controls and retains its certificate of completion when available.
Workflow Automation: Creates signing sessions and retrieves completed agreements without a separate paper process.
Embedded Signing: Places the signing process inside the investment workflow.
Core Technical Components & APIs
The service exchanges document and signing data with the external e-signature provider.
Primary Models:
Investment Model: The primary object that a signing event is associated with. The service updates this model's
signature_status.Document Model: The service uses this model (via the Filer) to store the final, executed agreements.
Fund Model: The source for the document templates that need to be signed.
Governing Logic:
Investment Status Lifecycle: The signing process is a critical step within this lifecycle.
Global Business Rules: It enforces the "re-signature" rule if investment data changes.
Primary APIs:
e-signature-api: Exposed by this service to allow other services (like Investment Process Management) to initiate a signing session.
Consumed APIs: This service consumes the APIs of the third-party provider to create templates, send signature requests, and retrieve signed documents.
Process Lifecycle
The service processes a signing session in three phases.
Phase 1: Document Preparation & Generation
This phase begins when another service requests a document to be signed for a specific investment.
Template Retrieval: The service identifies the correct document template based on the Fund the investor is committing to.
Dynamic Data Merging: It fetches the specific details from the Investment, Profile, and Fund models and merges them into the template to create a personalized, unique agreement for the investor.
Phase 2: Embedded Signing
The service presents the prepared document in the provider's hosted environment.
Session Creation: The service calls the third-party provider's API to generate a secure, one-time-use embedded signing URL.
Presentation: This URL is passed back to the calling service, which presents the signing interface to the user directly within the investment process. The user completes all required fields and applies their signature within the provider's secure UI.
Phase 3: Finalization, Storage & Auditing
This phase completes the process after the user has signed.
Webhook Confirmation: The service listens for a webhook from the e-signature provider confirming the signing process is complete.
Status Update: Upon confirmation, it immediately updates the Investment record's
signature_statustoSIGNED.Secure Storage: The service retrieves the final, executed PDF of the agreement and the accompanying audit trail document (Certificate of Completion) from the provider. It then uses the Filer to securely store these files, linking them to the Investment record.
Exceptions and Recovery
Re-signature on Data Change: If critical data on an Investment (e.g.,
amount,ownership) is modified after the signature step has been completed, the engine must automatically void the previous signature and require the investor to re-sign the updated agreement.Signing Session Expiration: If an investor does not complete a signing session within a pre-configured timeframe, the session will expire, and they will need to restart the step.
Declined to Sign: If an investor explicitly declines to sign a document, the service logs this action and prevents the Investment from proceeding.
Provider Unavailability: If the third-party provider's API is unavailable, the service logs the error and retries the request according to its retry policy.