--- title: Authorization controls slug: concepts/cards/issuing-models/integrated-issuing/issuer-processor/authorization-controls description: Learn how a real-time card authorization control system uses ALLOW and DENY rules to restrict transactions by MCC, merchant, country, and currency. docTags: createdAt: 2026-03-12T13:29:40.426Z --- # What authorization controls do ## Overview Authorization controls let you establish rules for card transaction validation. You check merchant category, currency, merchant ID, and country in real-time during: - **3DS Authentication:** Controls are evaluated during 3D Secure authentication flows - **Authorization Requests (0100):** Controls are evaluated for authorization messages - **Financial Authorization Requests (0200):** Controls are evaluated for financial transaction requests :::hint{type="info"} **Important:** Authorization controls apply only to 3DS authentication and authorization messages (0100, 0200). Clearing messages (0220) **are not restricted** by these controls. ::: The system automatically declines transactions that violate any configured authorization control rule. ## Control hierarchy The system evaluates two control levels before approving any transaction. Both levels must approve for a transaction to succeed: ### 1. Account level Individual account restrictions. Apply these controls to all cards associated with a specific account. ### 2. Card level Most granular level of control. Per-card controls provide the highest level of customization for individual cards. **Evaluation Order:** Account → Card **Approval Requirement:** Both levels must approve for transaction to succeed. ## API endpoints For a full description of the APIs used to configure `authorizationControls` refer to the following API endpoints: [PUT /v1/cards/\{cardId}/controls](docId\:r_Cxcl0l2UoyWkuuJpaJ1) [GET /v1/cards/\{cardId}/controls](docId\:AT16WGXZGoV5cqFuFNPTP) ## Action types Two action types define control behavior, ALLOW and DENY. | Action Type | Description | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ALLOW (whitelist) | - **Evaluation:** Value must be in the list - **Result if match:** Continue to next control - **Result if no match:** Decline transaction - **Empty list:** Declines all transactions | | DENY (blacklist) | * **Evaluation:** Value must **not** be in the list * **Result if match:** Decline transaction * **Result if no match:** Continue to next control * **Empty list:** Allows all transactions | | No controls configured | - **Behavior:** No restrictions applied at this level - **Result:** Continue to next hierarchy level | ### ALLOW (whitelist) Permits **only** the values listed in the control. The system declines any transaction with a value outside the list. **Use Case:** Restrict card to specific merchants or categories only. **Example:** Allow only fuel purchases :::BlockQuote \{ "type": "mcc", "action": "ALLOW", "list": \["5172", "5541", "5542", "5552"] } ::: ### DENY (blacklist) Blocks **only** the values listed in the control. All other values are permitted. **Use Case:** Block specific merchants, countries, or categories while allowing everything else. **Example:** Block gambling merchants :::BlockQuote \{ "type": "mcc", "action": "DENY", "list": \["7995", "7800", "7801"] } ::: ## Control types ### 1. MCC (Merchant Category Code) Restricts transactions based on merchant category codes. **Field name:** mcc **Value format:** 4-digit merchant category code (string) **Common use cases:** - Restrict to fuel purchases only - Block gambling transactions - Limit to specific business categories **Example:** Fuel purchase restriction: :::BlockQuote \{ "type": "mcc", "action": "ALLOW", "list": \[ "5172", // Petroleum Products "5541", // Service Stations "5542", // Automated Fuel Dispensers "5552" // Electric Vehicle Charging ] } ::: **Common MCC codes:** | Code | Category | | ---- | --------------------------------------------------- | | 5172 | Petroleum Products | | 5541 | Service Stations (with/without ancillary services) | | 5542 | Automated Fuel Dispensers | | 5552 | Electric Vehicle Charging | | 5812 | Restaurants | | 5411 | Grocery Stores | | 7995 | Betting/Casino Gambling | Full list: ::File{src="https://api.archbee.com/api/presign/4hvUOg5mU1sCngl0n0Has/a-zXn_JJNkVcbSJIHWllF_mcclisting.xlsx" label="MCCListing.xlsx"} ### 2. MID (Merchant ID) Targets specific merchant locations using card acceptor IDs. **Field name:** mid **Value format:** Merchant identifier string **Common use cases:** - Allow transactions at specific store locations only - Block specific problematic merchants - Restrict to corporate-approved vendor locations **Example: **Specific merchant allowlist: :::BlockQuote \{ "type": "mid", "action": "ALLOW", "list": \[ "MERCHANT\_12345", "MERCHANT\_67890" ] } ::: **Example: **Block specific merchant: :::BlockQuote \{ "type": "mid", "action": "DENY", "list": \["MERCHANT\_99999"] } ::: ### 3. Country Restricts transactions based on merchant country location using ISO 3166-1 alpha-2 country codes. **Field name:** country **Value format:** 2-character ISO country code (string) **Common use cases:** - Restrict to domestic transactions only - Block transactions from high-risk countries - Limit to specific geographic regions **Example: **US only: :::BlockQuote \{ "type": "country", "action": "ALLOW", "list": \["US"] } ::: **Example: **Block specific countries: :::BlockQuote \{ "type": "country", "action": "DENY", "list": \["XX", "YY", "ZZ"] } ::: Common country codes: | Code | Country | | ---- | -------------- | | US | United States | | ES | Spain | | GB | United Kingdom | | CA | Canada | | MX | Mexico | | FR | France | | DE | Germany | Country and currency codes: ::File{src="https://api.archbee.com/api/presign/4hvUOg5mU1sCngl0n0Has/RJUT9tPYhVEFid7dUD87-_countryandcurrencycodes.xlsx" label="CountryandCurrencyCodes.xlsx"} ### 4. Currency Limits transaction currencies using ISO 4217 currency codes. **Field name:** currency **Value format:** 3-character ISO currency code (string) **Common use cases:** - Restrict to home currency only - Block foreign currency transactions - Limit multi-currency exposure **Example: **USD only: :::BlockQuote \{ "type": "currency", "action": "ALLOW", "list": \["USD"] } ::: **Example:** Block specific currencies: :::BlockQuote \{ "type": "currency", "action": "DENY", "list": \["EUR", "GBP"] } ::: Common currency codes: | Code | Currency | | ---- | ------------------- | | USD | US Dollar | | EUR | Euro | | GBP | Great Britain Pound | | CAD | Canadian Dollar | | MXN | Mexican Pesa | | JPY | Japanese Yen | Country and currency codes: ::File{src="https://api.archbee.com/api/presign/4hvUOg5mU1sCngl0n0Has/RJUT9tPYhVEFid7dUD87-_countryandcurrencycodes.xlsx" label="CountryandCurrencyCodes.xlsx"} ## Transaction evaluation flow ### For authorization messages (0100, 0200) and 3DS authentication ```mermaid --- config: layout: elk --- flowchart TD A[Transaction Received
0100/0200/3DS] --> B[Account Level Controls] B --> C{Pass} C -->|Yes| D[Card Level Controls] D --> E{Pass} E -->|Yes| F[Transaction Approved] E -->|No| G[Transaction Declined] C -->|No| G classDef start stroke:#38bdf8,fill:#f0f9ff classDef process stroke:#a78bfa,fill:#f5f3ff classDef decision stroke:#fb923c,fill:#fff7ed classDef approved stroke:#4ade80,fill:#f0fdf4 classDef declined stroke:#f87171,fill:#fef2f2 class A start class B,D process class C,E decision class F approved class G declined ``` :::BlockQuote Transaction Received (0100/0200/3DS) ↓ Account Level Controls ↓ (Pass) Card Level Controls ↓ (Pass) Transaction Approved ::: **Decline at any level:** If any level declines the transaction, evaluation stops immediately and the transaction is declined. ### For clearing messages (0220) ```mermaid --- config: layout: elk --- flowchart TD A["Clearing Transaction Received (0220)"] --> B["Authorization Controls SKIPPED"] B --> C["Transaction Processed"] classDef processNode stroke:#818cf8,fill:#eef2ff classDef warningNode stroke:#fb923c,fill:#fff7ed classDef resultNode stroke:#4ade80,fill:#f0fdf4 class A processNode class B warningNode class C resultNode ``` :::BlockQuote Clearing Transaction Received (0220) ↓ Authorization Controls SKIPPED ↓ Transaction Processed ::: **Note:** Clearing messages (0220) bypass authorization controls and are processed without restriction checks. ## Use cases **Fleet card: **Fuel only Restrict card to fuel purchases at service stations: :::BlockQuote \{ "authorizationControls": \[ \{ "type": "mcc", "action": "ALLOW", "list": \["5172", "5541", "5542", "5552"] } ] } ::: **Corporate card: **Domestic only Restrict to US merchants using USD: :::BlockQuote \{ "authorizationControls": \[ \{ "type": "country", "action": "ALLOW", "list": \["US"] }, \{ "type": "currency", "action": "ALLOW", "list": \["USD"] } ] } ::: **Travel card: **Block gambling Allow all transactions except gambling: :::BlockQuote \{ "authorizationControls": \[ \{ "type": "mcc", "action": "DENY", "list": \["7995", "7800", "7801", "7802"] } ] } ::: **Vendor-specific card** Restrict to specific approved merchants: :::BlockQuote \{ "authorizationControls": \[ \{ "type": "mid", "action": "ALLOW", "list": \["VENDOR\_A\_001", "VENDOR\_B\_002", "VENDOR\_C\_003"] } ] } ::: ## Best practices 1\. **Use appropriate action type** - Use **ALLOW** for restrictive use cases (few permitted values) - Use **DENY** for permissive use cases (few blocked values) 2\. **Combine controls strategically** - Layer multiple control types for complete restrictions - Example: Country + Currency + MCC for fleet cards 3\. **Hierarchy considerations** - Set broad restrictions at Account level - Set specific restrictions at Card level - Avoid conflicting controls across hierarchy levels 4\. **Testing** - Test all control combinations before production deployment - Verify both approval and decline scenarios - Test edge cases (empty lists, special characters) 5\. **Updates without reissuance** - Update controls dynamically - Respond quickly to fraud patterns or policy changes - No need to reissue physical cards ## Limitations & constraints **Control scope** - **Applies to:** - Authorization requests (0100) - Financial authorization requests (0200) - 3DS authentication - **Does NOT apply to:** - Clearing messages (0220) - Authorization controls restrict only the authorization phase, not the clearing/settlement phase **Control limits** - Maximum controls per card: Check with Cross River P1 - Maximum list items per control: Check with Cross River P1 **Update frequency** - Controls can be updated in real-time - Changes take effect immediately for new authorization requests **Data validation** - Country codes must be valid ISO 3166-1 alpha-2 codes - Currency codes must be valid ISO 4217 codes - MCC codes must be 4-digit strings - MID format depends on merchant identifier standards