Vertical Embedded Finance: Adding Payments and Lending to Your SaaS (Build vs. BaaS)

Your SaaS already owns the workflow. Most people talking about embedded finance for SaaS skip right past that part, but it’s the whole thing really. Your customer’s already inside your product. The money just happens to move while they are there.

Payments and lending can turn into a monetization layer, sure. But they don’t deserve the same decision. Treat them like one question, and that’s usually where a team loses a year, maybe more. Build versus BaaS really just comes down to this:  how much of that financial infrastructure do you actually want to own, and for how long are you willing to own it?

 

1 : Why Vertical SaaS Is Adding Payments and Lending Now

Most software companies never think about money movement. They think about the workflow. That’s it. But if your customers are already doing their work inside your product, the payment’s sitting there too. You just haven’t looked at it yet. 

That’s vertical SaaS payment monetization, basically. Not some new business line. You are just noticing something that was already happening right next to you the whole time. 

1 : Embedded Finance as a SaaS Product Capability

So what is vertical embedded finance? Simple answer, really. You don’t need another app or another website. Pay or borrow right from the same app you already use. No separate login screen, nothing new to download.  

Customers stay exactly where they are. McKinsey’s basically talking about this same thing, putting financial products inside experiences that aren’t financial to begin with. The money part just happens there too, quietly, like it was always meant to. 

2 : Why Vertical SaaS Has the Distribution Advantage

Here’s something a bank will never have. Years of transaction data sitting inside your platform. Actual trust, the kind that builds slowly, because your customers have used this tool every day and nothing’s broken yet. That trust is the real engine behind SaaS payment monetization. Not a feature you shipped. Just an edge almost nobody else has. 

And the timings are already built in; you don’t have to create them. Every invoice. Every payout. Every renewal. Each one’s a moment where a financial product just fits, naturally, without anyone explaining why it’s there. It’s already part of what they are doing anyway.[Text Wrapping Break]H2-2: The Embedded Finance Stack: What You Own Before Choosing Build or BaaS

Before you even get to Build or BaaS, there’s something you need to see first. Layers here, a few of them. McKinsey splits this whole ecosystem into three pieces actually: the distributor, the tech provider, and the balance-sheet provider.

Some of these layers belong to you no matter what you pick. Some don’t. That’s fine, honestly; that’s sort of the whole point of an embedded finance platform for SaaS.

1 : The Product Layer: UX, Workflow and Customer Relationship 

This layer is yours. All of it, no question. Your customer’s identity lives here. The workflow they already know lives here too. How you show them a payment option, when it pops up, what it looks like next to the task they’re already doing; that’s you, that’s your product, nobody else touches this. 

This is also where trust actually gets built or lost. Not in the backend. Right here, on the screen your customer sees every day. Get this wrong and none of the infrastructure underneath even matters. 

2 : The Financial Infrastructure Layer: Rails, Ledger, Risk and Compliance 

This layer’s heavier, and it’s really the heart of embedded finance vs. BaaS. Payment processing sits here. So does the ledger, tracking whose money is whose, every second. Reconciliation too, making sure numbers actually match. Then the regulatory stuff. KYC, KYB, AML, and underwriting if lending is involved. 

None of this has to sit inside your company; it can sit with a partner. Either way, someone answers it. Our dev team says this a lot, actually. The hard part’s never the API call. It’s maintaining the financial state and compliance responsibility sitting right behind it. 

3 : What Building Payments and Lending In-House Actually Requires  

Build sounds clean on a slide. It’s not clean once you are actually doing it.  

Let’s walk through what you are actually signing up for. Not the pitch version. The real one. 

1 : Payments In-House: PayFac, Licensing, and the Ledger Problem 

So there’s something called the PayFac model. In plain terms, it just means you become the one responsible for how merchants get paid, instead of handing that off. You will likely need a sponsor bank behind you too, because moving money across states and countries brings money transmission rules into the picture, and that’s not something you skip. 

Then comes the orchestration: deciding which rail a payment takes and how it routes. The ledger has to track every cent, correctly, always. Reconciliation has to match it. And PCI scope follows you around the moment you are touching card data at all, even a little. 

2 : Lending In-House: Underwriting, Credit Risk and Capital 

Lending’s a different animal, honestly. This is where embedded finance credit risk actually lives. You are deciding who gets money and who doesn’t; that’s underwriting. You are also owning what happens when someone doesn’t pay back; that’s a risk, sitting on your books now.

Collections become your job too, not pleasant, but necessary. And there’s the capital side, money sitting on your balance sheet, tied up, waiting. Lending licensing adds another layer depending on where your customers are. None of this is a feature you ship once and forget. 

