Velocity Control Design

This guide describes how to conceptualize and design velocity controls. For additional information on ALCs, see these guides:

• Designing Authorization Controls
• Account-Level Authorization Controls
• Set Velocity ALCs

Velocity controls have these attributes:

• Transaction types affected, such as ATM or point-of-sale
• Timespan affected, such as day, week or single transaction
• Whether domestic or international transactions are affected
• Whether PIN or signature transactions are affected
• Amount per period or transaction
• Number of transactions per period
• MCCs that are affected (optional)

📘

Note

Authorization reversals can affect velocity limits depending on when they're performed. See Reversals and authorization limits in the Crediting Cardholder Accounts guide for more information.

Product-level velocity controls

This table contains some example product-level velocity controls that you might set:

For example, the top row controls how much may be withdrawn from domestic ATMs per day—$600 total in no more than three transactions, and the second row shows a total daily international ATM withdrawal limit of $400 but no limit on the number of transactions per day.

Galileo can help you consider which controls to set and provide general guidelines on limits, but ultimately you must consult with your bank to determine which product-level velocity controls to set.

Product-level velocity controls are represented in the Galileo system as shown in this table, which contains sample values:

• Control ID — A Galileo-generated value to identify the control. The control ID is unique per product-level control.
• Description — A description of the control, shown here for clarity.
• Period — The format is [numeral][D|T|M], where:
  • D – Calendar day, from 00:00:00 to 23:59:59 in Galileo system time
  • T — Single transaction
  • M — Calendar month; a rolling 30-day period is 30D
• Trans Type — Type of transaction affected:
  • ATM — Automated teller machine
  • CAD — Cash advance (over-the-counter, teller)
  • CBA — Cash back (at point of sale)
  • POS — Point of sale
  • VFT — Visa funds transfer
• Domestic Flag — Whether domestic or international transactions are affected:
  • Y — Domestic only
  • N — International only
  • A — Both domestic and international
• Has PIN — Whether PIN or signature transactions are affected:
  • Y — PIN only
  • N — Signature only
  • A — Both PIN and signature

Each velocity control also has an amount, a count (number of transactions) or both. A dash (—) means that there is no limit. For example:

• For the daily ATM controls, there is a limit of 12 transactions per day, and the amount is different depending on whether it's domestic or international.
• The per-transaction ATM limit is 200, but there is no need to set transaction count.
• The next two controls specify amount limits but not the number of transactions per period.

Galileo creates your default product-level velocity controls during product setup, and you can set them in the GCC. Once these product-level controls are created, you can view them in the GCC and CST and retrieve them using the Get Auth Control endpoint.

Account-level velocity controls

A velocity ALC must correspond to an existing product-level velocity control. If the product-level control does not exist, you cannot create the ALC. This table shows which ALCs can be created, given the controls shown in the tables above.

Creating a velocity ALC

Detailed instructions for creating a velocity ALC are in Set Velocity Controls.

• Product-level controls do not impose limits on velocity ALCs—you can set the ALCs to whatever value you want, because the ALC overrides the product-level control. However, you should consult with your bank when deciding to set ALCs to a higher amount or count to ensure that you do not exceed limits that they support.
• You cannot set other properties of a velocity control at the account level (description, transaction type, domestic flag, has-PIN flag).

This table shows example ALCs that you could create for the product-level controls above.

• Control ID 1 — The amount is doubled from 500 to 1000, and the transaction count limit is removed.
• Control ID 2 — The amount is doubled from 300 to 600 and the transaction count is also doubled.
• Control ID 3 — The amount is reduced by half. Because this is a per-transaction limit, there cannot be a transaction count limit.
• Control ID 4 — The amount is increased from 1500 to 2000 and the transaction count is unchanged.
• Control ID 5 — The amount is unchanged but a transaction count of 40 has been imposed.

📘

Note

