Card limits, MCC blocks and approvals: a spend control setup that works

An effective card spend control setup combines role-based card profiles, layered spending limits, targeted merchant category code blocks, proportionate approvals and a short expense policy. No single control is sufficient: limits cap exposure but do not establish whether a purchase is appropriate, while MCC blocks can restrict merchant types but cannot identify the specific item purchased.

The goal is to let routine, budgeted spending proceed without creating a finance ticket for every transaction, while making large, unusual or prohibited purchases visible before they become committed costs. The figures below are illustrative rather than platform limits and should be adjusted for the company’s budget, currencies and risk tolerance.

Start with the card funding and settlement flow

Before setting card limits, document where authorised transactions draw funds from and how they affect available liquidity. This is particularly important when the company treasury holds USDC or USDT but employees spend in fiat currencies.

Finance should confirm:

• Which treasury or fiat balance supports card authorisations.
• Which transaction and settlement currencies are supported.
• How currency conversion is calculated, including any applicable spread or fee.
• When an authorisation reduces the available balance and when the transaction is finally posted.
• How tips, incremental authorisations, offline transactions, refunds and reversals appear.
• What happens when the funding balance is insufficient.

A card limit is not the same as available treasury liquidity. A cardholder may have a €5,000 monthly limit but still receive a decline because the funding balance is insufficient, the merchant category is blocked or the purchase exceeds another limit. Stablerail provides corporate cards within a business account for USDC and USDT treasury, but finance should still document the exact funding, conversion and settlement workflow applicable to its account.

Create a small number of cardholder profiles

Companies with 10–100 cardholders rarely need a unique control model for every employee. Start with three to five profiles based on spending responsibility, then grant exceptions for defined purchases. This is easier to administer and review than maintaining individually designed controls.

Assign each cardholder to the lowest profile that supports normal activity. Avoid granting a high permanent limit because someone might occasionally need it. A documented temporary increase is safer and creates a clearer record of why additional capacity was provided.

Layer limits to contain different risks

A monthly limit alone does not prevent one large transaction or a burst of spending before finance can respond. Use multiple limit types where available:

• Per-transaction limit: caps the value of a single authorisation.
• Daily limit: contains rapid or repeated spending over a short period.
• Monthly limit: aligns card capacity with the budget and review cycle.
• Cash withdrawal limit: set to zero unless cash is operationally necessary.
• Temporary limit: supports an approved purchase or travel period without permanently increasing exposure.

For example, an employee with a €2,000 monthly allowance might have a €750 daily limit and a €500 per-transaction limit. A planned €900 purchase would require an approved temporary increase or a different payment route.

Allow room for merchant behaviour when setting limits. Hotels and car rental providers may place deposits or increase an authorisation after the initial amount. Restaurants may add tips at settlement. A control set exactly equal to the expected invoice can therefore cause legitimate declines. Finance should understand these patterns without creating excessive headroom.

Use MCC blocking for broad category risk

A merchant category code, or MCC, is a four-digit classification associated with a merchant by its acquiring bank or payment processor. Card controls can use it to allow or decline transactions based on the merchant’s primary business type.

Categories commonly blocked unless there is a documented need include:

• Cash withdrawals and cash-equivalent transactions.
• Gambling and betting.
• Money transfer services.
• Jewellery and other high-value personal goods.
• Personal entertainment categories unrelated to company activity.
• Cryptocurrency purchase services when treasury transactions must follow an approved company workflow.

MCC controls are useful but imprecise. A hotel may charge rooms, meals and event costs under one hotel code. A marketplace may use a broad retail classification regardless of the underlying item. Merchant classifications can also be incorrect or change when a merchant changes processor.

Use MCC rules to block clearly unsuitable merchant types, not to reproduce every sentence of the expense policy.

Review legitimate declines closely during rollout. If a rule repeatedly blocks expected activity, narrow or remove it rather than teaching employees to work around the card programme.

Separate network authorisation from business approval

Card authorisation and business approval are different events. The card network evaluates available funds, card status and configured controls during an authorisation request. A manager or finance reviewer decides whether the purchase is necessary, budgeted and compliant with policy.

Unless the card workflow explicitly connects approval to card availability, a manager approval record does not itself stop a card transaction. Finance should therefore combine pre-purchase approval with limits that prevent materially larger purchases.

These thresholds are examples. Set them with reference to average purchase size, department budgets, fraud tolerance and segregation-of-duties requirements. Apply additional scrutiny to new vendors, unusual categories, annual commitments and automatically renewing contracts.

For recurring software, approve the contract or annual budget once and use a dedicated virtual card with a limit close to the expected charge. This provides cleaner vendor-level visibility and makes it easier to stop one subscription without replacing a card used by several suppliers.

Write an expense policy employees can use

A practical expense policy should answer the cardholder’s questions at the point of purchase. It should state:

• Permitted expenses and explicitly prohibited uses.
• Pre-approval thresholds and authorised approvers.
• Receipt and business-purpose requirements.
• The deadline for submitting evidence, such as five working days.
• Rules for travel, tips, alcohol, software and recurring subscriptions.
• How to request a temporary limit increase.
• What to do if a card is lost, compromised or declined.
• How personal spending and repeated missing evidence are handled.

Require cardholders to acknowledge the policy before activation. Keep receipts, business purposes, approval records and limit changes linked to the transaction history. Exportable audit evidence is especially useful when controllers need to support account reconciliations, audit sampling or management review.

Create an exception process that preserves control

A slow exception process encourages personal-card use and other workarounds. A request should identify the cardholder, amount, merchant, purpose, required date and approving budget owner. Temporary increases should have an expiry time and return the card to its normal profile after the purchase window.

For example, finance could raise a per-transaction cap from €500 to €1,200 for 24 hours rather than permanently expanding the cardholder’s authority. If the purchase changes materially, require a new approval instead of repeatedly extending the exception.

Decline investigation checklist

1. Confirm the available funding or treasury balance.
2. Check the card’s status, activation and expiry date.
3. Compare the amount with transaction, daily and monthly limits.
4. Check MCC, geographic and transaction-type restrictions.
5. Review the merchant and card network response where available.
6. Confirm whether a deposit, tip or prior authorisation increased the amount.
7. Avoid repeated retries until the cause is understood.

Pilot, reconcile and review the setup

Start with five to ten cardholders representing different roles. Run the pilot for two to four weeks, examine every decline and confirm that approvals and receipts can be matched to posted transactions. Then roll out the standard profiles to the wider team.

Finance should review the programme monthly for unused cards, repeated declines, missing evidence, limit utilisation, blocked categories, expiring cards and recurring charges. Cancel cards for leavers immediately. Move important subscriptions from employee-dependent cards to company-controlled virtual cards so access survives role changes.

Controls should also fit the wider treasury process. Where card spend, stablecoin transfers, global payouts and fiat off-ramp activity share one operating environment, use distinct permissions and approval paths for each payment type. Stablerail supports approvals and signing quorum, sanctions and address screening before stablecoin sends, corporate cards, payouts and exportable evidence; card controls should remain proportionate to the narrower risks of employee purchasing.

A successful setup does not eliminate every exception. It establishes normal card capacity, blocks clearly unsuitable activity, records who approved larger commitments and gives finance a reliable way to investigate and evidence what happened.