Build vs. partner: The framework every platform needs
A common strategic mistake we see from platforms entering embedded finance isn't picking the wrong product to launch first. It's picking the wrong model for how to launch it.
Do we build it ourselves, or partner with a vendor?
Building an in-house service gives you more control and higher margins, but also incurs higher setup and ongoing maintenance costs, ongoing capital requirements, as well as significantly greater risk and regulatory requirements. All of these factors take time and impact speed-to-market.
Partnering with an embedded finance platform removes complexity, regulatory lift, and other requirements, while also allowing you to launch much faster, with little-to-no risk. The downside is you’re now sharing margin with the vendor, so while ongoing costs are minimal, your net and top-line revenue will also be lower than if you’d built an in-house service.
The right answer for your company usually depends on four things: your size and annual processing volume, your regulatory experience, your risk tolerance, and your ideal speed-to-market.
The framework
Of those four inputs, volume is where to start: it's the most concrete, and it sets the scale of everything else — regulatory lift, risk exposure, how fast you can realistically move.
This is the mental model we use at Jaris, adapted from conversations with partners and industry experts like Jane Podbelskaya of Charge Forward.
Whether you’re a software platform, or payment processing company, the first metric most partners should analyze is their Gross Annual Processing Volume (GPV), which is the total transaction volume flowing through your payment rails that a lender would underwrite against. Higher GPV leads to higher potential loan origination volume, and ultimately more revenue for your company. By understanding the potential origination opportunity, you can now gauge the opportunity costs of build vs. partner.
Once you’ve gauged the potential revenue opportunity, you can move to calculating the cost of building your own service. Most platforms typically focus on engineering headcount and infrastructure. That's the smallest cost center. Here's what the full bill of materials actually looks like:
Pre-launch (table stakes)
Licensing. Money transmitter licenses, lender licenses, sponsor bank agreements — each is a 6-12 month process with ongoing renewal and compliance overhead.
Capital. Lending requires real balance sheet capacity, not just code. You're putting your own money at risk against an underwriting model you're still refining.
Customer acquisition
Marketing. Customer acquisition cost (CAC) for financial products can be materially higher than software CAC, and most platforms underestimate the in-product activation work needed to convert eligible merchants.
Ongoing operations (forever costs)
Underwriting. Risk models, data infrastructure, decisioning engines, ongoing model retraining. The model is only as good as the data, and the data keeps drifting.
Fraud and anti-money laundering (AML). Continuous monitoring, regulatory exam readiness, suspicious activity reporting.
Servicing. Collections, customer support, dispute handling. Every day, indefinitely.
The compounding problem: every new embedded product inherits all six costs. Build payments, you pay these once. Add lending, you pay again — different licenses, capital requirements, and risk models. Add card issuing, you pay again — different network agreements and fraud liability.
Why partnering wins (in most cases):
For the vast majority of companies the best approach is almost always partner first. The upfront engineering lift, ongoing underwriting and compliance requirements, and capital needed to run in-house services take months to build, delaying your time-to-market while also creating significant overhead for new products. Platforms that wait to build the perfect in-house service miss the window that partnering would have opened in weeks.
The real question is who to partner with
When evaluating vendors for embedded finance, there are several factors that should be considered above others:
What am I trying to solve - revenue, retention, or both?
Single-product vs. multi-product - can this vendor help me launch multiple products?
How likely are merchants to adopt these products? (Instant Payouts has higher attachment than lending)
Merchant experience - Embedded or hosted?
Is there room to grow revenue/margin? (taking on risk to increase rev-share)
Do they understand our industry? (payment processing is meaningfully different than SaaS, different channel relationships and backend systems)
Not sure whether to build or partner? Talk to us about your embedded finance roadmap.