will.lasala@on… | Posts: 16

Rapid Proof Of Concept/Technical Evaluation - IDV Launcher - Description of predefined matcher settings

0 votes

Hi Everyone,
We recently received an email asking for more detail regarding how the Rapid Proof of Concept and the Technical Evaluation - IDV Launcher, are configured for the matcher settings.  The matcher settings are the internal values for the IDV backend that set the threshold for when a value is allowed to be accepted and thus allowing the transaction to pass or fail.

Matchers can be configured in 2 different ways, "execute_only" or "affects_verification_status".  When a matcher is configured to "execute_only", the value is still evaluated, but the outcome is not taken into consideration as to whether or not the IDV transaction passes or fails.  The "affects_verification_status" tells IDV to use the value to affect whether the transaction passes or fails.  This "behavior" setting is in contrast to the "enabled" setting.  The "enabled" settings tells IDV whether the specific matcher is evaluated at all.  If "enabled" is set to false, then the matcher is not run, if it is set to true, then the matcher is run and the "behavior" setting is used.

Different backend IDV providers allow for different matchers to be allowed per workflow.  There are many common matchers that are available for all workflows.   Please use this forum post to determine which workflow is which: https://community.onespan.com/forum/rapid-proof-concept-supported-workflow-ids-and-descriptions.  Here is how the RPOC and TE-IDV Launcher are configured for the common matchers:

  • address_match

    • The address match matcher checks to see if the address provided in the transaction matches the address captured during the document scanning.

    • For all workflows this matcher is disabled

    • Please remember that Passports do not have addresses, and many other ID's and other countries drivers licenses also do not have addresses on them.

  • date_of_birth

    • ​​​​​​​The date of birth matcher checks to see if the value entered in the transaction matches what has been scanned from the document

    • For all workflows except the "UAT testing rules" workflows, this matcher is disabled

    • For the "UAT testing rules" workflows, this matcher is enabled and the behavior is set to "execute_only"

  • date_of_expiry

    • ​​​​​​​The date of expiry matcher checks to see if the document being scanned has expired.

    • For all workflows this matcher is enabled, and for all workflows except the "UAT testing rules" workflows, the behavior is set to "execute_only"

    • For the "UAT testing rules" workflows, the behavior is set to "affects_verification_status"

  • document_authenticated
    • ​​​​​​​The document authenticated is a matcher that allows the provider to tell IDV if they suspect that the document being scanned is a genuine version of the document
    • For the "North American (US/CA) Drivers License Support" workflow, this is enabled and the behavior is set to "affects_verification_status"
    • For all other workflows, this is disabled. 
  • document_number

    • ​​​​​​​The document number is a matcher that evaluates whether the document number entered matches the one scanned from the document picture.

    • For all RPOC and TE-IDV Launcher workflows, this matcher is disabled.

    document_supported
    • ​​​​​​​The document supported matcher checks to see if the document that has been captured is a supported document type for the country and provider.

    • For the "North American (US/CA) Drivers License Support" workflow, this is enabled and the behavior is set to "execute_only"

    • For the "UAT testing rules" workflows, this matcher is enabled and the behavior is set to "affects_verification_status"

    • For the other workflows, this match is disabled

  • name
    • ​​​​​​​The name matcher checks to see if the name entered matches the name scanned on the document.

    • For all workflows, except the "UAT testing rules" workflows, this matcher is not enabled

    • For the "UAT testing rules" workflows, the matcher is enabled and the behavior is set to "affects_verification_status"

Here are additional matchers for the "UAT testing rules" workflows and the "development friendly rules" that are not "North American (US/CA) Drivers License Support":

  • face_similarity

    • ​​​​​​​The face similarity matcher is a matcher to determine if the faces captured match the face in the document captured

    • For "UAT testing rules" workflows, this matcher is enabled and the behavior is set to "affects_verification_status"

    • For "development friendly rules" (not North America) workflows, the matcher is disabled.

  • person_alive

    • ​​​​​​​The person alive matcher is used to determine if during the face capture, the provider was able to determine if the person was alive during the image capture

    • For "UAT testing rules" workflows, this matcher is enabled and the behavior is set to "affects_verification_status"

    • For "development friendly rules" (not North America) workflows, the matcher is disabled.

  • selfie_authenticity

    • ​​​​​​​The selfie authenticity matcher is used to determine if during the face capture, the provider was able to determine if the selfie being taken was a true live image selfie

    • For both the "UAT testing rules" and the "development friendly rules" (not North America) workflows, this matcher is enabled

    • For the "UAT testing rules" workflow, the behavior is set to "affects_verification_status", while for the "development friendly rules" (not North America) workflows, the behavior is set to "execute_only"

  • unduplicated_selfie

    • ​​​​​​​The unduplicated selfie matcher is used to determine if the provider returned whether it thought the face captured was in fact a real face instead of a previously captured picture of a face

    • For "UAT testing rules" workflows, this matcher is enabled and the behavior is set to "affects_verification_status"

    • For "development friendly rules" (not North America) workflows, the matcher is disabled.

 

