Application Funnel and Screen Requirements

Prove Pre-Fill is required to sit at the beginning of the application funnel. After the client product page where the consumer selects “apply now” or “open account”, the CX screen should move to the Mobile Auth Authentication Page Requirements or Challenge Page

There should be no additional screens ahead of Pre-Fill or in between Pre-Fill steps. The CX requirements are in order and provide the EXACT number of screens expectedIf the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide 

Link to Objection Handling

Mobile
(Same Domain)

When Client Product Page and Challenge Data Page are same domain and Mobile Auth implemented

US MNO-required language should be displayed and implicitly accepted (referenced in Terms and Conditions)

Implicit US MNO Carrier Language

Example: If “apply now” page is www.capitalone.com and application flow stays on this domain

If the customer attempts to deviate, IPM needs to follow rulebook outlined in (Implementation Guide)

Mobile
(Cross-Domain*)

*please talk to your Implementation lead to confirm if applicable

When Client Product Page and Challenge Data Page are cross-domain and Mobile Auth Implemented

Do not insert MNO language

Do not insert MNO language

MNO Consent will need to live on challenge data page. See details there.

Example: if “apply now” page is www.lowes.com and application flow moves to apply.syf.com

Mobile

For Phase 1 Implementation prior to Mobile Auth Implementation

Do not insert MNO language

Do not insert MNO language

No MNO Language Needed for Phase 1

Desktop

Instant Link

Do not insert MNO language

Do not insert MNO language

[CURRENT STATE] For Phase v0.5 if MNO is in scope for Instant Link, customer WILL need to insert MNO language on the challenge data page for Instant link.

[FUTURE STATE] In Phase 1, No MNO Language will be needed for Instant Link because the MNO check will not included in P1 and P2 by default  unless client has add-on InstantLink+

Required Language

Let’s Begin By Finding Your Info

We can prefill some of this request like your name, address, and contact info for you

We do not recommend any variation from this language. If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

If same domain and Mobile Auth Passed

Challenge data field only

Displaying the challenge data only is ONLY for same-domain Prove customers
‍
Example: If “apply now” page is www.capitalone.com and application flow stays on this domain

If cross-domain

Challenge data first
Then
Phone number field

If landing page is different from domain of Prove customer, the Challenge Page MUST have challenge data and phone number because MNO consent has to be collected on this page

Example: if “apply now” page is www.lowes.com and application flow moves to apply.syf.com

If Mobile Auth fails

Challenge data first
Then
Phone number field

Note: This would apply to both Desktop and Mobile Flows
‍
‍When to attempt MobileAuth: ‍

• Customer can use existing tools (such as libraries, UA tools etc) to know when consumer is coming from Desktop vs Mobile and send down appropriate pathNote: This would apply to both Desktop and Mobile Flows

• Alternatively customer can attempt MobileAuth irregardless of device

Prove CIP+

“Full SSN/ITIN”
In data entry field

Full 9-digit SSN

Prove CIP+ is the P2 SKU

If P2 (compliance) SKU is in scope, full SSN entry is mandatory to satisfy banking compliance requirements

If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

Prove US Pre-Fill

Customer can choose one from the following prompts:
“Last 4 SSN/ITIN”
“SSN/ITIN”
“MM/DD/YYYY”
"MM/YYYY"
"MM/DD"

Last 4 SSN/ITIN
Full SSN
Full DOB
DOB - Month & Year
DOB - Month & Day

Note: Customer can choose what format to prompt from the consumer (whether its a scroll button on DOB or MM/DD/YYYY) as long as they pass in the correct formatting into the API request

If Mobile Auth Failed
or
Desktop Flow
or
MNO consent not collected

Mobile Phone Number
(in data entry field)

(___)___-____

Prove US Pre-Fill

Customer can choose one from the following prompts:
“Last 4 SSN/ITIN”
“SSN/ITIN”
“MM/DD/YYYY”
"MM/YYYY"
"MM/DD"

Last 4 SSN/ITIN
Full SSN
Full DOB
DOB - Month & Year
DOB - Month & Day

When cross-domain Mobile Auth Implemented

US MNO-required language should be implicitly accepted on this page

Implicit US MNO Carrier Language

Example: if “apply now” page is www.lowes.com and application flow moves to apply.syf.com

If Trust Score+ add-on to Pre-Fill is in scope

US MNO-required language should be displayed and implicitly accepted

Implicit US MNO Carrier Language

This would only apply if MP9 is an add-on. Trust+ is NOT in scope of P1 or P2 by default

If consumer already completed Mobile Auth

Do not present opt out option

Implicit US MNO Carrier Language

There should be no opt out button here, only the challenge data. If the customer attempts to deviate, IPM needs to follow the rulebook outlined in Implementation Guide

If Mobile Auth Ineligible

I don’t have a mobile number

Send customer to manual entry screen

There should be no retries (see possession check policy)

If the customer attempts to deviate, IPM needs to follow the rulebook outlined in Implementation Guide

Required Language

Verify Your MobilePlease enter the code we just sent to
(XXX) XXX-7890

If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

Required Language

4-6 digit code

OTP needs to be entered within 5 minutes of the SMS being sent before dropping user to manual entry flow

Would suggest auto-populating this code into the web form field.

If Possession Check Policy Passed
AND
Trust Policy Passed
AND
Pre-Fill API call Succeeds

Verify Now

Moves consumer to consumer’s PII Pre-Filled Page

There should be no intermediate page after the SMS entered. Consumer should land directly on Pre-Filled PII page or if Pre-FIll failed for any reason, land on the manual PII entry page.

