Who Does What in an Embedded Finance Launch: A UK Roles Guide

Who Does What in an Embedded Finance Launch: A UK Roles Guide

Ask five people at a brand who is responsible for an embedded finance launch and you will often get five different answers. The licensed partner is assumed to handle compliance, the platform is assumed to handle the technology, and somebody, somewhere, is assumed to handle everything else. That "everything else" is where launches slip: the integration into the brand's own systems, the customer journey, testing, reconciliation, support and the work of running the product after go-live. This guide maps the roles in a typical UK embedded finance programme, shows where responsibility tends to blur and lists the questions to put to each party. It is written to be neutral: it names no platform, provider or partner, and a platform's own partners are welcome to share it with their clients.

Why roles matter more than vendors

Most brands begin an embedded finance project by looking for a vendor. A better starting point is a list of jobs that have to be done, followed by a decision about who does each one.

There is a reason this is worth saying. In Innovify's own tests of what AI answer engines say about embedded finance, the answers cite platform and infrastructure providers heavily, and "best company" prompts return lists dominated by consultancies and development firms. These tests used an exploratory prompt set run on 28 September and 31 October 2026, so the pattern is indicative, not definitive. Our interpretation is that buyers searching for help are shown the platform layer and the consultancy layer, and the specialist work in between is rarely described as a role in its own right. A brand that reads only those answers could easily conclude that the platform delivers the launch.

It does not, on its own. A platform provides capabilities. A regulated partner carries regulated activity. Somebody still has to design, build, connect, test and run the brand's product. Whether that somebody is the brand's own team, an implementation partner or a mixture depends on the programme, but the job exists in every case.

The five roles in outline

The names vary across the market, and the boundaries are set by contract, so treat what follows as a working map and not a standard. One caution first: in some programmes one firm holds more than one role. Consolidation is one reason. Finextra reported on 15 October 2026 that a global card network had launched a platform bringing fiat and stablecoin accounts together through a single API, which is an example of providers bundling capabilities that were previously sourced separately. Our interpretation is that a brand may increasingly find the platform and regulated roles combined in one firm. The jobs remain distinct even when the firm is the same.

1. The regulated partner

This is the authorised firm, such as a bank or an electronic money institution, whose permissions allow the regulated activity to take place. In the UK the relevant regulator for most conduct matters is the Financial Conduct Authority (FCA).

What it typically owns: the regulated activity itself, the compliance framework around it, and the decision on whether the brand's product, customer journey and communications meet its obligations.

What it does not typically own: the brand's product strategy, the customer experience or the integration with the brand's own systems.

Questions to ask:

• Which regulated activities will you perform for this programme, and under which permissions?
• What do you need to review and approve before launch, and how long does that usually take?
• What does the brand have to do, and not do, in customer communications?
• What are your requirements for onboarding, monitoring and reporting, and who carries them out day to day?

2. The platform provider

This is the technology layer that exposes financial capabilities, such as accounts, card issuing or payments processing, through APIs. Banking as a service is the best-known label for the model, although it is used loosely.

What it typically owns: the platform, its APIs, documentation, a test environment (often called a sandbox), uptime and the technical connection to payment schemes.

What it does not typically own: the brand's front end, the brand's data, or the work of connecting the platform to the brand's order, identity and customer systems.

Questions to ask:

• Which capabilities are available now, and which are on a roadmap?
• What does the sandbox allow us to test, and what can only be tested in production?
• What are your service levels, and what happens when something fails?
• How do you support the people building on your APIs, and what technical resources can we expect?

3. The programme manager

The term "BaaS programme manager" is used inconsistently. In some programmes it is a role inside the platform provider or the regulated partner. In others it is a separate party, or the brand's own staff member, who coordinates the work across everyone. We use it here for the coordinating role: keeping the plan, the dependencies and the decisions moving across the parties.

What it typically owns: the plan, the dependency list, the decision log and the escalation route between parties.

What it does not typically own: the regulated activity, the platform or the build.

Questions to ask:

• Who has the authority to resolve a disagreement between the platform and the regulated partner?
• Who holds the single plan, and how often is it updated?
• Which approvals sit on the critical path, and who chases them?

