[email protected]'s account

Hi Brian,

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

Thanks

-Will

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

Hi Brian,

In the "Identity Verification only Workflow with UAT testing rules", you must use real data and real documents and matching live face.  It will fail if any of the values do not match.  With regards to the specific data you are requesting, it will depend on the document and if the document contains those items.  For example, most US Passports do not include the Address and as such, the address does not need to be included in the transaction in order to validate the transaction.

With regards to the expiry_timestamp and erasure_mark, in the POC environment, those are predefined and can not be changed.  You can mark a transaction for erasure before the time listed, but it can not go past the time listed.

Hope this helps

-Will

Hi Brian, 

Transactions can be stopped and started with the same Transaction ID for up to 15 days in the POC environment.  After the 15 days, a new transaction will need to be created.  If the user fails the transaction, they have up to 15 days to attempt the transaction again as well.  You will see this message in the transaction if you choose to exit the transaction before it is completed.  Users can only retry a transaction up to 3 times in the POC environment.

Thanks

-Will

Hi Brian,

Sorry last week was a difficult week for me.

1. For POC how should groups and role be populated is there documentation already on the site or can you proide guidance.
   1. For the current POC, we only have a simple configuration allowed. 
      For the "users" component, the role must be set to "Customer"
      For the "tokens" component, the role should also only be set to "Customer"
2. How does the user model handle fields where there is a minimum length of 1 but that information is not applicable or null.  For example house_name, house_number, and flat_or_apartment_number all have min length of 1 but any given address will only have one of these variables.  In this instance can a all the fields be populated with the data.
   1. Yes, you can populate fields with data even if the data is not used for verification.  The data captured will be put into the audit trails.
3. As above where you say details are not included on a given ID (for example gender not on UK driving licence) do we populate an empty string or just not include the property.
   1.  The more data you populate, the more data you can put in your audit trails.  You can leave empty attributes completely off the transaction json.  So if the gender is empty, then you do not need to include the "gender" attribute in the "users" objects.

Thanks

Will