LimitRail - configuration operating manual

This manual explains how to turn product requirements into LimitRail configuration. It is written for people who configure products, operations, policy inputs, pricing rules, limit rules, conditions, customer thresholds, segments and exceptions.

The guiding principle is simple: the calling system sends facts, LimitRail makes the policy decision. Every rule must answer a clear business question: which operation is governed, which data is needed, which limit or price applies, when the rule must trigger and how the result will be explained.

1. Correct configuration flow

Use this order.

1. Create or verify the product in Products.
2. Create operation codes in Operation catalog.
3. Create missing inputs in Policy inputs.
4. Create the plan in Condition plans.
5. Configure pricing and limits in Rule editor.
6. Add conditions only when a rule does not always apply.
7. Publish the version when the draft is coherent.
8. Link accounts, segments or account deals to the published version.
9. Verify behavior in Scenario validation.

Do not start from rules before operation codes and policy inputs are clear. Even a clean rule becomes hard to manage if the data driving it was not defined well.

2. Operation code: the operational contract

An operation is the code sent by the calling system at runtime. If the core sends ATM_WITHDRAWAL, LimitRail must configure ATM_WITHDRAWAL. No mapping layer is needed.

When creating an operation, clarify:

• whether it is debit, credit or neutral;
• whether it requires an amount;
• whether it requires pricing coverage;
• whether it requires limit coverage;
• which channel/family it uses for grouping rules or counters.

Use distinct operation codes when the product wants distinct rules. Use the same channel when multiple operations must share a limit. Example: SEPA_OUT and SEPA_INSTANT_OUT may have different pricing but share a SEPA_OUTGOING channel limit.

3. Policy inputs

A policy input is not any descriptive field. It must be able to change at least one of these things:

• which rule applies;
• which threshold is used;
• which counter is consumed;
• what is explained in audit or reports.

Three sources matter.

Do not ask the caller to send precomputed decisions such as high_amount, discounted_fee, domestic_fee or limit_exceeded. Those are policy outcomes, not business facts.

4. Pricing: choose the right pattern

Supported V1 pricing methods are:

BUNDLE, MINIMUM and MAXIMUM are not supported pricing methods. Minimum and maximum are fields applied to a calculated fee, not standalone methods.

4.1 Explicit free operation

Use WAIVER when the business meaning is: this operation is included in the product and must appear as zero fee.

Example: free card purchase.

Configuration:

• rule type: pricing;
• operation scope: operation code;
• operation code: CARD_PURCHASE;
• calculation method: WAIVER;
• pricing group: usually BASE;
• priority: consistent with the other rules for the operation.

Runtime effect: LimitRail returns a zero fee. This is different from having no pricing rule: WAIVER makes the inclusion explicit.

4.2 Fixed fee

Use FIXED when every operation produces the same fee amount.

Example: instant SEPA transfer at EUR 0.80.

Configuration:

• calculation method: FIXED;
• fixed amount: 0.80;
• currency: EUR;
• fee base: OPERATION_AMOUNT or FIXED, depending on the available setting;
• operation code: SEPA_INSTANT_OUT.

Runtime effect: if the rule matches, LimitRail returns that fee.

4.3 Percentage fee with minimum and maximum

Use PERCENTAGE when the fee depends on operation amount.

Example: international transfer at 0.35%, minimum EUR 1.50, maximum EUR 12.00.

Configuration:

• calculation method: PERCENTAGE;
• percentage rate: 0.0035;
• min amount: 1.50;
• max amount: 12.00;
• currency: EUR;
• operation code: INTERNATIONAL_TRANSFER.

Runtime effect: LimitRail calculates the percentage on amount, then applies minimum and maximum.

4.4 First N operations included, then fee

Use TIERED with metric COUNT.

Example: first 6 ATM withdrawals per month included, then EUR 0.90.

Configuration:

• calculation method: TIERED;
• metric type: COUNT;
• period type: MONTHLY;
• tier application mode: SINGLE_MATCHED_TIER;
• tier charge base: OPERATION_AMOUNT;
• tier 1: upTo = 6, calculation WAIVER;
• tier 2: upTo = empty, calculation FIXED, amount 0.90;
• operation code: ATM_WITHDRAWAL.

Runtime effect: LimitRail looks at confirmed consumption and active reservations. If the request is inside the included quota, it returns zero fee; after the quota, it returns the configured fee.

4.5 Included volume, then fee

Use TIERED with metric AMOUNT when the threshold depends on volume.

Example: first EUR 1,000 monthly volume included for an operation family, then a fixed fee per operation.

Configuration:

• calculation method: TIERED;
• metric type: AMOUNT;
• period type: MONTHLY;
• tier 1: upTo = 1000, calculation WAIVER;
• tier 2: upTo = empty, configured FIXED fee.

Note: in V1 this does not automatically calculate a fee only on the excess portion. It decides which tier applies to the new operation.

4.6 Fee above amount threshold

When the fee changes based on the single operation amount, use conditions on amount.

Example: P2P free up to EUR 75, then EUR 0.40.

Configuration:

• rule 1: WAIVER, condition amount <= 75;
• rule 2: FIXED 0.40, condition amount > 75;
• same operation code: P2P_PAYMENT.

Runtime effect: the caller only sends amount; LimitRail chooses the rule.

5. Pricing composition: when multiple rules match

If multiple pricing rules match the same request, decide whether to sum them or select one.

Use PricingGroupCode to group rules and PricingGroupMode to choose the selection behavior.