3 : The Hidden Operating Burden 

Here’s the part most teams underestimate completely. Building the system is one thing. Running it, every day, forever, is the real cost nobody mentions upfront. That’s embedded finance compliance requirements, and it doesn’t stop after launch. 

KYC and AML checks don’t stop once someone signs up, they just keep going. Compliance operations need actual people, watching actual things. We’ve seen this take 12 to 18 months for a team of around 8, just to get steady. Not theoretical for us; we’ve lived that timeline. Someone’s managing the bank relationship daily. Someone’s watching transactions too. This isn’t something you build once and walk away from; it’s a team you keep, long past launch. 

4 : How the BaaS Route Actually Works and What It Does Not Remove 

So banking as a service for SaaS sounds like someone else just handles it. That’s the pitch, anyway. Not quite true, though. BaaS moves where the work sits. Doesn’t make the work disappear.

Worth being honest about this upfront, the same way we were honest about Build. Nobody wins if this section just sells you on it. 

1 : Sponsor Banks, FBO Accounts, and APIs 

Here’s the sponsor bank model, plain terms. A real bank sits behind all of it; someone regulated has to. Customer money usually lands in something called an FBO account, pooled together but tracked separately underneath so everyone’s share stays right.  

2 : Revenue Share, Fees, and Margin 

Now the money side. Usually there’s a take rate, a cut of every transaction going to your BaaS provider, not just you. Call it embedded finance revenue share, built into the deal from day one. 

That’s only part of it, though. Platform access, KYC and KYB checks, account maintenance, payment-rail costs, all of that can sit underneath too, depending on how the provider’s actually structured the thing.

3 : Dependency, Customization and Exit Risk

This is the part people skip past, mostly. You’re depending on a BaaS provider for SaaS companies now, and that provider depends on their own sponsor bank too. Regulators have made this pretty clear, not hypothetical. The Fed went after Evolve Bank and Trust over exactly this, weak oversight of fintech risk. If either one has a rough year, you feel it. Even when you did nothing wrong yourself. 

Customization has a ceiling too; you can’t always build exactly what you pictured, the provider’s system has its own limits built in. And getting out, if you ever want to, isn’t quick, and isn’t simple either. Synapse showed exactly why. When their systems came apart, customers were stuck dealing with ledger problems, access problems, real ones. That’s the honest version of exit risk. Not the version on the sales call.

5 : Payments vs. Lending: Why the Build-or-BaaS Answer Differs

Here’s where most articles get lazy. They treat payments and lending like the same decision. They’re not, not even close. Build vs. BaaS for embedded payments and lending needs two separate answers, not one.

Why? Because the risk sitting behind each one is just completely different. One’s about moving money. The others are about giving money away and hoping you get it back.

1 : Payments: Money Movement, Settlement, and Margin

Practically, embedded payments for SaaS are all about money movement. One pays, another accepts. However, it settles somewhere else; reconciliation confirms it reached right. There’s a take rate sitting in the middle of all this, and orchestration deciding which path the payment takes.

The risk here is mostly operational, honestly. Something breaks, a payment fails, and reconciliation doesn’t match. Annoying, costly even. But nobody’s handing out money they might not get back. That’s a very different kind of exposure.

2 : Lending: Underwriting, Credit Risk, and Capital

Now how does embedded lending work, that’s a harder question. You’re using customer data to decide who gets money; that’s underwriting. Credit decisioning sits right behind it, and it’s never simple, even with good data.

Default exposure is real here; some people just won’t pay back. Capital sits tied up too, waiting, not earning anything while it waits. Collections become your job as well, chasing money that’s already gone out the door. None of this applies to payments the same way.

3 : Why a Hybrid Product Strategy Often Makes More Sense

So here’s the honest conclusion. You don’t have to pick one path for both. A BaaS provider vs. building in-house payments decision can go one way for payments and a completely different way for lending.

Plenty of companies end up owning more of their payments infrastructure over time, since the risk there is manageable. Makes sense when you think about it plainly.

6 : Build vs. BaaS: The Decision Framework for Vertical SaaS 

Alright. This is the actual answer you came here for. Not more explaining, just the decision itself. Build vs. buy embedded finance comes down to six things, really, not some gut feeling. Let’s just walk through them straight, no fluff attached.

1 : The Six Decision Variables

Here’s the embedded finance decision framework, plain. Six questions, basically, that’s it. Where you land on each one points toward Build, BaaS, or something in between the two. Don’t go looking for some magic revenue number where Build suddenly gets cheaper either, it’s not that clean.

BaaS brings platform access, usage, and transaction fees. Build brings its own compliance costs, operating costs. Comes down to what you’re actually willing to own, not a formula.

