Implementation Guide: Vouched Phone Number Data Requirements

In an effort to enhance the Identity Verification (IDV) process, Vouched is introducing a new data requirement that will soon mandate the inclusion of mobile phone numbers in its system. To ensure a smooth transition for our customers, we have outlined the necessary changes for each implementation method.

This article will cover the following implementation guides:

• Vouched Plugin via Alloy SDK with Journeys
• Legacy Alloy SDK using Vouched Plugin
• Alloy API

If you have any questions about the new data requirement or require guidance about your implementation, please reach out to support@alloy.com.

Vouched Plugin via Alloy SDK with Journeys

This section will cover the implementation changes for Vouched Plugin via Alloy SDK with Journeys. Follow this implementation guide if your Alloy implementation includes using Journeys with a step-up for documentation verification coupled with a workflow configured with the Vouched Plugin.

When making the first POST/applications API call to create an application and run it through the Journey, ensure that the phone number is supplied as a top-level field with the key phone_number. The phone number should be passed as a string-type and it’s recommended to adhere to E.164 format, however, any of the formats in the example are supported.

Sample Code:

{
  "phone_number": "xxxxxxxxxxx",
  // Additional application data
}

Once phone number is supplied to Alloy, make sure your code that is initializing the Alloy SDK includes the journeyApplicationToken in the initialization parameters. This will ensure that Alloy grabs the supplied data about the entity, including the phone number, and sends it to Vouched when loading the Vouched Plugin.

Legacy Alloy SDK using Vouched Plugin

This section will cover the implementation changes for the Vouched Plugin via Legacy SDK. Follow this implementation guide if you are using Alloy’s SDK to run Document Verification step-up without Journeys. Your Document Verification workflow would also be configured with the Vouched Plugin within the SDK Config workflow setting.

The key phoneNumber should be added as a top-level field in the evaluationData object. The phone number should be passed as a string-type and it’s recommended to adhere to E.164 format, however, any of the formats in the example are supported.

Sample Code of SDK Init Params:

const alloyInitParams = {
    evaluationData?: { 
        phoneNumber?:string;
        // Additional evaluation data
    }
        // Additional init params
}

Alloy API

If you are using neither of Alloy’s SDK and instead collecting documents through your own in-house tool or a third-party, then your implementation of Alloy may be a combination of sending documents through the /documents API followed by a request to create an application or evaluation in Alloy.

When you make the request to Alloy to supply the application data, you may be configured with a Journeys implementation, Workflow-only implementation, or your account may have a mix of both.

• If leveraging Journeys to create applications in Alloy, then you would be using the POST/applications API endpoint.
• For those not utilizing Journeys, then you would be creating evaluations in Alloy using the POST/evaluations API endpoint.

For either API endpoint, ensure that the phone number is supplied as a top-level field with the key phone_number. The phone number should be passed as a string-type and it’s recommended to adhere to E.164 format, however, any of the formats in the example are supported.

Sample Code:

{
  "phone_number": "xxxxxxxxxx",
  // Additional application data...
}