Validation de documents pas en bon ordre

Not in Good Order (NIGO) Validation de pièces jointes vérifie les documents que vos signataires téléchargent par rapport au type de document que vous avez demandé. Lorsqu'un signataire télécharge une pièce jointe, OneSpan Sign classe le fichier, extrait éventuellement un ensemble défini de champs et effectue des vérifications de contenu dessus, et — lorsque cela est activé pour votre compte — inspecte les PDF à la recherche de signes de modification.

Avis uniquement, et non bloquant

Aucune vérification dans cette fonctionnalité empêche un signataire de faire quoi que ce soit. Un mauvais type de document, une vérification ratée, une image illisible, un signal de falsification ou une panne du service de validation laissent l'expérience du signataire inchangée : le téléchargement réussit, l'exigence de pièce jointe est satisfaite, et le signataire peut finaliser la transaction.

La validation produit des signaux pour une révision humaine. Agir en conséquence — demander un document de remplacement, rejeter une transaction, escalader vers la conformité — est une décision que vous prenez en dehors de la fonctionnalité.

L'extraction est volontaire, et désactivée par défaut

Deux contrôles sur chaque exigence d'attachement déterminent la quantité de validation qu'elle reçoit :

• Choisir un type de document active la classification pour cette exigence.

• De plus, cocher Vérifier document active l'extraction et les vérifications de contenu qui s'exécutent sur les champs extraits.

L'extraction est désactivée à moins que vous ne la cochiez, pour chaque exigence individuellement. Il n'y a pas de réglage à l'échelle du compte qui l'active pour chaque accessoire.

Activation de la fonctionnalité pour un compte

La validation des pièces jointes NIGO est désactivée par défaut pour tous les comptes. Elle est activée dans Backoffice, sous la page Fonctionnalités du compte. Trois paramètres la contrôlent, et les trois sont désactivées par défaut :

Les trois paramètres sont en couches, et la dépendance est appliquée lors de la sauvegarde : l'authenticité du document nécessite l'extraction des données jointes, qui nécessite la classification des pièces jointes. En tentant de casser la chaîne, on retourne « L'authenticité du document nécessite que l'extraction des données jointes soit activée en premier. » ou « L'extraction des données jointes ne peut pas être désactivée tant que l'authenticité du document est activée. »

La fonctionnalité dans son ensemble se trouve aussi derrière un drapeau de release que OneSpan active pour votre compte.

Demander une pièce jointe avec un type de document attendu

Dans la boîte de dialogue Pièces jointes du destinataire, chaque ligne de pièce jointe dispose d'un menu déroulant Type de document , d'une case à cocher Vérifier le document et d'une case à cocher Obligatoire . Les deux premières n'apparaissent que lorsque les fonctionnalités correspondantes du compte sont activées. Obligatoire n'a aucun lien avec la validation — il contrôle si le signataire doit tout simplement télécharger quelque chose.

Choisissez le type de document que vous attendez à ce que le signataire télécharge. Ce type attendu est à chaque résultat ultérieur qui est mesuré — sans lui, rien n'est classifié et aucun résultat n'est produit.

Dix-sept types de documents sont pris en charge dans la version 26.R5 :

Définir un type attendu ne change pas ce qu'on demande au signataire, et ne limite pas ce qu'il peut télécharger. Cela ne fait que déterminer avec quoi le fichier téléchargé sera comparé.

Activation de l'extraction

Cochez Vérifier document sur l'exigence. La case à cocher est désactivée jusqu'à ce qu'un type de document soit choisi, car l'extraction est définie par type de document. Lorsqu'elle est activée, OneSpan Sign extrait les champs définis pour ce type et effectue les vérifications sur les valeurs extraites.

L'extraction est sautée, aucun champ ni résultat de vérification n'est produit, chaque fois que l'exigence n'a pas coché le document Vérifier, que la classification n'a pas pu identifier le document, que le type détecté ne correspond pas au type attendu, que la classification a signalé un problème de qualité avec le fichier, ou que la classification n'est pas suffisamment confiante — l'extraction n'est effectuée que sur une classification à haute confiance.

Lecture des résultats

Les résultats ne sont visibles que par l'expéditeur et les autres disposant d'un accès d'édition à la transaction. Les signataires ne voient jamais les données extraites, ne vérifient les résultats, ne font jamais confiance ou ne manipulent pas les résultats.

Sur la page de la transaction, chaque fichier téléchargé par un signataire affiche un badge de statut sous son nom, ainsi qu'un bouton Résultat de vérification qui ouvre les résultats de ce fichier :

La boîte de dialogue Résultat de vérification affiche, pour le fichier :