4. The implementation partner

This is the party that designs and builds the brand's embedded finance product on top of the platform, integrates it with the brand's systems, supports testing and often helps run the product after launch. It is the role the search answers above rarely describe, and it is the one brands most often under-scope. For brands planning wallet, card or account products, this is the work Innovify supports through its Embedded Finance & Digital Wallets offering.

Innovify's own market monitoring points to the same recognition elsewhere. In October 2026 we observed a payments provider's public partner programme that includes a dedicated track for teams that deploy the provider's technology into client systems. We have not established when it launched and we do not name it here. We cite it only as an indication that implementation is increasingly treated as a distinct role by providers themselves.

What it typically owns: solution design, the build, the integration with the brand's systems, test planning and execution, and a share of the run phase as agreed.

What it does not typically own: the regulated activity, the platform or the commercial decisions about the brand's product.

Questions to ask:

• Which fintech platforms have you built on, and what did you build?
• How do you plan and test the integration with our own systems?
• How do you build compliance considerations into the design, and who reviews them?
• What do you hand over at launch, and what continues to be your responsibility afterwards?

5. The brand

You. The brand owns the customer relationship and, in most programmes, the commercial case, the product decisions and the customer experience.

What it typically owns: the proposition, the journey, customer communications, the business case and, in practice, the decision on when the product is ready to launch.

What it cannot hand over: accountability for the customer experience. Even where a regulated partner carries the regulated activity, customers still experience the brand.

Questions to ask yourself:

• Who on our side is accountable for this programme, and do they have the authority to make decisions?
• Which of our own systems, such as identity, orders and support, will need to change?
• What will we measure, and what result would make us stop, change course or extend?

Regulated partner versus implementation partner

These two are confused more than any other pair, so it is worth being direct. They do different jobs, and one cannot substitute for the other.

• The regulated partner carries the regulated activity. It holds the permissions. It does not usually build the brand's product.
• The implementation partner builds and integrates the brand's product. It does not hold regulated permissions on the brand's behalf and should not be described as if it does.

Innovify is a technology partner, not a regulated financial institution, and the distinction applies to us as it does to any implementation partner. An implementation partner can design a programme so that it fits the regulated partner's requirements, and can build the controls and reporting those requirements call for. It cannot take the regulated partner's place.

Where responsibility blurs: the gaps that get missed

Most under-scoped programmes have the same handful of gaps. Each sits between two roles, which is why it is easy to assume the other party has it.

1. Integration into the brand's own systems. The platform exposes APIs. Somebody has to connect them to the brand's identity, order, customer and finance systems. This is typically the largest single piece of build work, and it is usually the piece least described in a platform's own materials.
2. The customer journey and wording. The regulated partner will have views on what customers must be told. The brand designs the journey. Somebody has to bring the two together.
3. Testing across the whole chain. A sandbox lets you test against the platform. It does not by itself test the brand's own systems, customer scenarios or the partner's approval steps.
4. Reconciliation and operations. Money moving through a programme has to be matched against the brand's records. Failures, refunds and exceptions need an owner and a process.
5. Support and change. Customer questions, incident handling and product changes continue after launch. Decide who covers each before launch, not after.

There is also a softer gap: inertia. Innovify's review of recent small-business payments research shared on LinkedIn in mid-October 2026 by a payments company, with a card network, and by another card network points to the feeling that "the current process works" as a brake on embedded payments adoption among software and platform businesses. We have seen only a summary, and our reading is medium-confidence. It suggests that integration quality matters more than stated enthusiasm, which is an argument for giving the build and integration work its own owner.

The regulatory position in outline

This is an outline for orientation. It is not legal advice and does not describe the position for your product or organisation. Read the FCA's own material and take advice on your specific circumstances.

UK financial services regulation attaches to activities, not to labels such as "embedded finance" or "implementation partner". The question to answer early is which party performs each regulated activity and under whose permissions. In Innovify's own tests of AI answer engines, the FCA's website was the most-cited source (23 citations across all prompts in the 28 September 2026 baseline). The topics that we flagged as needing a clear explanation anchored in FCA material were permissions, the agent and electronic money models, the payment services rules derived from PSD2 and data protection. Those are sensible places to start reading on fca.org.uk.

