This guide explains how to design product-level authorization controls and how to decide which account-level controls (ALCs) to create.

Related documents:

• <a href="doc:about-account-level-auth-controls" target="_blank">**About Account-Level Authorization Controls**</a> — General explanation about ALCs, including use cases.

• <a href="doc:setting-account-level-auth-controls" target="_blank">**Setting Account-Level Authorization Controls**</a> — Instructions for developers to apply ALCs to individual accounts.

• <a href="page:mcc-and-merchant-id-alc-examples" target="_blank">**MCC and Merchant ID ALC Examples**</a> — 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:

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** — 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 <a href="ref:galileo-system-time" target="_blank">Galileo system time</a>

  • **`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 blank means that there is no limit. For example:

Galileo can create your default product-level velocity controls during product setup, or you can set them in the <<glossary:GCC>>. Once these product-level controls are created, you can view them in the GCC and <<glossary:CST>> and retrieve them using the <a href="ref:post_getauthcontrols" target="_blank">Get Auth Controls</a> 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.

• 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.

• "Now" means the time when you create the ALC, in <a href="ref:galileo-system-time" target="_blank">Galileo system time</a>.

• When an account-level control is removed, the account reverts back to the product-level controls.

See <a href="doc:setting-account-level-auth-controls#velocity-controls" target="_blank">Velocity controls</a> 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 <<glossary: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 or `57` 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.

• See [Authorization workflow](🔗) to see more on how MCC controls are applied.

• Also see <a href="page:mcc-and-merchant-id-alc-examples" target="_blank">MCC and Merchant ID ALC Examples</a>.

#### 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.

• Also see <a href="page:mcc-and-merchant-id-alc-examples" target="_blank">MCC and Merchant ID ALC Examples</a>.

### 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.)

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.

• See <a href="page:mcc-and-merchant-id-alc-examples" target="_blank">MCC and Merchant ID ALC Examples</a> for more examples of how MCC ALCs are applied.

• See <a href="doc:setting-account-level-auth-controls#mcc-controls" target="_blank">MCC controls</a> 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 <a href="doc:card-transaction-examples#amazon-transaction" target="_blank">Amazon transaction</a> 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 or `57` for all other networks.

This table shows how MID controls are applied.

• See <a href="page:mcc-and-merchant-id-alc-examples" target="_blank">MCC and Merchant ID ALC Examples</a> 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:

\* <a href="ref:post_gettranshistory" target="_blank">Get Transaction History</a> and <a href="ref:post_getalltranshistory" target="_blank">Get All Transaction History</a> 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 <a href="doc:auth-api-validation-checks" target="_blank">Auth API Validation Checks</a> 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.

<!--alc-flowchart-main.pngg-->

Galileo receives an authorization request from the network.

• If the MCC is on the MCC blocklist, Galileo calculates response code `57` or `03` (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 MCC controls exist, Galileo applies those controls.

  • If the MCC controls DENY, Galileo calculates response code `57` or `03` (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 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 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 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 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 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 you are using the <a href="ref:api-reference-auth-api-about-auth-api" target="_blank">Auth API</a> you can see all of the codes that Galileo calculated for a denial in `response_code_objects` (v3) or `response_code_list` (v2). You can also request that the `response_reasons` field be added to your <a href="ref:webhook_authorization_event_post" target="_blank">Authorization Events</a> messages to get textual explanations of the codes that Galileo calculated for the transaction. For ALC violations, these are the messages:

• `Limit violation. Amount exceeds account level limit`

• `Limit violation. Count exceeds account level limit`

-->