• Un résumé des vérifications. Tout problème de fichier est d'abord listé comme un échec. Ensuite, une ligne de type de document , rapportée comme correspondance ou inadéquation avec le type détecté. Ensuite, une ligne par vérification de contenu, marquée comme réussie, avertissement ou échec, en termes simples — par exemple, la date d'expiration trouvée et dépassée. Les lignes de passage sont reliées par défaut.

• Les données extraites, sous forme de liste de noms de champs et de valeurs — dates dans le format de votre localité et codes pays comme noms de pays — ou un message indiquant qu'aucune donnée extraite n'est disponible.

• Un aperçu du fichier, et le bouton « Marquer comme révisé » (voir Marquer comme révisé).

L'extraction s'exécute après le téléchargement et prend un peu plus de temps que la classification. Jusqu'à ce qu'elle soit terminée, la boîte de dialogue ne rapporte aucune donnée extraite.

Non affiché dans l'interface de l'expéditeur dans la version 26.R5, bien que disponible via l'API : la confiance en classification, la raison pour laquelle l'extraction n'a pas été exécutée, les résultats de falsification de documents, et qui a examiné un fichier et quand.

Lorsque le type détecté ne correspond pas à ce que vous avez demandé

Rien n'est bloqué. Le téléchargement reste en vigueur et l'exigence d'attachement reste satisfaite.

Sur la page de transaction, le fichier est signalé pour examen. Dans la boîte de dialogue résultats, la ligne de type de document apparaît comme un décalage, en même temps que le type réellement détecté, vous pouvez donc voir ce que le signataire a envoyé à la place. L'extraction est sautée pour ce fichier.

Le signataire voit un seul message sur son téléchargement indiquant que le document ne semble pas correspondre à ce qui a été demandé. Il n'est pas empêché de continuer, ne reçoit pas de re-téléchargement, et ne reçoit aucun e-mail ni notification.

Quand un document ne peut pas être classifié

Trois situations distinctes, toutes non blocantes :

Le type de document n'a pas pu être déterminé. Le fichier était lisible mais ne correspondait à aucun type supporté. Le fichier est signalé pour examen avec son type indiqué comme inconnu, et l'extraction est sautée.

Le fichier présentait un problème de qualité. Le fichier a été rejeté avant qu'une classification ne puisse être tentée — par exemple, il était trop flou, trop sombre ou de très faible résolution, avait des reflets, était corrompu, trop grand ou trop petit, ou était un format non supporté. La validation accepte les fichiers PDF, Word, JPEG, PNG, TIFF, BMP et GIF entre 1 Ko et 10 Mo, ainsi que des images d'au moins 200 × 200 px. Le problème spécifique apparaît dans la première ligne du résumé des résultats, et l'extraction est sautée. C'est la seule situation où le signataire voit également un message décrivant le problème réel de son fichier, sur lequel il peut agir en téléversant une meilleure copie.

Le service de validation était indisponible. Aucun résultat n'est enregistré pour le fichier. Sur la page de la transaction, il est signalé comme type non identifié ; sa boîte de dialogue de résultats indique qu'il n'y a pas de résultat, et n'offre pas de Mark tel qu'examiné. Le téléchargement lui-même n'est pas affecté, mais la validation ne s'exécutera pas pour le fichier ultérieurement ; si vous avez besoin qu'il soit validé, demandez au signataire de le remplacer.

Vérifications

Les vérifications de vérification s'exécutent sur les valeurs des champs extraites, elles nécessitent donc que le document Verify soit activé et l'extraction réussie. Chaque vérification signale Réussi, Avertissement ou Échec, et nomme les champs consultés.

Une date manquante ou illisible produit un Avertissement, jamais un échec. Seule une date lue avec succès et jugée hors de portée produit un échec.

Les vérifications exécutées, et contre quels champs, dépendent entièrement du type de document :

Détection de falsification de documents

Lorsque l'authenticité des documents est activée pour le compte, OneSpan Sign inspecte en outre les pièces jointes PDF pour détecter des signes indiquant que le fichier a été modifié après son émission : si l'outil qui a produit le PDF est cohérent avec un document émis authentique, si le contenu a été ajouté après la première écriture du fichier, si les horodatages du fichier sont cohérents, et si le fichier a été modifié bien après la date d'impression dessus. Il concerne onze des dix-sept types de documents — les relevés, factures, déclarations, factures, contrats et documents d'assurance et d'enregistrement — et non pour les documents d'identité avec photo, les chèques annulés ou les lettres d'emploi.

Dans 26.R5, les résultats sont retournés uniquement via l'API. La boîte de dialogue des résultats ne les affiche pas. Les intégrateurs peuvent les lire depuis le point de terminaison des vérifications ; voir Intégrité du document dans le sujet API pour les vérifications, leurs résultats et la note globale.

Limitations — ce qu'il ne détecte pas

