Designing Authorization Controls
This guide explains how to design product-level authorization controls and how to decide which account-level controls (ALCs) to create.
Related documents:
- About Account-Level Authorization Controls — General explanation about ALCs, including use cases.
- Setting Account-Level Authorization Controls — Instructions for developers to apply ALCs to individual accounts.
- MCC and Merchant ID ALC Examples — Tables that show how MCC and merchant ID controls are applied.
When you set up a product, you define default authorization controls for each product. These controls are configured in cooperation with your bank, according to your use case. In addition, you can create authorization controls to apply to individual accounts. You should also consult with your bank to make sure that your ALCs don't violate a limit that the bank sets.
You can set up three kinds of ALCs:
- Velocity
- MCC
- Merchant ID
Velocity controls
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
Some example product-level velocity controls that you might set are in this table:
Description | Amount | Transaction count |
---|---|---|
Total daily ATM withdrawal, domestic | $600.00 | 3 |
Total daily ATM withdrawal, international | $400.00 | blank |
Per-transaction ATM limit, domestic and international | $200.00 | 1 |
Total weekly point-of-sale amount, domestic and international | $5000.00 | blank |
Total weekly amount, all types, domestic and international | $10,000.00 | blank |
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.
You determine which default velocity controls to set in conjunction with your bank. At the same time, you can get permission for other controls that can be set on a per-cardholder basis and determine which criteria the cardholder must meet to qualify for the different limits.
Product-level velocity controls are represented in the Galileo system as shown in this table with sample values:
Control ID | Description | Period | Trans Type | Domestic Flag | Has PIN |
---|---|---|---|---|---|
1 | Daily ATM withdrawal limit, domestic | 1D | ATM | Y | A |
2 | Daily ATM withdrawal limit, international | 1D | ATM | N | A |
3 | Per-transaction ATM limit | 1T | ATM | A | A |
4 | Weekly POS limit | 7D | POS | A | A |
5 | Monthly combined limit (ATM, POS, CAD, CBD) | 1M | ATM, POS, CAD, CBD | A | A |
- Control ID — A Galileo-generated value to identify the control. This ID is unique per core.
- Description — A textual description of the control, provided 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 timeT
— Single transactionM
— Calendar month; a rolling 30-day period is30D
- Trans Type — Type of transaction affected:
ATM
— Automated teller machineCAD
— Cash advance (over-the-counter, teller)CBA
— Cash back (at point of sale)POS
— Point of saleVFT
— Visa funds transfer
- Domestic Flag — Whether domestic or international transactions are affected:
Y
— Domestic onlyN
— International onlyA
— Both domestic and international
- Has PIN — Whether PIN or signature transactions are affected:
Y
— PIN onlyN
— Signature onlyA
— Both PIN and signature
Each velocity control also has an amount, a count (number of transactions) or both. A blank means that there is no limit. For example:
Control ID | Description | Amount | Transaction Count |
---|---|---|---|
1 | Daily ATM withdrawal limit, domestic | 500 | 12 |
2 | Daily ATM withdrawal limit, international | 300 | 12 |
3 | Per-transaction ATM limit | 200 | blank |
4 | Weekly POS limit | 1500 | blank |
5 | Monthly combined limit (ATM, POS, CAD, CBD) | 10000 | blank |
Galileo can create your default product-level velocity controls during product setup, or 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 Controls endpoint.
Velocity ALCs
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.
Account-level control | Valid | Not valid |
---|---|---|
Per-transaction ATM limit | X | |
Monthly cashback limit (CBA) | X | |
Daily ATM withdrawal limit, international | X | |
Weekly ATM withdrawal limit, domestic | X | |
Daily POS limit | X | |
Per-transaction POS limit | X |
- The product-level controls do not impose limits on velocity ALCs—you can set the ALCs to whatever value you want, and the ALC overrides the product-level control. However, your bank may require that ALCs not exceed a certain threshold.
- When you set an ALC, you can specify either the amount or the transaction count or both. If you do not specify one of the limits, then that limit does not exist—the product-level limit is not used. For example, if you set the amount but not the transaction count, then the control does not have a transaction-count limit.
- You cannot set other properties of a velocity control at the account level (transaction type, domestic flag, has-PIN flag).
- 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 also create an ALC that takes effect "now" but that expires in 24 hours.
Account-level velocity control examples
The table below contains examples of velocity ALCs that you might set, given the product-level controls in the tables above, and assuming that today is March 10.
Description | Amount | Transaction count | Start Date | End Date |
---|---|---|---|---|
Total daily ATM withdrawal, domestic | 1000 | 6 | Now | None |
Total daily ATM withdrawal, international | 600 | Unlimited (blank) | March 10 | March 17 |
Per-transaction ATM limit, domestic and international | 500 | 3 | Now | March 21 |
Total weekly point-of-sale amount, domestic and international | 5000 | 14 | Now | Tomorrow |
Total weekly amount, all types, domestic and international | 7000 | Unlimited (blank) | Now | March 31 |
- "Now" means the time when you create the ALC, in Galileo system time.
- When an account-level control is removed, the account reverts back to the product-level controls.
See Velocity controls in the Setting Account-Level Authorization Controls guide for instructions on using the API to set velocity ALCs.
See Authorization workflow to see how velocity controls are applied.
MCC controls
Merchant category codes (MCCs) are 4-digit numbers established by ISO 18245 to categorize merchants by type, such as hotels, airlines, bookstores, gas stations, and so on. Merchants pass their MCCs to card issuers in authorization request messages.
You can set MCC controls at three levels:
- MCC blocklist
- Account level
- Product level
MCC blocklist conventions
- Set for all Galileo programs at the product level, the MCC blocklist typically blocks some gambling-related MCCs and other MCCs according to your bank's guidelines.
- This control overrides all other MCC and merchant ID controls.
- Changing this blocklist is done by Galileo at your request.
Warning
When deciding which MCCs to add to the blocklist, make sure there is no overlap with existing product-level MCC controls. If there is overlap, the product-level control will be invalidated. Ask Galileo to help you change product-level MCC controls as needed to accommodate the blocklist.
Account- and product-level MCC control conventions
An account-level MCC control is applied in addition to product-level MCC controls, not instead of. MCC ranges in an ALC cannot overlap existing MCC ranges. For example, if the MCC ranges at the product level are 2000–3000 and 4500–4550, then the ALC MCCs cannot overlap those ranges. An ALC that specified 2995–3100 would not be valid.
- If no MCC controls exist, then all MCCs are allowed, except those MCCs in the MCC blocklist.
- You are not required to set MCC controls at the product or account level.
- Product-level controls are set in cooperation with Galileo during product setup and can be edited by request.
- When inputting values in the endpoint calls or the CST, the valid range is 0001–9999, but the values 0001–0599 are not currently mapped to any merchant categories.
- Multiple ranges of MCCs can be specified at the product level, but the ranges cannot overlap.
- The MCC range of an account-level control cannot overlap a product-level range or another account-level range.
- MCC ranges at the product or account level cannot overlap the values in the MCC blocklist.
- An MCC control must either ALLOW or DENY a range.
- If one or more MCCs are ALLOW, then all other MCCs are denied.
- If one or more MCCs are DENY, then all other MCCs are allowed.
- All MCC controls at the product and account levels must all be either ALLOW or DENY.
- Account-level controls cannot contradict the ALLOW/DENY property of product-level controls. For example, if the product-level controls are ALLOW, then the account-level controls must also be ALLOW.
- If the product-level MCC control is 0000–0000 ALLOW it means DENY ALL, so account-level MCC controls can be ALLOW. In contrast, 0000–0000 DENY is not a valid setting, because ALLOW ALL is already the default.
- Setting 0000–0000 ALLOW must be done at Galileo by your request.
- MCC controls can be set for online transactions only, at both the product and account levels.
- When Galileo denies an authorization request because of an MCC violation, the response code is
03
for Mastercard or57
for all other networks.
Warning
When an account is switched to a new product, the account-level MCC controls move with it. However, if the account-level MCCs conflict with the new product's MCC controls, the authorization process will fail and authorization requests will be denied. Before performing product switches, ensure that the account-level controls do not conflict with the new product's MCC controls. You may need to consult with Galileo to confirm or adjust the values.
Example MCC controls
This table shows how MCC controls are applied.
Example 1 | Example 2 | Example 3 | |
---|---|---|---|
Transaction | MCC 3000 | MCC 3000 | MCC 3000 |
MCC blocklist | — | — | MCC 3000 |
Product level | MCC 2000–2999 ALLOW MCC 4000–4999 ALLOW | MCC 2000–2999 ALLOW MCC 4000–4999 ALLOW | MCC 2000–2999 ALLOW MCC 4000–4999 ALLOW |
Account level | — | MCC 3000 ALLOW | MCC 3000 ALLOW |
Result | DENY | ALLOW | setting not valid |
Reason | MCC 3000 falls outside the product-level ALLOW ranges | MCC 3000 is allowed at the account level | MCC 3000 ALLOW cannot be set at the account level because it overlaps with the MCC blocklist |
- See Authorization workflow to see more on how MCC controls are applied.
- Also see MCC and Merchant ID ALC Examples.
Online-only property
All MCC controls, at both the product and account levels, can be configured to apply only to online (card not present) transactions. By default, an MCC control applies to all transactions. You cannot specify that a control apply only to non-online (card present) transactions.
This table shows how the online-only property is applied.
Example 4 | Example 5 | Example 6 | |
---|---|---|---|
Transaction | MCC 5750 online | MCC 5550 not online | MCC 5750 online |
MCC blocklist | MCC 7995 | MCC 7995 | MCC 7995 |
Product-level MCC | 5500–5600 ALLOW | 5500–5600 ALLOW | 5500–5600 DENY |
Online only (product) | Y | Y | N |
Account-level MCC | — | — | 5750 DENY |
Online only (account) | — | — | Y |
Result | DENY | DENY | DENY |
Reason | MCC 5750 is outside the ALLOW range. | MCC 5550 is allowed only for online transactions. | MCC 5750 is denied at the account level for online transactions. |
- Also see MCC and Merchant ID ALC Examples.
Define product-level MCC controls
This table shows examples of product-level MCC controls that you might set. (When planning your own MCC controls, obtain the latest version of ISO 18245 to confirm the MCCs instead of using this guide.)
MCC control | Merchant types |
---|---|
3000–3300 ALLOW | Airlines |
3350–3450 ALLOW | Car rental |
3500–3899 ALLOW | Hotels |
4000–4790 ALLOW | Ground transportation |
5044–5046 ALLOW | Office supplies |
5531–5533 ALLOW | Auto parts |
5541–5542 ALLOW | Gas stations, fuel pumps |
6010–6012 ALLOW | ATMs and other cash disbursement |
With these MCC ranges set to ALLOW, all other MCCs are denied.
Other factors to keep in mind:
- Some merchants use more than one MCC. For example, Amazon began life as a bookstore, but since branching out it now uses multiple MCCs, depending on the service. Some of its MCCs are:
- 5942 (Bookstores) — Amazon Marketplace
- 5968 (Continuity/subscription) — Amazon Prime, Audible
- 5411 (Grocery stores, supermarkets) — Groceries
- New MCCs can be added to ISO 18245 at the request of merchant groups when the category has at least $10 million annual revenue. Always consult the most recent version of ISO 18245 when setting MCC controls.
Design account-level MCC controls
When determining which account-level MCC controls to set, remember that the account-level controls are applied in addition to product-level MCC controls, not instead of. For this reason they cannot overlap any of the product-level MCC ranges or the MCCs in the blocklist. They must also have the same ALLOW/DENY property as the product-level controls.
If you set the product-level MCC controls in the table above, all of your account-level MCC controls must also be ALLOW, and they cannot overlap any of the product-level ranges. This table shows which account-level controls would be valid and which would not.
ALC | Merchant types | Validity |
---|---|---|
5812–5814 ALLOW | Restaurants | Valid |
5942–5943 ALLOW | Books and stationery | Valid |
3690 ALLOW | Courtyard by Marriott Hotel | Not valid. Cannot overlap other ranges. |
5611–5691 DENY | Clothing stores | Not valid. Must be ALLOW. |
4121 DENY | Taxi cabs and limousines | Not valid. Must be ALLOW, and cannot overlap other ranges |
- See MCC and Merchant ID ALC Examples for more examples of how MCC ALCs are applied.
- See MCC controls in the Setting Account-Level Authorization Controls guide for instructions on calling the API to set MCC ALCs
Merchant ID controls
A merchant ID (MID) control is derived from DE042 of an ISO 8583 authorization request, which contains an identifier that is unique to a point of sale. An MID control at the account level can override existing MCC controls, either to ALLOW or DENY a transaction from a merchant that would otherwise be denied or allowed based on its MCC. Account-level MID controls exist independently of the product-level MID controls. If no product-level MID controls exist, you can still set MID controls, and they can overlap MCC controls and other MID controls.
Merchant ID control conventions
- A merchant ID is specific to a point of sale such as a store location or web site, not to a chain of stores.
- Product-level merchant controls follow these rules:
- The product-level control is applied only if the MCC controls allow the transaction.
- The product-level control includes the MID as well as terminal ID and merchant description so that it can be used to assess fees.
- If you are using Galileo's fraud-detection engine, the engine will automatically add DENY MIDs to your product-level controls as necessary.
- An MID control must specify the entire merchant ID—no wildcards are allowed.
- The MID is not case-sensitive.
- Merchant IDs often change when a merchant replaces its card readers or makes other adjustments.
- A single ecommerce site that provides merchandise or services from third parties will use different MIDs for each vendor. See Amazon transaction in Card Transaction Examples to see different MIDs in the same transaction.
- An account-level MID control overrides product-level and account-level MCC controls but does not override the MCC blocklist.
- When Galileo denies an authorization request because of a merchant ID violation, the response code is
03
for Mastercard or57
for all other networks.
This table shows how MID controls are applied.
Example 7 | Example 8 | Example 9 | |
---|---|---|---|
Transaction | MCC 3000 MID 5555 | MCC 3000 MID 5555 | MCC 3000 MID 5555 |
MCC blocklist | — | — | MCC 3000 |
Product-level MCC | any value | any value | any value |
Account-level MCC | any value | any value | any value |
Product-level MID | any value | any value | any value |
Account-level MID | MID 5555 DENY | MID 5555 ALLOW | MID 5555 ALLOW |
Result | DENY | ALLOW | DENY |
Reason | The account-level MID overrides MCC controls. | The account-level MID overrides MCC controls. | The MCC blocklist overrides all other controls. |
- See MCC and Merchant ID ALC Examples for more examples of how MID ALCs are applied.
- See Authorization workflow to see more on how MID controls are applied.
Galileo does not have a list of merchant IDs to provide—you must compile the list yourself. You can get these numbers from the merchants by request or you can harvest that data from Galileo data sources such as the Auth API, RDFs and Authorization Events messages. However, Galileo sources return the merchant ID only after the authorization process has checked for merchant ID controls, so you cannot harvest them from the Auth API webhook, for example, and then create a merchant ID ALLOW control for the current authorization—the MID control would apply only to subsequent authorization requests.
Because the product-level merchant controls are used to assess fees, you will develop these controls in conjunction with Galileo and your bank during product setup. In contrast, the ALCs specify only the MID to provide a quick way to allow or deny a particular merchant.
If you would like to correlate a merchant ID with the merchant name (DE043) in your lookup table, use these fields from these Galileo data sources:
Source | Merchant ID (DE042) | Merchant description (DE043) |
---|---|---|
Auth API | merchant_id | merchant_description + merchant_state + merchant_postal_code |
Events API | merchant_number | merchant_name + merchant_location |
RDFs | MERCHANT NUMBER | MERCHANT DESCRIPTION |
Program API | merchant_id * | details formatted_merchant_desc * |
* Get Transaction History and Get All Transaction History only.
Authorization workflow
During the authorization process, Galileo runs a series of checks and calculates a list of response codes when there are violations. When multiple violations result in multiple response codes, Galileo returns a single code to the network according to a proprietary algorithm. (See the Auth API Validation Checks guide for more information.)
Galileo performs the authorization checks described in this guide in this order:
- MCC blocklist
- Account-level MID
- Account- and product-level MCC
- Product-level MID
- Account-level velocity
- Product-level velocity
This flowchart shows the process for checking these authorization controls. The MCC online only property has been omitted for clarity.