Two practical consequences follow. First, a role map is also a responsibility map, and it should be agreed in writing with your regulated partner before build begins. Second, if your product uses AI, an FCA speech on 19 October 2026 on finance in the age of AI was reported as applying existing frameworks, including the Consumer Duty and senior-manager accountability, to AI, rather than creating new rules for agents. Innovify's industry monitoring flagged that the primary source should be read before relying on any detail, and we would say the same to you.

How to use this guide: a launch in sequence

Here is one way to assign leads to each phase. Adjust it to your programme.

1. Proposition and scope. The brand leads, with the implementation partner and the regulated partner advising on feasibility.
2. Regulatory structure and contracts. The brand and the regulated partner lead, with legal advice. The platform and implementation partner contribute technical constraints.
3. Platform onboarding and sandbox access. The platform leads, with the implementation partner and programme manager.
4. Design and build. The implementation partner leads, with the brand owning product decisions.
5. Testing and approvals. The implementation partner leads testing. The regulated partner leads its own review and approval.
6. Launch. The brand decides, based on sign-offs from the regulated partner and the platform.
7. Run. Agree this in advance: the platform runs the platform, the regulated partner runs regulated oversight, and the brand and implementation partner split support, reconciliation and change according to the contract.

Where Innovify fits

Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We help mid to large businesses, including brands that are not financial companies, build AI-native products, modernise their technology stack and launch fintech products. We act as an implementation partner across multiple fintech platforms, and we design compliance in from day one.

In the roles above, we sit in the implementation role: design, build, integration, testing support and a defined share of the run phase. We are not a regulated financial institution, we do not hold the regulated activity and we do not give legal advice. We work alongside the platform and regulated partner your programme uses. If you are scoping an embedded finance launch, a useful first conversation is a plain list of the jobs and who will do each. You can read more about our embedded finance and digital wallet work, or get in touch and we will talk it through. Where a business wants to test a proposition before committing, Innovify AI Labs runs several proofs of concept in parallel, tests with real users and finishes with a business case ready for funding.

FAQ

Who builds embedded finance?

The brand's own team, an implementation partner or a mixture of both builds the product. The platform provider supplies the capabilities through APIs, and the regulated partner carries the regulated activity, but neither normally builds the brand's customer-facing product or connects it to the brand's systems. Decide who owns the build before you sign any contracts.

What is the difference between a regulated partner and an implementation partner?

A regulated partner holds the permissions needed for the regulated activity, while an implementation partner designs and builds the brand's product and integrates it with the brand's systems. They do different jobs, and one cannot stand in for the other. An implementation partner should never be described as holding regulated permissions on the brand's behalf.

What does a BaaS programme manager do?

A BaaS programme manager coordinates the work across the parties in a programme, keeping the plan, dependencies and decisions moving. The title is used inconsistently: in some programmes it sits inside the platform or regulated partner, in others it is a separate party or the brand's own team. Ask who holds the single plan and who can settle disputes between parties.

How do I find an embedded finance implementation partner in the UK?

Start from the jobs that need doing, then ask each candidate which of them they own and how. Useful questions include which platforms they have built on, how they test integration with your own systems, how they build compliance considerations into design and what they hand over at launch. Check their answers against the regulated partner's requirements, and take advice on your own circumstances.

Does the platform provider handle compliance?

Not on its own, and it varies by programme. The regulated partner carries the regulated activity, and the brand remains responsible for its own product and customer journey. The FCA's own material is the place to start, and this is not legal advice, so take advice for your circumstances.

Conclusion

An embedded finance launch is a set of jobs shared between several parties. The regulated partner carries the regulated activity, the platform provides the capabilities, the programme manager coordinates, the brand owns the proposition and the experience, and the implementation partner builds and connects the product. Brands get into difficulty when they treat the build and integration work as somebody else's job. Write the list of jobs down, agree who does each, and ask each party the questions above before you commit.