Introduction

A “person” represents an real world person associated with a Netspend account,

Person Account Roles

A person can play several account roles:

Creating and Enabling a Person

The basic information required to create a person is their first name, last name, the account they will belong to, and their desired role in that account.

There are also additional risk analysis related data items that can be collected and used to help determine whether or not to allow a person to successfully become an active accountholder. Some of these risk analysis data items are configurable, the details for which can be worked out in a partner’s business level engagement with Netspend.

Additional data that factors into risk analysis:

• Street address
• Postal code
• Date of birth
• Government ID number (in the U.S. this is typically a social security number).
• Information for the expected account usage activity; for example, what deposits are expected in the account per month
• Acceptance of terms and conditions (see Agreements)
• Agreement to allow electronic signature (see Agreements)
• Acceptance of privacy policy agreement (see Agreements)
• Document uploads (see Document Requests)

Person Status

The status value of the first owner on an account or subaccount is generally set to “active” on creation. This is because typically the creation of an account involves and depends on the initial owner creating the account passing risk assessment as part of the account creation process. As such, passing account risk assessment requirements is treated as one with the person passing risk assessment as well.

In the case of joint accounts, however, after the original person on an account is created, any subsequent joint account owners follow a different “status” path, as illustrated below.

In the subsequent owner scenario, the next person to sign up as an owner initially enters an “applicant” state, which can be detached or re-attached as needed until an applicant graduates to an active state by completing additional steps.

An “active” status, regardless, does not necessarily mean that the person has access to the account yet.

Any other access enablement requirements for an “active” person are communicated by way of “kyc_status” or “ofac_status” and any relevant workflow steps, which may or may not coincide with “kyc_status” or “ofac_status”.

Person Enablement

There are a few fields in the Person object that will help indicate, at least in part, where that person is in terms of being able to access their account.

• “status”: Whether a person is active or not.
• “kyc_status”: Whether or not the person is blocked or rejected by Netspend’s KYC (“Know Your Customer”) risk assessment. Here a person can be in a “conditional” status, where some additional workflow steps may move the person into an “approved” status required to put the person into active status.
• “ofac_status”: Whether or not the person is rejected having been flagged for fraudulent activity by OFAC (“Office of Foreign Assets Control”).

Sample Flows

Onboarding a New Account and Person

The diagram below shows a possible flow onboarding a new account and person for an account type that requires the person to accept some agreements in order to cure and pass KYC.

Curing Steps for KYC Conditional After Answer Timeout

This diagram shows a potential flow where a person in a KYC conditional state fails to answer identifying questions within the default 5 minute timeout. The recourse is to call customer service.

Adding Second Joint Account Owner

The two diagrams below show a potential flow for a scenario in which Bob has created an account and wants Sara to be a joint owner of that account.
The partner application is presumed to allow Bob to identify Sara, by phone number perhaps, as a person to invite, and the partner application takes care of pushing the notification for the invite to Sara’s phone, where she accepts and creates an account.
In the process of creating the account, however, she drops off before completing a step needed to become active and so remains in an “applicant” state for a while.
Bob checks his app days later, which indicates that Sara hasn’t completed sign up yet, offering to cancel the invitation.
Bob opts to cancel, which leads to the partner app putting Sara in a “detached” state.
Bob talks to Sara about it, she apologizes and asks to try again.
Bob agrees and uses the partner app to reinstate Sara.
Sara tries again, completing steps to become active, and finally is able to get access to the account.

Person Webhooks

Payload data type: “person”

For more information on webhooks, see Webhook.