Il s'agit d'un ensemble d'heuristiques sur la structure et les métadonnées d'un PDF. Ce n'est pas une détection de fraude, et cela ne peut pas établir qu'un document est authentique.

• Il ne lit pas le contenu du document pour juger si le contenu est vrai. Il ne peut pas vous dire qu'un montant de revenu a été modifié, qu'un nom n'est pas celui du signataire, ou que le document a été remis à quelqu'un d'autre.

• Il est en grande partie à l'aveugle sur les documents numérisés et photographiés. Un PDF entièrement une image numérisée ne supporte que la vérification sur l'outil producteur ; chaque autre vérification indique qu'elle n'a pas été évaluée. Une photo ou une capture d'écran téléchargée directement sous forme d'image ne supporte aucune des vérifications. Parce qu'un grand nombre de pièces jointes légitimes sont des scans ou des photos de téléphone, le fait de ne pas être évalué est un résultat courant et attendu — et ce n'est pas un refus.

• La détection de l'outil de production ne lit que les métadonnées propres au PDF. Un fichier dont les champs de production et de créateur ont été supprimés, ou réglés sur quelque chose de non reconnu, signale que non évalué plutôt qu'un échec. Toute personne capable de modifier un PDF peut également modifier ces champs.

• Une conclusion n'est pas une preuve, et l'absence de constats n'est pas une preuve d'authenticité. Sauvegarder à nouveau un relevé bancaire via l'impression en PDF d'un navigateur, ou télécharger un relevé plusieurs mois après la période déclarée, sont des comportements ordinaires pouvant entraîner un avertissement.

Marquer comme évalué

Marquez comme Révisé enregistre votre décision formelle d'avoir examiné un fichier téléchargé et l'acceptez.

Il est disponible pour tout fichier ayant un résultat de validation, quel que soit ce résultat — extraction off, un décalage, une vérification ratée, un problème de qualité. Dans l'interface de l'expéditeur, le bouton se trouve dans la boîte de dialogue des résultats ; un fichier qui n'a jamais été validé n'a pas de résultat, donc pas de bouton. Via l'API, l'action est toujours disponible, y compris pour un fichier sans résultat — voir Marquer comme Examiné via l'API.

Marquer un fichier comme relu des enregistrements, qui l'a marqué et quand. Il ne supprime pas, ne nettoie, ne refait pas de vérification ou ne change aucune classification, données extraites, vérification ou détection de falsification — ces résultats restent exactement tels qu'ils étaient auparavant, aux côtés du dossier de votre revue.

Avis sur Undo

Annuler une revue est uniquement informative. Elle enregistre qui l'a annulée et quand, et préserve le dossier d'examen original afin que l'historique complet reste visible. Elle ne demande pas un nouveau document au signataire, ne l'informe pas, ne refait pas de classification, d'extraction ou de vérification, et ne modifie aucun résultat stocké.

Si un fichier est remplacé

Si un signataire remplace un fichier téléchargé, l'état de revue ne se reviendra pas. Le nouveau fichier commence sans être examiné et doit être examiné de lui-même.

Trace d'audit

Les actions de saisie suivantes sont enregistrées dans la piste d'audit de la transaction :

• Fichier annexe d'envoi

• Télécharger la pièce jointe

• Marquez comme vérifié — le nom de la piste d'audit pour Mark tel que révisé

• Undo Verification — le nom de la piste d'audit pour la révision Undo

Les résultats de validation ne sont pas enregistrés dans la piste d'audit dans la version 26.R5. Les résultats de classification, les valeurs de champs extraites, les résultats des vérifications de vérification et les résultats de falsification ne produisent pas d'entrées d'audit. La piste d'audit enregistre la décision humaine — qu'un expéditeur a marqué un fichier comme examiné — et non les conclusions de la machine qui l'ont informé.

Not in Good Order (NIGO) La validation des pièces jointes classe les documents que vos signataires téléchargent, extrait optionnellement un ensemble défini de champs à partir d'eux et effectue des vérifications de contenu sur ces champs, et — lorsque cela est activé — inspecte les PDF à la recherche de signes de modification. Ce sujet explique comment demander cette validation, comment récupérer les résultats et comment gérer chaque résultat.

Avis uniquement, et non bloquant

Aucun résultat de validation n'affecte la transaction. Un mauvais type de document, un contrôle défaillant, un fichier illisible, un signal de falsification ou une panne du service de validation ne causeront jamais un rejet d'un téléchargement, une exigence de pièce jointe pour rester insatisfait, ni empêche un signataire de la compléter. Considérez chaque champ décrit ici comme un conseil, et ne bloquez jamais votre propre flux de travail sur la disponibilité du service de validation.

Il n'existe pas de point final de classification ou d'extraction

