Embedded settlement for SaaS and ERP platforms

The payment no longer starts at the bank. It starts in the software where the business runs: the ERP that approves the invoice, the vertical SaaS product that manages the dental practice or the freight broker, the platform that runs payroll across nine countries. By the time money needs to move, every decision that matters, who gets paid, how much, when, in what currency, has already been made inside someone’s product. The transfer itself is the last step, and increasingly the platform wants to own it.

That instinct has a name and a track record. Embedded finance, the folding of payments, lending, and accounts into non-financial software, moved from thesis to infrastructure over the past five years. Bain and Bain Capital projected US embedded finance transaction value would more than double from $2.6 trillion in 2021 to $7 trillion by 2026, about 10% of US financial transactions, with the revenue pool for platforms and their enabling infrastructure more than doubling alongside it. Domestic embedded payments are now table stakes in many software categories.

Cross-border settlement is the unfinished half. A platform that can pay a domestic supplier in seconds still hands its user back to the bank portal the moment the counterparty is in another country or the payment needs a different rail. The transfer disappears into the correspondent chain, and the platform’s product promise stops at the border.

Why settlement is harder than payments

Embedding a card charge or a domestic transfer means integrating one well-paved rail. Embedding settlement means dealing with many: wires, local instant schemes, and increasingly stablecoins and tokenized deposits, each with different speed, cost, reach, and compliance obligations. Three problems follow.

Rail fragmentation. No single rail covers every corridor a platform’s customers will need. Building one integration per rail per market is an infrastructure company’s roadmap, and most platforms are not infrastructure companies. The alternative is a layer that presents one integration and routes each payment to whichever rail fits it. That is the job of an orchestration layer, and the reason the category exists.

The compliance model. Money movement carries screening, policy, and audit obligations that software teams underestimate. The question to ask any provider is where compliance actually happens: bolted on before or after the transfer in separate systems, or enforced in the settlement process itself, so a payment that cannot satisfy its governing policy does not settle. The second model produces something platforms specifically need: evidence, per transaction, that the rules were followed, without the platform building a compliance department.

The brand boundary. Platforms invest years in owning a workflow. Settlement infrastructure that inserts its own brand, its own accounts, or its own customer relationship into the flow gives some of that ownership away. White-label matters more in embedded settlement than almost anywhere else, because the platform’s customer should experience the platform, with the settlement layer invisible underneath.

The evaluation checklist

For a product leader at an ERP or SaaS company weighing embedded settlement, the questions that separate providers:

1. One integration or many? How many rails, currencies, and corridors does one integration actually reach, and what happens when the right rail for a payment changes?
2. Who enforces policy, and where? Is compliance a screening service around the transfer, or enforced inside settlement with evidence produced per transaction?
3. Whose brand does the customer see? Can the platform keep its product surface end to end?
4. What happens when a payment stops? Exceptions, reconciliation, and support determine the operational cost more than the happy path does.
5. What does the platform’s auditor see? Verifiable records of what settled, under what policy, matter at diligence and at audit.

Where Frame fits

Frame is the settlement layer for global finance: one integration to orchestrate payments at scale across fiat rails, stablecoins, and tokenized deposits, with compliance enforced on every transaction and settlement in seconds instead of days.

For a platform, that shape maps directly onto the checklist above. One integration reaches every rail Frame routes across, and the routing follows the policy that governs each payment rather than a fixed network choice. Frame’s Rules Engine evaluates every transaction against its governing policies inside settlement, so a transfer that cannot satisfy them does not settle, and every settled transaction produces verifiable evidence that its conditions were met, without exposing the underlying business data. The platform keeps its brand and its customer. Frame serves banks and financial institutions, payment providers and processors, exchanges and trading venues, SaaS and ERP platforms, and enterprises; for platforms specifically, the point is that settlement becomes a product feature rather than a build.

See how a rail-neutral settlement layer works: the Frame Blueprint.