Criterion	Favors Build	Favors BaaS
Strategic differentiation	High	Lower
Engineering capacity	Strong	Limited
Time-to-revenue	Flexible	Urgent
Compliance capability	Mature	Limited
Scale/economics	High volume	Early/uncertain
Regional complexity	Focused	Multi-region

2 : Which Route Fits Your SaaS?

So should a SaaS build or buy banking infrastructure? Depends on which column you landed in mostly. Build tends to fit when the financial piece is actually your core product, not a bolt-on. When your team already has the engineering and compliance muscle. When you’re staying in one or two regions, not ten.

Hybrid works for a lot of teams too, more than people admit. Need revenue now, but want room to grow into ownership later. Validate payments first, and keep lending with a partner a while longer, since that risk is heavier. Nothing wrong with starting there.

3 : Decision Matrix

Quick way to score it yourself, honestly. Count how many rows from the table above land in your Build column versus your BaaS column. Four or more on one side that’s usually your answer, roughly.

Three and three, split down the middle. That’s hybrid territory, most likely. Worth sitting with your team on this one before locking anything in, since it’s not a decision you walk back easily once infrastructure’s live.

7 : Regional Regulatory Reality: US, EU, UAE and Southeast Asia 

Here’s something people miss completely, almost every time. Where your customers sit changes this whole decision. Embedded finance compliance for SaaS doesn’t look the same in Texas as it does in Dubai, not even close. On the US side, you’re dealing with federal bank regulators and state rules stacked together. 

Europe runs its own payment and e-money framework, a different animal entirely. UAE splits oversight between the CBUAE and free zones like DIFC and ADGM. Southeast Asia, once you’re in there, the country-by-country differences get hard to ignore fast. 

1 : US 

In the US, money transmission licensing sits at the state level, not federal, so it’s not one rule; it’s fifty conversations, really. Most platforms lean on a sponsor bank here, letting that bank carry the regulated side while you handle the product. 

Lending licensing adds another layer too and varies by state again. And BSA and AML considerations follow any money movement, no matter how small your platform feels. This stuff adds up fast once you’re living in more than a couple states. 

2 : EU

Over in Europe, things are shifting right now, actually. PSD2 still runs the show today, but PSD2 embedded payments rules are being replaced by PSD3 and a new regulation, still working through EU approval as of now, not yet in force.

You’ll likely deal with either a PI or EMI license depending on your model, and strong customer authentication rules apply to most transactions. GDPR sits on top of all this too, since you’re handling payment data and personal data together, which always adds friction. 

3 : UAE 

The UAE runs through the Central Bank, CBUAE, for most of this. Embedded finance UAE regulations depend partly on where exactly you’re operating too, since DIFC and ADGM run their own separate frameworks from the mainland UAE. 

In West Asia, partner relationships matter the most. The financial regulatory environment shifts quite quickly in the UAE. Checking the latest regulation is advisable before forwarding a final plan. 

4 : Southeast Asia

This region’s genuinely fragmented, no way around saying it plainly. Embedded finance Southeast Asia means dealing with a different regime in nearly every country you enter; Singapore’s rules don’t carry over to Indonesia or Vietnam. 

Local payment rails vary too, not standardized across borders the way EU rails mostly are. Licensing requirements differ country to country, and most platforms end up needing local partners just to operate legally, not as a convenience, but as a requirement. 

8 : From Decision to Launch: A Pragmatic Embedded Finance Roadmap 

So here’s an embedded finance roadmap for SaaS, the practical version, not the theory. Start small, prove it works, then grow into more ownership only when it actually makes sense to. 

1 : Phase 1: Payments First

Here’s how to add payments to a vertical SaaS product, step one. Start with payments, not lending; payments are simpler to validate. Watch adoption closely. Are people actually using it or just seeing it? Check the attach rate too, and transaction volume; both tell you different things.

Operational readiness matters here too; can your team actually support this every single day? We’ve seen compliance automation cut risk significantly on a financial platform we built, close to a third reduction, just from getting checks right early on. That’s the part teams miss; usually, they’re too busy watching the payment flow go live to notice. Get the economics right at this stage, before anything bigger comes next.

2 : Phase 2: Add Lending With a Decision Gate

Only once payments are solid, look at embedded lending for SaaS. Not before. Check your underwriting data quality first; is it actually good enough to lend against? Figure out your real credit-risk appetite too: how much risk can you actually carry?

Capital requirements matter; lending ties up money, that’s real. Regulatory maturity, volume, and economics all need checking again here, same questions, bigger stakes. Then decide, stay with BaaS, move to hybrid, or go deeper into ownership, whichever fits where you actually are.