Designing Authorization Controls
This guide summarizes how to design product-level and account-level authorization controls. See the sections below for links to the individual control types.
When you set up a product, you define default authorization controls for the product. These controls are configured in cooperation with your bank, according to your use case. In addition, you can create authorization controls that apply to individual accounts. You should also consult with your bank to make sure that your account-level controls (ALCs) don't violate a limit that the bank sets.
You can set up three kinds of ALCs:
Velocity
Velocity controls involve these characteristics:
- Period — The amount of time the control takes into consideration, such as one day, one week, or one transaction
- Transaction type — Whether the transaction is initiated at an ATM, a point of sale, is a cash advance, or is cash back
- Domestic or international — Whether the transaction originates from a country that is foreign relative to the card account
- PIN or signature — Whether the transaction was authenticated with a PIN
- MCCs — The MCC of the merchant
- Amount — The amount of the limit
- Transaction count — The number of transactions allowed per period
Note
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.
- For instructions on designing these controls, see Velocity Control Design.
- For instructions on setting these controls, see Set Velocity Controls.
MCC
MCC controls either allow or deny MCC ranges. When you design these controls at both the product and account levels, you will need to pay close attention to overlapping ranges, which are not permitted.
Note
An account-level MCC control is applied in addition to product-level MCC controls, not instead of, so the allow or deny property must be consistent.
- For instructions on designing these controls, see MCC Control Design.
- For instructions on setting these controls, see Set MCC Controls.
Merchant ID
Merchant ID (MID) controls affect the merchant ID value that is passed in DE043 of the authorization request. This value is unique to a point of sale or merchant. You can use account-level MID controls to deny or allow specific merchant IDs that are excluded by MCC controls.
Note
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 product-level MID controls.
- For instructions on designing these controls, see Merchant ID Control Design.
- For instructions on setting these controls, see Set Merchant ID Controls.
Authorization workflow
This workflow shows the order of operations for authorization controls when Galileo receives an authorization request.
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 with MCC
- 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 an applicable control ID, 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 ID, 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 applicable velocity control ID, 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.
Workflow with velocity MCC ALCs
When a control ID has velocity ALCs with MCC ranges, the workflow changes slightly.
- If one of the ALCs has an MCC range that matches the transaction's MCC, that ALC's limits are applied. No other ALCs with that control ID will be applied.
- If none of the ALCs specify an MCC range that matches the transaction's MCC, Galileo checks for an ALC without an MCC range.
- If it exists, that control is applied.
- If it does not exist, the product-level control is applied instead.
- If none of the ALCs specify an MCC range that matches the transaction's MCC, Galileo checks for an ALC without an MCC range.
Events API
When an authorization request is denied because of an authorization-control violation, the response_reasons
field in the DAUT: denied_auth
event message indicates whether the violation was at the account level or the product level.
Violation type | response_code | response_reasons |
---|---|---|
MCC blocklist Product-level MCC | 57 or 03 (Mastercard) | deny_allow: a : mcc not allowed by productdeny_allow: d : mcc is blocked by product |
Account-level MCC | 57 or 03 (Mastercard) | deny_allow: a : mcc not allowed by account deny_allow: d : mcc is blocked by account |
Product-level MID | 57 | Acquiring merchant blocked by product |
Account-level MID | 57 | Account blocks the given merchant ID |
Product-level transaction amount | 61 | Limit violation. Amount exceeds product limit |
Account-level transaction amount | 61 | Limit violation. Amount exceeds account level limit |
Product-level transaction count | 65 | Limit violation. Amount exceeds product limit |
Account-level transaction count | 65 | Limit violation. Amount exceeds account level limit |
Updated 6 months ago