Onboarding Businesses

Business onboarding requires making API calls for the primary Business Application object, as well as the secondary Related Party Application and Document Request objects.

The primary Business Application object contains general information related to the business and the overall status of the application. Only one is needed per business.

The secondary Related Party Application object contains personal information for authorized representatives, beneficial owners (if applicable), and a member of senior management. A Related Party Application is required for each of these individuals.

The secondary Document Request object is a checklist of document requirements and is automatically generated based on information provided in the Business Application and Related Party Applications.

When the Business Application, Related Party Application, and Document Request objects have been completed, the overall Business Application can be submitted for review. From there, the Business Application will either indicate additional document/information requirements or reach a terminal status.

Business Application

To begin, create the primary Business Application object using the Create Application and Patch Application endpoints:

{
    "name": string,
    "entity_type": "SOLE_PROPRIETOR" | "CORPORATE" | "LLC" | "PARTNERSHIP" | "NON_PROFIT" | "INCORPORATED_ASSOCIATION" | "UNINCORPORATED_ASSOCIATION",
    "doing_business_as": string,
    "identification_number": {
        "identification_number": string,
        "type": "TIN" | "EIN" | "NON_US_BUSINESS_ID"
    },
    "address": {
        "street_address": string,
        "street_address2": string,
        "city": string,
        "postal_code": string,
        "state": string, // 2-character state code
        "country": string // ISO-3166 Alpha-2 country code
    },
    "website": string,
    "contact": {
        "name": {
            "first_name": string,
            "middle_name": string,
            "last_name": string
        },
        "phone_number": string, // e.164 format
        "email": string
    },
    "formation_date": string,
    "risk_info": { // contains conditionally required fields, see below*
        "risk_categories": ["INTERNET_GAMBLING", "CANNABIS", "CRYPTOCURRENCY", "CROWDFUNDING", "FINANCIAL_OR_MONEY_MOVEMENT"],
        "company_mission": string,
        "has_current_enforcement_actions": boolean,
        "primary_regulator": string,
        "business_activity_location": "PRIMARILY_US" | "MIX_OF_US_AND_NON_US" | "PRIMARILY_NON_US",
        "source_of_funds": "INTERNAL_FUNDS" | "CLIENT_OR_EXTERNAL_FUNDS",
        "account_usage": "MONEY_STORAGE",
        "annual_revenue": "PRE_REVENUE" | "5M_OR_LESS" | "BETWEEN_5M_100M" | "100M_OR_MORE",
        "monthly_transactions": "5_OR_LESS" | "BETWEEN_5_AND_15" | "15_OR_MORE",
        "first_month_deposit": "1M_OR_LESS" | "BETWEEN_1M_AND_5M" | "BETWEEN 5M_AND_20M" | "BETWEEN_20M_AND_50M" | "50M_OR_MORE"
    },
    "industry": {
        "industry": enum, // see below*
        "other_industry": string
    },
    "agreement_consent": {
        "version": string,
        "timestamp": date
    }
}

*Conditionally required fields for risk_info:

Diligence type Trigger values Conditionally required fields
Standard
  • industry.industry equals "GAMBLING"
  • risk_info.risk_categories contains "INTERNET_GAMBLING", "CANNABIS", or "CROWDFUNDING"
  • risk_info.company_mission
  • risk_info.source_funds
Crypto risk_info.categories contains "CRYPTOCURRENCY" Everything in "Standard" + risk_info.has_current_enforcement_actions
Regulated risk_info.categories contains "FINANCIAL_OR_MONEY_MOVEMENT" Everything in "Crypto" + risk_info.primary_regulator

For the full list of possible enum values for industry.industry, see the API Reference, and expand the IndustryInfo object under the request schema.

For agreement_consent, call List Agreements for the list of agreements to display to your customers:

    {
        "version": string,
        "release_date": string,
        "documents": [
            {
                "pdf_download_url": string, // PDF
                "title": string,
                "type": string,
                "category": string
            }
        ]
    }

After displaying the agreements to your customers, provide the appropriate agreement_consent.version in the Business Application.

When the Business Application object has been completed, along with Related Party Applications and Document Requests (see below), call Apply with the application_id to submit the business application for review.

After the application has been submitted, call Get Application to monitor the application status:

Status Description
CREATED

The application has been created but not submitted for review. After the Business Application object, Related Party objects, and Document Requests have been completed, call Apply to update the overall application status to SUBMITTED

Subsequent status: SUBMITTED

SUBMITTED

The application has been submitted and is being reviewed.

Subsequent statuses: CLOSED, APPROVED, REJECTED, DOCUMENTS_NEEDED, MANUAL_REVIEW

CLOSED The application has been closed due to inactivity. This is a terminal status.
APPROVED The application has been approved and a customer_id now exists for the business. This is a terminal status.
REJECTED The application has been rejected. This is a terminal status.
MANUAL_REVIEW

The application is being manually reviewed based on provided documents.

Subsequent statuses: CLOSED, APPROVED, REJECTED, DOCUMENTS_NEEDED

DOCUMENTS_NEEDED

The application requires documentation. Call List Document Requests to view the outstanding list of documents, then call Upload Documents to submit each requested document. When all requested documents have been uploaded, the application status will automatically update to PENDING.

Subsequent status: PENDING

PENDING

If an application needed further action (for example DOCUMENTS_NEEDED), this status signifies the required actions are completed and the application is ready to be submitted again.

Subsequent status: SUBMITTED

Related Party Applications

For each Related Party — defined as authorized representatives, beneficial owners (if applicable), and a member of senior management — create an application using the Create Related Party Application and Update Related Party Application endpoints:

{
    "name": {
        "first_name": string,
        "middle_name": string,
        "last_name": string
    },
    "address": {
        "street_address": string,
        "street_address2": string,
        "city": string,
        "postal_code": string,
        "state": string, // 2-character state code
        "country": string // ISO-3166 Alpha-2 country code
    },
    "date_of_birth": string,
    "identification_number": {
        "identification_number": string,
        "identification_type": "SSN" | "PASSPORT" | "NON_US_ID"
    },
    "phone_number": string, // e.164 format
    "title": string,
    "roles": ["CONTROL_PERSON", "AUTHORIZED_REPRESENTATIVE"],
    "ownership_percentage": string,
    "citizenship": string, // ISO-3166 Alpha-2 country code
    "email": string
}

You can also call List Related Party Applications and Delete Related Party Application.

When each Related Party Application has been created, along with the Business Application and Document Requests, the overall application can be submitted using Apply.

Document Requests

Document Requests vary depending on the information provided in the Business Application and Related Party Application objects.

Call the List Document Requests endpoint to retrieve the list of documents based on your application:

[
    {
        "id": string,
        "type": enum, // see below*
        "status": "PENDING_UPLOAD" | "PENDING_REVIEW" | "APPROVED" | "INVALID",
        "name": string,
        "exception_reason": string
    }
]

For the full list of possible enum values for type, see the API Reference, and expand the successful response schema.

For each document request, call Upload Document to upload a .png file of the requested document. Uploading a document updates the Document Request status from PENDING_UPLOAD to PENDING_REVIEW. From there, the document will be reviewed and the status will move to either APPROVED or INVALID. If APPROVED, no further action is needed. If INVALID, an exception_reason will be provided as guidance on next steps.

When all Document Requests have been provided (all requested documents have either APPROVED OR PENDING_REVIEW as the status), along with the Business Application and Related Party Applications, the overall application can be submitted using Apply.


Last updated: Dec 18, 2023