StopAfterGroup is used when, after a fee was selected in one group, later groups must not add more fees.

Premium promotion example:

• group SEPA_PRICE;
• standard rule: FIXED 0.60;
• premium rule: WAIVER with condition customer_tier = PREMIUM;
• group mode: BEST_PRICE.

If the customer is premium, the engine sees 0.00 and 0.60 and selects 0.00.

6. Limits: choose metric, period and scope

A limit rule controls capacity or thresholds.

6.1 Single-operation limit

Example: transfer maximum EUR 1,250.

Configuration:

• metric type: AMOUNT;
• period type: SINGLE;
• limit amount: 1250;
• operation scope: OPERATION_CODE;
• operation code: SEPA_OUT;
• blocking: true.

No historical counter is needed: the rule compares the request amount.

6.2 Period limit per operation

Example: maximum EUR 450 ATM per day.

Configuration:

• metric type: AMOUNT;
• period type: DAILY;
• limit amount: 450;
• operation scope: OPERATION_CODE;
• counter scope: ACCOUNT_OPERATION;
• operation code: ATM_WITHDRAWAL;
• blocking: true.

Each commit consumes the daily counter for that account and operation.

6.3 Operation-count limit

Example: maximum 4 ATM withdrawals per day.

Configuration:

• metric type: COUNT;
• period type: DAILY;
• limit count: 4;
• counter scope: ACCOUNT_OPERATION.

The engine counts operations, not their amount.

6.4 Shared channel limit

Example: SEPA_OUT and SEPA_INSTANT_OUT share the daily transfer channel limit.

Configuration:

• operation scope: OPERATION_CHANNEL;
• channel code: SEPA_OUTGOING;
• counter scope: ACCOUNT_CHANNEL;
• metric type and period based on the threshold.

This avoids two separate allowances when the business wants one allowance.

6.5 Account-global limit

Example: maximum EUR 10,000 monthly total across all governed operations.

Configuration:

• operation scope: GLOBAL;
• counter scope: ACCOUNT_GLOBAL;
• metric type: AMOUNT;
• period type: MONTHLY.

Use it for total account exposure, not for one operation.

6.6 Dimension-split limit

Example: maximum EUR 5,000 per month by destination country.

Configuration:

• create dimension destination_country;
• enable the dimension to split counters;
• counter scope: CUSTOM_DIMENSIONS;
• add destination_country as scope dimension;
• metric type: AMOUNT;
• period type: MONTHLY.

Use this only for controlled, low-cardinality values. Country, currency or profile are suitable. Transaction id, merchant id or free text descriptions are not.

7. Conditions: when a rule must trigger

A rule without conditions always applies inside its scope. Add conditions only when the rule applies in a specific case.

Examples:

• amount > 75 to apply an above-threshold fee;
• destination_country != ITA for international fee;
• customer_tier = PREMIUM for premium waiver;
• regulatory_status IN [UNDER_REVIEW, RESTRICTED] for risk block;
• average_monthly_balance < 200 for maintenance fee.

Supported operators:

8. Customer-selected thresholds

A customer threshold makes the product stricter for one account. It is not an exception and cannot exceed the standard limit.

Example: the product allows EUR 450 ATM per day, but the customer chooses EUR 200.

Configuration on the limit rule:

• enable "customer can choose this limit";
• set customer minimum;
• set customer maximum;
• save the rule and publish the version.

Operations:

• channel or integrator reads configurable limits for the account;
• it sets the customer-selected threshold;
• runtime uses CUSTOMER_SETTING before the product default.

9. Segments, account deals and policy exceptions

Use segment when an account category needs a different policy: RETAIL, PREMIUM, BUSINESS.

Use account deal when one account has negotiated or exceptional conditions. An account deal is an account-level policy assignment and wins over segment and product.

Use policy exception when you need to allow or trace a temporary controlled bypass of a blocking rule without changing the standard policy.

10. Scenario validation

Timeline validation checks behavior and counters over time. Do not only test one single call.

For each important policy, verify:

• first operation inside threshold;
• operation that consumes the last available capacity;
• operation that exceeds the threshold;
• case with customer threshold;
• case with missing metadata;
• case with exception;
• case after period change, for example next day or next month.

The policy is ready when each step can be explained:

• which rule decided;
• which fee was calculated;
• which counter was consumed;
• why a request was blocked or allowed.

11. Do not configure these in V1

Do not use these as supported patterns:

• pricing method BUNDLE;
• pricing method MINIMUM or MAXIMUM;
• automatic fee only at commit;
• automatic fee on technical reverse;
• excess-only fee with REMAINING_AMOUNT;
• counters split by high-cardinality data;
• operation mapping between external and internal code.

Correct alternatives:

• use TIERED for included quotas;
• use MinAmount and MaxAmount fields for fee floors/caps;
• use a dedicated operation, for example TRANSFER_RETURN, for return fees;
• use coherent operation codes and channels for operation variants;
• use conditions and pricing groups for promotions.

12. Final checklist before publication

Before publishing a version, check:

• all required product operations exist;
• operations requiring coverage have at least one pricing or limit rule;
• data required by conditions is registered and active;
• counter limits have correct period and scope;
• tiered fees have at least two tiers and an open final tier;
• customer thresholds have coherent min/max values;
• pricing groups are not accidentally summing fees;
• timeline validation covers positive and negative cases;
• the calling system is not required to send precomputed decisions.