Bo Jiang, CEO of Lithic, on the power of the cards as a digital payment rail

Why are cards a superior payment rail compared to others?

Oftentimes, when we make comparisons to other rails, we think about a very narrow, simple, happy path use case, where you're like, "I trust Jan and I have to send him 50 bucks,” and it's like, “Venmo works super well, right?” 

But the real beauty of card payments is that it’s ubiquitous, and it works pretty flawlessly at scale across a broad variety of use cases. Cards generally just work and transfer money in real time. I think we take for granted how clean an experience that is.

For example, we take for granted the fact that you can authorize a payment for a certain amount and then complete it for a different amount. And if there's an issue, there's a standardized dispute resolution process that’s about as clean as you can get at scale. Dispute resolution processes are always going to be kind of messy, but to be able to do so effectively at scale is really, really impressive. 

Another example is spending money abroad. If you’ve ever tried to transfer money internationally through a bank –  sometimes you have to go through an intermediary bank, and jump through all these hoops, and it’s super painful. It takes multiple days. With a card, I can go abroad and spend money and not think about where it goes. 

Cards also provide a foundation for programmable money. I can easily generate a card number programmatically, set limits and spend controls, and adjust these things in real-time based on various conditions or the context of the transaction. It's all programmatic. We talk about programmatic money movement, making money programmable. You can't really do that with other things all that easily. You could have it be on the blockchain, obviously, or a number of other forms other than maybe physical cash, but I would posit that cards provide the best foundation.

With all the programmability and auth that you can add fine-grained rules for, how do you empower and maybe create more activity, more usage with end-to-end users?

It’s counterintuitive, maybe, but it’s by being smarter about, and sometimes creating more, contextually relevant and intelligent policies. Setting really smart spend controls and building these rules allow people to move more quickly and spend more freely without having to ask permission ahead of time. 

With cards, you can reconcile spend really quickly and understand what users are spending on. Can you talk about that value—the reconciliation as compared to something like ACH payments?

Reconciliation is definitely something that gets complicated quickly, but developer first card issuer processors can help make it easier.

Going back to my earlier Venmo example, reconciliation is easy  when you have the happy path, but it gets harder with  all the exceptions that come with payments. When do things post to your general ledger? When do you get returns? When do debits and credits line up? How do you handle force-post transactions?

Having a consistent system with rules makes reconciliation really easy, and you can do this with cards.  You can essentially build a set of recon tools that aren't necessarily super complex, as long as you trust the fidelity of the data. 

 We recently rolled out a settlements API that focuses on providing high-quality data access to network reporting fees and reconciling to the cash that you have in your bank account.

Is reconciliation mostly about winning more B2B payments use cases? How do you think about that?

I would argue that for any business that is in the payments landscape or has payments as part of their business—whether that’s a digital banking product like Mercury or a vertical software company embedding payments—flawless reconciliation, within 12 hours for example, is really important because it's part of your business. 

You have to have that visibility into your cash movement. You have to have that ability to see what your network fees are. It's a critical part of the business for any modern-day digital payments company or company doing payments.

Is migration from ACH to card a big part of the Lithic tailwind?

Yeah, I think there are certain transactions where vendors are much less willing to accept fees around card acceptance.  In all likelihood, those’ll continue over other rails for the foreseeable future. 

Our ethos as a company is to be pretty focused. We're doing some stuff around ACH now and rolling that out to be able to help our customers tie together an end-to-end view of reconciliation, cash, and money flowing through their system.

 And we've constructed this unified view  to be a a modular system. So, if people want to bring their own ACH provider for whatever reason, they're able to do that still. That's a key tenet for us from a product development perspective, where each of these products should be pretty modular. 

That said, we aren't really in the business of selling standalone ACH, so it's more of an add-on to our card products. That is how we think about it.

What is your view and reaction to FedNow, where maybe the money transfer is kind of being reinvented for the digital age, finally?

I think it's interesting, right? You see a couple of different attempts to go at this. My general sense is that the rate of adoption here is going to be slower than we would all like. 

In general, these types of rails will have the most value when you have that ubiquity that you see with cards, and to some extent, ACH in the US. That's my quick take on some of these newer, faster payments rails.

Can you go into more detail regarding building a card issuing workflow in Lithic vs. banking-as-a-service platforms like Unit? What makes using Lithic advantageous if you’re a software company looking to build cards into a payment flow? What are the trade-offs there?

It really depends on the product that you're trying to build and the level of fintech knowledge on your team. If you’re looking for a relatively turnkey banking product and you're not thinking about your payment strategy as being all that core to your business, banking-as-a-service is a good way to get started.

If payments is potentially a pretty core part of your business and you anticipate needing to innovate more quickly on product and have a more differentiated experience, I think working with a card-issuer processor is worth the upfront investment. 

What we see a lot of times is scale players that really want to have that fine-grained control over the customer experience and their stack. They may value redundancy. They may value reliability. They may value the ability to control card design more tightly or want to have a direct dialogue with the bank. Those tend to be the types of customers where, at least at scale, we work pretty well.

Then there are use cases like Order where they don't have a broad need for a banking product. If we go back to categories, it's the category of embedding a relatively simple virtual card use case, and we can differentiate by being really fast, and because we've got our direct connections to the networks, the best features, the best reconciliation, etc. But the overarching differentiator, I think, is speed to market.

Do you see this abstraction away of the payment method happening?

Yes. For example, look at bill pay.

We're going from a world where a lot of payments are just about handing someone a card, to a world where you’re clicking a button in software.  This shift from offline to online is part of that abstraction, where you lose a physical card.  .  You But even virtually,  the concept of cards as a payment method is increasingly becoming abstracted away, where it's like, "Okay, your job-to-be-done, Bo or Jan, is to pay your SaaS vendor."

You don't ultimately care how that money gets from your account to the SaaS vendor's account. You  do care about workflows in the company and: "Is everyone empowered to spend in a way that makes sense?" You may care about price, obviously, for a negotiation, but nowhere is the job-to-be-done like, "Hey! It needs to go through a certain rail." 

I think you're definitely seeing vendors realize that. I would put Order in that category of like, "Hey! I care about the workflow as a buyer of the Order software. I care about visibility. I care about having a single invoice. I don't really care if I pay via a check, ACH, card, or whatever." And so, I think that's a really insightful point.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.