AltScore
Nodes

Document Verifications

Document Verifications signs PDF documents and attaches a timestamp that proves when the signing occurred. Depending on the country and configured provider, signing happens either through a qualified electronic certificate or through AltScore's OTP signature. In both cases, each signed document is linked to an Authorization entity on the borrower's record as a permanent legal record.

The node supports two signing providers:

  • Uanataca (Ecuador) — qualified electronic certificate, backed by a prior liveness check.
  • AltScore (OTP) — signature backed by an OTP verification, with a verifiable QR stamped onto the PDF.

The provider is selected by country in the node configuration.

Common configuration

OptionDescription
providerSigning provider (by country)
selectedIdentityIdIdentity key to pull the signer's identifier from (e.g., person_id)
signerNameSourceWhat is shown as "Signed by" (see below)
documentsArray of documents to sign (see below)
storeInPackageCreate an audit record with signing results and metadata

Each document in the array needs:

FieldDescription
filenameOutput filename for the signed PDF
urlVariableVariable containing the PDF URL (or use urlStaticValue for a fixed URL)
pagePage number for signature placement (0-indexed)
posXHorizontal position as percentage (0-100)
posYVertical position as percentage (0-100)
authorizationKeyLinks the signed document to an Authorization entity

Authorization Key links the signed document to an Authorization entity on the borrower's record. Multiple documents can share the same key. These entities serve as permanent legal records containing the signer's identity snapshot, timestamp, and the signed PDF.

Store in Package creates an audit record with the signing results and metadata.

Document Verifications configuration

Document Verifications configuration continued

Signer display name

The "Signed by: ..." text on the PDF (and the signerName in AltScore's QR) is resolved from signerNameSource. These are two different things: which identity signs (the validation) and which name is displayed. This setting controls only the second one.

ValueWhat is shown
DefaultName built from the identity's components (given names and surnames); if none, falls back to the client's label
Client label (label)The borrower's label (for companies, usually the legal/company name)
An identity (identity)The value of the chosen identity, e.g. legal_name

Since identities are defined per tenant, the selector lists the ones that exist in the tenant, ordered by priority. If nothing is selected, behavior is unchanged. This avoids "Signed by: N/A" for companies, which have no natural-person names but do have a legal name.

Provider: Uanataca (Ecuador)

Uanataca issues a qualified electronic certificate and requires a prior Liveness Verification: the liveness check establishes who the person is, and this node uses that verified identity to sign. The two work as a pair.

OptionDescription
verificationIdVariableVariable containing the verification ID from Liveness Verification

Provider: AltScore (OTP + QR signing)

With the AltScore provider, the signature is backed by an OTP verification instead of a liveness check. The typical flow:

  1. An OTP Verification node verifies the signer and leaves an Authorization with the OTP registered.
  2. Document Verifications takes that Authorization, signs the PDFs, and stamps a verifiable QR.
OptionDescription
authorizationIdVariableVariable containing the Authorization ID that holds the verified OTP
signatureLabelsLanguageLanguage for the stamped labels ("Signed by", "Date", footer) — es or en

The stamped QR contains a verifiable record of the signature: signatureId, authorizationId, otpId, borrowerId, tenant, personId, signerName, signedAt, provider, and verificationMethod. Below the QR, the "Signed by" and "Date" labels are stamped, along with a footer telling where to verify the signature.

Verifying a signature

Any PDF signed with AltScore can be validated on the public verification page:

hub.altscore.ai/public/signature-verification

(the same link that appears in the PDF footer). The page asks you to upload the signed PDF and:

  1. Detects the QR inside the PDF and reads the signature record.
  2. Recomputes the PDF's SHA-256 hash and compares it against the hash stored at signing time. If they match, the document is the original, untampered.
  3. Displays the signature data in readable form: signer, date, method (OTP), and the signature and authorization identifiers.

This is an integrity check: if the PDF was modified after signing, the hash won't match and validation fails. The page is public and requires no login.

Output Handles

HandleWhen
SuccessAll documents signed and attached to their Authorization entities
ErrorMissing verification/authorization ID, identity not found, required fields missing, or signing failed

Things to Know

Uanataca is Ecuador only. The Uanataca provider operates in Ecuador. The selected identity must have the required fields populated: cédula number, name, email, phone, and address.

The identity must exist first. The node reads signer information from an existing Identity record on the borrower. If you're using OCR Verification to create that identity, make sure it runs first.

Spouse co-signing happens automatically. With Uanataca, if the borrower's marital status indicates married and spouse data exists, the system generates a second set of signed documents for the spouse.

Documents must be accessible. The URLs you provide must point to downloadable PDFs. Consider using Workflow Execute or PDF Creator to generate documents earlier in the flow.

On this page