This article is a branded post, presented by Privacy.com. While the following essay is sponsored, all editorial content was created by FTT. If you have any questions or comments, feel free to email Ian at ian@fintechtoday.co.

Last week, I went over some limitations in the partnership model with fintech companies—the high level thesis is that while some companies are making it easier to partner and make digitally native financial products, we were still in the first inning of this transformation, and there are a lot of problems that need to be solved.

Which is why I’m excited to highlight Privacy.com’s interesting path towards becoming a card issuing platform. Privacy.com still has a thriving consumer product—its one that I use pretty frequently actually—but more recently announced an API for developers to create their own debit cards.

The genesis of this product is fascinating—they ended up building all of this internally for their own product. Then, they started getting inbound requests from others to use it as well.

Privacy.com first launched in 2016—CEO Bo and I met when I was still a reporter at Quartz. We’ve remained friends over the past few years and it’s given me a really unique understanding both issues in the issuing space and how Privacy.com can solve them.

Privacy.com’s most innovative feature for consumers was around flexibility and control around spending, and obfuscating card numbers for transactions. Back in 2016, Visa and MasterCard were exploring different ways to reduce online fraud, but Privacy.com wanted users to create individual cards per merchant, and also things like spending limits, “burner” or single-use cards, and the ability to shut off cards.

The issue? Figuring out the right card issuing and processing partners was an arduous task—the entire process wasn’t anything but developer friendly. Terms weren’t appealing for an early stage startup, you needed to jump through multiple hoops to even see if a potential partner could even support your requests, and accessing developer documentation was, for some reason, really hard.

It because increasingly clear that it made more sense to think about building this technology from scratch. Not only would it make Privacy.com’s consumer product more compelling, but the team was already seeing interest from developers who wanted to build on top of Privacy.com.

While the API was announced more recently, and has seen a bunch of cool partnerships from brands like MSCHF, Privacy.com’s been testing it for over the past year with select partners. The early indicators showed that the expansion into a B2B product held a ton of potential, and it makes sense.

An issue I highlighted last week was the complexity for non-fintech companies that were interested in developing financial services products for their users. I think companies like Privacy.com and others like Unit Finance & Mood are focused on solving that eduction gap—which will make their sales process much simpler. Part of the slow adoption by non-fintech companies has been the fact that they don’t get the value proposition. How would a virtual wallet or a debit card or another financial product help my user and improve my bottom line? By focusing on simplicity and a self-serve product, Privacy.com can make a lot of headway here.

Another way Privacy.com has focused on simplicity is in its pricing model. Typically for most partnerships between API providers, banks, and startups, the process is riddled with hurdles to jump. NDA’s are required before companies talk pricing, and even after the deals are executed, terms are filled with confusing terminology and opaque pricing. With a transparent pricing structure, startups can easily understand the cost and time it would take to implement Privacy.com.

Lastly, another reason is speedy integrations. The cost and time to implement is a bit confusing for companies—its hard to predict how long things take until you actual start working on it. For most processors, implementation time can take anywhere from 4-6 months—with Privacy.com, customers can start issuing cards within hours and without talking to a salesperson.

From a strategic perspective, I think a lot of other consumer fintech companies might explore building and offering their own technology. Some like Astra, have already taken this approach, and are offering developers easy and cheap ways to integrate into their service. For some, this has two benefits: not only does this become a potential revenue source, but you’re also adding more value for your consumers as well. Interesting enough, it might be that the B2B side can fuel more efficient B2C growth; when you compare that to the ever-rising customer acquisition costs for consumer fintech companies, and this growth strategy could be an interesting one for some (obviously, you need infrastructure to sell. Which most companies don’t.)

Or, you could keep your technology as a competitive advantage—something that Current has been focused on, according to some folks I’ve spoken to in the past. Given their focus on underserved demographics—initially teens, but that group has expanded to lower income demographics that are fiscally responsible, like essential workers—they needed to be focused on having strong unit economics. This meant building out a lot their own core banking technology—called Current Core. It’s unlikely a company like Current will outsource their tech—at least for the foreseeable future. In a sector as competitive as consumer banking, having a technology advantage that leads to a better user experience *and* better margins is a win-win.

As for Privacy.com, expect the company to continue pushing new features and capabilities—like eventually physical cards. And in the future, it’ll be interesting to see if other consumer fintech companies expand into infrastructure…or…if an infrastructure company expanding into a consumer product (like GreeenDot.)