​​Our previous post introduced Lithic Authorization Intelligence as a framework for thinking about modern payment decisioning: a programmable governance layer that incorporates context, permissions, and continuous risk signals into every authorization decision, rather than relying on rudimentary rules that can’t distinguish a legitimate high-value purchase from a fraudulent one with similar surface characteristics.

Here, we’ll go one click deeper and explore the Lithic platform components that comprise our approach in practice. Authorization Intelligence derives its value from the breadth of the payment stack it touches: the same decisioning engine to determine approvals, declines, or challenges supports multiple event streams, with context flowing freely between them. What follows is a look at how each of those works in practice, what data you can actually build rules against, and how Lithic's platform is designed to let programs iterate on authorization logic without the risk of introducing new failure modes in the process.

How It Works Across Your Stack

The beauty of Lithic’s Authorization Intelligence approach lies in the cross-platform versatility and unified governance across payment types of our core decisioning engine. This programmable rule layer enables clients to set context-aware decisioning across every stage of the payment lifecycle (from identity verification to transaction authorization) and multiple payment form factors (card, ACH, or wallet token). 

Each touchpoint in the cardholder payment experience represents a distinct opportunity to intercept fraud—and of course, the earlier we catch it, the better. Stopping a fraudulent digital wallet token provisioning eliminates every transaction that would have followed. Catching a suspicious card-not-present session with 3DS prevents a liability-shifted dispute before a card authorization ever occurs. In the event that a fraudster gets past tokenization 2FA or a 3DS challenge, Lithic’s card authorization decisioning provides the most robust line of defense with comprehensive risk signals and expressive rule logic. For programs that also move money over ACH, the same Authorization Intelligence extends to that rail as well, so fraud logic doesn't have to be rebuilt from scratch for a different payment type.

Wallet Tokenization: Lithic programs gain an unprecedented level of flexibility with the ability to apply custom decisioning logic to digital wallet tokenizations, approving in real-time cardholder attempts to a card to Apple Pay or Google Pay. Programs can either leverage Lithic’s decisioning framework or build and apply their own custom decisioning logic (similar to how Lithic’s Authorization Stream Access (ASA) works for card transactions). Rather than accepting wallet recommendations blindly, clients can evaluate tokenization requests against their own fraud models and user authentication data, then respond to approve, decline, or require additional authentication within milliseconds. This matters because fraud on digital wallet cards is generally non-disputable, meaning stopping fraudulent tokenizations at the decisioning layer prevents unrecoverable losses that static approval processes could miss.

3D Secure: When merchants trigger a 3DS check on an ecommerce transaction, Lithic’s integrated 3DS solution delivers forensic-level intelligence of over 150 data points, across device, cardholder, and merchant categories, to clients for them to either approve, decline, or challenge that authentication request. More importantly, although authentication and authorization are separate decision points, Lithic’s Authorization Intelligence evaluates 3DS authentication data within the same transaction context, eliminating the latency and data fragmentation that occurs when authorization decisioning and 3DS checks run through separate systems like with legacy providers. The intelligence gathered during 3DS authentication becomes most valuable when it also informs the final authorization decision.

Card Authorizations: When a transaction enters Lithic's authorization platform, our dynamic rules engine evaluates far more than basic fraud signals like MCC codes or velocity thresholds. The system can assess transaction type, how the transaction was initiated, historic card and account behaviors, liability shift factors, risk scores, and more, simultaneously, then executes conditional logic based on how these factors interact. Through ASA, clients can inject real-time account-level signals from their own data attributes such as recent password changes, suspicious login attempts, proprietary risk scores directly into their authorization decision. This means decisioning adapts to what's happening with that specific account at that specific moment, not what a static rule anticipated six months ago.

ACH Transactions: Authorization Intelligence extends beyond card rails into ACH, applying the same contextual decisioning framework whether money moves through card networks or ACH rails. Clients can build unified fraud logic that evaluates contextual attributes consistently across payment types, rather than managing separate decisioning platforms for cards and ACH. This matters particularly for programs that blend both rails—buy now pay later, disbursements, bill pay—where fragmenting fraud controls across different systems creates gaps that sophisticated fraud exploits.

Iteration Without Risk

One of the most common failure modes in authorization is a rule change that backfires. Too restrictive and you decline valid transactions; too permissive and fraud slips through before you catch it. Legacy processors fail to offer solutions to this dilemma. Not only can it sometimes take weeks to even push through a rule change to production, but then you’re forced to wait to see how these changes play out in your program before amending or removing rules.

We built Lithic's decisioning platform with testability as a core requirement. Rules are created in a shadow-mode draft state and must be explicitly promoted before they affect live transactions, which gives teams time to review performance before anything touches a real authorization. In shadow mode, rules evaluate against live traffic without influencing the outcome, so you can measure its real-world impact before bringing your ruleset live. And backtesting lets you replay a rule against months of historical transactions, compressing what would otherwise be months of shadow observation into a much shorter feedback cycle. Lithic’s decisioning platform also supports native A/B testing, so you can thoroughly vet the performance of any tweaks to your rules safely. 

Every rule evaluation is logged, with both machine-readable decline codes and human-readable explanations so when a transaction is declined, you know exactly which rule triggered and why. That transparency matters for troubleshooting, for cardholder support, and for the compliance and audit trail that financial services programs require.

For teams who prefer a UI to the API, all of this is available in the Lithic Dashboard's Authorization Rules interface.

Define Rules Your Way

Authorization Intelligence’s strength lies in its ability to set complex, sophisticated rules quickly and easily, especially when the diverse array of clients leveraging Lithic’s decisioning platform means that the teams defining fraud logic don’t all look the same. At Lithic, we build from a developer-first mindset but with the goal of being easily manageable and usable for technical and non-technical users alike. That’s why a core component of our imminent roadmap is to expand how clients can express Authorization Rules to match how they actually work.

For technical teams, an exciting feature coming next month will let clients write authorization logic in TypeScript, hosted directly on Lithic's infrastructure. Custom Code Auth Rules removes the ceiling on rule complexity: combine signals, derive values, and express conditions that no generic template could reasonably accommodate—all with Lithic handling the availability and performance guarantees that make custom logic safe to run in the authorization hotpath.

For less technical users, a natural language rule writing assistant lets clients define rules in plain English, with an LLM translating intent into code and deploying it in shadow mode for review before it goes live. A risk analyst who wants to say “flag any liability-shifted card-not-present transaction over $500 from a foreign country where the address doesn't match” can do exactly that, without writing a line of code.

No other processor offers this level of customization and intent expressibility. Together, they mean that the sophistication of your authorization logic is no longer constrained by who on your team can implement it.

Go Deeper

The Authorization Intelligence overview covers the broader case for programmable authorization. If you're ready to start building, the Auth Rules API reference, ACH Auth Rules documentation, and 3DS decisioning docs are good starting points. Or talk to our team about how Authorization Intelligence can unlock your program’s fraud prevention strategy.