OneSpan Sign n' expose pas ni /extract, ni tout autre point de terminaison qui exécute une validation à la demande. La classification et l'extraction sont internes, et sont déclenchées comme effet secondaire du téléchargement ou du remplacement d'une pièce jointe par un signataire. Vous ne pouvez pas soumettre vous-même un document pour validation, relancer une validation sur un document existant, ni valider un document qui n'est pas une pièce jointe sur une transaction.

Votre intégration comporte exactement deux points de contact : vous configurez ce qui doit être validé lors de la construction de la transaction, et vous lisez les résultats ensuite.

Demande de validation

Les deux paramètres reposent sur une exigence d'attachement, qui est imbriquée à l'intérieur d'un rôle. Définissez-les lorsque vous créez ou mettez à jour le rôle, ou lorsque vous créez le package.

{
  "id": "role1",
  "type": "SIGNER",
  "signers": [
    { "email": "jane@example.com", "firstName": "Jane", "lastName": "Doe" }
  ],
  "attachmentRequirements": [
    {
      "id": "attachment-1",
      "name": "Proof of address",
      "description": "Upload a recent bank statement",
      "required": true,
      "attachmentType": "BANK_STATEMENT",
      "extractionEnabled": true
    }
  ]
}

POST ou PUT à cela, /aws/rest/services/packages/{packageId}/roles[/{roleId}]ou l'inclure dans la charge utile de création de paquet.

extractionEnabled est un booléen nullable : null et false sont équivalents, et tous deux signifient faux. Il est nullable de sorte qu'un champ omis ne peut jamais permettre accidentellement l'extraction — seul un explicite true le fait.

Erreurs de validation

La demande est rejetée si vous demandez quelque chose auquel le compte n'a pas droit :

La détection de falsification n'a pas de champ par condition. Elle est contrôlée uniquement par le paramètre d'authenticité du document au niveau du compte, et s'applique à chaque pièce jointe éligible sur le compte.

Récupération des résultats

GET /aws/rest/services/packages/{packageId}/attachment/verifications

Notez que le segment de chemin est attachment, singulier.

La réponse est un tableau nu, pas un objet avec un champ nommé. Il n'y a pas de pagination.

Ce point de terminaison nécessite des privilèges d'édition de transaction — expéditeur, propriétaire ou délégué. Les signataires reçoivent 403. Les résultats de validation ne sont exposés nulle part dans l'API orientée vers le signataire.

La classification est synchrone ; l'extraction est asynchrone. La classification s'achève pendant le téléchargement, donc classificationResult disponible dès le retour du téléchargement. L'extraction s'exécute ensuite, et son résultat apparaît à ce point de terminaison une fois terminé — jusqu'à ce moment-là, les éléments du fichier rapportent extractionStatus: "NOT_PERFORMED" avec un null reasonCode et un non extractionResult. Les résultats sont assemblés à chaque requête : le résultat d'extraction est récupéré depuis le service de validation et les vérifications de contenu sont évaluées à ce moment-là, donc lisez ce point de terminaison lorsque vous avez besoin des résultats actuels plutôt que de le mettre en cache.

Détection de la complétion

L'extraction est asynchrone, aucun événement n'annonce sa fin dans la version 26.R5 (voir Rappels et événements), et PACKAGE_ATTACHMENT se déclenche avant de s'être terminé — un client qui a besoin des résultats d'extraction doit donc relire ce point de terminaison jusqu'à ce que chaque fichier atteigne un état final.

Ce point de terminaison n'est pas limité en débit dans 26.R5, donc limitez-vous. Chaque appel récupère le résultat d'extraction actuel pour chaque fichier validé sur la transaction depuis le service de validation et réévalue les vérifications de contenu. Ne boucle pas de façon serrée. Recommandé : commencez sur le PACKAGE_ATTACHMENT rappel (par téléversement) ou sur SIGNER_COMPLETE (une fois le signataire terminé), relisez au maximum toutes les 10 secondes par transaction — un appel couvre tous les fichiers de la transaction — et arrêtez après 5 minutes, en considérant tout fichier encore sans état final comme indisponible. Ce sont des recommandations, pas des limites mesurées : il n'y a pas de limite publiée au moment de l'extraction.

Décidez par fichier, à chaque lecture :

Si vous n'avez besoin que de la classification, il n'y a rien à attendre.

Forme de réponse

Chaque élément du tableau :

classificationResult:

extractionResult:

