Overview

Authorization Rules are a flexible, Lithic-hosted solution that gives card programs detailed control over transaction decisioning. By defining rules based on high-signal attributes like MCC, country, currency, and risk score, you can enforce business-specific authorization logic at the program, account, or card level, without managing additional infrastructure.

Rules can be applied at three entity levels:

• Program level: across the entire card program
• Account level: to specific accounts
• Card level: to specific cards

Beyond card authorization, the Auth Rules engine supports multiple event streams, each enabling decisioning for a different payment flow: card authorizations, 3DS authentication, digital wallet and merchant tokenization, and ACH receipts.

Authorization Rules also include tools to test and measure rules before they affect live transactions: shadow mode lets draft rules observe the authorization stream without affecting outcomes, while performance reports and backtesting measure impact over time. For more complex decisioning, Authorization Rules work alongside Lithic's Auth Stream Access (ASA).

Rule Types

Authorization Rules are categorized by the action they take. The primary rule types are:

• Conditional Action (CONDITIONAL_ACTION): take an action when a transaction matches a set of attribute conditions. Available on every event stream. See Conditional Action Rules
• Velocity Limit (VELOCITY_LIMIT): restrict the number or value of transactions over a time period. Available on the AUTHORIZATION event stream. See Velocity Limit Rules
• Custom Code (TYPESCRIPT_CODE): write authorization logic in TypeScript that compiles to WebAssembly and runs in the Rules Engine, for logic that cannot be expressed as a set of conditions. Available on every event stream. See Custom Code Rules

On the AUTHORIZATION event stream, a CONDITIONAL_ACTION rule can also adjust the authorization hold instead of declining or challenging, reserving extra balance to cover expected clearing overages such as tips and fuel. See Hold Adjustment Rules.

📘

Custom Code Rules are part of Lithic Fraud Command.

The following table summarizes which rule types and actions are available on each event stream:

The actions available on a stream depend on the rule type. On the AUTHORIZATION stream, velocity limit rules only DECLINE, while the CHALLENGE action applies to conditional action and custom code rules.

📘

The CHALLENGE action on the AUTHORIZATION event stream (Authorization Challenges) is part of Lithic Fraud Command. See Authorization Challenges.

You may also see rules with the MERCHANT_LOCK type (often Lithic-managed) in rule listings.

Event Streams

Each event stream applies Authorization Rules to a different payment flow:

• AUTHORIZATION: decline, challenge, or adjust the hold on card transactions. Covered by Conditional Action Rules, Velocity Limit Rules, Hold Adjustment Rules, and Custom Code Rules
• THREE_DS_AUTHENTICATION: decline or challenge 3D Secure authentication requests. See 3DS Authentication Rules
• TOKENIZATION: decline tokenization requests or require two-factor authentication (TFA) before a card is added to a digital wallet or stored by a merchant. See Tokenization Rules
• ACH_CREDIT_RECEIPT / ACH_DEBIT_RECEIPT: approve or return incoming ACH payments. See ACH Auth Rules

📘

Tokenization Rules are part of Lithic Fraud Command.

Creating and Managing Rules

Every rule follows the same lifecycle: you draft a rule, which runs in shadow mode; promote the draft to make it active; and disable or delete it when it is no longer needed. You can also list rules, fetch a single rule, and view a rule's version history.

See Authorization Rule Lifecycle for the full create, promote, disable, and delete flow, or Lithic Dashboard - Authorization Rules UI to manage rules through the no-code Dashboard.

Analytics and Observability

Authorization Rules include tools to test and measure rules:

• Shadow mode: draft rules evaluate live transactions and log how they would have affected outcomes, without changing any authorization
• Performance reports: daily statistics on how each version of a rule evaluated transactions, so you can compare an active version against a draft before promoting
• Backtesting: simulate a rule against historical transactions to estimate how it would have performed
• Rule results: per-transaction detail on which rules affected the outcome and why

📘

Backtesting is part of Lithic Fraud Command.

See Analytics and Observability for details.

Limitations and Considerations

• Compliance with card network policies: when using block rules such as MCC or country restrictions, ensure they comply with your cardholder agreement terms. Restrictions beyond what is stated in your agreement may require additional steps to remain compliant with card network policies. Reach out to your Customer Success representative if you need assistance
• Conflict resolution: when multiple rules apply to a transaction at different entity levels (program, account, or card), the most restrictive rule takes precedence. For example, if a program-level rule allows transactions in all countries but a card-level rule restricts transactions to the US, that card's transactions are only allowed in the US
• Rule testing: use shadow mode and performance reports to test rule logic before activation. Poorly defined rules can cause unintended declines, especially when combining multiple conditions
• Velocity limit accuracy: velocity limits are enforced on authorized and settled volume and are eventually consistent, so they are not suitable for balance or reconciliation-level accuracy. See Velocity Limit Rules
• Lithic-managed rules: some rules may be flagged lithic_managed. These are managed by Lithic and cannot be modified or deleted through the API or Dashboard, but they appear in rule listings and rule results
• Rule naming: rules support an optional name parameter (up to 1,024 characters). Descriptive names appear in rule_results on declined transactions, making it easier to identify which rule caused a decline

Authorization Rules FAQ

How do Authorization Rules at different entity levels interact?

When multiple Authorization Rules apply to a transaction at different entity levels (program, account, or card), the most restrictive set of conditions applies. For example, if an account-level rule allows transactions only in the US and Canada, and a card-level rule allows only US transactions, then transactions on that card are restricted to the US.

How do Authorization Rules work if I already have ASA implemented?

Authorization Rules are evaluated before a transaction reaches your Auth Stream Access (ASA) endpoint. If a transaction violates an Authorization Rule, it is declined without sending a request to ASA. The card program is still notified of the attempted transaction via a card_transaction.updated webhook. Authorization Rules act as an initial filter, preventing unnecessary ASA requests for transactions that do not meet your rules.

Can I set different Authorization Rules for specific cards or accounts?

Yes. Authorization Rules can be applied at the program, account, or card level, so you can create specific rules for individual entities while maintaining broader rules at the program level. See Authorization Rule Lifecycle.

How do country restrictions work for e-commerce transactions?

Country restrictions are based on the country in the merchant schema of the transaction object, which reflects the country of the card acceptor. This data is usually accurate for card-present transactions but can be less reliable for e-commerce transactions. For programs with heavy e-commerce use cases, we recommend testing specific merchants before implementing broad country restrictions.

Related Pages

• Conditional Action Rules: take action on transactions that match attribute conditions
• Velocity Limit Rules: restrict transaction count or spend over time
• Hold Adjustment Rules: pad authorization holds to cover expected clearing overages
• 3DS Authentication Rules: decision 3D Secure authentication requests
• Tokenization Rules: decision digital wallet and merchant tokenization
• ACH Auth Rules: approve or return incoming ACH payments
• Custom Code Rules: author rules in TypeScript
• Contextual Rule Features: enrich rules with card and account behavioral history
• Authorization Rule Lifecycle: draft, promote, disable, and delete rules
• Analytics and Observability: shadow mode, performance reports, backtesting, and rule results
• Backtesting Authorization Rules: simulate rules against historical data
• Lithic Dashboard - Authorization Rules UI: manage rules in the Dashboard
• Auth Stream Access (ASA): provide your own decisioning logic
• Merchant Category Codes (MCCs): reference for MCC values

For detailed information about any endpoint, see the Auth Rules API specification. If you have questions, reach out to our support team using the HELP button in your Lithic Dashboard.