01Why one card for everything stops working
Past about 12 cards or $30,000/month in spend, a single multi-purpose card becomes a liability. The limit logic stops fitting. The audit trail gets noisy. The dispute workflow loses context.
Single-card architectures also miss fraud signals. If one card is doing ads, subscriptions, and travel, a fraud event on travel looks like a normal spend pattern. Splitting cards lets you see fraud by category - if the travel card has 5 fraud attempts and the ads card has 0, the pattern is obvious.
The card-per-category architecture also enables better budgeting. Your finance team can see exact spend by category without parsing transaction descriptions. Each card is a budget line.
02Architecture 1: Cards by department
The most common architecture. One card pool per department: ads, content, engineering, sales, ops, travel. Each department has 1-3 cards, each with limits sized to the department's budget.
Pros: clean budgeting, clean permissions, clean handover when a department lead leaves. Cons: within a department, you lose card-level isolation - if the marketing team has 3 cards, all 3 cards share the same risk surface.
Best for: teams of 5-50 with stable department structure.
03Architecture 2: Cards by ad account
The architecture for teams running serious ad spend. One card per ad account: Google Ads - Brand campaign, Meta Ads - Q3, TikTok Ads - Retargeting. Each card is dedicated to one billing relationship with one ad platform account.
Pros: complete isolation of ad-account spend, simple dispute routing, easy to verify each platform's actual cost. Cons: more cards to manage (a team running 20 ad accounts has 20 cards), more potential for human error.
Best for: media buyers, agencies, e-commerce operators running multiple ad accounts.
04Architecture 3: Cards by vendor type
Group cards by what they buy, not by who buys it. Card pool: SaaS (Notion, Linear, Slack, Figma), cloud (AWS, GCP, Cloudflare), AI tools (OpenAI, Anthropic, Midjourney), advertising, travel, marketplace.
Pros: clear spend reporting by category, easy to compare category budgets quarter-over-quarter. Cons: requires tight naming conventions, does not isolate ad-account billing well.
Best for: operators who need category-level reporting more than per-account isolation.
05Architecture 4: Cards by risk profile
Group cards by risk tolerance, not by purpose. Low-risk cards (long-time trusted vendors), medium-risk cards (newer vendors, smaller budgets), high-risk cards (vendor trials, marketplaces, anything with high chargeback rates).
Pros: fraud containment by design - a fraud event on a high-risk card cannot touch the low-risk cards. Cons: you need clear rules for which vendors go in which bucket, and you need to revisit them quarterly.
Best for: teams with a mix of trusted and untrusted vendor relationships, anyone who has been burned by a marketplace vendor.
06Architecture 5: Cards by time horizon
Cards that live 7 days, cards that live 30 days, cards that live forever. The time-horizon architecture uses expiry as a primary control. Trial vendor cards have 30-day expiry. Operational cards are perpetual. Ad-account cards expire every quarter for compliance reasons.
Pros: a card that expires is impossible to misuse after its window. Expiry becomes a calendar-driven audit. Cons: more card creation events, need to monitor expiring cards and replace them.
Best for: organizations with strong compliance or audit requirements.
07Combining architectures
Most operators run a hybrid. Cards by ad account for advertising. Cards by vendor type for SaaS. Cards by risk profile for marketplace vendors. The dominant pattern is: the architecture that matches the highest-spend, highest-risk category takes priority.
If your highest-risk spend is ad accounts, run cards-by-ad-account. If your highest-risk spend is marketplace vendors, run cards-by-risk-profile. The lower-spend categories can use simpler architectures.
The right test: which architecture, if removed, would expose you to the worst possible failure mode. Use that as your primary architecture.
08The minimum-card-rule
A common anti-pattern is creating cards as a planning ritual. Every new vendor, every new subscription, every new project gets its own card. Within six months you have 60 cards, half of them frozen, and you cannot remember why most of them exist.
The minimum-card rule: a card exists only if it isolates a real risk or a real budget. If a vendor can sit on an existing card without risk or budget issues, do not create a new card. The fewer cards, the simpler the program.
Aim for a card count that grows linearly with budget, not with vendor count. A $100K/month budget should have 8-15 cards. A $1M/month budget should have 30-60. Anything more is fragmentation.
09Naming conventions across architectures
Whatever architecture you pick, the naming convention determines whether it works in practice. Use three parts: purpose, scope, and budget.
Examples: ADS-META-Q3 (purpose: ads, scope: Meta, budget: Q3), SAAS-NOTION-TEAM (purpose: SaaS, scope: Notion, scope: team license), RISK-HIGH-MARKETPLACE-TRIAL (purpose: high-risk, scope: marketplace trial vendor).
Audit-friendly names are short, structured, and searchable. They should fit a 30-character card label without truncation. They should encode the architecture into the name itself - anyone reading the name knows the architecture.
