Embedded banking for platforms and non-financial brands

The companies building the most interesting financial products in the UK today are not banks. They're property platforms, construction companies, gig economy platforms, marketplaces, payroll providers and even restaurant chains. They're businesses that, at their core, are not financial services companies at all. But somewhere in the course of building their product, they ran into a problem that only banking infrastructure could solve.

Why non-financial brands are building banking features

The case for embedded banking is usually made in abstract terms. Platforms can monetise their user base. Companies can increase engagement. Retention improves when financial services are embedded. All of that is true. But the more honest version is simpler: companies that handle money eventually need a bank, whether they planned to or not.

Consider what Starbucks discovered when it launched its loyalty programme. More money is stored in the Starbucks app at any given time than in most US community banks. That balance has to sit somewhere, move somewhere, and be protected somewhere. Starbucks didn't set out to become a financial institution. It sells coffee. But the moment it created a stored value account, it became one by default.

Uber had a version of this problem. Driver earnings needed to land in accounts instantly, not on a weekly payroll cycle. The gap between a completed ride and when a driver could access their earnings was itself a product problem. The solution was a driver account that could receive earnings in real-time and give drivers access to financial products built around the way they actually work.

The pattern repeats across industries. A property management platform needs to hold tenant deposits securely and separately from its own funds. A marketplace needs to pay thousands of vendors in multiple currencies on irregular schedules. A construction platform needs to manage retentions, project accounts, and supplier payments simultaneously. A travel platform sitting on millions in advance customer payments needs somewhere safe and compliant to hold that money. In each case, the financial problem isn't an edge case. It's core infrastructure.

What products non-financial brands actually need

The specific banking products required vary by industry and use case, but they fall into a small number of categories.

Money movement and payments

The most immediate need for most platforms is the ability to move money reliably, quickly, and with full visibility. This means access to UK payment rails: Faster Payments for near-instant transfers, BACS for payroll and bulk payments, CHAPS for high-value transfers, and book transfers for moving money between accounts within the same banking infrastructure.

For platforms operating internationally, international remittance and cross-currency payments are equally important. A marketplace with sellers in multiple countries needs to pay out in local currencies. A hotel booking platform needs to move GBP into emerging market currencies reliably.

The underlying question is always the same: where does money go, how does it get there, and can I see exactly where it is at every point?

Accounts for customers

Many platforms need to give their customers accounts‍—‌virtual wallets, e-money accounts, real bank accounts. The type of account is dependent on the use case and has the ability to change the customer experience fundamentally.

For example, a driver account in the Uber app, powered by Griffin, gives drivers a real UK bank account. If they opt in, they also get a savings account. Earnings land there from completed rides, they can spend via their card, and any money set aside in savings earns interest. The app becomes the financial hub.

For platforms like Vinted or Booking.com, the equivalent is a seller or host account that holds sale proceeds, handles disputes, and makes payouts. The operational complexity of managing thousands of individual balances disappears when each customer has their own dedicated account rather than a share of a pooled balance.

Safeguarding customer money

If you are holding money on behalf of your customers, you may be required to safeguard and separate it. Property platforms holding tenant deposits are a clear example. The deposits belong to the tenant, not the landlord, not the platform. They must be held separately from the platform's operating funds, reconciled accurately, and returned promptly at the end of a tenancy.

For regulated platforms, safeguarding is a legal requirement. For others, the principle is equally important: customer money should never mix with your money. The moment it does, you have a compliance problem and, more importantly, a trust problem. Safeguarded funds should be easy to reconcile with and a clear audit trail. One pooled bank account managed by spreadsheet is not adequate.

Residual income and retention (embedded savings)

For platforms with customers who hold balances, there is a growing expectation that those balances should work harder. A host on a vacation rental property holding advance booking payments doesn't just want a place to store that money. They want it to earn interest while it waits.

Embedded savings accounts change the proposition for platforms significantly. A gig economy marketplace that can offer a savings account inside its app is no longer just a work platform. It's a financial companion for the worker and may result in better retention.

FSCS-protected savings accounts, earning competitive rates, available inside platforms people already use daily is what embedded savings looks like in practice.

Operational accounts and backend complexity