Lequel et reasonCode lire. Les deux apparaissent deux fois — sur l'élément tableau et à l'intérieur de . Lisez les champs au niveau de l'élément : ils sont toujours présents. Lorsque  est non nul, its  et  sont identiques à ceux de l'élément (l'élément les copie de lui), et it  est simplement  ne pas être . Lorsque  est , les champs au niveau de l'élément sont les seuls, et expliquent pourquoi il n'y a pas de résultat. Un cas limite : si le service de validation rapporte un statut que extractionStatus cette version ne connaît pas, la valeur imbriquée est  et l'élément rapporte .

Les champs nuls sont présents dans le JSON, non omis. Ne considérez pas la présence d'une clé comme une preuve qu'elle a une valeur. Inversement, de nouveaux champs peuvent être ajoutés dans les versions ultérieures — ignorez les clés que vous ne reconnaissez pas.

Exemple — un résultat réussi

[
  {
    "attachmentUuid": "attachment-1",
    "fileName": "statement-june",
    "fileId": "8842",
    "extension": "pdf",
    "classificationResult": {
      "documentUuid": "9f2c1d84-3b7e-4a15-9c2d-6e8f1a4b7c30",
      "documentType": "BANK_STATEMENT",
      "confidenceScore": 0.95,
      "confidenceLevel": "HIGH",
      "providerName": "bedrock",
      "failed": false,
      "errorCode": null,
      "failureMessage": null
    },
    "extractionResult": {
      "documentUuid": "9f2c1d84-3b7e-4a15-9c2d-6e8f1a4b7c30",
      "extractedFields": {
        "accountHolderName": "JANE DOE",
        "financialInstitutionName": "Bank of Example",
        "statementDate": "2026-06-30",
        "statementPeriodStart": "2026-06-01",
        "statementPeriodEnd": "2026-06-30"
      },
      "providerName": "bedrock",
      "verificationCheckResults": [
        {
          "ruleName": "data_completeness",
          "fields": [],
          "status": "PASS",
          "message": "esl.error.attachment_verification_check.data_completeness_pass"
        },
        {
          "ruleName": "date_validation",
          "fields": ["statementDate"],
          "status": "PASS",
          "message": "esl.error.attachment_verification_check.date_recent"
        }
      ],
      "extractionStatus": "COMPLETED",
      "reasonCode": null,
      "failureMessage": null,
      "preflight": {
        "checks": [
          {
            "check": "SOURCE",
            "status": "PASS",
            "messageKey": "esl.error.preflight_check.source_verified",
            "params": {}
          },
          {
            "check": "EDITS_AFTER_CREATION",
            "status": "PASS",
            "messageKey": "esl.error.preflight_check.no_edits_after_creation",
            "params": {}
          },
          {
            "check": "FILE_DATES",
            "status": "PASS",
            "messageKey": "esl.error.preflight_check.file_dates_consistent",
            "params": {}
          },
          {
            "check": "PERIOD_DATE",
            "status": "PASS",
            "messageKey": "esl.error.preflight_check.period_date_within",
            "params": {}
          }
        ],
        "verifiability": { "inputType": "VERIFIABLE_PDF" },
        "tier": "CLEAR"
      },
      "failed": false
    },
    "extractionStatus": "COMPLETED",
    "reasonCode": null,
    "typeMatch": true
  }
]

Exemple — le fichier n'a pas pu être classifié

[
  {
    "attachmentUuid": "attachment-1",
    "fileName": "photo",
    "fileId": "8843",
    "extension": "jpg",
    "classificationResult": {
      "documentUuid": "1a4b7c30-9f2c-4a15-8e6d-3b7e5c2d9f10",
      "documentType": null,
      "confidenceScore": 0.0,
      "confidenceLevel": null,
      "providerName": null,
      "failed": true,
      "errorCode": "esl.error.attachment_verification.image_too_blurry",
      "failureMessage": "Document is difficult to read"
    },
    "extractionResult": null,
    "extractionStatus": "NOT_PERFORMED",
    "reasonCode": "CLASSIFICATION_QUALITY_WARNING",
    "typeMatch": false
  }
]

Types de documents et champs d'extraction

Dix-sept types de documents sont pris en charge. La colonne Champs d'extraction liste toutes les clés pouvant apparaître extractedFields pour ce type. Les clés marquées (date) sont retournées sous forme ISO YYYY-MM-DD ; toutes les autres valeurs sont renvoyées telles qu'imprimées sur le document.

Deux champs sont contraints à un ensemble fixe de valeurs :

• utilityType — l'un des electric, gas, water, internet, mobile, other

• payFrequency — un des weekly, bi-weekly, monthly, undefined

taxYear est une chaîne simple, pas une date. Elle est retournée telle qu'imprimée sur le document.

Notez que la classification peut indiquer un document comme un type non reconnu, auquel documentType cas . "UNKNOWN"UNKNOWN n'est pas valide attachmentType et ne peut pas être demandé.

Traitement des champs extraits

extractedFields est clairsemée. Elle ne contient que les clés réellement trouvées et lisibles. Un champ absent du document, illisible, ou que l'extracteur a refusé de deviner est totalement omis de la carte — il n'est pas retourné comme null ou sous forme de chaîne vide.

Cela s'applique à toutes les clés, y compris celles requises par les vérifications. Votre code doit gérer toute clé manquante, et ne doit pas supposer que chaque clé listée pour un type de document sera présente dans chaque réponse.

Toutes les valeurs sont des chaînes de caractères.

• Les dates sont normalisées à ISO YYYY-MM-DD. Cette normalisation est effectuée par l'extracteur et contrainte par son schéma de sortie, mais elle n'est pas revalidée par la suite. Considérez une date ISO bien formée comme le cas attendu, et traitez une valeur qui ne parse pas plutôt que de supposer qu'elle le fera.

• Les montants monétaires sont retournés exactement tels qu'imprimés — par exemple "65000.00", "$75,000 per year", ou "120,000 00". Ils ne sont pas normalisés en chiffres. Analysez-les vous-même, de manière défensive.

• Tout le reste est rendu tel qu'imprimé sur le document.

Les données extraites sont produites par le service de validation et diffusées via ce point de terminaison. Elles ne sont pas modifiables via l'API, et il n'y a pas de point de terminaison pour corriger ou remplacer une valeur extraite.

Résultats des vérifications

extractionResult.verificationCheckResults est un tableau de résultats de vérification, présent uniquement à l'issue de l'extraction. Chaque élément :

Il y a quatre vérifications. Lequel d'entre eux s'exécute, et contre quels champs, est déterminé entièrement par le type de document.

Toutes les clés de message sont préfixées esl.error.attachment_verification_check.

Une date manquante ou incalculable produit WARNINGtoujours , jamais FAIL. Seule une date lue avec succès et jugée hors de portée produit FAIL. Ne considérez WARNING pas comme une défaillance douce du document — dans la plupart des cas, cela signifie que la vérification n'a pas pu être effectuée.

Configuration par type :

Notez que data_completeness certains champs que l'extracteur considère comme optionnels — payDate sur une fiche de paie et totalIncome sur une déclaration fiscale en sont des exemples. Un data_completeness défaut de nommer ces champs signifie qu'ils n'ont pas été trouvés sur le document, pas qu'il y a eu un problème.

Intégrité des documents (détection de falsification)

extractionResult.preflight contient les conclusions d'intégrité du document. Sauf null si toutes les informations suivantes sont vérifiées : le compte a activé l'authenticité du document, le type de document est l'un des onze supportés pour l'analyse d'intégrité, le fichier est un PDF ou une image, et l'extraction a été soumise. Parce que l'analyse d'intégrité s'exécute avant l'extraction du champ, elle est également présente sur un résultat dont extractionStatus est FAILED. Elle est absente, en extractionResult elle-même null, chaque fois que l'extraction n'a pas été soumise — un décalage de type, un type non reconnu, une défaillance qualité ou une extraction non activée — donc aucune conclusion n'est perdue dans ces cas ; aucune n'a été produite.

Les onze types supportés sont BANK_STATEMENT, UTILITY_BILL, TAX_RETURN, PAY_STUBINVOICE, CONTRACT, T4_SLIP_CA, , AUTO_INSURANCE_CERTIFICATE, et LIFE_INSURANCE_POLICY PROPERTY_INSURANCEVEHICLE_REGISTRATION. Les documents d'identité avec photo, les chèques annulés et les lettres d'emploi sont exclus : les signaux reposent sur la structure d'un PDF émis et ne s'appliquent pas à une photo de carte.

Dans la version 26.R5, ce bloc est disponible uniquement via l'API. L'interface de l'expéditeur n'affiche pas les résultats d'intégrité.

Quatre vérifications indépendantes sont effectuées sur le fichier, chacune rapportant l'un des quatre résultats suivants :

{
  "checks": [
    {
      "check": "SOURCE",
      "status": "FAIL",
      "messageKey": "esl.error.preflight_check.unexpected_source",
      "params": { "tool": "Canva", "field": "CREATOR", "matchedValue": "WWW.CANVA.COM" }
    }
  ],
  "verifiability": { "inputType": "VERIFIABLE_PDF" },
  "tier": "HIGH"
}

Rendre tier tel que livré. C'est le verdict global unique, et il prend déjà en compte la part du document pouvant être inspectée ainsi que ce que les vérifications individuelles ont trouvé. Ne le re-dérivez pas à partir des statuts de vérification.

params.matchedValue sur un SOURCE résultat, c'est du texte tiré des métadonnées propres du document téléchargé. Il est aseptisé et tronqué, mais provient d'un fichier non fiable — HTML-escape avant de l'afficher.

Limitations

L'analyse d'intégrité examine la structure et les métadonnées d'un PDF. Elle ne lit pas le contenu du document pour juger si ce contenu est véridique, et elle ne peut pas établir qu'un document est authentique. Une conclusion est un prompt pour une revue humaine ; l'absence de conclusions n'est pas une preuve d'authenticité. Parce que la plupart des pièces jointes légitimes sont des scans ou des photos de téléphone, NOT_ASSESSED c'est un résultat courant et attendu. Voir Détection de falsification de document dans le sujet Interface de l'expéditeur pour la déclaration complète de ce qu'elle ne détecte pas.

Rappels et événements

À venir dans 26.R6 : ATTACHMENT_VALIDATION_RESULT

26.R6 ajoute un événement de rappel, ATTACHMENT_VALIDATION_RESULT, abonné comme tout autre événement. Il se déclenche une fois par signataire par transaction, une fois que l'étape de téléversement de ce signataire est terminée et que chaque extraction de ses fichiers a atteint un résultat. C'est message FINISHED lorsque l'extraction de chaque fichier est terminée, ou FAILED quand au moins un ne l'est pas ; sessionUser identifie le signataire et packageId la transaction. L'événement annonce que les résultats sont prêts et ne contient aucun détail par fichier — à la réception, lisez le point de terminaison de vérification. Il supprime le besoin de relire le point de terminaison sur un minuteur.

Erreur et référence de statut

extractionStatus

reasonCode

Résolution d'un null code de raison. Utilisez les champs présents pour exclure les causes terminales avant d'attendre quoi que ce soit. classificationResult.failed Jamais accompagné de code null de raison — une classification échouée rapporte CLASSIFICATION_QUALITY_WARNING toujours — donc l'arbre part d'une classification réussie :

1. classificationResult est null — la classification stockée ne pouvait pas être lue, et l'extraction n'a jamais été lancée. Terminal.

2. L'exigence n'avait extractionEnabled: true pas — l'extraction n'a jamais été demandée. Terminale, et attendue.

3. classificationResult.documentType n'est pas celui attachmentType que vous avez demandé — le type détecté ne correspondait pas, et l'extraction n'a jamais été soumise. Terminal. (Un type correct détecté à MEDIUM ou LOW une confiance n'atteint pas cet arbre : il rapporte CLASSIFICATION_QUALITY_WARNING.)