Galileo receives an authorization request from the network.
- If the MCC is on the MCC blocklist, Galileo calculates response code
57
or03
(Mastercard) and stops checking authorization controls. - If a merchant ID ALC exists, Galileo applies that control.
- If the ALC is DENY, Galileo calculates code
57
and stops checking authorization controls. - If the ALC is ALLOW, Galileo begins to check the velocity controls.
- If no ALC exists, Galileo goes to the next step.
- If the ALC is DENY, Galileo calculates code
- If MCC controls exist, Galileo applies those controls.
- If the MCC controls DENY, Galileo calculates response code
57
or03
(Mastercard) and stops checking authorization controls. - If the MCC controls ALLOW, Galileo goes to the next step.
- If MCC controls do not exist, Galileo goes to the next step.
- If the MCC controls DENY, Galileo calculates response code
- If a product-level merchant ID control exists, Galileo applies that control:
- If the product-level control is DENY, Galileo calculates response code
57
and stops checking authorization controls. - If the product-level control is ALLOW, Galileo goes to the next step.
- If no product-level control exists, Galileo goes to the next step.
- If the product-level control is DENY, Galileo calculates response code
- If a velocity ALC exists for the control, Galileo applies the ALC to the transaction.
- If an amount limit exists in the ALC, Galileo applies that limit; if it does not exist, then no amount limit is applied.
- If the transaction violates the amount limit, Galileo calculates response code
61
and stops checking authorization controls. - If the transaction does not violate the amount limit, Galileo goes to the next step.
- If the transaction violates the amount limit, Galileo calculates response code
- If a transaction count limit exists in the ALC, Galileo applies that limit; if it does not exist, then no transaction-count limit is applied.
- If the transaction violates the transaction-count limit, Galileo calculates response code
65
and stops checking authorization controls. - If the transaction does not violate the transaction-count limit, Galileo checks the next control, if it exists.
- If the transaction violates the transaction-count limit, Galileo calculates response code
- If an amount limit exists in the ALC, Galileo applies that limit; if it does not exist, then no amount limit is applied.
- If no ALC exists for the control, Galileo applies the product-level control to the transaction.
- If an amount limit exists at the product level, Galileo applies that limit; if it does not exist, then no amount limit is applied.
- If the transaction violates the amount limit, Galileo calculates response code
61
and stops checking authorization controls. - If the transaction does not violate the amount limit, Galileo goes to the next step.
- If the transaction violates the amount limit, Galileo calculates response code
- If a transaction count limit exists at the product level, then Galileo applies that limit; if it does not exist, then no transaction-count limit is applied.
- If the transaction violates the transaction-count limit, Galileo calculates response code
65
and stops checking authorization controls. - If the transaction does not violate the transaction-count limit, Galileo checks the next control, if it exists.
- If the transaction violates the transaction-count limit, Galileo calculates response code
- If an amount limit exists at the product level, Galileo applies that limit; if it does not exist, then no amount limit is applied.
Updated 6 months ago