In addition to these matchers, there are also thresholds that are combined and leveraged when a matcher is being evaluated by IDV.  Similarly to the matchers, there are some common thresholds and some thresholds that are only available for certain providers.

Here are the current configuration settings for the RPOC and TE-IDV Launcher workflows.

  • name_match_threshold

    • ​​​​​​​The name match threshold is used to provide a threshold for deciding whether the name entered during the transaction creation matches the name that was captured during the document scanning.

    • For all workflows this threshold is set to 70%

  • similarity_threshold

    • ​​​​​​​The similarity threshold is used to provide a threshold for deciding whether the captured face matches the face in the captured document

    • For the "North American (US/CA) Drivers License Support" workflow and the "UAT testing rules" workflows, the threshold is set to 70%

    • For all other workflows, the threshold is set to 10%

As with the matchers, here are additional thresholds for the "UAT testing rules" workflows and the "development friendly rules" that are not "North American (US/CA) Drivers License Support":

  • document_authenticity_threshold

    • ​​​​​​​The document authenticity threshold is the threshold for deciding whether the document is considered to be real for the current country and document type.

    • For both the "UAT testing rules" and the "development friendly rules" (not North American) workflows, the threshold is set to 80%

  • selfie_authenticity_threshold

    • ​​​​​​​The selfie authenticity threshold is the threshold for deciding whether the face captured is considered a real face.

    • For the "development friendly rules" (not North American) workflows, the threshold is set to 10%

    • For the "UAT testing rules" the threshold is set to 70%

  • unduplicated_selfie_threshold

    • The unduplicated selfie threshold is the threshold for deciding whether the face that has been captured is a duplicate of a picture of the face.​​​​​​​

    • For the "development friendly rules" (not North American) workflows, the threshold is set to 10%

    • For the "UAT testing rules" the threshold is set to 70%


brmg | Posts: 13

Reply to: Rapid Proof Of Concept/Technical Evaluation - IDV Launcher - Description of predefined matcher settings

0 votes

Hi Will,

I have a few questions arising out of this:

  1. With the document_authenticated matcher disabled in RPOC, can you clarify how it would authenicate the id as genuine if it were active.  Does it look for security features etc?
  2. Does the name_match take title into account?

Thanks


will.lasala@on… | Posts: 16

Reply to: Rapid Proof Of Concept/Technical Evaluation - IDV Launcher - Description of predefined matcher settings

0 votes

Hi Brian,

I need to look into this for you, I will get back to you shortly.

Thanks

-Will


will.lasala@on… | Posts: 16

Reply to: Rapid Proof Of Concept/Technical Evaluation - IDV Launcher - Description of predefined matcher settings

0 votes

Hi Brian,

Sorry for the delay.

When it comes to our matchers and how we interact with our providers there are multiple layers.  The matchers are used to ultimately determine if a transaction was successful or failed.  By disabling a matcher, that matchers outcome is not taken into consideration when the transaction decision is considered.  However, our providers still add a level of detail on top of this, and within the SDK being used to capture the document there are still validations and checks that are being performed to help reduce the number of false positives and to stop the processing of un-supported/un-authenticated documents.  In this case, the matcher is not using this to determine if the document was authentic, but the provider is still checking to see if it should be allowed to be processed at all.

With regards to a title in the name matcher, we do not include that in our fuzzy matching system, instead it can be included directly in the transaction JSON as "title".

Thanks
-Will


brmg | Posts: 13

Reply to: Rapid Proof Of Concept/Technical Evaluation - IDV Launcher - Description of predefined matcher settings

0 votes

Hi, in the original post the it mentions that matcher behaviour can be configured in the live version.  Does this include their pass/fail threshold can they also be configured?

 

Thanks


will.lasala@on… | Posts: 16

Reply to:

0 votes

Hi Brian,

There are many thresholds you can modify, each provider has different matchers and each of those matchers can be modified and tweaked.  In some cases it is not simply a "true"/"false" answer, sometimes its a threshold value from 0 to 100 or 0 to 1000.  During your production integration, your professional services engineer should be able to walk you through these different values.  You can setup multiple environments and have different configurations for the matches for different environments.

-Will


Hello! Looks like you're enjoying the discussion, but haven't signed up for an account.

When you create an account, we remember exactly what you've read, so you always come right back where you left off