Account-Level Authorization Controls

This guide explains what account-level authorization controls are and how to use them. You may also want to consult these documents:

• Designing Authorization Controls — Instructions on deciding which product-level controls to set by default and what kinds of account-level controls to set.
• Setting ALCs — Instructions on how to implement ALCs using the Program API.

Why authorization limits?

When you set up a product that has a card, you also set up authorization restrictions such as velocity limits—amount per transaction or per day, for example, or number of transactions per day—as well as limits on which merchants are valid. These product-level restrictions apply to all accounts with that product ID. For a particular card product you might limit the number of ATM withdrawals per day to 3 and limit the amount per withdrawal to $200. You might also exclude certain merchant types by MCC or merchant ID. These limits are set in cooperation with your bank to help mitigate fraud or to manage corporate spending for businesses.

Issuers commonly set up different limits for different cardholders, such as providing higher per-transaction limits for cardholders who meet certain criteria. Issuers create multiple tiers to address use cases such as these:

• Rewarding the best customers — The higher limits help increase cardholder engagement by removing negative experiences of hitting a limit. It also encourages cardholders to qualify for the higher limits by engaging in behavior that benefits the issuer.
• Limiting teen accounts more than parent accounts — When offering products that pair an account for parents with accounts for teens, the issuer can provide lower velocity limits for the teens while keeping more advanced limits for the parents.
• Providing different limits for different employees — Creating different tiers is also useful for business-to-business issuers who create cards for specific uses, such as gas cards for fleet drivers or cards issued to employees with different levels of purchasing authority.
• Restricting cards to certain merchant types — A business that issues cards to its employees may want to specify that one card be used only to buy office supplies, whereas another be used only for transportation-related expenses such as gasoline and auto repairs.

One way to provide the different tiers is to create one or more products that are similar to each other except that they have different authorization limits, and then switch the cardholder's account to the product to change the authorization limits (as described in Switching Products). This method is viable when you have only a few combinations of limits to set and do not wish to customize limits any further, or when the different product levels represent more benefits than different authorization limits.

With account-level authorization controls (ALCs) you can impose authorization limits on a per-account basis. In this way, you can create only one product and then set customized velocity limits or merchant restrictions per cardholder. By using ALCs you can:

• Expend fewer resources on creating and maintaining multiple products
• Easily create multiple tiers for the same product
• Instantly apply customized limits per cardholder account
• Set temporary limits
• Instantly remove customized limits
• Set lower limits than the default
• Provide one-time limit increases
• Provide one-time permission for a particular merchant or merchant type

📘

Note

If you create multiple products for multiple tiers, you can still use ALCs.

Prerequisites

You can set ALCs for any account that has a card, regardless of network. Contact Galileo to request access to ALCs so that they can be set up in the system and the ALC-related API endpoints enabled. You will need to work with your bank to specify which velocity limits or merchant restrictions to set at both the product and account levels. See Designing Authorization Controls for instructions on creating these authorization controls.

Use cases

These use cases provide examples of ways to use ALCs. To see how to implement these use cases with the Program API, see Use cases in Setting ALCs.

Use case 1: Reward qualifying cardholders with higher velocity limits

You and your bank have set your default product controls to limits that are suitable for the average cardholder. However, you and your bank also agree that cardholders who maintain a balance above a certain amount for six months should be rewarded with higher velocity limits. You also create a third tier for cardholders who maintain an even higher balance.

When a particular cardholder meets a requirement, you call an API to create ALCs for that account. The ALCs start at the time the ALCs are created and do not expire.

See Use case 1 for instructions on setting these controls.

Use case 2: Set special limits during a cardholder's vacation

To your cardholders you offer a vacation service wherein the cardholder indicates that they will be making international purchases during a certain period in the future. Because the cardholder plans on spending more than usual, you call an API to create an ALC that increases limits for international transactions during the vacation time.

See Use case 2 for instructions on setting this control.

Use case 3: Reduce velocity limits for a cardholder

Some cardholders' spending behavior could indicate that fraud is taking place. Rather than cancel the card and anger an innocent cardholder, you call an API to set ALCs that are lower than the defaults to reduce risk. If the cardholder contacts you and demonstrates that the behavior is legitimate, you can instantly call an API to remove the ALCs to restore the defaults.

See Use case 3 for instructions on setting these controls.

Use case 4: One-time increase to a limit

A cardholder attempts to withdraw cash from an ATM, but the withdrawal violates the transaction-count limit. You offer a service whereby the cardholder can request a one-time override of a limit. The cardholder contacts you, and because the cardholder has been a reliable customer, you create an ALC to override the transaction-count limit. The ALC expires after 30 minutes. (You could also create an ALC to provide a temporary increase to the withdrawal amount.)

See Use case 4 for instructions on setting this control.

Use case 5: Fleet cards

A business has a fleet of vehicles and issues cards to its drivers. By default, these cards can be used at gas stations as well as auto parts and auto repair stores but not at any other type of merchant. However, a subset of the drivers perform long-distance deliveries, and so you permit those cards to be used at hotels as well. You set up the default merchant restrictions for the product, and then call an API to permit hotel usage for each cardholder that needs hotels. See Fleet Cards for more information on fleet programs.

See Use case 5 for instructions on setting this control.

Use case 6: Food-delivery cards

A business that contracts with drivers to deliver food issues a card to each driver to pay for the customer's order at the restaurant. To prevent misuse of the card, the default setting denies all merchants, and then when an order comes in from a restaurant, you call an API to authorize transactions for that merchant only for the next hour.

See Use case 6 for instructions on setting this control.

Use case 7: Teen spending cards

Your program permits parents to request cards for their teen children, and you permit the parents to determine the types of spending limits the cards should have. For example, parents can impose a weekly spending limit, prevent spending at certain types of merchants, or put limits on how much can be spent by merchant type.

See Use case 7 for instructions on setting these controls.