Request Documents for Application Review

1. An account holder card product application with an IN_REVIEW status
2. Access to the Highnote API, API Explorer, or dashboard

In some cases, applications can be flagged for review because additional account holder verification information is needed. This review process confirms the identity of the person or business and ensures compliance with Know-Your-Customer (KYC) or Know-Your-Business (KYB) regulations.

When an application is flagged for review, it inherits the status IN_REVIEW. Applications with an IN_REVIEW status return one of two responses:

• A response with a request that additional documentation is needed from the applicant
• A response that does not require additional documentation

You can use the Application Status Event Notifications to send an email or push alerts to account holders to alert them of the application review status and direct them to your document upload UI flow. In your document upload UI flow, you can use the Highnote API to generate URLs for each required document, allowing account holders to upload documents directly from your application or website.

Once the account holder has uploaded their documents, a Highnote agent reviews the documents and takes the following actions:

• Approve the application: This indicates the documents were verified and confirmed the identity of the account holder.
• Deny the application: This indicates documents were not provided or appear to be fraudulent.
• Ask for more documents: This indicates that additional documents are needed to confirm the identity of the account holder.

Documents cannot be expired, and supporting documents must be dated within 60 days. If the document appears forged, is outdated, and/or is otherwise invalid, the application will be DENIED.

Depending on the type of account holder applying for a card product, documentation may be required from more than one applicant. For example, for business account holders, documents may be required for the primary authorized person and each beneficial owner.

When an application enters IN_REVIEW status, the GraphQL API returns a response for why it was flagged for review. Each response contains documents that may be required to process the application. When there are multiple response codes, the account holder may need to provide multiple documents.

Business entity documentation is only relevant to USBusinessAccountHolders and includes documentation related to the business.

In cases where a business account holder is a sole proprietor, personal information can be used in place of business-related documentation. For example, a sole proprietor may not have an EIN but can have one of the following documents:

• Taxpayer identification
• Social Security card
• Owner’s full tax return with Schedule C included

Warning: Account holder documents cannot be expired, and supporting documents must be dated within 60 days. If the document appears forged, is outdated, and/or is otherwise invalid, the application will be DENIED.

When an Application enters IN_REVIEW status and verification documents are required, you can collect documents using two methods:

• Use the Document Upload SDK
• Use the Highnote API to generate URLs for each required document

If you use the Highnote API, the document upload process consists of the following steps:

1. Optional - Generate a client token
2. Start document upload session
3. Create document upload link
4. End the document upload session

One or more documents may be required based on the review response and the document type they provide.

Note: For compliance reasons, if you are not using a server or do not have access to one, you must generate a client token to make requests directly from your client. For more information, see Client Tokens.

To start the document collection process, start a document upload session by generating a URL to send the account holder that allows them to upload their documents. You can use the Application Status Event Notifications to send an email or push alerts to account holders to alert them of the application review status and provide a URL to your document uploading UI flow.

Note the following when starting a document upload session:

• A document upload session expires 30 days from creation. The application will be DENIED if the account holder does not provide the required documentation within 30 days.
• A session will indicate to you any requirements that may need to be enforced by your system when uploading the file.

Use the following mutation to start a document upload session. In the mutation’s response, the required documents are listed under primaryDocumentTypes:

Note: Document upload links expire five minutes after creation.

Once a document upload session has started, you must create a secure upload link for each document the applicant must upload to Highnote’s secure document store. For example, if the applicant must provide a driver’s license and utility bill, each document would need its own unique upload link.

Note the following when creating upload links:

• Upload links expire five minutes after creation. If an upload link has expired, an error message will be returned, and you must request a new link.
• Each upload link represents a single upload file.
• When creating upload links, the session status is PENDING.
• You can use the uploadURL field in the mutation's response to stream the document upload.

The following types of file formats are supported for document uploads:

Use the following mutation to create a document upload link. Use the DOCUMENT_UPLOAD_SESSION_ID from the startDocumentUploadSession response for this mutation’s variable field:

After an account holder has confirmed they have uploaded all required documents, you can end the document upload session.

Note the following when ending a document upload session:

• When ending a session, the session status transitions to SUBMITTED.
• Once a session’s status is SUBMITTED, no other actions can be taken for it. If more documentation is required, a new session must be started to upload the additional documents.
• The Highnote team will review the account holder's documents and decide on the application status.

Use the following mutation to end a document upload session:

Note: Highnote will not return a public link to access the content of the documents to protect the account holder's privacy.

