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/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 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:

* 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 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 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:
    1. Call Update Enrollment and pass the new information.
    2. Call Run Enrollment CIP to submit the customer information to CIP again.
    3. If the customer passes, call Complete Enrollment 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 Customer ID Types 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 RDFs, 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 Get Account by ID 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 Specifying a card design 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

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 in id2 for duplicates.
• If you attempt to submit a duplicate id, the enrollment endpoint returns one of these status codes:
  • 407-02 — Create Account
  • 520-12 — Create Virtual Card Account
  • 504-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 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 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 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 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 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 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 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 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:

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. See the Onboarding (KYC/CIP) table on the Parameters page for the full list and details on these parameters.