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 <a href="ref:api-reference-customer-id-types" target="_blank">Customer ID Types</a> 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 (<a href="ref:post_createaccount" target="_blank">Create Account</a> or <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a>) 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/or `id2`, `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 <a href="doc:create-account-procedure#create-account-using-your-own-cip" target="_blank">Create Account using your own CIP</a> in the _Creating an Account_ guide for the account-creation workflow when using <a href="ref:post_createaccount" target="_blank">Create Account</a> or <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a>.

### 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 <<glossary: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 <a href="ref:api-reference-customer-id-types" target="_blank">Customer ID Types</a> 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.

• **<a href="ref:post_createaccount" target="_blank">Create Account</a>** — Gathers personal information and identifiers. Creates a customer record. Successful ID verification results in account creation.

• **<a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a>** — 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.

• **<a href="ref:post_startenrollment" target="_blank">Start Enrollment</a>** — 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.

• **<a href="ref:post_runcip" target="_blank">Run CIP</a>** — Runs ID verification on a customer who has an existing record. Also reruns CIP after it has already been run.

• **<a href="ref:post_runenrollmentcip" target="_blank">Run Enrollment CIP</a>** — 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:

\* 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 <a href="ref:post_createaccount" target="_blank">Create Account</a> or <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a> 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 <a href="ref:post_forcepasscip" target="_blank">Force Pass CIP</a> endpoint to move the account to active `status: Y` and account `status: 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 <a href="doc:create-account-procedure#create-account-using-Galileo-cip" target="_blank">Create Account using Galileo CIP</a> in the _Creating an Account_ guide for the account-creation workflow when using <a href="ref:post_createaccount" target="_blank">Create Account</a> or <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a>.

### Start Enrollment process

When you use the <a href="ref:post_startenrollment" target="_blank">Start Enrollment</a> 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 <a href="ref:post_completeenrollment" target="_blank">Complete Enrollment</a> 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:

    1. Call <a href="ref:post_updateenrollment" target="_blank">Update Enrollment</a> and pass the new information.

    2. Call <a href="ref:post_runenrollmentcip" target="_blank">Run Enrollment CIP</a> to submit the customer information to CIP again.

    3. If the customer passes, call <a href="ref:post_completeenrollment" target="_blank">Complete Enrollment</a> to create the account.

### Using the `id` and `idType` parameters

The endpoints that gather ID verification information have two sets of parameters for government ID inputs:

• `id` and `id2` — Contain the actual identifier

• `idType` and `idType2` — Specify the type of ID that is in `id` or `id2`

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 <a href="ref:api-reference-customer-id-types" target="_blank">Customer ID Types</a> enumeration. For example, if you set `idType: 2` (SSN), then `id` must contain nine numerals.

#### `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 in `id2` for duplicates.

• In the <<glossary:RDF>>s, an SSN/SIN that was entered in the `id` field is masked, whereas an SSN/SIN in `id2` is not masked. Because the SSN/SIN is personally identifiable information (PII), inputting the SSN/SIN in `id` avoids mishandling that information.

• The value in the `id` parameter is sometimes called the "customer ID," such as when using the <a href="ref:post_getaccountbyid" target="_blank">Get Account by ID</a> endpoint. Galileo also calls it the "government ID" in some contexts.

#### `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` and `idType2` parameters to pass card-art information to your embosser. See <a href="doc:design-a-card#specifying-a-card-design" target="_blank">Specifying a card design</a> in the _Design a Card_ guide for details.

• If you populate `id2` but not `id`, you must set these product parameters; otherwise, you must populate `id` with unique values such as the account holder's phone number:

  • **VLDLV** — `null` or not set

  • **VALID** — `0` or not set

## 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 <a href="ref:post_createaccount" target="_blank">Create Account</a> or <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a>. 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 contains `status_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 <a href="ref:post_startenrollment" target="_blank">Start Enrollment</a>, pass `runCip: 0`. If you want to run ID verification later on that same customer, use <a href="ref:post_runenrollmentcip" target="_blank">Run Enrollment CIP</a>.

## Use cases for ID verification override

These are some of the use cases for `cipStatus` in the <a href="ref:post_createaccount" target="_blank">Create Account</a> and <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a> endpoints and `runCip` in <a href="ref:post_startenrollment" target="_blank">Start Enrollment</a>:

• `cipStatus: 1` or `runCip: 1` — You want to check whether a customer passes ID verification before creating an account. If the customer passes ID verification, then call the <a href="ref:post_completeenrollment" target="_blank">Complete Enrollment</a> 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` or `runCip: 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 <a href="ref:post_createaccount" target="_blank">Create Account</a> or <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a> endpoint with `cipStatus: 2` or the <a href="ref:post_startenrollment" target="_blank">Start Enrollment</a> endpoint with `runCip: 0`.

If the minor's account is to be a secondary account to a parent's account, pass the parent's <<glossary:PRN>> for `primaryAccount`. See <a href="doc:about-accounts#primary-and-secondary-account-scenarios" target="_blank">Primary and secondary account scenarios</a> 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 <a href="ref:post_runcip" target="_blank">Run CIP</a> endpoint.

🚧

Warning

Do not call <a href="ref:post_createaccount" target="_blank">Create Account</a>, <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a>, or <a href="ref:post_startenrollment" target="_blank">Start Enrollment</a> 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 <a href="ref:post_createaccount" target="_blank">Create Account</a>, <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a>, and <a href="ref:post_startenrollment" target="_blank">Start Enrollment</a> in the <<glossary:CV>> environment, you can pass specific names for the `firstName`, `middleName`, and `lastName` parameters to trigger different verdicts:

• `John F Smith` triggers a **fail**

• `John R Smith` triggers a **refer**

• `John P Smith` triggers a **pass**. Other names besides the two listed above will also trigger a pass.

🚧

Warning

In <<glossary:Production>> **do not** pass false information such as `firstName: testname`. All values in Production must be valid. In CV, the terms `test` and `account` 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`, or `666`

  • Middle two digits are `00`

  • Last four digits are `0000`

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:

<!--Don't put a space after CAPP: or the wrap becomes untenable in that first column...-->

## 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.