Beyond customer-facing products, platforms have their own operational banking needs. Paying suppliers, managing project accounts, running internal treasury operations, and automating reconciliation.

In construction, for example, a platform might need to hold project funds separately from operating funds, release payments against milestones, manage retentions, and reconcile across dozens of concurrent projects. Doing this manually is not viable at scale. Doing it through a bank that doesn't understand your business model is slow and expensive.

The answer could be programmatic banking. Accounts and payments that can be opened, configured, and managed via API, with real-time visibility into every transaction across every account.

Why this matters and what the benefits actually are

Embedded banking is not primarily about revenue diversification, though that is a genuine benefit. It is about building products that work the way the people who use them actually live and work.

Retention and stickiness. A driver who banks with their ride platform is not going to switch to a competitor very easily especially if the competitor does not offer them an easy way to do this. A freelancer who uses their marketplace for invoicing, payments, tax management and savings has significantly less incentive to move. Financial products, done well, are the stickiest products a platform can offer.

Operational efficiency. Manual payment processes are expensive, error-prone, and hard to scale. Programmatic banking replaces manual steps with API calls. Payouts that took days happen in minutes. Reconciliation that required a team of people runs automatically.

Revenue. Interchange on card spending, interest on balances held, fees for premium financial features: there are real commercial opportunities for platforms that move into financial services thoughtfully. Starbucks earns meaningful float income on the balances sitting in its rewards programme. Platforms with large user bases and high-frequency transactions have equivalent opportunities.

Trust. Customers whose money is held securely and visible to them at all times trust the platform more. That trust transfers into the core product relationship.

Why the choice of banking partner matters

Not all embedded banking infrastructure is the same, and the differences matter enormously depending on your use case, product and operational capacity. The most important distinction is between building on a licensed bank that owns its own infrastructure and building on one that doesn't, or on a non-bank intermediary layer.

When you build on Griffin, you are building directly on the regulated infrastructure of a UK bank. There is no middleware between you and the underlying bank. This matters for non-financial brands and platforms in particular because of how we manage regulatory oversight. Because everything runs on our own infrastructure, compliance monitoring happens programmatically and continuously, not as a periodic manual exercise. Oversight doesn't become a burden on your team.

When we work with a platform, we understand the flow of funds from end to end. We know whose money is where at every point. We can identify risk early, support compliance, and give platforms the audit trail they need for regulators, auditors, and ultimately their own customers.

On the other hand, safeguarding accounts and savings accounts can only be offered by a licensed bank. If either of these is part of your product, the choice of provider is obvious.

Who we're working with

Proptech and real estate. Property platforms sit at the intersection of tenant money, landlord money, and platform money. Getting those boundaries wrong has serious legal and regulatory consequences. We work with LettsPay, Calmony and Street to automate payments, reconciliations and manage money movement.

Mobility and gig economy. Uber uses Griffin to power driver payments and savings in the UK. Drivers get a real bank account, earnings land there in real time, and savings products are available inside the same app they use to manage their work.

Construction. Construction has some of the most complex payment flows of any industry. Multiple stakeholders, milestone-based payments, retention management, high-value transactions with long timelines, and a sector with a persistent insolvency problem. Saible is building payment infrastructure for the construction industry on Griffin.

Coming soon. We are currently building with platforms in travel, employee benefits and payroll, and some other sectors where the complexity of money movement has historically been managed by manual processes that don't scale. If you're building in these spaces, we'd like to talk.

Getting started

Non-financial brands don't become financial brands overnight. The journey usually starts with a specific problem: driver payments that take too long, customer deposits that are held in the wrong account, supplier payments that require too much manual intervention.

The first step is understanding how money moves on your platform. Where does money enter your platform, what happens to it while it's there, and how does it leave? As simple as it sounds, this usually surfaces the banking infrastructure you actually need. From there, the conversation becomes practical. What accounts, what payment rails, what compliance infrastructure? What can you launch first? And what should come later?

Griffin's sandbox is free, requires no NDA, and gives you full API access to test the mechanics of your product before you commit. When you're ready to talk through the specifics, our commercial team has worked with enough platforms across enough industries to have a useful view of what goes wrong, what works, and how to sequence the build.