LogoLogo
  • API Documentation
  • Authentication
  • Testing
  • Contact Support
  • System Status
  • VX
    • Create Session
    • API Methods
  • Agematch
    • United States
    • United States (DMV)
    • International
    • With KBA Quiz
    • Selfie Age Estimation
  • IDMATCH
    • United States
      • With KBA Escalation
      • KYC/CIP Compliance
      • COPPA Compliance
    • International
  • idmatch+
    • United States
  • IDMATCH+PREDICT
    • Fraud Score
  • phonematch
    • Verification and Validation
      • Smart 2FA
      • Phone Verification
      • Phone Validation
    • One Time Passwords
      • SMS
      • Call
    • Message Delivery
      • Dialer
  • emailmatch
    • Email Validation
  • dcams
    • Document Capture and Management Services
      • Scanning Basic
      • Scanning Enhanced
      • Manual Review
      • Storage
        • Create or Update a Customer
        • Get Customer Status
        • Get Customer Document Images
        • Update Customer Status
      • iFrame
        • Canned Responses
        • Create Token
        • View Callback
        • User Status
        • Generate Link
      • Swift SDK
      • Android SDK
  • Bouncer
    • Overview
    • Bouncer as an add-on
  • V-PIN
    • Overview
    • V-PIN as an add-on
    • V-PIN Stand Alone
  • Service Coverage
    • Data Coverage
  • Testing
    • Test Cases
    • Answers to KBA Questions
  • Reporting
    • Audit
  • API Processing Errors
    • Error Returns
  • Knowledge Base
    • Best Practices
    • Understanding Veratad Services
  • IDMax
    • IDMax Button Creator SDK
Powered by GitBook
On this page
  • What is a service?
  • What if I have multiple goals?
  • What if I want a different rule set?
  1. Knowledge Base

Understanding Veratad Services

PreviousBest PracticesNextIDMax Button Creator SDK

Last updated 4 years ago

What is a service?

A Veratad service is defined by four attributes:

  • The goal(s) of the service transaction

For example, the AgeMatch service goal is to discover the target's age, while the PhoneMatch service goal is to discover the target's phone number. With both services you can still verify other data points, but the main goal is as above. See the What if I have multiple goals section below for more details.

  • The data sources to be accessed

For example, the AgeMatch service may have additional data sources that are age specific and only beneficial if you are trying to verify an individual's age. While the PhoneMatch service may have phone number specific data sources that are only useful when you are attempting to verify a phone number.

  • The base evaluation rules

Each service has a distinct base rule set that will run on each transaction. That said, if you require something other than the base this is as simple as changing the rules attribute value in the query.

For example, AgeMatch has a base rule set that consists of the following: target is found, is not deceased and meets the minimum age requirement. But, if you want to ensure the Year of Birth always matches in order to receive a PASS you would just set the rules attribute to AgeMatch5_0_RuleSet_YOB . Most service descriptions include pre-made rule sets, but if you require a different rule set from what is documented please contact your Veratad Representative and they will configure and provide the name.

  • The required inputs

For example, when you run AgeMatch you will never be allowed to process without setting the age attribute and with PhoneMatch you will never be able to process without the phone attribute.

What if I have multiple goals?

Not a problem! All Veratad services can be customized and coupled. So, for example, if your goal is to verify a user's age and their phone number Veratad will create a service that has these goals for your business. During this creation process Veratad will also ensure you are accessing the correct data sources to accomplish them efficiently.

What if I want a different rule set?

Not a problem! Rule sets can be customized and provided to you for any Veratad service. Using a custom rule set is as simple as including the custom rule set value in the rules attribute in your initial POST request.

You can also have as many rule sets as you require, that way you can adjust the rules per transaction for the same service.