Persons
Understand statuses, required verification, and possible errors for Persons.
Persons Statuses
In the Deliver API, a person can have one of the following statuses, indicated by the status field.
A person was created to represent an individual or a person’s record was updated in a way that requires identity re-verification.
A person was created to represent an individual or a person’s record was updated in a way that requires identity re-verification.
A person passed identity verification. The person can send or receive funds with all transfer use cases.
A person did not pass identity verification. The person cannot send or receive funds.
A person matched a sanctions list during watchlist screening. The person cannot send or receive funds.
A person has been soft-deleted in Orum’s platform (this action can only be completed by the Orum team). The person cannot send or receive funds.
Regardless of whether you are using Orum’s customer identification provider (Orum-KYC) or your own customer identification provider (BYO-KYC), all persons you create will always move from a Created to a Verified status. The POST API response will return the person with a status
of created
.
A majority of use cases require that persons have a status of verified
in order to send or receive funds. However, some use cases allow a person to have a status of created.
Your use case will be determined during onboarding and will dictate which Persons Status is required to transact. The respective data requirements are listed below:
Created Person
- Customer reference ID
- First name
- Last name
Verified Person
- Customer reference ID
- First Name
- Last Name
- SSN
- DOB
- Address
- *Phone Number - only required for persons transacting with a card
Diagram
The below example shows how a person can move through the above statuses. A person can move from “verified” to “restricted” if they match a sanctions list anytime after their initial customer identification. To learn more about why a person is in the “rejected” or “restricted” state, refer to the status_reason
field in the API response.
If a person fails customer identification and is set to the rejected status, Orum will automatically kick off a manual review and attempt to retry the customer identification workflow to resolve the issue.
Persons Verification
Orum maintains a comprehensive Customer Due Diligence (CDD) program.
KYC involves identity verification of a person in addition to ensuring that customers are not on any government-sanctioned lists. We provide two options for verification:
- BYO-KYC (bring your own)
- Orum-KYC
BYO-KYC
BYO-KYC (bring your own-KYC) allows you to conduct your own KYC process. To utilize this option, you must provide Orum with your BSA/AML Policy and procedures detailing your internal KYC process, in addition to a virtual walkthrough of the process with our compliance team. Orum reviews and verifies the adequacy of your KYC process in conjunction with our financial partner agreements and Federal Financial Institutions Examination Council (FFIEC) compliance.
For BYO-KYC, you need to conduct adequate identity verification on your individual customers. At a minimum, you must verify the following information:
- Full legal name
- Physical address
- Tax ID (SSN)
- Date of birth
Orum performs watchlist screening on all individuals during onboarding and on an ongoing basis. Orum reserves the right to reject or restrict any customer from utilizing our services.
Orum-KYC
Orum-KYC is an additional service we provide if you don’t have a Customer Identification Program (CIP) established and don’t plan to set one up for your platform. This option manages the complexities of creating and maintaining your own CIP in-house. We use third-party vendors to perform KYC verification on all Orum customers to verify their true identity before transacting with our product.
For Orum-KYC, we obtain and screen the following information through our third-party vendor at onboarding and on an ongoing basis.
- Full legal name
- Physical address
- Tax ID (SSN)
- Date of birth
All individuals in Orum-KYC undergo watchlist screening, which provides constant monitoring and updates to various sanctioned lists (OFAC-SDN, OFAC NON-SDN, etc.).
Persons Reason Codes
Status Reasons
If a person fails customer identification, Orum sends a person_rejected
or person_restricted
webhook. The person object in the webhook will have a status of rejected
or restricted
and a status_reasons array that explains why the person failed customer identification.
Status Reasons contain:
reason_code
: a word-based code that describes the customer identification failurereason_code_message
: a friendly description of the reason code that can be surfaced directly to your end users
To reattempt customer identification, you can use the PATCH /persons endpoint to update any invalid or missing information.
status_reasons
will also be present in the GET /persons and GET /persons/id API responses.
reason_code | reason_code_message |
---|---|
deceased_person | User is reported as deceased |
incomplete_address | Address submitted is missing some or all required elements |
incomplete_dob | Date of birth submitted is missing some or all required elements |
incomplete_ssn | SSN submitted is missing some or all required elements |
ineligible_age | Age submitted is under 18 and not eligible for this product |
invalid_address_type | Address submitted is a non-supported address type |
invalid_dob | Date of birth is invalid |
invalid_name | Name is invalid |
invalid_ssn | SSN is invalid |
matched_alertlist | Matched a list of known fraudulent users |
matched_watchlist | Matched one or multiple sanctions lists |
Webhook Example
Deliver sends webhooks to notify you of changes to a person’s status.