4. Sinon, l'extraction a été demandée et aucun résultat n'est encore disponible : il est toujours en cours, il a été refusé lors de la soumission (par exemple, le minimum de 1 024 px pour les six types à haut niveau de détail), ou le service de validation n'a pas pu être atteint. Dans la version 26.R5, ces points ne sont pas distingués. Relisez ce point de terminaison à intervalles réguliers avec backoff, et après un temps limité de votre choix, considérez le résultat d'extraction comme indisponible pour ce fichier.

Ce qui peut ou ne peut pas être réessayé. OneSpan Sign exécute la classification et l'extraction une fois par fichier, au téléchargement, et ne les réessaie ni ne révèle de moyen de les redéclencher. Relire ce point de terminaison ne détecte qu'une extraction encore en cours — branche 4 ci-dessus. EXTRACTION_ERROR , et a classificationResult.errorCode de upstream_service_error, sont des résultats stockés pour ce fichier et ne changeront pas lors d'une relecture ; la seule récupération est que le signataire remplace le fichier, qui relance la validation depuis le début. Si l'un ou l'autre réapparaît sur de nombreux fichiers, le service de validation est dégradé — contactez le support OneSpan.

Distinguer la configuration de la défaillance.EXTRACTION_NOT_ENABLED Cela signifie que la fonctionnalité n'a pas été activée — rien n'a mal tourné. Tous les autres codes de raison décrivent quelque chose qui est arrivé au document.

