Tokenization: The Engine Behind Commercial and Virtual Cards
This post is the second in our Tokenization series. You can read the first post here.
For most of payments history, the commercial card space was the one that nobody paid enough attention to. Consumer solutions got the investment, the design thinking, the innovation cycles. B2B sat there as the untouched part of the industry, running on older rails and accepting complexity as the price of doing business.
That's changed. Over the last decade, we’ve seen an entire wave of B2B fintechs, expense management platforms, corporate card programs, and payment infrastructure companies built specifically to modernize commercial payments. And if you look at what's actually enabling that wave, at the architectural layer underneath all of it, you find tokenization.
This isn't a coincidence.
Why virtual cards can't exist without tokenization
Virtual cards are, at their core, a tokenization product. The ability to generate a card credential on demand, tied to a specific merchant, department, employee, time window, or spend limit, is only possible because tokenization provides that control layer.
Before tokenization matured as a standard, the only way to manage commercial spend was to issue physical cards, share actual card numbers across systems and suppliers, and then try to manage the reconciliation mess that created. You had one credential serving many purposes. You had card numbers sitting in supplier portals, OTA booking systems, and employee expense tools with no real-time controls attached.
When a card was compromised in that environment, you didn't just have a fraud problem. You had a rebuild-everything problem. Think about what happens when you cancel a personal card that you've saved to ten different merchant websites. Now multiply that by an entire corporate card program with hundreds of employees and dozens of supplier relationships.
Tokenization solved this by decoupling the credential from the control. Each virtual card is essentially a token with rules attached to it. Those rules define where it can be used, how much can be spent, and for how long. Compromise that token, and you've compromised nothing of value. The actual card data stays protected.
Programmability: the part that changes everything
What makes commercial tokenization genuinely powerful is programmability. This is where the B2B use case goes from interesting to transformative.
Consider a practical scenario. An employee is traveling to meet a client. They need a card for the trip. With a properly implemented token infrastructure, that card can be provisioned in one step, added to their digital wallet instantly, capped at a specific spend limit, restricted to travel-relevant merchant categories, and set to expire at the end of the trip. All of this happens without the employee needing to fill out an expense form in advance or carry a shared corporate card.
That's not a workflow. That's a product. And it's entirely built on token controls.
The same logic applies to supplier payments. Instead of sharing an actual card number with a supplier, you can generate a single-use token tied to a specific invoice, for a specific amount, valid for a specific window. The supplier gets paid. The token expires. Your real credentials never leave your system.
Fraud patterns unique to b2b that tokenization addresses
Commercial card programs attract a specific set of fraud patterns that consumer cards don't face in the same way. Tokenization addresses each of them directly.
The first is out-of-channel use. When you issue a token restricted to a specific set of merchant category codes, any transaction outside those codes is immediately flagged. If a corporate travel card is suddenly used at a retailer that doesn't match travel merchants, the system knows that doesn't belong.
The second is time-based misuse. Tokens can be time-bound. If a token is issued for an invoice due on a specific date range, and transactions start appearing outside that window, that's a signal. It doesn't require a fraud analyst to catch it. The architecture catches it.
The third is velocity abuse. Shared card numbers are inherently vulnerable to incremental charges that fly under the radar of standard monitoring. Token-level spend controls eliminate this vector entirely. There's a cap, and it's enforced at the transaction level.
How tokens should map to your ledger architecture
This is where the infrastructure story gets more sophisticated, and it's where many commercial programs underinvest. In a well-designed system, tokens don't just float independently. They map to your ledger hierarchy. A department token draws from a department sub-account. An employee token draws from that department's allocation. The funding source is clear, the reconciliation trail is clean, and the reporting is real-time.
Banks and fintechs that are building the next generation of B2B products are increasingly asking for this. They don't just want tokenization. They want the full end-to-end: the token, the controls, the sub-ledger it draws from, and the data enrichment that flows through the transaction, including Level 2 and Level 3 data that feeds into their ERP or spend management platform automatically.
That last piece is more important than it sounds. One of the biggest friction points in commercial payments has always been reconciliation. An employee travels, the card is charged, and then someone has to manually match the charge to a trip record, an invoice, and a budget line. With tokenization plus real-time ledger integration and data enrichment from the schemes, that process becomes largely automatic. The transaction carries its own context.
And as AI-driven financial operations become more common, that clean, structured data becomes the input that makes it all work.
Token lifecycle in B2B: more critical, more neglected
If lifecycle discipline is important in consumer tokenization, it's essential in commercial tokenization. In a B2B environment, the credentials attached to real-world relationships are constantly changing. Employees join and leave. Supplier relationships start and end. Departments restructure. Budget cycles reset. Every one of these events needs to be reflected in your token infrastructure.
If an employee leaves and their token isn't deactivated, you've left an active credential in the wild. If a supplier relationship ends but their token still works, you have an open door to your funds. These aren't edge cases. They're regular business operations, and they happen constantly.
The solution isn't manual token management. It's building token lifecycle into your onboarding and offboarding workflows from the start. When a user is deprovisioned, their tokens are deactivated. When a new supplier is onboarded, a fresh token with appropriate controls is issued. The lifecycle runs alongside the business process, not independently of it.
This is what separates the commercial programs that scale cleanly from the ones that accumulate risk over time.
Is tokenization foundational for scalable B2B programs?
B2B programs rely on tokenization for scalability. But I'd go further than that. Tokenization isn't just foundational. It's the decision point that determines how far your commercial program can go. You can build a basic corporate card program without deep tokenization. But you can't build a programmable, real-time, controls-driven, fully reconciled commercial card infrastructure without it.
The companies that are winning in this space—the platforms that banks are eyeing because they want to launch the next Ramp or the next Brex—are winning because they invested in the token infrastructure early. They built the controls. They built lifecycle management. They built the ledger mapping. And now they can move fast on features because the foundation supports it.
The platforms that treated tokenization as a checkbox are rebuilding. Or they're asking us for help.
About the author
Sireesha Krishnama is Director of Solutions Architecture, APAC at Episode Six. She has specialized in payment tokenization since 2014 and works with banks, fintechs, and program managers across the Asia-Pacific region.
About Episode Six
Episode Six is The World’s Local Processor™. Episode Six is a global provider of enterprise-grade card issuing and ledger infrastructure for financial technology companies, banks, and brands. Episode Six delivers the innovative capabilities needed to compete with disruptors and lead the market. Flexibility, adaptability, and resilience are built into the core of Episode Six's platform, ensuring clients maintain a market-leading position. Episode Six operates in over 50 countries, powering millions of accounts and billions in payments globally, with an expanding team located in the US, Canada, UK, Europe, Japan, Singapore, Hong Kong, Australia, and India. Investors include HSBC, Mastercard, SBI Investment Co Ltd, Anthos Capital, Avenir, and Japan Airlines.