User Adjustable Parameters

What User Adjustable Parameters are

User Adjustable Parameters let you define a rule once, with default values, and then override those values for individual cards without duplicating the rule.

In the legacy Rules Engine, User Adjustable Values existed, but they were difficult to configure and maintain. In Decision Engine, this capability has been redesigned as a typed, API-driven framework that is easier to manage, easier to scale, and better suited to card-level customisation.

The key idea is simple:

the rule logic stays shared
the values used by that logic can vary per card

This means a single rule can support broad portfolio consistency while still allowing per-cardholder controls.

Why it is useful

Without User Adjustable Parameters, card-level variations usually require one of two bad options:

duplicate the same rule many times with different hard-coded values
avoid card-level personalisation altogether

User Adjustable Parameters remove that trade-off.

They allow you to:

define a rule once at client, product, or group level
give that rule sensible defaults
override only the values that need to be different for a specific card
update those values through API calls without rebuilding the rule

This makes customisation safer, faster, and easier to govern.

The most important benefit

The strongest way to think about User Adjustable Parameters is not as a niche feature for spend limits, but as a way to externalise rule inputs.

In practice, this means that many of the values you would otherwise hard-code into a rule can instead become card-level parameters, including:

thresholds
amounts
time windows
country codes
MCC lists
transaction type lists
day-of-week lists
other enum-driven allow or deny lists

So rather than creating a different rule for each cardholder preference, you keep one rule and vary the parameter value.

What can be adjusted

Decision Engine supports five parameter families:

TEXT
DECIMAL
TIME_SPAN
MONEY
ENUM

Each can be defined as either:

SCALAR(Single Value)
LIST

This gives you a wide range of customisation patterns, for example:

a single amount threshold
a list of blocked or allowed MCCs
a configurable lookback period
a per-card daily or weekly limit
a list of allowed transaction types
a list of allowed transaction days

How it works

When you declare a parameter in a rule, you give it:

a name
a type
a default value
optional constraints such as minimum and maximum values

The rule then references that parameter instead of using a hard-coded value.

At runtime:

if no card-specific value exists, the rule uses the default
if a card-specific value has been set, the rule uses the override for that card

Card-level values can be set, listed, and removed through the User Adjustable Parameter APIs.

Setup flow

1. Define the parameter in the rule

Create or edit your Decision Engine rule and declare a parameter for the value you want to make configurable.

Examples:

a spend limit
a list of allowed MCCs
a list of allowed days of the week

2. Set the default value

In PayControl, define the default value that should apply when a card does not have its own override.

You can also define:

scalar or list mode
min and max constraints where applicable
currency for money values
time span type for time-based parameters
enumeration type for enum parameters

3. Reference the parameter in the predicate

Use the parameter in the rule expression instead of a hard-coded literal.

In the rule builder, user adjustable value is available as a value source where the operator and field type are compatible.

4. Override the value for a specific card

Use the card-level User Adjustable Parameter APIs to set a value for an individual card.

This is what enables real per-card behaviour.

If you want the cardholder to control the setting, the usual pattern is:

expose the preference in your own app or servicing channel
translate the customer’s choice into a card-level parameter update via API

Examples

Example 1: card-specific amount limit

Use case:

one shared high-spend rule
different cardholders need different thresholds

Pattern:

define a default amount limit in the rule
override that amount for specific cards

Result:

the rule logic stays shared
only the threshold changes by card

Example 2: MCC controls chosen by the cardholder

Use case:

a cardholder wants to control which merchant categories are allowed

Pattern:

define a TEXT list parameter for allowed or blocked MCCs
reference that list in the rule
update the list per card through API

Example outcome:

Card A allows 5411, 5912, and 7995
Card B allows a different MCC list
both cards use the same rule

This is a strong example of why User Adjustable Parameters matter: the policy stays shared, but the allowed merchant categories can vary per cardholder without cloning the rule.

Example 3: allowed transaction days chosen by the cardholder

Use case:

a cardholder wants their card to work only on selected days

Pattern:

define an ENUM list parameter using DayOfWeek
use that parameter with the isDayOfWeek(...) style rule logic
set the allowed days per card

Example outcome:

Card A is allowed only on Monday to Friday
Card B is allowed only on Saturday and Sunday
both cards still use the same underlying rule

This enables customer-controlled scheduling without duplicating rules by card or by programme.

Example 4: transaction type controls

Use case:

a cardholder wants to allow some transaction types and decline others

Pattern:

define an ENUM list parameter for allowed transaction types
reference that parameter in the rule
update the list per card

Example outcome:

one card allows purchases and refunds
another card allows only refunds

Why this is better than duplicating rules

User Adjustable Parameters give you:

less rule duplication
easier maintenance
faster rollout of personalised controls
lower risk of inconsistent rule logic across cards
real-time card-level updates without redesigning the rule

This is especially valuable when the rule logic is stable but the acceptable values vary by customer.

Summary

User Adjustable Parameters turn hard-coded rule inputs into managed, typed, card-level configuration.

They allow you to keep rules centralised while still supporting highly personalised behaviour. In practice, that means many of the values a rule evaluates against can be made configurable per cardholder, including thresholds, lists, time windows, MCC controls, and allowed days, without duplicating the rule itself.

How are user Adjustable Values Overriden?

We provide API's to set and manage the User Adjustable Values.

List User Adjustable params for a card List User Adjustable params for a rule Remove User Adjustable value for a card Remove All User Adjustable values for a card Set User Adjustable values for a card