You can monitor the status of account holder documents while the Highnote team reviews them by querying for the status using the Highnote API or the dashboard. For a full list of application status codes, see the AccountHolderApplicationStatusCode enum.

Note the following about monitoring application review statuses:

• Each document has its own individual status
• Displaying the review status to the account holder is optional

Use the following query to fetch the review status of an account holder application:

Warning: The Highnote test environment allows you to freely explore the platform features and functionality. It is intended for experimenting, building integrations, and training your team.

To ensure the security of your real-world data, please refrain from entering production data into the test environment. Production data includes sensitive information like customer details, financial data, or personally identifiable information (PII).

Use only dummy or test data explicitly created for testing purposes in the test environment.

You can simulate application reviews to ensure your account holders can upload documents. Additionally, you can use the simulator to trigger application failure under various scenarios. An application failure simulation will produce tags associated with the application decision and explain why an application outcome was APPROVED, IN_REVIEW, or DENIED.

When simulating DOB and SSN, use the following values:

• DOB: 2000-01-01
• SSN: 111-11-1111 or 111-11-1211

Note, the DATE OF BIRTH field has a maximum age of 99 and the SSN field requires valid SSN input.

US Person Account Holder (KYC) Verification Simulation

When simulating an IN_REVIEW or DENIED response, you can input test values for different fields of an application, resulting in a tag that provides context for the response and application status. Use the following values to simulate an IN_REVIEW or DENIED response:

• To simulate a DENIED response: Input the value FORCE-DECLINE for an application's FIRST NAME field, resulting in a NAME_MISMATCH tag.
• To simulate an IN_REVIEW response: Input the value 123 Manual Review St. for an application's ADDRESS LINE 1 field, resulting in an ADDRESS_MISMATCH tag.

The following table contains a list of failure values you can use to simulate a DENIED response:

US Business Account Holder (KYB) Verification Simulation

When simulating an IN_REVIEW or DENIED response, you can input test values for different fields of an application, resulting in a tag that provides context for the response and application status. Use the following values to simulate an IN_REVIEW or DENIED response:

• To simulate a DENIED response: Input the value FORCE-DECLINE for an application's BUSINESS LEGAL NAME field, resulting in a NAME_MISMATCH tag.
• To simulate an IN_REVIEW response: Input the value 123 Manual Review St. for an application's BUSINESS ADDRESS LINE 1 field, resulting in an ADDRESS_MISMATCH tag.

The following table contains a list of failure values you can use to simulate a DENIED response:

Once an application has entered IN_REVIEW status, you can begin a document upload session to simulate adding supporting documents. Use the queries from the following sections of this guide to simulate the document upload session:

1. Optional - Generate a client token .
2. Start document upload session.
3. Create document upload link.
4. End the document upload session.

Once you've closed the document upload session, you can simulate the review status of each document by assigning a new status of APPROVED or DENIED. Use the following mutation to simulate the review status for each document uploaded in the upload session:

There are two scenarios where additional document upload sessions may be needed:

• In some cases, the document(s) provided by the account holder may be insufficient to approve the application. If the account holder needs to upload additional documents, a new document upload session must be created to upload new document types.
• If the application is for a business account holder, additional document upload sessions may be needed for primary authorized persons and beneficial owners.

In the Test Environment, simulating additional document upload sessions requires the request inputs to be specific for each document type. Multiple applicants under the same application can be selected, and multiple document types can be requested for each applicant.

Once an additional document upload session is simulated, the application status will remain IN_REVIEW, the currentVerification.status for each unverified applicant will remain PENDING, and the currentVerification.reason for each requested applicant will be changed to DOCUMENT_UPLOAD_REQUIRED.

An additional upload session will trigger the CARD_PRODUCT_APPLICATION_DOCUMENT_UPLOAD_REQUESTED notification event. The event allows you to create a unique notification template for your account holders when additional documents are requested for their application.

Use the following mutation to simulate additional document upload sessions in your Test Environment:

After uploading account holder identity verification documents and simulating a review status for each document, you can simulate the identity verification status. The identity verification status verifies the identity of the account holder(s) associated with the application. All account holder identities must be passed for the application to be approved.

This simulation will transition the application identity verification status from IN_REVIEW to PASSED or DENIED. Optionally, you can simulate the status passing from IN_REVIEW to DOCUMENT_UPLOAD_REQUIRED if you want to test your flow for requesting additional documents.

Use the following mutation to simulate the identity verification status:

You can also simulate the outcome of an entire application and transition the application's status from IN_REVIEW directly to APPROVED or DENIED. If multiple account holders are on an application, there is only one status for the full application.

Use the following mutation to simulate the full application status: