About Accounts

This guide explains how accounts are structured in the Galileo system and which account types are relevant to the API consumer. This guide does not explain the many account characteristics that a program or product may support.

Account types

In the Galileo system, an account can be either a primary account or a secondary account. The purpose of creating secondary accounts is to create relationships among accounts in the Galileo system. In most cases, the related accounts all belong to the same customer, although the secondaries can also belong to someone else. In some cases, the secondaries are all business accounts that draw on the same fund.

It is up to you whether to use the primary/secondary linkage inside the Galileo system or whether to use your own logic to set up relationships among accounts. If you use the primary/secondary linkage in the Galileo system, the following will be true:

• You can share account balances among a primary account and its secondary accounts.
• The CST shows which accounts are related.
• You can easily link naturally related accounts such as a DDA and its overdraft account.
• You can add a secondary account to another secondary account, but only when using the Add Account endpoint. With the Create Account endpoint, secondaries must be linked to primaries only.
• Galileo sets up and maintains the primary product parameters to indicate which products can be its secondaries, and also how many secondaries a primary account can have.
• During customer onboarding the primary account must be created first and the secondaries later.

Primary accounts

A primary account is the first account you create when onboarding a new customer. To create this account you must pass the customer's full name, address, and other personal information that goes into the customer record. You will also need this information to run CIP on the customer. (See Customer ID Verification (KYC/CIP) for more information.) In almost all cases you will use the Create Account endpoint to collect and submit this information. (See Creating an Account for instructions on using this endpoint.)

Primary accounts are typically DDAs with a debit card, but your use case may require a different type of primary account such as a health savings account, credit account, or instant-issue card.

Secondary accounts

Secondary accounts represent additional products that a customer wishes to acquire, such as an overdraft account, a savings account, or an additional card. When creating a secondary account for a customer who already has a record in the Galileo system, you use the Add Account endpoint. (See Adding an Account for instructions on using this endpoint.)

It is also possible to create a secondary account that belongs to someone other than the primary account owner. For example, Gerry has a primary account for a debit card and his wife Sylvia also wants a debit card. Sylvia's card account can be created as a secondary account to Gerry's account.

Similarly, Gerry has a secured credit primary account for a credit card, and his wife Sylvia also wants a credit card. Sylvia's credit card account can be created as an authorized user (secondary account) to Gerry's secured credit account.

This arrangement makes it easy to retrieve data on both accounts at the same time. In this case you would use Create Account so that you can create a customer record for Sylvia and verify her identity.

Things to keep in mind about secondary accounts:

• A maximum of 3000 secondary accounts can be associated with a primary account; however, you may set a lower limit at the product level. For secured credit accounts, a maximum of 15 authorized users can be added.
• By default you cannot add multiple secondary accounts with the same product ID. To enable multiple secondary accounts with the same product ID, set SECLM on the secondary account.
• A secondary account can belong to the same customer or it can belong to a different customer than the primary customer.
• Product settings can dictate that a minor child meet a minimum age requirement to obtain a secondary account.

📘

Note

Although there is no flag in the Galileo system to specifically mark primary and secondary accounts, you can view the relationships in the CST, or you can use the Get Related Accounts endpoint to retrieve related accounts.

Primary and secondary account scenarios

These example scenarios demonstrate some of the ways to set up primary and secondary accounts.

One customer with multiple secondary accounts

In this scenario you offer these products:

• Product ID 5 — DDA with a debit card
• Product ID 9 — Overdraft account
• Product ID 4 — Savings account

1. A new customer, Leona Álvarez, signs up for the DDA. You create this account by calling Create Account and include these input parameters:
   • Name, address and personal information
   • prodId: 5

The endpoint returns 33333 as the PRN (pmt_ref_no) and 99999 as the PAN. The balance ID (galileo_acct_no) is 2222.

2. You offer an overdraft account for the DDA, and Leona opts in. You call Add Account with these parameters:
   • accountNo: 33333
   • prodId: 9

The endpoint returns pmt_ref_no: 66666 and balance ID 4444.

3. Leona also wants a savings account. You call Add Account again with these parameters:
   • accountNo: 33333
   • prodId: 4

The endpoint returns pmt_ref_no: 77777 and balance ID 5555.

This is the end result of the above steps:

Two customers with the same primary account

In this scenario you offer three products:

• Product ID 2 — DDA with a debit card
• Product ID 3 — A version of the above product that is designed for adolescents
• Product ID 8 — Savings account

1. A new customer, Adele Johnson, signs up for the DDA. You call Create Account with these parameters:
   • Name, address and personal information
   • prodId: 2

The endpoint returns pmt_ref_no: 33333 and 99999 as the PAN. The balance ID is 0101.

2. Adele also wants the savings account, you call Add Account with these parameters:
   • accountNo: 33333
   • prodId: 8

The endpoint returns pmt_ref_no: 22222 and balance ID 1212.

3. Adele wants a card for her adolescent son Andy, and she wants Andy's account associated with hers. You call Create Account with these parameters:
   • Andy's name, address and personal information
   • prodId: 3
   • primaryAccount: 33333

The endpoint returns pmt_ref_no: 66666 and 55555 as the PAN. The balance ID is 2323.

This is the end result of the above steps:

📘

Note

Do not confuse primary and secondary accounts with primary and secondary products. At the time program managers set up a product they have the option of creating a secondary product with a separate product ID. The secondary product typically has lesser features compared to the primary product—such as a lower spending velocity—and is intended for minors to use.

Accounts for minors

If your program settings permit it, non-adult (under 18) customers can obtain secondary products. Specify the minimum age for eligible customers in the DOB product parameter. Where a minimum age is specified, the dateOfBirth parameter is required to ensure that the minor is eligible for the product.

Joint accounts and shared balances

It is not currently possible to set up true joint accounts in the Galileo system, wherein one account has multiple account holders. Instead, you can use the shared balance feature. A shared balance is a bank account that multiple products (accounts) can transact on. The accounts can belong to the same customer or to different customers.

With shared balances you can support scenarios such as these:

• A customer wants multiple products from the same provider and wants all of those accounts to transact on the same bank account.
• A parent wants a separate card for a child, and both the parent and child will transact on the same bank account.
• A cardholder wants to add an authorized user to their credit account so that the authorized user can benefit from the credit reporting without being liable for payments.
• A customer wants to add a virtual card to share the same bank account as their physical card.
• Two spouses want the same product, and want both product accounts to transact on the same bank account.

About 3000 secondary accounts can share a balance with a primary account; however, product settings may limit the number of secondary accounts or secondary products a primary account can have. Secured credit accounts can have a maximum of 15 secondary accounts (authorized users). If you are planning to use a high number of secondary accounts with shared balances for corporate spending cards, Galileo offers two solutions: Real-Time Funding for debit accounts and Corporate Credit for credit accounts. These solutions scale better than using shared balances and provide superior reporting and account management.

A secondary account can share a balance only with the specified primary account.

🚧

Warning

Once you share a balance between accounts, you cannot "unshare" the balance. Instead, you would have to close the accounts and create new ones without shared balances. Likewise, you cannot share balances after the accounts have already been created.

📘

Note

When sharing balances, make sure that you do not share a balance among two or more interest-bearing accounts. For example, if you were to share a balance between an interest-bearing DDA and a savings account (meaning that the SAVIR parameter is set for both products), you would create a condition that the interest-payment process cannot properly handle. Likewise, you should not share a balance among multiple savings accounts.

Shared balances scenarios

The following scenarios demonstrate some of the ways to set up shared balances.

One customer, two products

In this scenario, Ana Ramírez, an existing customer, wants another product and would like the second product to transact on the same bank account as the first product.

You already called the Create Account endpoint to create Ana's first account (primary account), with PRN 444 and balance ID 2222. To create the secondary account with a shared balance, call the Add Account endpoint with these parameters:

• accountNo: 444
• sharedBalance: 1

This is the relationship that is set up:

Two customers, one product

In this scenario an existing customer, Simón Ramírez, wants to add an account for his son, Simón Ramírez, Jr. The product IDs are:

• Product ID 6 — DDA with a card
• Product ID 7 — DDA with a card, configured specially for adolescents

For this scenario, you already called the Create Account endpoint to create the father's account (primary account). The endpoint returned pmt_ref_no: 444 and balance ID 2222. To create the account for the son, call Create Account again with these parameters:

• Simón Ramírez Jr.'s name and personal information
• primaryAccount: 444
• prodId: 7
• sharedBalance: 1

This is the relationship that is set up:

Two customers, one secured credit product

In this scenario an existing customer, Adriana Santana, wants to add a secured credit account for her daughter, Fabiana. The product ID is:

• Product ID 20 — Credit account

For this scenario, you already called the Create Account endpoint to create Adriana's secured credit account (primary account). The endpoint returned pmt_ref_no: 92929 and balance ID 36363. To create the secured credit account for Fabiana, call Create Account again with these parameters:

• Fabiana's name and personal information
• primaryAccount: 92929
• prodId: 20
• sharedBalance: 1
• authorizedUser: 1

This is the relationship that is set up:

Getting related account information

With some transaction-retrieval endpoints, you can use the includeRelated parameter to get information for all accounts that share the same balance. If accountNo contains a secondary account, set the parameter like this:

• includeRelated: 0 — Return data only for this secondary account.
• includeRelated: 1 — Return data for all accounts that share the same balance_id.

If accountNo contains a primary account, the data for all accounts that share the same balance_id are returned by default, so there is no need to set includeRelated.

For example, with the Get Transaction History endpoint, these are the possible results for the Two customers, one product scenario, above:

For secured credit accounts, use the getAuthorizedUsers endpoint.

New account creation

In most cases you will use Create Account to create a customer record and a corresponding account record. Other endpoints that create a customer record are:

• Start Enrollment — Creates a customer record but not an account. Use this endpoint when you want to wait until after a customer passes ID verification before creating an account. See Start Enrollment process in Customer ID Verification (KYC/CIP) for more information.
• Create Virtual Card Account — Creates a virtual card and returns the full PAN. You must be PCI-compliant to use this endpoint, and the product ID must be for a virtual card.

Customer record fields

• Customer name
• Customer billing address
• Customer shipping address
• Phone numbers
• Date of birth
• Email address
• Identifiers such as SSN or driver license number
• Occupation and income source

Account record fields

• PRN — Payment reference number. A Galileo-generated account identifier that is unique across the Galileo system. This is the primary identifier for an account.
• Status — The account status. See the Account Statuses enumeration.
• Balance — The amount of funds present in the account that is available to spend.
• Balance ID — An identifier that corresponds to the bank account where customer funds reside.
• Application date — The date the customer is first onboarded to the Galileo system.
• Currency code — The denomination of the funds, such as U.S. dollar or Mexican peso.
• Routing number — The identifier for the bank where the account's funds reside.
• Product ID — The identifier for the specific offering of a program.
• Customer record — The information in the customer record.
• Savings interest object — Where applicable, the amount of interest accrued.
• Transactions — List of settled transactions made on the account.
• Authorizations — List of pending authorizations for the account.
• Pending fees — List of fees to be charged to the account.
• Holds — List of holds for the account.

Card record fields

See Card records in Retrieving Card Information for the fields.

Create Account vs Add Account

Whether to use the Create Account endpoint instead of Add Account is determined by whether the customer already exists in the Galileo system:

• Create an account to onboard new customers, including a new customer who will be the owner of a secondary account.
• Add an account to an existing customer who wants additional products such as savings or overdraft accounts. You cannot use Add Account to deposit funds into the account, nor does it run CIP. For more information on how to add overdraft accounts, see Creating an Overdraft Account.

Create Account and Add Account use cases

Account identifiers

In the Galileo system you will encounter several types of account identifiers:

PRN

The payment reference number is a unique, 12-digit Galileo-generated account identifier. Galileo recommends that you use this number to identify accounts, instead of card numbers or customer IDs, because a PAN can change but a PRN never does. A permanent identifier prevents maintenance headaches when the other identifiers change.

The PRN comprises three parts:

• 3-digit prefix, unique per Galileo client
• 8-digit account number, which in new programs begins with 101 and increments to 102 when the five remaining digits are exhausted. These remaining digits can be generated in sequence or randomly, according to your settings.
• 1-digit checksum

The PRN is also the number that customers provide to their banks when setting up ACH accounts or when setting up direct deposit from an employer. The Program API returns the PRN as pmt_ref_no.

In most cases, you can use the PRN for accountNo in the Program API; however, some endpoints will return an error if there are multiple cards associated with the PRN (not multiple secondary accounts). In that case, use the PAN or the CAD, if the endpoint supports it.

PAN

The primary account number is the globally unique 16-digit number that is displayed on a card. The first 6–8 digits are the BIN, which is assigned by your bank. See PAN Logic for details on how PANs are assigned and generated.

If you are PCI compliant, you can receive the full PAN in Program API responses, Events API messages, the RDFs and the CST. If you are not PCI compliant you receive a masked PAN. The PAN is also called the "card number".

See Card elements in the Setting Up a Card Program guide for more information.

Galileo account number

Also called the "balance ID," the Galileo account number is an identifier that points to the bank account that the product transacts on. The Program API returns the balance ID as galileo_account_no.

Do not pass this number for primaryAccount or accountNo.

External account ID

An external account ID is a number you provide that can be used for your own purposes. Some examples uses of this value are:

• Mapping the customer account to your back-end systems
• Communicating with the embosser to specify which art to use on the card (See Specifying a card design in the Design a Card guide for more information.)

This is how you use the externalAccountId in the Galileo system:

Do not pass this number for primaryAccount or accountNo.

ACH account number

An ACH account points to an external bank account, which can be used for such transactions as interbank transfers. An ACH account is set up using the Add ACH Account endpoint. See About ACH for more information.

External customer ID

An external customer ID is an identifier you provide to associate multiple accounts under the same customer. This field can be used for your own purposes, including mapping and traceability.

This is how you use the externalCustomerId in the Galileo system:

Account identifiers in the Galileo system

This table is a summary of how account identifiers are represented across the Galileo system.

Virtual card accounts

A virtual card exists only on a customer's mobile device, on the web, or in an email: it is not issued as a physical card. See Digital cards in the Choose a Card Strategy guide and Setup for Virtual Cards for information on virtual card accounts.

Account status

An account's status is designated by a single capital letter in the Galileo system, as shown in the Account Statuses enumeration.

📘

Note

Account status is not the same as card status. The statuses may be similar in some cases, but they operate independently. See the Card Statuses enumeration.

By default, when a card account is first created, it is in status: W (waiting to be processed). (For a different default status, set the XAACT parameter.) The Galileo system runs an account-setup process, a cron job that runs every 5–30 minutes, depending on your product settings. When successful, the account is put into its next state, according to your product parameters. Most virtual card accounts and Digital First card accounts are put into status: N (active). A conventional physical card would be moved into status: X (waiting for emboss).

An emboss process periodically checks for physical card accounts in status: X and collects the emboss information to send to the card embosser. At this point the account is moved to status: Y (ready to activate), and when the card is mailed to the cardholder and activated it is changed to status: N (active). See the Card Statuses guide for information on how card statuses change during the emboss process.

To manually change an account status, use the Modify Status endpoint. Consult Modify Status Codes for a list of values for the type parameter. Be sure that the Modify Status type changes exactly what you want: the account status, the card status or both.

Account features

Most of an account's features are set at the product level; however, a few features can be set or modified at the account level, such as allowing international transactions or sending paper statements. To set or change these features use the Set Account Feature endpoint. Defaults for some of these features can also be set at a product level. Contact Galileo to set these defaults.

Also see About Account-Level Authorization Controls for authorization limits to set at an account level.

Depositing funds into accounts

According to your product settings you have the option to deposit funds into an account at the time of account creation or you can deposit funds later. Customers can also deposit funds into their accounts if your product settings permit it. The sooner funds are deposited into a debit account, the more likely the cardholder is to start spending and to stick with the product.

Consult this table to see how to use the endpoints for each use case.

Retrieving account information

Use these endpoints to retrieve the desired account information..

Column header key

• A — Get Balance
• B — Get Account Overview
• C — Get Account Features
• D — Get Account
• E — Verify Account
• F — Get Interest
• G — Get Savings Interest
• H — Get Overdraft Balance

Modifying account information

After you have created a new account you can modify customer record attributes using the Update Account endpoint, as long as the account is active (status: N). (To update account information in status C or Z, set the UPDCZ parameter.) When sending the Update Account call, you pass only the parameters to be modified. Parameters that are not being modified can be left blank. Do not pass null unless you want to set the parameter's value to null.

📘

Note

According to the settings in your product parameters, some customer record information may not be modifiable or nullable. See Update Account for details.

You can input either a primary or secondary account number to change the associated customer record attributes.

User-defined account fields

While administering your accounts you may want to append additional information that is not included in the account-creation endpoint parameters. For this you can use the Set User-Defined Account Field endpoint to create a custom field and populate it however you need.

These are the properties of user-defined fields:

• The field and its contents are added at the PRN level, not the card or customer level.
• You can add only one field per endpoint request.
• You can choose any string up to 15 alphanumeric characters for the field name (no spaces). The field name must be unique to the PRN, but it does not need to be unique across your program.
• The contents of the field can be up to 175 characters including spaces and punctuation.
• The fields can be created and populated only by the API endpoint. You cannot use the CST or a batch process to create or update the fields.
• You can view the user-defined fields for a PRN by calling Get User-Defined Account Fields or by clicking User-Defined Fields on the account's landing page in the CST.
• To update a field, call Set User-Defined Account Field, specify the field name in fieldId, and enter the new contents in fieldValue.
• You cannot delete a field. If you attempt to set the field value to spaces, the endpoint will interpret the spaces as an empty value and return an error.

Switching to a new product

You can change the product ID for an account by following the steps in Switching Products.

Closing accounts

Because the Galileo system is an official system of record, it is not possible to delete an account from the Galileo system. Legal requirements specify that all activity, including account creation, be stored for a period of several years for auditing purposes.

However, an account may be closed, which prevents further transactions from being made on it and deactivates any cards associated with it. The Account Statuses enumeration shows which transactions are valid for each account status.

Your product settings determine some of the events that trigger an account closing, such as an account having zero or negative balance for a specified period. Other events such as a stolen or lost card can result in a closed account. (See Lost, Stolen, or Damaged Cards.)

Your product settings also determine which procedures must be followed when an account is closed, such as whether to send a check for the remaining balance or whether the cardholder must return the card before receiving a check. See Account Holder Refunds for more information.

This table shows some of the statuses that can represent a closed or unusable account and the type parameter in the Modify Status endpoint that moves the account to that status. See Modify Status Codes for all Modify Status types. Follow your business plan to decide when to use these Modify Status types. Also see Card cancelation in the Setting Up a Card Program guide.

📘

Note

If the card is in status: N but the account is in a canceled status, the card cannot be used.

📘

Note

You cannot update the information in a closed account using Update Account, unless the provider parameter UPDCZ is set to permit updates to accounts in statuses C and Z.

Reversing an account creation

If you have created an account in error, follow these steps:

1. Optional. Call Update Account to set the id and id2 values to null, so that the customer can attempt to join again.
2. Call Modify Status with type: 2 to cancel the account.

Alternatively, you can use the Customer Service Tool to cancel the account.

Reactivating accounts

When you close a savings account and its associated debit account (DDA), and then you reopen the DDA using type: 1 or type: 11, the savings account is automatically activated as well.

🚧

Important

Mastercard considers status: C (canceled) and status: Z (canceled without refund) to be permanent statuses. As of 3 Jun 2025, issuers are required to return response_code: 46 for accounts or cards in those two statuses. If you reactivate a card or account that was closed, Mastercard could assess penalties for transactions attempted against that card. If you need to temporarily close an account or card to reopen later, use status: D (disabled).

Events API

These event messages represent stages in account creation and management. You can arrange with Galileo to receive the events that correspond to your use case. Some of the events are triggered only by actions taken in the CST, others only by the Program API, and others by both. Click the event to see details:

• CAPP: app_completed — Account creation is successful.
• PTID: pass_id — The customer passed Galileo's integrated ID verification
• FTID: fail_id or BFID: failed_id — The customer failed ID verification
• ACST: account_status_change — Account status changed (in some circumstance)
• ADRC: addr_chg — The Program API updated the customer's primary address
• ECHG: email_addr_change — The Program API or CST updated the customer's email address.
• PHCH: phone_changed — One of the customer's phone numbers was changed.
• PCHG: profile_changed — The CST changed customer profile information.
• CHPC: cardholder_info_changed — The CST changed customer profile information.
• BBAL: bal — The account has a positive balance today.
• BNEG: neg_bal — The account has a negative balance today.
• LBLC: low_balance_notify — The balance has dropped below a specified amount.
• ACCL: account_closed — The CST closed a customer account.

Galileo setup

Refer to the Accounts table on the Parameters page for account-related settings.