Skip to main content

Enrolment

Due to the way FSS data is gathered, no two individual signatures will be the same. The Verification SDK measures a signature's consistency and variability to verify whether or not the signature is authentic.

Every signature a person creates will be different to some extent, but the level of variation will depend on the person. GSV provides a mechanism to create a template for each person in which a reference set of known genuine signatures is stored. Questioned signatures can then be tested to see if they are consistent within the range of variability measured.

This page outlines the steps to be followed when using GSV.

Enrolment​

A separate template must be created for each person, together with the appropriate configuration options to control how it behaves.

The template options cannot be changed after the first signature has been added. Most importantly, the number of signatures required to complete the enrolment must be set if the default setting of 6 isn't appropriate. The time between template updates and whether size normalization is used should also be set at this stage.

Once the template has been created, the reference signatures must be added using the VerifySignature method. This should continue until the template status changes to 'Enrolled'. The following should be noted:

  • During the enrolment stage, a comparison result is reported using 1:1 verification after each signature is added.

  • Known genuine signatures must be enrolled until the template status has changed from 'Enrolling' to 'Enrolled'. This might require more than the expected number of samples.

    For example, if the enrolment size is set to 6 it might be necessary to enroll 7 or more signatures if there is excessive variability.

  • Each template can handle one signature style each. If a person changes their style, e.g. "John Smith" changes to "J S", then the template won't enroll.

  • Each template can handle both static and dynamic samples from the same person, provided the signing styles are the same.

  • Every enrolment signature must be unique. The same signature must not be enrolled more than once, because in order to measure signature variability, different signature samples are needed. If an attempt is made to enroll a dynamic sample a second time, it will be rejected. Rejection is based on comparing the date/time of captures. NB: This protection isn't possible with scanned images.

  • Scanned images must be cropped and cleaned, such that the image contains only the ink of a single signature. See Implementation Requirements for Static Signature Verification.

Verification​

Signatures of uncertain authenticity can be verified once the template status is fully enrolled. The same method, VerifySignature, is used, but the comparison process takes into account the observed variability of the enrolment signatures, thus allowing a more accurate assessment to be made. The following should be noted:

  • Templates that are used to handle both static and dynamic data will achieve fully enrolled status at different times. It is important to check the status of the template for the type of signature being verified.
  • The template status will change to "Updated" from time to time. This indicates that the last signature verified was a good match and that enough time has passed since the last template update for it to replace the oldest signature in the reference set. The default update period is one month but can be configured when the template is created.
  • The result of each verification is a score of between 0 (inconsistent) and 1 (consistent). It is up to the system implementer to decide what score should be considered acceptable. A minimum of 0.5 should be used as a pass, but higher values might be appropriate to meet higher security requirements.
  • The same requirement for scanned images to be cropped and cleaned apply as for the enrolment stage.