Giving Your Team Cards Without Giving Them the Treasury

Employees need a practical way to pay for software, travel, advertising and day-to-day operating costs. Giving each person access to a company wallet may solve the payment problem, but it also gives them capabilities they do not need.

Team cards offer a narrower form of spend delegation. A cardholder can pay approved merchants within defined limits, while the finance team retains control of the underlying treasury balance. They do not need a wallet key, permission to initiate an on-chain transfer or visibility into every company account.

With Stablerail, companies can issue virtual or physical corporate cards funded from their treasury balance. Finance teams can set limits and merchant category code controls, assign operational roles, and review card activity alongside fiat and stablecoin treasury operations. Card availability, supported funding arrangements and fees depend on the company’s jurisdiction and onboarding eligibility.

How team cards work

A team card is issued to a named employee or another authorised cardholder. It draws from company funds but operates within a separate set of card permissions.

A typical issuance process is:

• Create the cardholder: Add the person’s required identity and contact details.
• Select the card type: A virtual card can be used for online purchases, while a physical card is intended for in-person spending and may require delivery and activation.
• Set limits: Define the maximum permitted spend per transaction or over a recurring period, depending on the available configuration.
• Apply merchant controls: Allow or restrict purchases using merchant category codes, commonly called MCCs. Card networks use these codes to classify businesses such as airlines, restaurants or advertising services.
• Approve issuance: Route the request to an authorised finance user before the card becomes available.
• Monitor transactions: Review authorisations, completed payments, reversals and declined transactions from the treasury workflow.

The cardholder receives a payment instrument, not general control over the treasury. This distinction matters when company funds also include USDC, USDT, fiat balances or assets held in self-custodial vaults.

Role-based issuance separates requests from approvals

Effective roles and permissions answer three separate questions: who may request a card, who may approve it, and what the cardholder can do after issuance.

For example, a department manager might request a card for a new employee, but only a finance manager can approve it. The employee can then use the card within its limits without being able to issue another card, increase a limit or transfer treasury funds.

The exact role design should match the size of the finance team. A smaller company may combine card administration and approval, while a larger organisation may separate them by entity, department or spending threshold.

What a cardholder can and cannot see

Cardholders need enough information to use their cards and resolve payment issues. They do not necessarily need access to the company’s broader financial position.

A cardholder’s view can be limited to information relevant to their card, such as:

• Available card details and current card status.
• Their own pending and completed transactions.
• The applicable spending limit.
• Instructions for a declined payment or card freeze.

Access to treasury-wide balances, other employees’ transactions, fiat account details, virtual IBANs and on-chain wallet addresses can remain restricted to finance roles. Most importantly, holding a card does not need to grant authority to convert fiat into stablecoins, withdraw USDC or USDT, add payout beneficiaries or sign an on-chain transaction.

Finance teams should verify the precise visibility available to each role before rollout. A short test using non-administrator accounts is more reliable than assuming that an internal job title automatically maps to the intended permissions.

Why this is different from handing out wallet keys

A wallet signing credential is designed to authorise blockchain transactions. Depending on the wallet configuration, a signer may be able to transfer assets, interact with smart contracts or approve token allowances. Those actions are materially broader than paying a merchant by card.

Stablerail uses self-custodial MPC vaults with quorum signing. MPC, or multi-party computation, distributes the signing process so that a complete private key is not held in one place. Quorum signing requires the configured number of authorised participants to approve an action. These protections are appropriate for treasury transfers, but they do not make every employee a suitable wallet signer.

Wallet permissions should therefore remain with people who genuinely need to manage on-chain assets. Cards are a better fit for employees whose job requires purchasing rather than treasury movement.

Controls to set before issuing cards

Start with the expected use case rather than issuing every card with the same settings. A media buyer, frequent traveller and engineering manager have different spending patterns.

• Choose the right limit: Base it on expected purchases and review it periodically. Avoid setting a high limit solely to reduce approval work.
• Use MCC controls: Restrict categories that are unrelated to the cardholder’s role. Remember that merchants can sometimes be misclassified by their payment provider.
• Define limit-change approval: Decide who can request a temporary increase and who must approve it.
• Set an offboarding process: Freeze or cancel cards promptly when a person changes roles or leaves the company.
• Reconcile regularly: Match transactions to receipts, invoices or expense records and investigate unfamiliar merchant names.
• Review declined payments: A decline may result from the limit, an MCC restriction, card status, merchant acceptance or other card-network checks.

Card activity should also form part of the company’s audit evidence. Stablerail provides an audit log and evidence workflows that finance teams can use alongside approvals and transaction records.

A practical model for spend delegation

A useful starting model is to keep treasury movement and employee purchasing as separate permission domains. Treasury signers control transfers from self-custodial vaults. Card administrators manage card issuance and settings. Finance approvers authorise requests or material limit changes. Cardholders spend only within the resulting boundaries.

This gives employees a familiar payment method while avoiding unnecessary wallet access. It also lets finance change or revoke one person’s purchasing ability without restructuring the company’s treasury signing quorum.

Before launch, document who can request, approve, issue, modify, freeze and cancel each card. Then test those permissions with representative users and confirm the applicable card fees, limits, funding mechanics and jurisdictional availability during onboarding.

For more information about virtual and physical cards funded from company treasury balances, see crypto corporate cards.