Customer ID Verification (KYC/CIP)
Before opening an account and conducting financial transactions with a customer, a bank must fulfill Know Your Customer (KYC) requirements, which verify the identity of a prospective customer. The details of KYC requirements are specific to each country. In addition, banks in the United States are required by the Patriot Act to have a customer identification program (CIP) to ensure that a prospective customer is not on a government watch list.
Note
Because the endpoint code uses
CIP
to refer to Galileo's integrated ID verification process, which performs KYC and CIP functions, Galileo sometimes uses the term "CIP" to refer to the whole ID verification process.
Banks fulfill ID verification requirements by:
- Obtaining identifying information from the prospective customer
- Verifying the information
Choosing an ID verification solution
You have these options for performing ID verification:
- Use Galileo's integrated ID verification process.
- Use a third-party ID verification provider.
- Combine Galileo's process with a third-party process.
When deciding how to perform CIP, remember to prioritize the customer experience during this onboarding phase. When a legitimate customer does not initially pass CIP, for example, the customer might decide not to take the extra step to supply additional documentation or call customer support. If your CIP solution has a low pass rate for your target demographic, you can lose customers to onboarding friction.
Work with Galileo to determine which solution best addresses your use case. For example, Galileo's CIP process does not verify businesses (KYB). Maybe your target demographic is likely to possess ID documents from outside the U.S. or Canada. Some CIP solutions use biometric technology or artificial intelligence to screen out likely bad actors, and others are integrated with blockchain technology.
Regardless of which solution you choose, your app or website must collect identifying information from your customers and submit the information for verification. Required information is:
- Legal name — First, middle, last
- Address — Cannot be a P.O. box in the U.S. and Canada. Must include street address, city, state, postal code, and country.
- Date of birth
- Customer ID — The types of customer identifiers to accept are determined by your bank and specified in your product settings. Consult the Customer ID Types enumeration for possible ID types. The account-creation process supports one or two identifiers per customer.
Implementing ID verification
ID verification must be performed prior to account creation.
Using your own ID verification process
If you are using your own KYC/CIP provider, send customer information to your provider, and after ID verification is successful, you send a request to an account-creation endpoint (Create Account or Create Virtual Card Account) with these parameters populated:
- First, middle, and last names
- Date of birth
- Primary address
- Optional — Ship-to address (if different from the primary address, to mail a physical card)
- Optional — Customer ID:
id
,idType
and/orid2
,idType2
, as required by your bank for record-keeping. See Using the id and idType parameters for additional information. cipStatus
— Do not include
You do not need to inform Galileo whether a customer passed ID verification; however, you should create accounts only for those customers who pass.
Note
See Create Account using your own CIP in the Creating an Account guide for the account-creation workflow when using Create Account or Create Virtual Card Account.
Using Galileo's ID verification process
When using Galileo's integrated ID verification process, you will need to make the following decisions in cooperation with your bank:
- Which applications will use the integrated ID verification process: Program APIs or CST
- Whether the product requires a government ID
- Which government ID is accepted or required, such as SSN (U.S.), SIN (Canada), passport or driver license. Consult the Customer ID Types enumeration for the complete list.
- Whether a second form of ID is required
- Whether minors will be using the product, and what the minimum age is
- Whether the same government ID must be unique across all of your offerings or only within the same program or product
- What to do when a customer fails ID verification:
- What account status to set
- Whether you or Galileo will perform additional verification when a customer has a partial match
- How a customer with a partial match can provide verification documents
- Whether to send a Notice of Adverse Action
- Whether to send a refund check
- The order in which to perform ID verification relative to other onboarding processes such as:
- Create an account
- Send a card to the embosser
- Add funds
- Charge an activation fee
- Activate the account
- Set the start date
Endpoints for performing ID verification
Depending on your enrollment strategy, you can use these endpoints to run Galileo's integrated ID verification process. Galileo will tell you which endpoints you should use for your particular program and use case.
- Create Account — Gathers personal information and identifiers. Creates a customer record. Successful ID verification results in account creation.
- Create Virtual Card Account — Gathers personal information and identifiers. Creates a customer record. Successful ID verification results in account creation for a virtual card. You must be PCI compliant to use this endpoint.
- Start Enrollment — Gathers personal information and identifiers. Creates a customer record. Does not create an account and therefore does not send a record of unsuccessful CIP attempts to the bank. Consult with Galileo before using this endpoint.
- Run CIP — Runs ID verification on a customer who has an existing record. Also reruns CIP after it has already been run.
- Run Enrollment CIP — Runs ID verification on a customer identifier but does not create a customer record or an account. Use when you have already run Start Enrollment for the customer with
runCip: 0
.
This table summarizes the inputs and actions of the endpoints listed above:
Create Account* | Start Enrollment | Run CIP | Run Enrollment CIP | |
---|---|---|---|---|
Input: Customer profile | X | X | ||
Input: Customer ID | X | X | X | |
Input: PRN | X | |||
Action: Run ID verification | X | X | X | X |
Action: Create customer record | X | X | ||
Action: Create account | X |
* Also applies to Create Virtual Card Account.
ID verification process
When Galileo receives your customer's information, Galileo sends it to a third party for verification, and the third party returns one of three results: pass, failure, or referral. The specifics of the process are different depending on which endpoint you use to submit the information.
Create Account and Create Virtual Card Account process
When you use the Create Account or Create Virtual Card Account endpoint to submit customer information to the ID verification process, these are the results:
- Galileo creates a customer record using the information provided.
- When ID verification is successful, the account is created and put into
status: W
(Waiting for processing). - When ID verification is not successful, the account is created and put into
status: F
(failed ID verification). The endpoint response includes one of these values:F
— Failed. The submitted data did not yield a plausible match. The customer is either on a watch list or is unlikely to be a real person. No further action can be taken. The account is never activated.R
— Referral. The submitted data yielded a partial match. The customer is likely to be a real person.S
— System failure. The CIP-related data was not formatted properly, and the CIP check was not performed. See Testing ID verification for the validation checks.
When the result is R
, there are two options, depending on your arrangements with Galileo:
- Galileo instructs the customer how to pass ID verification. When the customer's identity is verified, Galileo activates the account.
- You instruct the customer how to pass verification. When ID verification is successful, you call the Force Pass CIP endpoint to move the account to active
status: Y
and accountstatus: N
. (Force Pass CIP only updates the account statuses—it does not run ID verification again.)
If ID verification is still unsuccessful after the additional verification steps, the account is never activated.
Note
See Create Account using Galileo CIP in the Creating an Account guide for the account-creation workflow when using Create Account or Create Virtual Card Account.
Start Enrollment process
When you use the Start Enrollment endpoint to send customer profile information to the ID verification process, these are the results:
- Galileo creates a customer record based on the information provided but does not create an account.
- The endpoint response includes one of these values:
P
— Pass. The submitted data matched. Call Complete Enrollment to create the account.F
— Failed. The submitted data did not yield a plausible match. The customer is either on a watch list or is unlikely to be a real person. No further action can be taken. The account is never created.S
— System failure. The CIP-related data was not formatted properly, and the CIP check was not performed. See Testing ID verification for the validation checks.R
— Referral. The submitted data yielded a partial match. The customer is likely to be a real person. For a referral, you request additional information from the customer and then follow these steps:- Call Update Enrollment and pass the new information.
- Call Run Enrollment CIP to submit the customer information to CIP again.
- If the customer passes, call Complete Enrollment to create the account.
Using the id
and idType
parameters
id
and idType
parametersThe endpoints that gather ID verification information have two sets of parameters for government ID inputs:
id
andid2
— Contain the actual identifieridType
andidType2
— Specify the type of ID that is inid
orid2
When one of the id
parameters is populated, the corresponding idType
parameter is required. The format for id
is determined by the value in its idType
field, as shown in the Customer ID Types enumeration. For example, if you set idType: 2
(SSN), then id
must contain nine numerals.
id
and idType
id
and idType
When you are using Galileo's integrated ID process, you must populate id
and idType
at minimum. If your bank requires an SSN (U.S.) or SIN (Canada) for verification, you must populate id
with the SSN/SIN. Do not put it in id2
:
- Galileo checks the value in
id
for duplicate entries when IDSSN is set. It does not check the value inid2
for duplicates. - In the RDFs, an SSN/SIN that was entered in the
id
field is masked, whereas an SSN/SIN inid2
is not masked. Because the SSN/SIN is personally identifiable information (PII), inputting the SSN/SIN inid
avoids mishandling that information. - The value in the
id
parameter is sometimes called the "customer ID," such as when using the Get Account by ID endpoint. Galileo also calls it the "government ID" in some contexts.
id2
and idType2
id2
and idType2
Populating id2
and idType2
depends on the requirements of your program.
- If you are using Galileo's integrated ID process, and your program requires two forms of ID, then populate these parameters with the second form of ID (as long as SSN/SIN is in
id
). - Alternatively, you can use the
id2
andidType2
parameters to pass card-art information to your embosser. See Specifying a card design in the Design a Card guide for details. - If you populate
id2
but notid
, you must set these product parameters; otherwise, you must populateid
with unique values such as the account holder's phone number:- VLDLV —
null
or not set - VALID —
0
or not set
- VLDLV —
Duplicate ID values
During product setup, you determine whether a customer can sign up more than once for the same product. Galileo can verify that an id
value is unique per product (prod_id
), per program (prog_id
), or across your entire product line. See Partners, Programs and Products for an explanation of these levels. The VLDLV parameter controls the level.
- Galileo checks the value in
id
for duplicate entries when VLDLV is set. It does not check the value inid2
for duplicates. - If you attempt to submit a duplicate
id
, the enrollment endpoint returns one of these status codes:407-02
— Create Account520-12
— Create Virtual Card Account504-12
— Start Enrollment
Overriding your ID verification setting
If your product is using Galileo's ID verification, you can override that setting for individual customers at the time of account creation by passing the cipStatus
parameter for Create Account or Create Virtual Card Account. This parameter has no effect if you are using your own ID verification.
0
or empty — Do not override program settings.1
— Send customer information to Galileo ID verification but do not create an account. When you pass this value, the endpoint response containsstatus_code: 407-13
as well as the verdict.2
— Do not send customer information to Galileo ID verification but create an account.
Open the Recipe below to see the Create Account response when cipStatus: 1
.
To exempt an individual customer from ID verification when using Start Enrollment, pass runCip: 0
. If you want to run ID verification later on that same customer, use Run Enrollment CIP.
Use cases for ID verification override
These are some of the use cases for cipStatus
in the Create Account and Create Virtual Card Account endpoints and runCip
in Start Enrollment:
cipStatus: 1
orrunCip: 1
— You want to check whether a customer passes ID verification before creating an account. If the customer passes ID verification, then call the Complete Enrollment endpoint to create the account. Do not call Create Account, Create Virtual Card Account, or Start Enrollment more than once per customer, or you will create duplicate customer records.cipStatus: 2
orrunCip: 0
— You need to exclude the customer from ID verification. See "Running ID verification on minors," below, for one use case.
Running ID verification on minors
Minor persons are not required to fulfill ID verification requirements but they do need to fulfill minimum age requirements. Determine the minimum age for minor customers and Galileo will set it in the DOB product parameter. The dateOfBirth
endpoint parameter is then verified against the age limit.
When you are creating an account for a minor while using Galileo's integrated ID verification, call the Create Account or Create Virtual Card Account endpoint with cipStatus: 2
or the Start Enrollment endpoint with runCip: 0
.
If the minor's account is to be a secondary account to a parent's account, pass the parent's PRN for primaryAccount
. See Primary and secondary account scenarios in the About Accounts guide for more information.
Running ID verification on existing customers
When a customer record already exists but you need to run ID verification again, use the Run CIP endpoint.
Warning
Do not call Create Account, Create Virtual Card Account, or Start Enrollment more than once per customer, or you will create duplicate customer records.
The Run CIP endpoint returns the same verdicts—pass, fail, and refer—as the other ID-verification endpoints.
Testing ID verification
When using Create Account, Create Virtual Card Account, and Start Enrollment in the CV environment, you can pass specific names for the firstName
, middleName
, and lastName
parameters to trigger different verdicts:
John F Smith
triggers a failJohn R Smith
triggers a referJohn P Smith
triggers a pass. Other names besides the two listed above will also trigger a pass.
Warning
In Production do not pass false information such as
firstName: testname
. All values in Production must be valid. In CV, the termstest
andaccount
trigger a failed status, and in Production they cannot be used.
When testing in Production, the following will result in status: S
(system failure) from the CIP system, which means that a formatting or validation error was present in the CIP data, and so the CIP process was not initiated:
- Year of birth before 1900
- Missing required values
- The SSN (
idType: 2
) has one or more of these characteristics:- Nine sequential digits (
123456789
) - Begins with
9
,000
, or666
- Middle two digits are
00
- Last four digits are
0000
- Nine sequential digits (
If you would like to use real customer names and IDs for testing in CV, ask Galileo to enable that feature for you with the CIPEV parameter.
Events API
You can arrange with Galileo to receive events that are related to customer ID verification:
Event | Description |
---|---|
CAPP:app_completed | The customer passed ID verification and the account has been created. This event is also triggered when ID verification is not run and account creation is successful. This event is not triggered for Digital First accounts. |
PTID: pass_id | The customer passed ID verification. |
BFID: failed_id FTID: fail_id | The customer failed ID verification. Consult Galileo about which event to use for your use case. |
Galileo setup
These are some of the product parameters to be configured at Galileo to control ID verification. Additional internal parameters that are not listed here also need to be set up.
Parameter | Description |
---|---|
CIPEV | Enable CIP testing with real customer names and IDs in the CV environment |
TOTID RTTID | Whether to use Galileo's integrated ID verification |
TUCRY | Which country's database to use for ID verification: U.S. or Canada |
CIPGT | Which forms of ID to require |
FFTID | Whether a driver license can be accepted as a government ID |
VLDLV | At what level a government ID must be unique: across the product, program, or provider |
DOB | Minimum age for customers |
TIDST | Which account status to set when ID verification fails: F (default) or other |
MPADD | Mailing address where customers can send documents after being referred |
MPFAX | Fax number where customers can send documents after being referred |
MTOTB | Maximum refund check amount after failing ID verification |
CIPAP | Which applications can run ID verification when onboarding customers: CST or Program API |
ACSET | The order in which to perform ID verification relative to other processes, such as account creation and sending an emboss order. |
Updated 5 months ago