Step 2 - User Creation
Phase 1 - Customer Onboarding
API Reference
- POST Create User - Mandatory Information and Structure
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
Field | Question | If "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 null | SEC 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
Updated about 1 year ago