It is ultimately up to the organization to handle how to employ Input Attributes in a workflow. The workflow may check a single or multiple data field(s) from the supplied payload sent via API as Input Attributes. These Input Attributes can then be leveraged in informational and/or decisional tags. For example, Input Attributes can allow a workflow to auto-Deny an application if the applicant is under 18 years of age. You can also use Input Attribute data to decide whether to run or not run certain data services.

Below are some examples of use cases for Input Attributes:

When checking if a field is not provided:

• {field_name} != (blank)

Above is a classic example of checking if a field is not provided to decide whether to run or not run a data service (e.g., Inscribe).

Based on the address:

• Checking if the applicant is inside a given US state

  

• Checking multiple US states

  

• Checking if the applicant is outside a given US state

  

• Checking if the applicant is within a given area based on the first two digits of the zip code

In the above case, regex (regular expression) filters a range of regions using the zip code data of the applicant. The “Zip Code Rejected” tag will fire for any zip codes that begin with a 66 or 65.

• Checking the applicant’s address country

  

Based on age:

• Checking if the applicant is under 18 years of age

  

• Checking if the applicant is within a specific age range

  

Based on the product:

• Checking if the applicant is applying for/using a specific product

  

• Checking the applicant’s product ID

  

Based on the funding information:

• Checking if the applicant is using a specific funding source provider

  

Based on the employer information:

• Checking the applicant’s employer information

  

• Checking the applicant’s employment/occupation period/length

Based on the new or existing customer info:

• Checking if the applicant is an existing customer

  

In the above case, if the applicant is not an existing customer (meta.IsExistingCustomer = false), then the specified data service (e.g., Socure) will run.

Based on whether the application is a Joint application:

• Checking if the applicant is part of a Joint application

  

• Checking if the applicant is a Primary or Secondary account holder

  

Fraud check use cases:

• Example of multiple Input Attributes considered in a tag

  

The tag checks for the merchant ID and transaction shipping address or item type in the above case.

• Example of Input Attribute used with other informational tags

  

In the above case, the data service (e.g., LexisNexis InstantID Q&A) will only run if the above conditions are met. The Input Attribute skip_KBA (more on Knowledge-Based Authentication (KBA) here) is one of the conditions that affect whether the data service runs.

There are various ways to send and leverage supplied data as Input Attributes. Input Attributes can be used as informational or decisional tags (e.g., deciding to run certain data services or deciding on an evaluation outcome). These tags are highly customizable.

Please don’t hesitate to contact support@alloy.com for further assistance and consider these other helpful articles:

• How to add Input Attributes in workflows
• How to add decisional Input Attributes in a workflow