The sophistication of your fraud controls should never be limited by the size of your engineering team. Today, we're excited to announce that two powerful new capabilities, backtesting and Custom Code Rules, are now available in the Lithic Dashboard.

We launched backtesting at the end of last year in a closed beta via API, so are pleased that this transformative feature is now accessible directly in the Dashboard, putting historical rule simulation in front of the risk and operations teams who need it most. Custom Code Rules is an entirely new rule type and one of the most significant expansions of Authorization Intelligence we've shipped. It lets your team write decisioning logic in TypeScript, hosted directly on Lithic’s infrastructure, to express conditions that no dropdown or template could ever accommodate. Together, they represent a meaningful expansion of what card programs can do with our decisioning rules platform and they’re among the first features available within Fraud Command, our new premium fraud tooling tier launching soon.

Backtesting: Validate Rules Before They’re Live

Rule changes carry real risk. A velocity limit that seems conservative on paper may be challenging thousands of legitimate transactions a week or a precisely targeted suspicious merchant block may be catching almost no actual fraud due to backend MCC configurations. Legacy processors offer no safe path here: you’re compelled to deploy a rule and hope for the best, with your cardholders absorbing the consequences. Lithic’s shadow mode has always let you evaluate rules against live traffic without affecting outcomes. But shadow mode still requires time, sometimes weeks, before you have enough signal to act with confidence. Backtesting compresses that cycle dramatically, replaying a rule against months of historical transactions in minutes.

With backtesting now more easily accessible in the Lithic Dashboard, risk teams and account managers can simulate any proposed decisioning rule against your program’s actual historical transaction data before a single live authorization is affected. The results show you exactly how the rule would have performed: how many transactions would have been approved, declined, or flagged and by implication, how much fraud it would have caught and legitimate transactions it would have accidentally blocked.

Why it matters: Risk teams move faster when they can build and validate rules in a compressed feedback loop rather than waiting weeks for shadow mode data to accumulate. Backtesting doesn’t replace shadow mode, but instead accelerates the path to confident deployment. Programs that previously had to make careful, slow rule changes can now iterate with more confidence and less exposure at every step.

Custom Code Rules: Auth Logic Without a Ceiling

Standard rule types (e.g., conditional actions, velocity limits) handle a wide range of fraud patterns well. But sophisticated card programs encounter situations that don’t map cleanly onto any available template. What happens when you need to combine signals in ways a UI can’t express or encode business logic that’s specific to your cardholder population, use case, or risk model and appetite?

Custom Code Rules is the answer to that question. Write decisioning logic directly in TypeScript, and Lithic handles hosting, availability, and performance, so your custom logic runs safely in the authorization hotpath without your team needing to own the infrastructure behind it.

The feature has access to the full authorization context: every data attribute that powers the rest of the rules engine is available to your code. That means you can derive new values, combine signals across transaction, card, account, and merchant dimensions, and implement conditions that would be impractical or impossible to configure through a visual interface. And because Authorization Intelligence spans your entire payment stack, Custom Code isn't limited to card authorizations: the same expressive rule logic applies across 3DS and digital wallet tokenization decisioning as well and allows programs to leverage contextual data from pre-auth events for the authorization.

Here’s a sample of what that looks like in practice:

• New device + recent credential reset. Decline a tokenization request to Apple Pay when the device attempting provisioning has never been seen on the account before and the cardholder has had a password reset in the prior 72 hours. Fraudsters who obtain credentials often move quickly to provision a digital wallet before the account owner notices. Custom code lets programs encode that specific sequence of events as a hard block at the tokenization layer, stopping every downstream transaction before it starts.
• Geo-velocity detection. Flag any transaction where the cardholder’s current merchant location is physically inconsistent with their prior transaction, e.g., a swipe in Dallas appearing 20 minutes after a swipe in London. Standard rule types can catch individual suspicious transactions, but expressing the relationship between two sequential events across time and geography requires the kind of compound logic that only custom code can handle.
• Account lifecycle risk. Apply stricter controls on high-value transactions for accounts under 30 days old that haven’t completed specific verification milestones. New accounts represent a disproportionate share of first-party fraud exposure; custom code lets programs encode their own risk thresholds based on account age, verification status, and spend history, all evaluated together at the moment of authorization.
• Behavioral pattern + merchant category combo. Block transactions at high-risk merchant categories when the account has experienced an unusual spike in transaction volume in the prior 48 hours. Individual velocity limits catch repetitive spend, but combining a volume anomaly signal with a specific MCC context—cryptocurrency exchanges, for example—lets programs target the specific pattern that signals account takeover rather than casting a wider net that would catch legitimate cardholders too.

Why it matters: The programs that have historically run the most sophisticated decisioning logic have needed large engineering teams or custom-built processing infrastructure to do it. Custom Code Rules makes that level of precision available to any Lithic client: your rules can now be as complex as your fraud patterns demand, without requiring an in-house technical team to build or maintain the system that runs them.

If any of the illustrative scenarios outlined above resonate with you, reach out to our team to chat and stay tuned for a deeper technical look at how we built Custom Code Rules coming next week.

Coming Soon: Fraud Command

Backtesting and Custom Code Auth Rules are among the first generally available features of Fraud Command, a new premium tier built for programs that have outgrown standard controls and need more expressive, data-driven decisioning, without taking on infrastructure complexity to get there. The full feature set is coming out of public beta over the coming weeks, and there’s a lot more in store.

Moreover, these features are emblematic of a broader Lithic commitment: that programmable, context-aware authorization decisioning should be accessible to every serious card program, not just those with the deepest engineering resources. That's the core principle of Authorization Intelligence and we’re excited to ship Fraud Command as our first commercial expression.

Ready to explore what’s possible? Contact us or read the documentation.