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:

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:

Controlling Application Status

In the sandbox API, the first number of the Business ID (identification_number) allows you to control which status the application receives after applying:

• ID starts with 2: DOCUMENTS_NEEDED

• ID starts with 3: MANUAL_REVIEW

• ID starts with 4: APPROVED

• ID starts with 5. REJECTED

• ID starts with anything else: Application ends in MANUAL_REVIEW

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.