Des limites que vous pouvez vérifier avant de les télécharger

Les limites ci-dessous appartiennent au service de validation et sont distinctes des limites d'envoi des pièces jointes propres à OneSpan Sign (environ 16 Mo, et les types de fichiers autorisés sur le compte). Dépasser les limites de téléchargement rejette le téléchargement. Dépasser les limites ci-dessous ne le rejette pas — le téléchargement réussit et la classification échoue avec le code d'erreur affiché. Les vérifier sur le client évite complètement ces erreurs.

L'extraction applique un minimum plus strict pour six types de documents.T4_SLIP_CA , AUTO_INSURANCE_CERTIFICATE, PROPERTY_INSURANCE, LIFE_INSURANCE_POLICY, et EMPLOYMENT_LETTER VEHICLE_REGISTRATION nécessitent 1 024 × 1 024 px lors de l'extraction en cours. Un fichier entre 200 et 1 024 px passe la classification, puis l'extraction est refusée avant de commencer et rien n'est enregistré — le fichier rapporte extractionStatus: NOT_PERFORMED avec reasonCode: null. Si l'extraction est active pour l'un de ces types, imposez 1 024 px au client.

Les vérifications restantes — image_too_blurry, image_too_dark, image_low_contrast, image_glare_detected — mesurent les pixels et ne peuvent pas être pré-validés par taille ou type. Le flou et l'obscurité s'appliquent à chaque entrée ; le contraste et l'éblouissement ne s'appliquent qu'aux téléchargements de photos (JPEG, PNG, TIFF, BMP, GIF), jamais aux pages PDF ou Word. Un PDF né numérique sans images les saute complètement. Pour les photos, guidez le signataire vers une capture plate, uniformément éclairée, nette sans reflet du flash.