When you set an ALC, you can change the amount or the transaction count or both. If you do not specify one of the limits, then that limit does not exist for the control—the product-level limit is not used. For example, for Control ID 5, the same amount from the product-level control is repeated while the transaction count has changed. If the amount were left blank, there would be no amount limit anymore—the 10000 limit at the product level would not be applied.

MCC velocity controls

Besides the properties described above, you can create velocity ALCs that apply to specific MCCs. (You cannot set MCC ranges for product-level velocity controls.)

For example, you could create an ALC for Control ID 4 that has a different amount and count than the product-level control, and then you could create another version of the same ALC to apply different limits to gas stations and fuel pumps (MCC 5541–5542).

• Both of these ALCs have the same control ID.
• The first ALC sets the weekly POS limit to a higher amount than the product-level control and also imposes a transaction count.
• The second ALC specifies that only 300 per week may be spent at gas stations and imposes a limit of 10 transactions.

🚧

Warning

When you set MCCs for velocity ALCs, the MCCs must be allowed by both the product-level and account-level MCC controls.

The MCCs for a velocity ALC must also not overlap the MCCs of existing velocity ALCs.

If you create a velocity ALC with an MCC range that is currently allowed, you cannot add or modify an account-level MCC control to deny any part of that range—the Set Account-Level MCC Controls endpoint would return an error. For example, if you have an MCC velocity control that specifies the 3000–3049 range, you cannot use the Set Account-Level MCC Controls endpoint to create a DENY control for 3020–3025.

However, if you create a DENY control for 3020–3025 at the product level, you will not get an error, because you do not use the Program API to make the change. Instead, the authorization process will malfunction, and transactions will likely be denied. Therefore, you should check the MCC ranges of your velocity ALCs before changing product-level MCC controls.

When you set MCC-specific limits, they must be equal to or less than the limits of an ALC with the same control ID that does not specify MCCs. In the example above with the two Control ID 4 ALCs, the amount for the second ALC cannot be more than 2000, and the transaction count cannot be more than 24.

Besides the ALCs shown in the table above, you could create a few more versions of Control ID 4 with different MCC ranges and different limits. For example, you could set different weekly limits for airlines, restaurants, and transportation.

In the table below, you can see how the amount limits for each of the MCC-specific ALCs are under 2000, but they together add up to a value higher than 2000. This means that after the cardholder spends 1500 on airlines and 500 on hotels, for example, the cardholder cannot make any more POS purchases for the rest of the week, because that ALC limit has been reached. (In the Description column below, the description of the MCC range is shown here for clarity, but in the Galileo system, the ALCs do not have different descriptions for different controls.)

• It is not necessary to first create an ALC that has no MCCs. If you deleted the first ALC in the table above, the 1500 limit for airlines would become the upper limit for the weekly POS limit.

ALCs and timespans

ALCs can be applied either permanently or temporarily. For example, you can create an ALC that is in effect for one week only, either the current week or a week in the future. You can create an ALC that takes effect "now" but that expires in 24 hours, or you can create an ALC that takes effect immediately and never expires.

The time limitation is useful when you know that the cardholder is going to have different spending patterns for a short time. For example, if you know that 40 business cardholders will be attending a five-day conference next month, you can set ALCs for that timespan that make sense for their needs such as different limits for lodging, transportation, and restaurants.

The table below contains examples of temporary and permanent velocity ALCs that you might set, given the product-level controls in the tables above, and assuming that today is March 10. See Setting time limits in Setting ALCs for more details on how the time settings work.

• "Now" means the time when you create the ALC, in Galileo system time.
• When all account-level controls are removed for a particular control ID, the account reverts back to the product-level controls.
• See Set Velocity Controls for instructions on using the API to set velocity ALCs.
• See the Authorization workflow in Designing Authorization Controls to see how velocity controls are applied relative to other types of controls, as well as which response codes to expect when there are violations.

👍

Tip

Also see Velocity MCC examples in MCC and Merchant ID ALC Examples for another set of product IDs and ALCs.