Giving Your Team Cards Without Giving Them the Treasury

Employees need practical ways to pay for software, travel, advertising and everyday 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. A team card creates a narrower permission: the employee can purchase from card-accepting merchants within defined boundaries without gaining authority over the underlying treasury.

This separation matters when a company manages USDC, USDT and fiat within the same treasury operation. A cardholder generally does not need to see total balances, add payout beneficiaries, convert assets or approve an on-chain transfer. Those powers should remain with finance users whose roles require them.

How team cards work

A team card is issued to a named employee or other authorised cardholder. It uses company funds but operates through card-specific permissions rather than wallet signing rights. Depending on the provider and programme, finance may be able to configure transaction or recurring limits, merchant category restrictions, card status and other controls.

A typical issuance workflow is:

1. Create the cardholder record. Collect the identity, contact and employment information required by the card programme.
2. Select the card type. Virtual cards are useful for online purchases, while physical cards support in-person spending and normally require delivery and activation.
3. Set the intended use. Record the business purpose, department, cost centre and expected purchase pattern.
4. Configure controls. Apply an appropriate limit and, where supported, merchant category code restrictions.
5. Approve issuance. Route the request to a finance user with sufficient authority rather than allowing requesters to approve their own cards.
6. Monitor and reconcile. Review authorisations, completed transactions, reversals, refunds and declines, then match settled spending to receipts or invoices.

Card availability, fees, funding arrangements and supported controls vary by programme, company jurisdiction and onboarding eligibility. Finance should confirm these details before designing internal procedures around a specific provider.

Separate requests, approvals and card use

A sound permissions model answers three questions: who may request a card, who may approve or issue it, and what the cardholder may do after issuance. Combining all three powers in one role weakens oversight and makes inappropriate changes harder to detect.

A small finance team may need one person to perform more than one operational role. If so, preserve an independent approval for sensitive actions such as issuing a high-limit card or raising a limit. Larger companies can divide authority by legal entity, department, geography or approval threshold.

Limit what cardholders can see and do

Cardholders need enough information to make purchases and resolve payment problems. They do not need unrestricted visibility into the company’s financial position. A focused cardholder view may include:

• Their card details, card status and available spending capacity.
• Their own pending, completed, reversed and declined transactions.
• The limit and relevant restrictions applying to their card.
• Instructions for reporting a lost card, suspected fraud or an incorrect charge.

Treasury-wide balances, other employees’ transactions, fiat account details, wallet addresses and conversion functions can remain restricted to finance. Holding a card should not automatically permit a user to add beneficiaries, initiate global payouts, convert fiat into stablecoins, withdraw USDC or USDT, or sign blockchain transactions.

Do not rely solely on role names such as manager or administrator. Test each role using non-administrator accounts. Confirm what users can view, which actions they can initiate and whether they can approve their own requests.

Why a card is not the same as a wallet key

A wallet signing credential can authorise blockchain activity. Depending on the setup, a signer may be able to transfer tokens, interact with smart contracts or approve token allowances. These capabilities are materially broader than paying a merchant by card.

Signing quorums reduce dependence on one person by requiring the configured number of authorised participants to approve a treasury action. They do not make wallet access appropriate for employees whose job only requires purchasing. Card permissions and treasury signing should therefore remain separate control domains.

This narrower capability also simplifies personnel changes. Finance can freeze one card without changing the treasury signing quorum used by the rest of the company.

Controls to set before issuing cards

Start with the expected use case instead of giving every employee the same configuration. A media buyer, frequent traveller and engineering manager have different purchase patterns. Document the purpose first, then choose controls that support it.

• Set a justified limit. Base it on expected transaction size and frequency. Review limits periodically rather than making them permanently high to avoid approval work.
• Use merchant controls carefully. Merchant category codes classify businesses, but a merchant may be classified unexpectedly by its payment provider. Maintain an exception process for legitimate declines.
• Define limit-change approval. State who can request an increase, who approves it and whether temporary increases automatically expire.
• Plan for card-not-present risk. Establish how employees should store card details, report suspicious activity and respond when credentials may be compromised.
• Create an offboarding trigger. Freeze or cancel cards promptly when someone leaves, changes role or no longer has a business need.
• Reconcile settled transactions. Match charges to receipts, invoices, cost centres and accounting periods. Investigate unfamiliar merchant descriptors rather than assuming they identify the legal supplier.

Limits and MCC rules reduce risk, but they do not replace reconciliation. A permitted transaction can still be incorrect, duplicated or unsupported by business evidence. Conversely, a legitimate transaction can be declined because of the card status, available limit, merchant classification, acceptance rules or other card-network checks.

Understand authorisation, settlement and refunds

Finance teams should distinguish a card authorisation from a settled expense. An authorisation reserves spending capacity when the merchant requests approval. The final settled amount may differ, particularly where tips, deposits, foreign exchange or incremental charges are involved. A reversal releases an authorisation, while a refund is a separate credit initiated after a transaction has settled.

This distinction affects both available spending capacity and accounting. Reconciliation procedures should identify pending authorisations, final charges, reversals and refunds separately. Employees should submit the commercial evidence for the settled purchase, not treat the initial authorisation as the final accounting record.

Finance should also verify whether cards draw directly from a shared balance, require prefunding or use another funding arrangement. A card limit controls what the cardholder can attempt to spend; it does not necessarily mean that the same amount has been ring-fenced in a separate account.

Build an audit-ready operating process

For each card, retain the request, business purpose, approver, configured limit, subsequent changes, transaction evidence and closure record. The evidence should allow a reviewer to reconstruct who requested an action, who approved it, what changed and when it took effect.

Stablerail supports corporate cards alongside approvals and signing quorum, sanctions and address screening before stablecoin sends, global payouts, fiat conversion and exportable audit evidence. Keeping card activity and treasury records within a connected operational process can reduce gaps between purchasing, treasury movement and period-end review.

Pre-launch checklist

1. Map who can request, approve, issue, modify, freeze and cancel cards.
2. Confirm card funding mechanics, fees, jurisdictional availability and programme limits.
3. Define standard controls for each employee use case.
4. Test every role with a non-administrator account.
5. Document limit increases, decline handling, lost-card reporting and exceptions.
6. Connect card reconciliation to receipts, invoices, cost centres and the general ledger.
7. Add card cancellation to HR offboarding and role-change procedures.

The objective is not to prevent employees from spending. It is to give them the smallest practical payment capability for their work. Team cards provide that capability while leaving stablecoin transfers, fiat conversion, beneficiary management and treasury approvals with the finance team.