classificationResult.errorCode

Rempli uniquement lorsque classificationResult.failed est true, et seulement avec une des valeurs ci-dessous. Ce sont des clés de traduction, toutes préfixées esl.error.attachment_verification.

Sur la réponse de téléversement. Le client du signataire reçoit immédiatement les mêmes clés, que classificationErrorCode sur chaque fichier de la réponse à l'appel de téléversement ou de remplacement de pièce jointe, afin de pouvoir afficher un message approprié. Cette réponse peut également contenir une clé qui n'apparaît jamais sur classificationResult.errorCode: type_mismatch — le type détecté ne correspond pas au type demandé. Un fichier transporte au maximum une clé à cet endroit ; un problème de qualité prime sur un décalage. Sur le point de terminaison des vérifications, un décalage est exprimé par typeMatch et documentType à la place. La réponse de téléversement porte verificationResultUuidégalement , la même valeur que classificationResult.documentUuid.

« Aucun résultat » indique

Un résultat vide n'est jamais une erreur. 204 Cela signifie qu'aucune validation n'a été validée sur cette transaction, qui est l'état normal pour une transaction n'utilisant pas cette fonctionnalité.

Conciliez ce tableau avec les fichiers que vous savez avoir été téléchargés. Chaque fichier téléchargé est listé dans attachmentRequirements[].files[] le rôle. Un fichier dans cette liste mais absent de ce tableau n'a jamais été validé — le service était inaccessible lors de son téléchargement, ou la validation n'était pas configurée pour ses besoins à ce moment-là. Considérez cela comme un état explicitement non validé et montrez-le ainsi : relire ce point de terminaison ne le modifiera pas, et la seule façon de valider le fichier est que le signataire le remplace. Ne le confondez pas avec un fichier présent avec extractionStatus: NOT_PERFORMED un null reasonCode et — résolvez-le avec l'arbre de décision sous reasonCode.

Marquez comme révisé via l'API

PUT    /aws/rest/services/packages/{packageId}/attachment/{attachmentId}/file/{fileId}/reviewed
DELETE /aws/rest/services/packages/{packageId}/attachment/{attachmentId}/file/{fileId}/reviewed

PUTmarque le fichier comme examiné ;DELETE annule-le. Aucun ne prend de corps de requête. Les deux reviennent 200 avec la mise à jour AttachmentFile, et nécessitent tous deux des privilèges d'édition de transaction. A fileId qui n'appartient pas aux retours 404 error.validation.AttachmentFileNotFounddonnés attachmentId .

Le nom du champ API est reviewed, et la fonctionnalité est Marquez comme Examiné ; la piste d'audit l'enregistre comme Marqué comme Vérifié. Pour ce que l'action signifie et ne fait pas — toujours disponible, ne relance jamais ni ne réactive les résultats, ne notifie jamais le signataire — voir Marquer comme Examiné dans le sujet Expéditeur UI.

Cinq champs sur AttachmentFile portent l'état. Ils sont également renvoyés partout AttachmentRequirement.files[] où un rôle ou un package est lu, vous pouvez donc voir l'état de révision sans appeler le point de terminaison des vérifications :

• Marquage définit reviewed, reviewedBy et reviewedAt, et efface unreviewedBy et unreviewedAt.

• Défaire des ensembles reviewed de false et records unreviewedBy et unreviewedAt, tout en préservant l'original reviewedBy et reviewedAt comme l'histoire.

• Annuler un fichier qui n'a jamais été marqué, ou qui n'est déjà pas marqué, est une opération interdite qui renvoie l'état actuel.

• Remplacer ou supprimer un fichier supprime son état de relecture.

Trace d'audit

Marquer un fichier comme examiné et le retirer produit les entrées Mark as Verified d'audit et Undo Verification — les noms des traces d'audit pour ces actions — aux côtés de l'existant Upload File Attachment et Download File Attachment, tous récupérables depuis GET /aws/rest/services/packages/{packageId}/audit. Aucun résultat de classification, valeur extraite, résultat de vérification ou constatation d'intégrité ne produit une entrée d'audit dans 26.R5 — si vous avez besoin d'un enregistrement durable de ce que la validation a rapporté à un moment donné, capturez-le vous-même depuis le point de terminaison de vérification.