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
• MCC
• Merchant ID

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

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.

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.