Advanced spend controls

Overview and key benefits

Have full control over where your cards can be used, in what way, how much, and when.
Provide your customers with bespoke card products that cater to specific needs where controlling card use is a central part of the offering.

Our solution is fully managed, meaning: you only need to define the rules and which cards they apply to. We will take care of the rest. You can rely on our excellent uptime, and high performance ensuring fast responses to merchants and managing peak times.

Sophisticated spend controls can differentiate you in the market, support your customer´s values, improve the sense of safety, and prevent misuse.

The authorisation control messages include all relevant transaction data:

• Create truly bespoke and fit-for-purpose card propositions and improve customer loyalty with a product they can´t get from your competition.
• Help clarify, empower, and enforce spending policies, ensuring money is used for intended purposes only
• Protect cardholders with restrictions for safety and security, preventing intended or unintended misuse and fraud

Solution

Enfuce advanced spend controls allow you to define authorisation rules, i.e. which authorisations should be approved and which should be declined. Choose the rule parameters that are relevant for you and create both card-specific rules as well as rules that apply to a group of cards.

The solution enables you to:

• independently define and apply spend controls
• apply the defined controls in real-time
• with the help of the card groups, apply controls for 1 card as effortlessly as for thousands of cards
• define rules without in-depth knowledge of card scheme authorisation content and logic
• easily manage the controls (add, update, remove, view)

Rules

Rules determine which authorisations are approved and which are declined. The rules can be single parameter rules: “if X then decline” or a combination of multiple rules: “if X and Y then decline”. You can also choose if the rules allow when the transaction meets the criteria: “if X then allow” or define the rules so that they decline when predefined criteria are met: “if Y then decline”.

Rule parameters

The rule parameters are defined based on the available data in the authorisation message. The content of the authorisation message in turn is defined by the card schemes. This means that the data received from the merchant defines e.g. what country the transaction is from or if the transaction is contactless or not. The majority of merchants comply with the rules and recommendations, but there can be unexpected values in marginal cases. For example, there might be room for interpretation as to what merchant category is used.

Rule types

Merchant category code (ALLOWED_MCC, BLOCKED_MCC): Merchants are categorised into hundreds of categories. Some global merchants (airlines, hotel chains, car rentals) have their own code while others, like clothing stores, are grouped under a common code. Card schemes maintain the merchant category code lists.

Rules based on merchant category code are an easy way to limit usage to certain types of merchants. Use case examples:

• Lunch cards where usage is limited to restaurants
  • Applicable MCCs: 5812 – Eating places and restaurants, 5814 Fast food restaurants
• Mobility cards where usage is limited to public transport
  • Applicable MCCs: 4111 Local passenger transportation, 4112 – Passenger railways, 4131 – Bus lines
• Fuel and EV cards
  • Applicable MCCs: 5541 Service stations, 5542 – Automated fuel dispensers, 5552 – EV charging

Merchants (ALLOWED_MERCHANT, BLOCKED_MERCHANT): There are cases where merchant categories are too wide and there is a need to limit usage to predefined merchants or there might be a requirement to block predefined merchants. As there are tens of millions of merchants in the world, there is no directory of all of them, which means you would need to gather or request the identifiers from the merchants you wish to include in your rules. Enfuce uses a combination of merchant id and acquirer id to ensure uniqueness on a global scale. Use case examples:

• Gift cards where usage is limited to a predefined store
• Limited network cards where usage is limited to a predefined retail chain
• Single-use cards for ecom purchases where usage is limited to a predefined merchant

Merchant country (ALLOWED_COUNTRIES, BLOCKED_COUNTRIES): Rules defined based on merchant country allow you to define where in the world the card can be used or where it can´t be used. It should be noted that Enfuce fraud services also enforce country restrictions to sanctioned countries. These rules can´t be overridden with spend controls. Use case examples:

• Expense cards that are intended to only be used in one country. E.g. a card issued to a maintenance worker who only needs to use it in domestic stores can be limited to only work in one country.
• Limit usage in countries that are considered high-risk or are sanctioned.

Transaction amount (AMOUNT): You can define that single purchases can´t be bigger than a defined amount. Use case examples:

• Cards for kids/youth that are intended to be used for buying snacks or other smaller purchases.
• Enforce expense policies that require separate approval for purchases beyond a predefined amount.

Apply multiple rules

By applying multiple rules to a card, you can combine different parameters and create even more granular rules. Expanding on the use cases already mentioned, the use case could be:

• Lunch card where usage is limited to restaurants in a predefined country
• Mobility cards where usage is limited to public transport and a maximum of 10£/purchase
• Expense cards that are intended only to be used in one country and where the employer enforces their expense policy that requires separate approval for purchases beyond a predefined amount.

If there are multiple rules applied to a card, you can define if all rules should pass or if it is enough that any of them passes. This functionality is beneficial in cases where you e.g. want to limit usage to predefined merchants for certain types of purchases but want to allow purchases from all merchants in an MCC. So, for example, a cardholder could make fuel purchases only at a predefined retail chain (merchant-based rule) but can use the card at all parking lots (MCC-based rule).

Linking rules to cards and groups of cards

As the authorisation is processed, we need to determine which rules should apply to it. You might have rules that apply to all of your cards, rules that apply to a group of cards and rules that only apply to a single card. To enable this, you can create card groups and hierarchies.

The card hierarchy is a tree structure where you can define different levels and link different rules to different levels. A rule linked to a higher level will apply to all linked cards at the lower levels. Card hierarchies allow you to easily manage rules that apply to multiple cards. You can create new rules and update existing rules with a single API call and it will apply to an entire group of cards.

In this example, the hierarchy has three levels, and rules are linked to each of them. A rule linked to a higher hierarchy level will apply to all cards linked to sub-levels:

• For the red card, rules X, Z (from customer group level) and rule Q (from sub group level) apply
• For the purple card, rule Y (from customer group level) applies