Is 2022 Finally the Year of the Virtual Card?

Virtual cards are one of the hottest topics these days. Card networks, banks, fintechs and industry analysts talk about virtual cards virtually every day, all day. They monitor virtual cards adoption, expecting usage and associated revenue growth. Virtual cards are believed to be a fantastic product for businesses of all sizes. Yet, despite all the excitement and accolades, the adoption rate is underwhelming. Why is that?

Virtual cards and why they can be great

A virtual card is a card where it's you, the user, not the card-issuing organization, who controls how much can be spent, where and how, and you, the user, have the power to create and destroy these cards whenever you want. You are the master of cards. On the surface, virtual cards act like regular cards, but behind the scenes are really digital wallets.

To answer why virtual cards can be great, we need to take a closer look at the product itself. When asked to explain virtual cards, banks, fintechs and card networks would do it in a rather straightforward but not very helpful way:

• One famous neobank explains that a virtual card is a payment card that only exists in a digital form, which is not exactly true but, more importantly, not very helpful — and we will see later why.

• One hot unicorn-fintech also resorted to recursion and tautology to explain virtual cards, stating that they are exactly what they sound like: cards without the plastic. Scandalous!

• A famous paleobank (what is the antonym for "neobank"?) explains virtual cards as virtual card numbers. Which makes you question if you missed something or are looking at a wrong answer? Don't cards and numbers mean different things?

From the end-user perspective, nothing is obvious, everywhere is fine print, but specifically, why use one over another and when? Defining a new product as exactly the same as an old product but having one unimportant thing different is not helpful. I personally use credit cards to buy stuff on the internet and through POS terminals, and I don't even remember when was the last time I held that credit card in my hands — I use Apple Pay on my phone and Google Pay in the browser. My card exists in those two virtual places at the same time — does this make it virtual? Of course, not... or does it? Do I need a virtual card?

This is where virtual cards proponents cannot rely on System 1 thinking and tautological definitions, and promptly respond with a list of value propositions, unique features and possible use cases. Suddenly, this clarifies a lot of things and makes previously given definitions ostensibly wrong.

Plastic Virtual Cards

Virtual cards are virtual not because there is no plastic or other physical material involved but because the cards act as avatars to the funding source account that remains securely incognito behind this avatar. So you can create these avatars and even print them as physical cards and hand them out to real people. Or better yet, send them as special files for their 3D printers, so they can print their plastic virtual cards by themselves. I love this feature also because it reminds me of a funny dialogue between Peppa Pig and Suzy Sheep that I watched with my daughter:

• And my boots are very special because they are made of Gold!

• They're not gold, they're yellow!

• They are not yellow! They are real plastic gold!

Low-resolution-avatars.jpg

To avoid confusion (or, accidentally, create more of it) I will keep using the term "avatar" from time to time because this is what it means on the internet: “a static or moving image or other graphic representation that acts as a proxy for a person or is associated with a specific digital account or identity, as on the internet.”

I find this to be a very accurate description of virtual cards that is not fixated on the medium (digital, physical, plastic, or even real plastic gold). It also implies that an avatar has a very limited scope compared to the actual account. In the world of virtual cards, this is manifested through a variety of things:

• Limited spending: The available amount is less than the limit on the funding source.

• Limited usage: It can be swiped only once and only for a specific merchant.

• Limited lifespan: Can be a tiny fraction of the actual physical card. They can be revoked and cancelled faster than a person can be cancelled on Twitter.

While Internet avatars make it less risky for grown-ups with careers to post silly memes and troll each other on forums, card avatars make it less risky to use card products for payments, so card product convenience doesn't come at the expense of security anymore.

Virtual cards don't have to be credit cards

I deliberately use the term "funding source" as opposed to "credit card account," and this is why I'm not discussing cash flow and working capital implications related to virtual credit cards as a payment method. It is important to abstract the UX of a payment product away from its funding source. If it looks like a card, behaves like a card, can be accepted by Stripe or Block (Square) or a POS terminal — does it matter for a vendor/supplier if a funding source is a credit card account, line of credit, debit account or an Ethereum wallet if the funds were withdrawn from the source account and reached the destination account?

Why the adoption of virtual cards is underwhelming

The two biggest benefits of virtual cards are better financial controls (better than sharing a non-virtual card) and easier reconciliation (versus using a single non-virtual card for all cardable payments).

To become a true Jedi master of cards and fully capitalize on those benefits, one (business client) still has to do some manual work in their finance department. A company that is looking to adopt virtual cards will need to change their processes and, most probably, adopt new software. The company will probably need to update their policies to answer previously unanswered questions around payables and expense management processes that used to be open to ad-hoc interpretations (and misinterpretations, mistakes and fraud).

In an attempt to streamline AP reconciliation, this problem can just turn into a different, arguably smaller, problem of multiple virtual cards management. While expense management can become significantly simpler with virtual cards, vendor management can lead to unpredictable results. For example, pushing virtual cards as a payment method at some vendors whom you paid differently in the past, may lead to them reacting by increasing prices and changing terms.

With an abundance of payment methods and payment providers, it is important to remember which problems each of those methods are meant to solve. Unfortunately, this does not seem to be the case. It's become almost fashionable to fetishize virtual credit cards as one of the most profitable payment methods and try to make every expense and payment cardable. Yes, I've seen people swallowing knives but it's not the intended use of the tool nor a natural human behavior. It's a trick and a dangerous one.

What banks can do to improve the adoption of virtual cards

I believe the most interesting benefits of virtual cards are better controls, risk management and reconciliation potential. Professional deformation can, at times, narrow a professionals' worldview, where they tend to see things only through their industry and products lenses. Everything becomes a nail for a hammer, everything becomes a payment rail and a lending product for a bank, everything is cardable for card networks and around-cards fintechs.

However, for the end-users, those are tools existing within a broader scope and context. Reconciliation is directly touching ERP and accounting systems. So does expense management. Risk management directly impacts a company's financial controls and policies and requires accurate, real-time updates of the system of record in ERP or accounting software.

To make virtual cards a success and a really transformational product, banks and card networks need to be able to exchange information with end-users systems of records in real-time. Embedded and ERP banking can be the answer to this challenge.