Link to Implementation Guidance

If Possession Check Policy Failed
OR
Trust Policy Failed
OR
Pre-Fill Call Failed

If Possession Check Policy Passed
AND
Trust Policy Passed
AND
Pre-Fill API call Succeeds

PII Manual Entry Page

Max Characters

The entire text is required to be <=160 characters total including the OTP code. Going over 160 characters will cause issues with any MNO that does not concatenate messages that spill over

Required Language

Make sure everything is correct

We do not recommend any variation from this language. If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

First Name

Yes - no masking

Yes

Upon Edit, Call Verify

Last Name

Yes - no masking

Yes

Upon Edit, Call Verify

Address

Yes - no masking

Yes

Upon Edit, Call Verify

Extended Address

Yes - no masking

Yes

Upon Edit, Call Verify

City

Yes - no masking

Yes

Upon Edit, Call Verify

State

Yes - no masking

Yes

Upon Edit, Call Verify

Postal Code

Yes - no masking

Yes

Upon Edit, Call Verify

Phone Number

Yes - no masking

No

Upon Edit, repeat PRO

If customer wanted this to be editable, Consumer must repeat PRO

SSN

Mask first 5 (display last 4)

The last 4 is required to be displayed to consumer for their review.

Please speak to your Implementation Lead if you do not need the consumers SSN as part of your onboarding flow.

Yes

Upon Edit, clear the data, require consumer to enter full SSN and Call Verify. First 5 of SSN should always remain masked

Customers should not mask the whole SSN, this defeats Product benefit of reviewing data.

If the client is collecting DOB as Challenge data and does NOT want to display the SSN, we will enforce the following:
We will not allow the SSN value to return on the Pre-Fill response (we will disable this field in the API response via the payfex config)

If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

DOB

Yes - MM/DD/YYYY

Yes

Upon Edit, clear the data, require consumer enter full DOB MM/DD/YY and Call Verify

First Name

Yes - no masking

Yes

Yes

Last Name

Yes - no masking

Yes

Yes

Address

Yes - no masking

Yes

Yes

Extended Address

Yes - no masking

Yes

Yes

City

Yes - no masking

Yes

Yes

State

Yes - no masking

Yes

Yes

Postal Code

Yes - no masking

Yes

Yes

Phone Number

Yes - no masking

No

No

If edited, Consumer must repeat PRO

SSN

Mask first 5 (display last 4)

The last 4 is required to be displayed to consumer for their review.

Please speak to your Implementation Lead if you do not need the consumers SSN as part of your onboarding flow.

No

Do not allow edit.

Justification: Consumer entered full SSN - it should not be editable

DOB

Yes - MM/DD/YYYY

Yes

Upon Edit, clear the data, require consumer enter full DOB MM/DD/YY and Call Verify

Justification: Consumer did not enter this - it was returned from Prefill. CIP compliance would dictate Address, DOB and SSN need to come directly from the consumer or be editable

Checkbox

Yes - Check box with the text: "I have reviewed the infomation provided and confirm its accurate"

N/A

N/A

Edit Button

Should be below the pre-filled data.

Should be one edit button TOTAL and below the pre-filled data

We do not recommend any variation from this language. If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

Required Language

Let’s Complete your Application

We would recommend limiting additional fields to the very minimum required to open the account/apply for product. The key is the minimum required.

Example fields you may wish to include are:
• Email address
• Confirm email address
• Income

We do not recommend any variation from this language. If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

Consumer Confirmation

You are required to include the following statement just above the “submit” button:
‍I have reviewed the information provided and confirm it is accurate

If desired, you can include a check box by this statement but it is not required

This is a new statement required for customers to include by Prove Legal as of Jan 2024.

Submit Button

This button should convey a clear and decisive action, the button should alert the user of a final state.For example button can say ‘Submit’ or ‘Apply now’ signifying that the user will not be given the option to go back after proceeding.

Application submission should occur on the submit button

Customer should NOT have more screens with data entry before opening the account/applying for the product. Those steps should come POST acquisition. If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

Required Language

Your Information

All fields are required unless stated otherwise.

We do not recommend any variation from this language. If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

First Name

Yes

Last Name

Yes

Street Address

Optional

Apartment Number

Optional

City

Optional

State

Optional

Postal Code

Optional

Phone Number

Yes

SSN

Optional

DOB

Optional

Required Language

Customer discretion

We would recommend limiting additional fields to the very minimum required to open the account/apply for product. Save additional steps for afterwards to minimize friction to consumer or a combo of this and what you said just above. The key is the minimum required.
Example fields you may wish to include are:
• Email address
• Confirm email address
• Income

Submit Button

This button should convey a clear and decisive action, the button should alert the user of a final state.

For example button can say ‘Submit’ or ‘Apply now’ signifying that the user will not be given the option to go back after proceeding.

Application submission should occur on the submit button

Customer should NOT have more screens with data entry before opening the account/applying for the product. Those steps should come POST acquisition.

If the customer attempts to deviate, IPM needs to follow rulebook outlined in Implementation Guide

Verizon and/or T-Mobile

Prove WEB SDK or FETCH (AJAX) Implementation

Please talk to your Implementation lead for more details

Pixel is also an option but Fetch is easier to implement

ATT and Verizon and
T-Mobile

Prove Web SDK or PIXEL Implementation (image load)

Prove customer implements an HTML 10x1 pixel image load and assigns the redirect URL to that image source <img src=“the redirect url that you got from the /ABR call goes here”>

If the GET call is successful, the FinalTargetURL with VFP would load in the 10x1 pixel

Please talk to your Implementation lead for more details