Step 2 - User Creation

Phase 1 - Customer Onboarding

API Reference

SQS Reference


Task O4 - Review Data Requirements for User Creation

Review Data points necessary in the API Reference - Create User Mandatory Information and Structure and determine if already collected or stored, is it retrievable?

Data Validation for Task 4

  • When capturing Customer Address, it must be a physical location it cannot be a PO Box, this is a mandatory requirement

  • When creating a new user in the Request payload there is a name/value pair "findersFee" it is a Boolean (true/false) field that must be set to "false"

  • Beginning with User Creation if LPMA accounts are necessary the User creation and subsequent steps have been reviewed if applicable

  • Previously Stored Customer Information - Many Partners already collect, and store customer information as part of an existing product, if so, a majority of the minimum required points of information can be leveraged from the existing Platform and passed via API to reduce the number of customer onboarding questions.

Brokerage Specific Questions

FieldQuestionIf "Yes"If "No"Additional Info
1. Politically Exposed Individuals
field - "politicallyExposedNames"
โ€œIs the account maintained for a current or former Politically Exposed Person or Public Official (includes U.S. and Foreign)? A politically exposed person is someone who has been entrusted with a prominent public function, or who is closely related to such a person.โ€Display and send the response:

"Please provide the names of that official and official's immediate family members (including former spouses)."
send null- A โ€œPolitically Exposed Personโ€ is defined by FATF (Financial Action Task Force) as an individual who is or has been entrusted with a prominent public function, for example, Heads of State or of government, senior politicians, senior government, judicial or military officials, senior executives of state-owned corporations, or important political party officials.
2. Employee at a Broker Dealer or other Exchange Member
field - "broker"
โ€œAre you or anyone who has a beneficial interest in this account affiliated with or employed by a registered securities broker-dealer, stock exchange, exchange member firm, FINRA, or a municipal securities dealer?โ€Display:

โ€œIf answered "yes," you are obligated to notify the employer member in writing of your intention to open an account.โ€
send null- Additional Guidance: FINRA Rule 3210
3. Director or 10% Shareholder in a Public Company
field - "directorOf"
"Is the account holder(s) a control person of a publicly traded company? A Director, Officer or 10% stock owner?"Display and send the response:

"If yes, please list the company name and its ticker symbol."
send nullSEC Information
SEC Information 2

LPMA - User/Customer Creation for Limited Purpose Margin Accounts

The โ€œLimited Purposeโ€ signifies the enabling of an instant increase in buying power without increasing financial leverage; this distinction is what makes the account different from a traditional Margin account

For (Limited Purpose Margin Account) Workflows for "Individual Funding," "Bulk Funding," or "Trade Settlement you will need to incorporate 4 items:

1. Add the following โ€œdocumentsโ€ object to the User Create Request Payload

โ€œdocumentsโ€: [
        {
            โ€œtypeโ€: โ€œMARGIN_DISCLOSUREโ€,
             โ€œdataโ€: {
                โ€œmarginAgreementโ€: true
              }
         }
      ]

2. When sending in the POST call to create Account in Step 3 please make the following changes:

  • The name/value pair: tradingType.name = โ€œMARGINโ€
  • Add this name/value pair to your "create account" request payload if not already included:
    leverage = 1

3. Please use the LPMA Specific โ€œDisclosure Widgetโ€ LPMA Disclosure Widget

4. Pattern Day Trade (PDT) logic integration: for margin accounts the Partner will
incorporate logic to capture and notify customers of PDT violations (vs GFV - good faith violations, for cash accounts)


Task O5 - Create a User

You will then send DriveWealth your customerโ€™s data via API (request), this action creates the User in the DW system and allows you to create a User's account next. You should receive a valid response when creating a User via API

Sanitizing Customer Data

In order to perform background checks during the KYC and AML processes it's imperative to provide sanitized and accurate customer information:

Full legal name

  • "firstname" and "lastname" properties should ALWAYS match the full legal name used on their official government ID. Short hand or spelling errors ("Liz" rather than "Elizabeth"), can result in KYC failure.

  • For multiple names include them in the "firstname" property, and keep the "lastname" property to a single name.

Example: Full legal name - Sita Maha Lakssmi Ramadugula via the API as:

"firstname" : "Sita Maha Lakshmi"
"lastname" : "Ramadugula"

Address information

There are many free third party services that provide a simple API to verify and collect customer address (ex: Google Places, USPS Address API's). These services can enable customers to input short hand address names and have the API return back possible address values; this can reducing time spent on-boarding, and standardized address details.

Identification number

In the IDENTIFICATION_INFO Data Object the value for the field "data.value" provided in the 'create user request' is what is included on the W9 or W-8BEN that is filed with the US IRS. It's important the value provided is the same value the customer uses to file their taxes locally, else they cannot report their taxes at the end of the year due to ID miss-match.

For API Calls

  • Receive 200 status = NO ERROR

  • Receive 400 Status = ERROR

  • The Data Layout Definition (DLD) follows JSON